- ebXML Business Process Analysis Participants
- Introduction
- Goal and Objectives
- Business Collaboration Overview
- Business Process and Information Modeling
- The Analysis Process
- Relationship Between Business Process and Core Components
- Analysis Aids: Worksheets and Tools
- References
- Disclaimer
- Contact Information
- Appendix A Context Category—Meta Model Cross-reference
This chapter is from the book
This chapter is from the book
This chapter is from the book
7 The Analysis Process
7.1 Introduction
The process described below is intended to assist enterprises with the analysis of business process and business documents necessary for engaging in electronic commerce with other enterprises. The analysis of business processes is concerned with the elaboration of the higher-level processes that are required to conduct electronic business. The analysis of business information and documents activity identifies the business documents involved in the business transactions of the business processes. The outputs of the analysis activities are business-process-specifications and business document definitions.
The analysis effort is best carried out by a cross-functional analysis team of experts from IT, marketing, software development, business analysis, procurement, etc. When applying the analysis processes described herein, it is RECOMMENDED that the analysis team be staffed with people experienced in business process analysis or process re-engineering. It is also assumed that the analysts understand the challenges associated with business process analysis such as trying to analyze a business process with ill-defined requirements and objects.
Such a team is encouraged to use the ebXML Business Process Analysis Worksheets , UML modeling tools, or business process editors that provide similar functionality (see Section 10). The team will be able to develop an ebXML Business Process Specification that can be reviewed and verified by the entire enterprise, plus all necessary information to populate models based on the Meta Model and The Specification Schema. The analysis process supports analyzing new processes and process re-engineering as well as supporting the analysis and documentation of existing processes.
7.2 Recommended business process and business information analysis methodology and meta model
Analysis teams will use methodologies and meta models to specify the business processes in an electronic business community. An analysis methodology prescribes the overall process and sub-processes by which teams should proceed when defining business processes. The semantics of the meta model define the information that needs to be discovered and documented during the analysis process. Methodologies often include patterns to expedite the "design" of the model and help achieve common expression of similar concepts.
ebXML recommends (but does not require) that analysis teams use the methodology specified by the UN/CEFACT Modeling Methodology. If an alternative methodology is used, it is highly recommended that it be compliant with the UN/CEFACT Modeling Methodology so as to have the best opportunity of creating business process models that are compatible with business process models created using the UN/CEFACT Modeling Methodology.
ebXML requires that the business process and business information artifacts generated as a result of the analysis effort be conformant to the semantics defined by the UN/CEFACT Modeling Methodology eBusiness Process Meta Model and other semantics defined in the UN/CEFACT Modeling Methodology. This is necessary to give the best assurance of compatibility between business process models and model sub-components. This semantic conformance is necessary to meet the requirement that the models to be usable and re-usable, and be capable of being compared and contrasted. With models that are eBusiness Process Meta Model conformant, users and tools can generate ebXML Business Process Specification Schema XML instances of the model. Furthermore, the models can be freely shared among ebXML-compliant modeling tools, including, but not limited, to UML tools.
7.3 Business processes and business documents
At a very basic level, a business process is the means by which one or more activities are accomplished in the conduct of business. Within the business process there could be one or more collaborations, each consisting of one or more transactions. Figure Figure 7.3-1, below is a simple representation of a business process and an illustration of the types of business processes which might be needed between Customer and Supplier to complete an order for materials.
)
FIGURE 7.3-1 Business Process, Collaborations, and Transactions Conceptual View
Business document definitions are the specifications for the business document schemas and the information components that compose the business document and contained information components. A schematic representation of a business document can be seen in Figure 7.3-2, below.
)
FIGURE 7.3-2 Document Conceptual View
Documents such as Purchase Orders, Invoices, etc., exist at the business process level and are exchanged in business transactions by means of placing documents into document envelopes. Documents are put into document envelopes. They are addressed with the business identifier (e.g. DUNS number) of the recipient and sender. This is analogous to the "Attention:" line on a standard mailing address. A document envelope is placed into a message envelope and is exchanged between business service interfaces. The message envelope might be addressed with the URN of the destination business service interface. Messages have timeouts and other transaction control mechanisms associated with them. Message envelopes are placed into a transport/routing envelope for low level transmission across an e-business network. The target address on message envelope might be the URL of the destination's message-in-box service. A logical view of the nested envelope structure is shown in Figure 7.3-4.
)
FIGURE 7.3-4 Messaging and Enveloping Conceptual View
7.4 The analysis process
The high-level activities related to business process and business information analysis is shown in Figure 7.4-1.
)
FIGURE 7.4-1 Activities Related to Analyzing Business Processes and Business Information
As a first step, it is useful to develop a Statement of Intent, which clearly identifies the scope and purpose of the analysis activity and serves to focus the efforts of the team.
The next step involves the gathering of requirements based on the Statement of Intent. Marketing and product management teams often perform this requirement gathering activity. The output of this activity may be a marketing requirements document or a product requirements document. In any case, the result SHOULD be a set of clearly defined requirements for the analysis.
After the requirements have been defined and agreed, the actual analysis can begin. As illustrated by Figure 7.4-2, there can be many inputs to and aspects of the process required to produce the desired output. Inputs to the analysis process can come from requirements, customers and partners, standards, other existing models, and domain experts. Requirements MAY be in the form of product requirement documents, statements of work, customer change requests, etc. Customers, partners, and domain experts provide their input when they are being consulted during the requirement elaboration process and during documentation reviews. Existing standards (cross industry and industry specific) and other existing models (e.g. EDI message implementation guides) are also consulted.
)
FIGURE 7.4-2 Analyze Business Processes and Business Information
The controls6 for the analysis activities are the methodology (UMM), Meta Model, patterns, and other analysis techniques. These controls specify the process and information model REQUIRED for the business process and information analysis process to produce correct outputs. Patterns include transaction patterns and collaboration patterns.
The mechanisms for the analysis activities are the analysts, tools, and reviewers. Analysts are the people who are defining the processes and documents based on the Meta Model.
One of the key tools to assist with the analysis is the ebXML Business Process Analysis Worksheets, discussed in Section 9, Analysis Aids: Worksheets and Tools.
The Analyze Business Processes and Business Information Activity can be logically partitioned into two separate but interrelated activities: analyze business processes and analyze business information, shown here in Figure 7.4-3:
)
FIGURE 7.4-3 Analyze Business Process and Business Information Activities
The overall analysis process will generally be more effective if the analysis of the business processes and associated business information happens at the same time. Business information analysts will need to be familiar with the business process and will want to be co-participants during the business process analysis. Otherwise, the business information analysts MAY need to re-interview domain experts, customers, and partners, to get clarification on matters that could have been more effectively addressed during the analysis of the business process. Furthermore, business information analysts will likely have the background that will help identify the key business information elements that effect the business processes.
The analyze business processes activity can proceed along different paths depending on the focus of the modeling effort. For example, if the goal is to establish a business reference model for an industry, the process will likely proceed as discussed in the UMM, from the beginning to the end of the UMM documentation. However, if the effort is to model existing X12 or EDIFACT documents and their associated business processes, the process will more naturally start with the elaboration of business transaction and roles. In this case, there is usually a strong implicit understanding of the associated business process by domain experts. Business process analysis can be partitioned into four high-level activities7 as shown in Figure 7.4-4:
)
FIGURE 7.4-4 Analyze Business Process Activities
Once the business process and business information analysis is complete, the next activities are the Develop Schemas activity and the Implement Services activity. Development of schemas involves the creation of the document and information component schemas (XML schema/DTD or EDI message and data element definitions) and sample documents. Implementing the service/application involves coding or configuring business service interfaces and services/applications (such as back-end systems) in accordance to the business process definitions and the document schemas.
Once the analysis is complete and the business processes and documents have been full defined and developed, the specifications SHOULD be registered in a Business Library, e.g., an ebXML Registry. A Business Library can be either generic or business domain specific. A business library is a repository of business process specifications and business information objects within an industry or shared by multiple industries. There will be many business libraries, pubic and private, moderated and non-moderated. A public library is one that is available for public access. Typically the content of these will be owned by standard's efforts, such as ebXML or UN/EDIFACT, and large electronic communities (such as automotive marketplaces). A private library is one that does not have public access. These are for private exchanges where the participating parties do not wish to disclose the nature of their business processes. Obviously, the public access business libraries will be the most useful in promoting interoperability between trading partners in different electronic communities. For example, it MAY be necessary for the e-business systems of a trading partner in the automotive community to access business processes registered in a chemical community.
A moderated business library is one whose content is administered by some organization, such as standards body or electronic community. Business process and business information specifications WILL be submitted to a working group or other supervising activity for the controlled business library. The working group WILL review the submissions for quality and accuracy. The specifications MAY be put to public or community voting for approval. Approved specifications are then registered in the business library. At such time, key model ele-ments - such as Business Process, Business Collaboration, and Business Transaction - are officially assigned their identifiers according to the Business Identifier Naming Scheme. These identifiers facilitate re-use and interoperability by providing unique identifiers that can be referenced by business process specifications, Core Component's contextual categories, CPPs and CPAs. Moderated business libraries will typically have more credibility than ones that are not moderated. A business library that is not moderated will allow anyone in the community to register specifications. The quality and accuracy of the specifications will be suspect. However, these types of libraries could result in significant business process specifications. Business process specifications that get significant usage will become more widely adopted over time.
The format in which these specifications are stored is an important consideration, as the key to an enterprise's ability to utilize these specifications in their analysis process is that they are stored in a format that is interoperable with business modeling tools. It would appear RDF offers the opportunity to encapsulate business process models during the analysis, design and 'record for posterity' stage in business process life cycles. In addition, the use of RDF will also help achieve one of the original goals of UN/CEFACT for ebXML, which was assuring that model specifications could be interchanged between standards organizations using a controlled vocabulary for metadata classification and categorization, so as to further promote business process modeling globally and to promote reuse of common solutions. The advantage of RDF over other formats such as XMI is that RDF can be restricted by use of namespaces to a specific problem domain, whereas others typically conform to the more general UML domain. The ability to express a metastructure in RDF and validate it means better control on the applicability of model content. When using models in a constricted domain like B2B, it is attractive to be able to validate model content according to a metastructure. From a business information standpoint, It is particularly useful that RDF allows association to BusinessAction elements, i.e., placing a message in the context of a business process.
A summary of the entire analysis effort and its results is shown in Figure 7.4-5 below:
)
FIGURE 7.4-5 Modeling, Conversion to XML, and Registration Activity
Flow
The overall effort starts with the analysis and modeling of business processes and business information. The UMM Methodology can be employed directly or indirectly through the use of the Business Process Analysis Worksheets or business process editors. Re-usable business process and information components from Business Libraries are applied, as well as collaboration and transaction patterns. The analysis effort results in business process models and business information models that are based on the Meta Model. The models are then converted into XML based Business Process Specifications and Information/Document schemas according to a set of production rules. The specifications and schemas are then registered and stored in Business Libraries for re-use and reference by CPAs.