Business Process and Business Information Analysis Overview v1.0

1 Business Process and Business Information
2 Analysis Overview v1.0

3
4 Business Process Team

5 11 May 2001
6
7 1 Status of this Document

8 This Technical Report document has been approved by the Business Process Project Team and
9 has been accepted by the ebXML Plenary.
10 This document contains information to guide in the interpretation or implementation of ebXML

11 concepts.
12 Distribution of this document is unlimited.
13 The document formatting is based on the Internet Societys Standard RFC format.
14 This version:
15 http://www.ebxml.org/specs/bpOVER.pdf
16 Latest version:
17 http://www.ebxml.org/specs/bpOVER.pdf
18
19
Business Process and Business Information Analysis Overview Page 1 of 40
Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

ebXML BP/CC Analysis Team March 2001
20 2 ebXML Business Process Analysis Participants

21 Business Process Project Team Co-Leads
22 Paul Levine, Telcordia
23 Marcia McLure, McLure-Moynihan, Inc.
24 We would like to recognize the following for their significant participation to the development of this
25 document.
26 Editors:
27 Randy Clark, Baker Hughes, Inc
28 Brian Hayes, Commerce One
29 Contributors:
30 James Bryce Clark, Spolin Silverman & Cohen LLP
31 Jim Clark, I.C.O.T.
32 Charles Fineman, Arzoon.com
33 Bob Haugen, Logistical Software LLC
34 Stephan de Jong, Philips International B.V.
35 Larissa Leybovich, Vitria Technology
36 Paul Levine, Telcordia
37 Bill McCarthy, Michigan State University
38 Marcia McLure, McLure-Moynihan, Inc.
39 Karsten Riemer, Sun Microsystems
40 Nita Sharma, IONA Technologies
41 David Welsh, Nordstrom.com

42 3 Table of Contents
43 1 Status of this Document............................................................................................. 1
44 2 ebXML Participants.................................................................................................... 2
45 3 Table of Contents....................................................................................................... 3
46 4 Introduction............................................................................................................... 4
47 4.1 Summary........................................................................................................... 4
48 4.2 Scope and Audience........................................................................................... 4
49 4.3 Related Documents............................................................................................. 5
50 4.4 Document Conventions........................................................................................ 5
51 5 Goal and Objectives................................................................................................... 7
52 5.1 Goal.................................................................................................................. 7
53 5.2 Objectives .......................................................................................................... 7
54 5.3 Caveats and Assumptions .................................................................................... 7
55 6 Business Collaboration Overview............................................................................... 8
56 6.1 ebXML Electronic Business Collaboration............................................................... 8
57 6.2 Economic Elements in Business Processes.......................................................... 10
58 6.3 ebXML Design Time and Runtime Reference Model .............................................. 13
59 7 Business Process and Information Modeling............................................................ 15
60 7.1 Overview ......................................................................................................... 15
61 7.2 Business Process and Information Meta Model ..................................................... 15
62 8 The Analysis Process .............................................................................................. 16
63 8.1 Introduction...................................................................................................... 18
64 8.2 Recommended Business Process and Business Information Analysis Methodology
65 and Meta Model..18
66 8.3 Business Processes and Business Documents.................................................... 188
67 8.4 The Analysis Process........................................................................................ 22
68 9 Relationship Between Business Process and Core Components .............................. 28
69 9.1 Introduction...................................................................................................... 28
70 9.2 Business Library and Business Information Objects ............................................... 28
71 9.3 Core Components Analysis................................................................................ 30
72 9.4 Core Component Contextual Classification........................................................... 30
73 9.5 Context and Common Business Processes .......................................................... 31
74 10 Analysis Aids: Worksheets and Tools ...................................................................... 32
75 10.1 Analysis Worksheets and Guidelines ................................................................... 32
76 10.1.1 Analysis Worksheets and Editor..32
77 10.1.2 Business Process Editor and Document Editor.33
78 11 References34
79 12 Disclaimer............................................................................................................... 35
80 13 Contact Information................................................................................................. 35
81 Appendix A: Context Category-Meta Model Cross-Refere nce......................................... 36
82 Copyright Statement .. 34

83 4 Introduction
84 4.1 Summary
85 The vision of ebXML is to create a single global electronic marketplace where enterprises of any size
86 and in any geographical location can meet and conduct business with each other through the
87 exchange of XML based messages. ebXML enables anyone, anywhere, to do electronic business with
88 anyone else, however, it is anticipated that compliance with and adoption of the various ebXML
89 components will be incremental, over time.
90 In order for enterprises to conduct electronic business with each other, they must first discover each
91 other and the products and services they have to offer. They then must determine which business
92 processes and documents are necessary to obtain those products and services. After that, they need
93 to determine how the exchange of information will take place and then agree on contractual terms and
94 conditions. Once all of this is accomplished, they can then exchange information and products/services
95 according to these agreements.
96 To facilitate this, ebXML provides an infrastructure for data communication interoperability, a semantic
97 framework for commercial interoperability, and a mechanism that allows enterprises to find, establish a
98 relationship, and conduct business with each other.
99 Data communication interoperability is ensured by a standard message transport mechanism with a

100 well-defined interface, packaging rules, and a predictable delivery model, as well as an interface to
101 handle incoming and outgoing messages at either end.
102 Commercial interoperability is provided by means of a specification schema for defining business
103 processes and a core components and context model for defining Business Documents. ebXML
104 recommends a methodology and provides a set of worksheets and guidelines for creating those
105 models. A business library (catalog) of business process and information models promotes business
106 efficiency by encouraging reuse of business processes or parts of predefined business processes.
107 In order for the actual conduct of business to take place, ebXML provides a shared repository where
108 businesses can discover each others business offering by means of partner profile information, a
109 process for establishing an agreement to do business (Collaboration Protocol Agreement, or CPA), and
110 a shared repository for company profiles, business-process-specifications, and relevant business
111 messages.
112 4.2 Scope and Audience
113 This document deals with aspects of commercial interoperability, specifically the process by which
114 enterprises can analyze, identify, and define those business processes and business documents
115 necessary for the conduct of electronic business with other enterprises, within the ebXML framework.
116 The audience for this document will typically comprise representatives of any of a number of different
117 functional areas within an enterprise, including marketing, business development, executive
118 management, procurement, software development, IT, etc.

119 4.3 Related Documents
120 [ebTA] ebXML Technical Architecture Specification. Version 1.0.4. 16 February 2001. ebXML
121 Technical Architecture Project Team.
122 UN/CEFACT Modelling Methodology. CEFACT/TMWG/N090R9. February 2001. UN/CEFACT

123 Technical Modeling Working Group.
124 Information Technologies - Open-EDI Reference Model. ISO/IEC 14662:1997(E). International

125 Organization for Standardization (ISO) and International Electrotechnical Commission (IEC).
126 [bpWS] ebXML Business Process Analysis Worksheets and Guidelines v1.0. May 11, 2001. ebXML
127 Business Process Project Team.
128 [bpPROC] ebXML Catalog of Business Processes. Version 1.0. Date May 11, 2001. ebXML Business
129 Process Project Team.
130 [bpPATT] ebXML Business Process and Simple Negotiation Patterns. Version 1.0, May 11 2001.
131 ebXML Business Process Project Team.
132 [ebBPSS] ebXML Business Process Specification Schema. Version 1.0 May 11 2001. Context/Meta
133 Model Group of the CC/BP Joint Delivery Team.
134 [ebCCD&A] ebXML Methodology for the Discovery and Analysis of Core Components. V1.0, May 11
135 2001. ebXML Core Components Project Team.
136 [enCNTXT] ebXML The role of context in the re-usability of Core Components and Business Processes
137 ebXML Core Components. Version 1.0, May 11 2001. ebXML Core Components Project Team.
138 [ebCCDOC} ebXML specification for the application of XML based assembly and context rules. Version
139 1.0, May 11 2001. ebXML Core Components.
140 [ebGLOSS] ebXML TA Glossary. Version 1.0, May 11 2001. Technical Architecture Project Team.
141 [ebRIM] ebXML Registry Information Model. Version 1.0, 11 May 2001. ebXML Registry Project Team.
142 [ebRS] ebXML Registry Services. Version 1.0, May 11 2001. ebXML Registry Project Team.
143 [ebCPP] ebXML Collaboration-Protocol Profile and Agreement Specification. Version 1.0, May 11 2001
144 [secRISK] ebXML Technical Architecture Risk Assessment Report. Version 1.0, May 11 2001
145 4.4 Document Conventions
146 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHALL NOT,
147 RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as
148 described in RFC 2119 [Bra97].
149 When the term Meta Model is used, it refers to the e-Business Process Meta Model as defined in the
150 UN/CEFACT Modeling Methodology .

151 When the term Specification Schema is used, it refers to the Meta Model and its DTD form as defined
152 in the ebXML Business Process Specification Schema .
153

153 5 Goal and Objectives

154 5.1 Goal
155 The goal of this document is describe the analysis process in such a way that the audience will have a
156 general understanding of how to conduct business process and documentation definition and
157 identification, within the ebXML framework, and how that relates to the overall development of
158 electronic business relationships with other enterprises.
159 5.2 Objectives
160 In order to accomplish the goal, as set for in 5.1 above, this document will:
161 Provide an overvi ew of electronic business collaboration
162 Discuss the role and use of business process modeling
163 Describe the analysis process
164 Discuss economic elements in Business Processes
165 Establish the relationship of core components to business processes
166 5.3 Caveats and Assumptions
167 The intent of this document is to provide a general overview of business process and business
168 document analysis. It is not intended to be a specification.
169 It is assumed that the audience has some general understanding of the ebXML framework and is
170 particularly familiar with the ebXML Technical Architecture Specification.
171 To better understand the concepts of economic elements in business processes, it is helpful to have a
172 familiarity with the Resource-Event-Agent (REA) Enterprise Ontology.
173

173 6 Business Collaboration Overview

174 6.1 ebXML Electronic Business Collaboration
175 The strength of the ebXML technical architecture is that it provides a framework for electronic business
176 collaboration. The architecture enables businesses to work together to specify business process,
177 discover each other, negotiate collaboration agreements, and execute business processes. The
178 significant activities implementing and executing this ebXML electronic business collaboration are
179 shown in Figure 6.1-1.
180 The overall process starts with Process Definition, utilizing Business Process and Business Document
181 Analysis and logically progresses to Partner Discovery, Partner Sign-Up, Electronic Plug-in, Process
182 Execution, Process Management, Process Evolution.
183 Process Definition: Utilizing Business Process and Business Document Analysis, an enterprise
184 determines and defines which processes will be necessary for electronic commerce. In some cases,
1 2
185 a community of trading partners for example AIAG or RosettaNet may define the business
186 processes to be used in the community. These business processes are defined according to a well
187 known model and described in agreed upon formats.
188 Partner Discovery: Enterprises identify potential electronic trading partners through a search of
189 company profiles held in ebXML compliant registries.
190 Partner Sign-up: Trading partners then negotiate agreements that will serve as the terms and
191 conditions of their collaboration.
192 Electronic Plug-in: The trading partners then configure their electronic interfaces and business
193 services according to their agreements.
194 Process Execution: Businesses exchange documents and complete commercial transactions in
195 accordance with their agreements and carry out the agreed upon business processes.
196 Process Management: The business processes defined in the Process Definition phase and
197 agreed to in the Partner Sign-Up phase are monitored for compliance with trading partner
198 agreements and successful execution.
199 Process Evolution: Participants in the electronic marketplace will evaluate their existing
200 processes, improve them through process re-engineering, and create new processes to meet the
201 needs of the market.
202
1
The AIAG is the Automotive Industry Action Group (http://www.aiag.org/).
2
RosettaNet is a consortium of major Information Technology, Electronic Components and Semiconductor
Manufacturing companies (http://www.rosettanet.org/).

Process
Definition
Process Partner
Evolution Discovery
Electronic
Business
Process Collaboration Partner
Management Sign-Up
Process Electronic
Execution Plug-in
203
204
205 Figure 6.1-1, ebXML Business Collaboration Process
206 The following table shows the relationship between ebXML Project Teams, significant ebXML
207 documents, and the activities in Figure 6.1-1:
Activity ebXML Project Team ebXML Document
3
Process Definition Business Process, UN/CEFACT Modeling Methodology , ebXML
CC/BP Analysis sub- Business Process Specification Schema ,
team, Registry Business Process and Business Document
Analysis Overview, ebXML Business Process
Analysis Worksheets and Guidelines , ebXML
Catalog of Business Processes, ebXML The role
of context in the re-usability of Core Components
and Business Processes, and ebXML
specification for the application of XML based
assembly and context rules, ebXML Registry
Services, ebXML Registry Information Model
Partner Discovery Technical Architecture, ebXML Tec hnical Architecture Specification,

Trading Partner, Registry Collaboration-Protocol Profile and Agreement
Specification, ebXML Registry Services, ebXML
Registry Information Model.
208
3
The UMM is not an ebXML document; however, it is a significant document which is administered by the UN/CEFACT.

208
Partner Sign-up Trading Partner, Collaboration-Protocol Profile and Agreement
Technical Architecture Specification, and Business Collaboration
Patterns.
Electronic Plug-in Technical Architecture, Collaboration-Protocol Profile and Agreement

Trading Partner Specification, ebXML Technical Architecture
Specification, Information Technologies - Open-
EDI Reference Model [ISO14662E], Transport,
Routing and Packaging Message Services
Process Execution Trading Partner, Collaboration-Protocol Profile and Agreement

Technical Architecture, Specification, ebXML Technical Arc hitecture
Transport, Routing and Specification, Information Technologies - Open-
Packaging (TRP) EDI Reference Model [ISO14662E], Transport,
Routing and Packaging Message Services
Process None Information Technologies - Open-EDI Reference

Management Model [ISO14662E] (Section Open-EDI Support
4
Infrastructure) , Transport, Routing and
Packaging Message Services,
Process Evolution None None not in scope of ebXML.
209
210 6.2 Economic Elements in Business Processes
211 The most common ebXML business collaborations will be resource exchanges between companies:
212 buying and selling products and services. The most common collaboration pattern for these
213 exchanges will probably be order-fulfillment -payment. The ebXML Meta Model provides Economic
214 Modeling Elements for specifying these collaborations in business and economic terms rather than in
215 technical terms. The Economic Elements include:
216 Economic Contracts: ranging from simple orders to long-term component contracts
217 Economic Resources: including products, services, and cash
218 Economic Events: including product or service deliveries, and payments
219 Partner Types: including the parties and roles authorized to commit and exchange resources in
220 business collaborations
221 Using these elements, it will be possible to determine in a business collaboration:
222 When an Economic Contract is formed
223 When an Economic Event SHOULD be recognized
4
The Information Technologies - Open-EDI Reference Model [ISO14662E] is not an ebXML document. It is a
significant document for the UMM and the ebXML Technical Architecture Specification.

224 When an Economic Resource or a claim to a resource SHOULD be recognized in accordance with
225 generally accepted accounting principles (GAAP)
226 Whether or not a delivery fulfills a commitment
227 What events MAY follow if a delivery does not fulfill an order
228 When an exchange is complete from a business point of view
229 Many other aspects of typical business relationships
230 Using the ebXML Economic Modeling Elements, these typical business collaboration patterns can be
5
231 designed once and re-used in many situations . Figure 6.2-1 provides an overview of the REA
232 economic elements in a typical product-oriented Order-Fulfillment Business Process.
233 The above concepts and relationships are specified in the UMM, but there is no programmatic support
234 for them in the first version of the ebXML Business Process Specification Schema [BPSS]. They could,
235 however, be implemented in business collaboration management software based on the UMM Meta
236 Model.
237 The Business Process is composed of several Business Collaborations, taken directly from the Catalog
238 of Common Business Processes [CCBP] and other business libraries.
239 Query Product Information receives Product Master or Catalog information about the products that
240 can be ordered. In REA, products are Economic Resource Types.
241 Distribute Inventory Report receives information about products that are currently available. This
242 purpose could also be accomplished through a Query Availability process. In REA, inventory is an
243 Economic Resource. Each inventory element is typed by a Product Master (Economic Resource
244 Type).
245 Create Order forms a Purchase Order (an Economic Contract) composed of Line Items (Economic
246 Commitments). Each Line Item reserves the committed quantity of the ordered product type, due at
247 the committed date and time.
248 Notify of Shipment results in a Shipment (an Economic Event) which SHOULD fulfill one or more of
249 the Purchase Order Line Items.
250 Process Payment results in a Payment (an Economic Event) which pays for the Shipment (the
251 REA "duality" relationship).
252 When all of the Line Items have been fulfilled, and all the Shipments have been paid, the Business
253 Process is complete. The contract terms in this simple example specified "pay on receipt". Otherwise
254 the business process might have another step, e.g. Process Invoice.
255 If something goes wrong, and the shipments do not fulfill the commitments, and the payments do not
256 compensate for the shipments, or some economic event is late or otherwise incorrect, the problem can
257 be expressed using the REA concepts and relationships explained above.
5
The ebXML Economic Modeling Elements are based on the Resource-Event-Agent (REA) Enterprise Ontology -- a
well accepted, well reviewed, and published economic modeling framework for business enterprises of all sizes. REA
component descriptions are available at http://www.reamodel.org/.

258
Order-Fulfillment
<<Business
Process>>
Query Product Product Master

Information <<Economic
<<Business Resource
Collaboration>> Type>>
type
Distribute
Inventory
Inventory Report
<<Economic
<<Business
Resource>>
Collaboration>>
reserves
Create Order forms Purchase Order Line Item

<<Business <<Economic <<Economic
Collaboration>> Contract>> Commitment>>
fulfills
Notify of
resultsIn Shipment
Shipment
<<Economic
<<Business
Event>>
Collaboration>>
duality
Process
resultsIn Payment
Payment
<<Economic
<<Business
Event>>
Collaboration>>
259
260 Figure 6.2-1, overview of the REA economic elements in a typical product-oriented Order-Fulfillment Business Process.
261

262 6.3 ebXML Design Time and Run Time Reference Model
263 In order to put Business Process and Business Information Analysis on its proper context, it is useful to
264 consider the ebXML Technical Architecture. ebXML Technical Architecture is comprised of two basic
265 components: Design Time and Run Time. Business Process and Business Information Analysis is a
266 part of Design Time component. The Design Time component deals with the procedures for creating
267 an application of the ebXML infrastructure, as well as the actual discovery and enablement of ebXML-
268 related resources required for business transactions to take place. Business Process and Business
269 Information Analysis is one way accomplishing the Design Time component of the Technical
270 Architecture.
271 The Run Time component covers the execution of an ebXML scenario with the actual associated
272 ebXML transactions.
273 The Design Time and Run Time components of the ebXML Technical Architecture are found in Figure
274 6.3-1.
Business Business Core/Domain

Design Time
Process Documents Components
Business Register &

Library Registry/ Discover
Repository
Collaboration Collaboration
Protocol Protocol
Profile CP Agreement Profile
Business Business
Run Time
Service Transport Service

Interface Interface
Package
Business Business
Services/Apps Services/Apps
ebXML CCBP Analysis 88
275
276 Figure 6.3-1, ebXML Design Time and Runtime Reference Model
277 The Design Time artifacts enable the Run Time systems to execute the agreed business processes.
278 Business processes and business documents are defined during the Business Process and Business
279 Information Analysis activity. Core Components and Domain Components are the reusable information
280 building blocks used to specify document content and structure. They can be identified and defined
281 using the ebXML Methodology for the Discovery and Analysis of Core Components. The Business
282 Process Specifications for the defined Business Processes and Business Documents are stored and
283 registered in Business Libraries which contain catalogs of Business Processes and Business

284 Information Objects (document components). These catalogs reside in ebXML compliant
285 registries/repositories.
286 The business process modeling results in an ebXML Business Process Specification, which MAY be
287 referenced in the Collaboration Protocol Profiles (CPPs), of businesses and form the basis for
288 Collaboration Protocol Agreements (CPAs) established between business parties. Ultimately, the
289 business processes specified in the CPAs drive the business service interfaces to execute those
290 processes and send the REQUIRED documents.

291 7 Business Process and Information Modeling

292 7.1 Overview
293 Business process models define how business processes are described. Business processes
294 represent the verbs of electronic business and can be represented using modeling tools. The
295 specification for business process definition enables an enterprise to express its business processes so
296 that they are understandable by other enterprises. This enables the integration of business processes
297 within an enterprise or between enterprises.
298 Business process models specify business processes that allow business part ners to collaborate.
299 While business practices vary from one organization to another, most activities can be decomposed
300 into business processes that are more generic to a specific type of business. This analysis, utilizing
301 business modeling, will identify business processes and business information Meta Models that can
302 likely be standardized. The ebXML approach looks for standard reusable components from which to
303 construct interoperable processes.
304 7.2 Business Process and Information Meta Model
305 The UMM Meta Model is a mechanism that allows Trading Partners to capture the details for a specific
306 business scenario using a consistent modeling methodology. A Business Process describes in detail how
307 Trading Partners take on roles, relationships and responsibilities to facilitate interaction with other Trading
308 Partners in shared collaborations. The interaction between roles takes place as a choreographed set of
309 business transactions. Each business transaction is expressed as an exchange of electronic Business
310 Documents. Business Documents MAY be composed from re-useable Business Information Objects (see
311 Relationships to Core Components under 8.2.3 Interfaces below). At a lower level, Business Processes
312 can be composed of re-useable Core Processes, and Business Information Objects can be composed of re-
313 useable Core Components.
314
315 The UMM Meta Model supports a set of business process viewpoints that provide a set of semantics
316 (vocabulary) for each viewpoint and forms the basis of specification of the artifacts that are recommended
317 to facilitate Business Process and information integration and interoperability.
318
319 An additional view of the UMM Meta Model, the ebXML Business Process Specification Schema , is also
320 provided to support the direct specification of the set of elements required to configure a runtime system in
321 order to execute a set of ebXML business transactions. By drawing out modeling elements from several of
322 the other views, the ebXML Business Process Specification Schema forms a semantic subset of the UMM
323 Meta Model. The ebXMLBusiness Process Specification Schema is available in two stand-alone
324 representations, a UML version, and an XML version.
325
326 The only part of the UMM Meta Model that is currently mandatory for use in ebXML is the semantic subset
327 represented by the ebXML Business Process Specification Schema. As UN/CEFACT finalizes and evolves
328 the UMM, it is anticipated that other parts of the UMM Meta Model may also become mandatory.
329
330
331
332
333
334

335
336 The relationship between the UMM Meta Model and the ebXML Business Process Specification Schema
337 can be shown as follows:
338
UMM Meta Model
Semantic
Subset
Specification Schema Specification Schema

(UML) (XML)
339 Figure 7.2-1 UMM Meta Model and the ebXML Business Process Specification Schema
340
341
342

342 The ebXML Business Process Specification Schema supports the specification of business transactions and
343 the choreography of business transactions into Business Collaborations. Each Business Transaction can be
344 implemented using one of many available standard patterns. These patterns determine the actual exchange
345 of Business Documents and signals between Trading Partners to achieve the required electronic
346 transaction. To help specify the patterns the UMM provides a set of standard patterns, and the ebXML
347 Business Process Specification Schema provides a set of modeling elements in support of those patterns.
348 The ebXML specification of a Business Process is referred to as a Business Process Specification. The
349 Business Process Specification serves as primary input for the formation of Collaboration Protocol Profiles
350 (CPPs) and Collaboration Protocol Agreements (CPAs).
351
352 This can be shown as follows:
353
354 Figure 7.2-2 Relationship of Business Process Specification and CPP/CPA
355
356 One of the key benefits of using a single consistent modeling methodology is that it is possible to compare
357 models to avoid duplication of existing Business Processes.
358
359 To further facilitate the creation of consistent Business Process and information models, ebXML will
360 define a common set of Business Processes in parallel with a Core Library. It is possible that users of the
361 ebXML infrastructure may wish to extend this set or use their own Business Processes.
362

362 8 The Analysis Process

363 8.1 Introduction
364 The process described below is intended to assist enterprises with the analysis of business process
365 and business documents necessary for engaging in electronic commerce with other enterprises. The
366 analysis of business processes is concerned with the elaboration of the higher-level processes that are
367 required to conduct electronic business. The analysis of business information and documents activity
368 identifies the business documents involved in the business transactions of the business processes.
369 The outputs of the analysis activities are business-process-specifications and business document
370 definitions.
371 The analysis effort is best carried out by a cross-functional analysis team of experts from IT, marketing,
372 software development, business analysis, procurement, etc. When applying the analysis processes
373 described herein, it is RECOMMENDED that the analysis team be staffed with people experienced in
374 business process analysis or process re-engineering. It is also assumed that the analysts understand
375 the challenges associated with business process analysis such as trying to analyze a business process
376 with ill-defined requirements and objects.
377 Such a team is encouraged to use the ebXML Business Process Analysis Worksheets , UML modeling
378 tools, or business process editors that provide similar functionality (see Section 10). The team will be
379 able to develop an ebXML Business Process Specification that can be reviewed and verified by the
380 entire enterprise, plus all necessary information to populate models based on the Meta Model and The
381 Specification Schema. The analysis process supports analyzing new processes and process re-
382 engineering as well as supporting the analysis and documentation of existing processes.
383 8.2 Recommended Business Process and Business Information Analysis

384 Methodology and Meta Model
385 Analysis teams will use methodologies and meta models to specify the business processes in an
386 electronic business community. An analysis methodology prescribes the overall process and sub-
387 processes by which teams should proceed when defining business processes. The semantics of the
388 meta model define the information that needs to be discovered and documented during the analysis
389 process. Methodologies often include patterns to expedite the design of the model and help achieve
390 common expression of similar concepts.
391
392 ebXML recommends (but does not require) that analysis teams use the methodology specified by the
393 UN/CEFACT Modeling Methodology. If an alternative methodology is used, it is highly recommended
394 that it be compliant with the UN/CEFACT Modeling Methodology so as to have the best opportunity of
395 creating business process models that are compatible with business process models created using the
396 UN/CEFACT Modeling Methodology.
397
398 ebXML requires that the business process and business information artifacts generated as a result of the
399 analysis effort be conformant to the semantics defined by the UN/CEFACT Modeling Methodology
400 eBusiness Process Meta Model and other semantics defined in the UN/CEFACT Modeling Methodology.
401 This is necessary to give the best assurance of compatibility between business process models and model
402 sub-components. This semantic conformance is necessary to meet the requirement that the models to be
403 usable and re-usable, and be capable of being compared and contrasted. With models that are eBusiness
404 Process Meta Model conformant, users and tools can generate ebXML Business Process Specification
405 Schema XML instances of the model. Furthermore, the models can be freely shared among ebXML-
406 compliant modeling tools, including, but not limited, to UML tools.

407 8.3 Business Processes and Business Documents
408 At a very basic level, a business process is the means by which one or more activities are
409 accomplished in the conduct of business. Within the business process there could be one or more
410 collaborations, each consisting of one or more transactions. Figure 8.3-1, below is a simple
411 representation of a business process and an illustration of the types of business processes which might
412 be needed between Customer and Supplier to complete an order for materials.
Business Process
Business ... Business
Process Process Create Long Term Contract
Collaboration
Transaction Forecast Component
Requirements
Transaction
Send Planning Document
...
Supplier
Customer
Collaboration Place Order
Ship Materials
Arrange Payment
413
414 Figure 8.3-1, Business Process, Collaborations, and Transactions Conceptual View
415

415 Business document definitions are the specifications for the business document schemas and the
416 information components that compose the business document and contained information components.
417 A schematic representation of a business document can be seen in Figure 8.3-2, below.
Document Example: Purchase Order

Information Component
Order
Information Component OrderHeader
...
...
Information Component OrderIssueDate
BuyerParty
... ...
Information Component
OrderDetail
...
OrderDetail
OrderSummary
418
419 Figure 8.3-2, Document Conceptual View
420

420 Documents such as Purchase Orders, Invoices, etc., exist at the business process level and are
421 exchanged in business transactions by means of placing documents into document envelopes.
422 Documents are put into document envelopes. They are addressed with the business identifier (e.g.
423 DUNS number) of the recipient and sender. This is analogous to the Attention: line on a standard
424 mailing address. A document envelope is placed into a message envelope and is exchanged between
425 business service interfaces. The message envelope might be addressed with the URN of the
426 destination business service interface. Messages have timeouts and other transaction control
427 mechanisms associated with them. Message envelopes are placed into a transport/routing envelope
428 for low level transmission across an e-business network. The target address on message envelope
429 might be the URL of the destinations message-in-box service. A logical view of the nested envelope
430 structure is shown in Figure 8.3-4.
Transport/Routing Envelope
Message Envelope
Document Envelope
Business Process
Document
...
Business Service Interface

Document
Transport/Routing Protocols
431
432 Figure 8.3-4, Messaging and Enveloping Conceptual View

433 8.4 The Analysis Process
434 The high-level activities related to business process and business information analysis is shown in
435 Figure 8.4-1.
Statement Of
Intent
Requirements
Gather Documents
Require- Business Process
ments Analyze Definition,
Business Document Definition
Process and
Business
Information Develop Document
Schemas Schema, XML
Samples
Implement
Service/
Business Process
Application
Definition
436
437 Figure 8.4-1, Activities Related to Analyzing Business Processes and Business Information
438 As a first step, it is useful to develop a Statement of Intent, which clearly identifies the scope and
439 purpose of the analysis activity and serves to focus the efforts of the team.
440 The next step involves the gathering of requirements based on the Statement of Intent. Marketing and
441 product management teams often perform this requirement gathering activity. The output of this
442 activity may be a marketing requirements document or a product requirements document. In any case,
443 the result SHOULD be a set of clearly defined requirements for the analysis.
444 After the requirements have been defined and agreed, the actual analysis can begin. As illustrated by
445 Figure 8.4-2, there can be many inputs to and aspects of the process required to produce the desired
446 output. Inputs to the analysis process can come from requirements, customers and partners,
447 standards, other existing models, and domain experts. Requirements MAY be in the form of product
448 requirement documents, statements of work, customer change requests, etc. Customers, partners,
449 and domain experts provide their input when they are being consulted during the requirement
450 elaboration process and during documentation reviews. Existing standards (cross industry and industry
451 specific) and other existing models (e.g. EDI message implementation guides) are also consulted.
6
452 The controls for the analysis activities are the methodology (UMM), Meta Model, patterns, and other
453 analysis techniques. These controls specify the process and information model REQUIRED for the
454 business process and information analysis process to produce correct outputs. Patterns include
455 transaction patterns and collaboration patterns.
6
The definition of control conforms to the definition in the Integration Definition For Function Modeling (IDEF0), Federal
Information Processing Standards Publication 183,1993 December 21.

456 The mechanisms for the analysis activities are the analysts, tools, and reviewers. Analysts are the
457 people who are defining the processes and documents based on the Meta Model.
458 One of the key tools to assist with the analysis is the ebXML Business Process Analysis Worksheets,
459 discussed in Section10, Analysis Aids: Worksheets and Tools.
Patterns
Methodology Other Analysis Techniques
Requirements Business
Customers/ Process
Analyze Definitions
Partners
Business
Standards Processes and
Other Existing Business Document
Models Information Definitions
Domain Experts
Analysts Reviewers
Tools
460
461 Figure 8.4-2, Analyze Business Processes and Business Information

462 The Analyze Business Processes and Business Information Activity can be logically partitioned into
463 two separate but interrelated activities: analyze business processes and analyze business
464 information, shown here in Figure 8.4-3:
465
Analyze
Business
Processes
Start
Develop Document
Schemas, Implement
Analyze Services/Applications
Business
Information
466
467
468 Figure 8.4-3, Analyze Business Process and Business Information Activities
469

469 The overall analysis process will generally be more effective if the analysis of the business processes
470 and associated business information happens at the same time. Business information analysts will
471 need to be familiar with the business process and will want to be co-participants during the business
472 process analysis. Otherwise, the business information analysts MAY need to re-interview domain
473 experts, customers, and partners, to get clarification on matters that could have been more effectively
474 addressed during the analysis of the business process. Furthermore, business information analysts will
475 likely have the background that will help identify the key business information elements that effect the
476 business processes.
477 The analyze business processes activity can proceed along different paths depending on the focus of
478 the modeling effort. For example, if the goal is to establish a business reference model for an industry,
479 the process will likely proceed as discussed in the UMM, from the beginning to the end of the UMM
480 documentation. However, if the effort is to model existing X12 or EDIFACT documents and their
481 associated business processes, the process will more naturally start with the elaboration of business
482 transaction and roles. In this case, there is usually a strong implicit understanding of the associated
483 business process by domain experts. Business process analysis can be partitioned into four high-level
7
484 activities as shown in Figure 8.4-4:
Domain and
Process Start
Transaction
Centric Centric Analysis
Analysis
Economic Event
or Collaboration
Centric Analysis
Business
Process
Identification Elaborate Elaborate
and Discovery Business Business
Processes Collaborations Elaborate
and Economic Business Roles
Events and
Transactions
485
486 Figure 8.4-4, Analyze Business Process Activities
487 Once the business process and business information analysis is complete, the next activities are the
488 Develop Schemas activity and the Implement Services activity. Development of schemas involves the
489 creation of the document and information component schemas (XML schema/DTD or EDI message
490 and data element definitions) and sample documents. Implementing the service/application involves
491 coding or configuring business service interfaces and services/applications (such as back-end systems)
492 in accordance to the business process definitions and the document schemas.
493 Once the analysis is complete and the business processes and documents have been full defined and
494 developed, the specifications SHOULD be registered in a Business Library, e.g., an ebXML Registry.
495 A Business Library can be either generic or business domain specific. A business library is a repository
496 of business process specifications and business information objects within an industry or shared by
497 multiple industries. There will be many business libraries, pubic and private, moderated and non-
498 moderated. A public library is one that is available for public access. Typically the content of these will
7
It is recognized that the analyze business process activity MAY be partitioned in different ways to suit the sensibilities of
the participants in the analysis process.

499 be owned by standard's efforts, such as ebXML or UN/EDIFACT, and large electronic communities
500 (such as automotive marketplaces). A private library is one that does not have public access. These
501 are for private exchanges where the participating parties do not wish to disclose the nature of their
502 business processes. Obviously, the public access business libraries will be the most useful in
503 promoting interoperability between trading partners in different electronic communities. For example, it
504 MAY be necessary for the e-business systems of a trading partner in the automotive community to
505 access business processes registered in a chemical community.
506 A moderated business library is one whose content is administered by some organization, such as
507 standards body or electronic community. Business process and business information specifications
508 WILL be submitted to a working group or other supervising activity for the controlled business library.
509 The working group WILL review the submissions for quality and accuracy. The specifications MAY be
510 put to public or community voting for approval. Approved specifications are then registered in the
511 business library. At such time, key model elements - such as Business Process, Business
512 Collaboration, and Business Transaction - are officially assigned their identifiers according to the
513 Business Identifier Naming Scheme. These identifiers facilitate re-use and interoperability by providing
514 unique identifiers that can be referenced by business process specifications, Core Component's
515 contextual categories, CPPs and CPAs. Moderated business libraries will typically have more
516 credibility than ones that are not moderated. A business library that is not moderated will allow anyone
517 in the community to register specifications. The quality and accuracy of the specifications will be
518 suspect. However, these types of libraries could result in significant business process specifications.
519 Business process specifications that get significant usage will become more widely adopted over time.
520 The format in which these specifications are stored is an important consideration, as the key to an
521 enterprises ability to utilize these specifications in their analysis process is that they are stored in a
522 format that is interoperable with business modeling tools. It would appear RDF offers the opportunity to
523 encapsulate business process models during the analysis, design and 'record for posterity' stage in
524 business process life cycles. In addition, the use of RDF will also help achieve one of the original goals
525 of UN/CEFACT for ebXML, which was assuring that model specifications could be interchanged
526 between standards organizations using a controlled vocabulary for metadata classification and
527 categorization, so as to further promote business process modeling globally and to promote reuse of
528 common solutions. The advantage of RDF over other formats such as XMI is that RDF can be
529 restricted by use of namespaces to a specific problem domain, whereas others typically conform to the
530 more general UML domain. The ability to express a metastructure in RDF and validate it means better
531 control on the applicability of model content. When using models in a constricted domain like B2B, it is
532 attractive to be able to validate model content according to a metastructure. From a business
533 information standpoint, It is particularly useful that RDF allows association to BusinessAction elements,
534 i.e., placing a message in the context of a business process.
535
536

536 A summary of the entire analysis effort and its results is shown in
537 Figure 8.4-5 below:
Methodology
Business Processes
and Business Business
Information Modeling Libraries
Patterns
Business Process and

Metamodel
Business Information Model
Conversion to
Model-XML Rules
XML
Business Process Specification and

XML Schema/DTD
Information/Document Schema
Registration Business
Libraries
538
Categorization/Classification
539
540 Figure 8.4-5, Modeling, Conversion to XML, and Registration Activity Flow
541 The overall effort starts with the analysis and modeling of business processes and business
542 information. The UMM Methodology can be employed directly or indirectly through the use of the
543 Business Process Analysis Worksheets or business process editors. Re-usable business process and
544 information components from Business Libraries are applied, as well as collaboration and transaction
545 patterns. The analysis effort results in business process models and business information models that
546 are based on the Meta Model. The models are then converted into XML based Business Process
547 Specifications and Information/Document schemas according to a set of production rules. The
548 specifications and schemas are then registered and stored in Business Libraries for re-use and
549 reference by CPAs.
550

550 9 Relationship Between Business Process and Core

551 Components
552 9.1 Introduction
553 As previously stated, business process models define how business processes are described and
554 represent the verbs of electronic business. Information models define reusable components that can
555 be applied in a standard way within a business context. Core Components and domain components
556 represent the nouns and adjectives of electronic business. They are defined using identity items that
557 are common across all businesses. This enables users to define data that is meaningful to their
558 businesses while also maintaining interoperability with other business applications. Figure 9.1-1
559 illustrates how reusable information components fit within a business process.
Components used in modeling a Business

Scenario
Business
Process 1:m
Collaborations 1:m
Transactions 1:m
Document 1:m
Busines Information
Object (CC +/- DC)
1:m
Core component
0:m
Domain component
0:m
560
561 Figure 9.1-1 Relationship between Business Process and Core Component
562 9.2 Business Information Objects
563 Business Information Objects MAY be composed of Core Components, domain components, and
564 other business information objects. The component and business information object definitions are
565 stored in business libraries. Core Components can be stored in the specially named Core Library.
566 Business document definitions are constructed of business information objects, domain components
567 and Core Components. The following steps describe how to develop business document definitions.
568 1. Search Business Library for REQUIRED attributes available in business information objects.

569 2. If business information objects with appropriate attributes are not available, new business
570 information objects MUST be created.
571 3. Domain components in the business libraries and core components in the Core Library
572 COULD be candidates for business information object attributes, assuming the context is
573 appropriate.
574 4. Add the new attributes to existing business information objects, or introduce new business
575 information objects through a registration process that manages changes to the Business
576 Library.
577 5. Use the new attributes, now in the Business Library, to create the business documents.
578 In summary, Figure 9.2. -1 illustrates that the primary sources for creating business documents in a
579 business process and information model are business information objects in a Business Library. The
580 secondary sources are domain components in business libraries and the core components in the Core
581 Library, when appropriate business information objects cannot be found. Until the Business Library is
582 constructed, or imported from a credible sources, core components are likely to be utilized frequently,
583 first to add to the repertoire of business information objects in the Business Library, and second, to
584 create business documents.
Core Components
Business Information Objects,Domain Components
Business Domain
Core Library
Library Library
Concept metamodel
Business Domain Core

Information Components Components
Objects
585

Core Components
Business Information Objects,Domain Components
Business Domain
Core Library
Library Library
Concept metamodel
Business Domain Core

Information Components Components
Objects
586 Figure 9.2-1 Composition of Business Information Object
587
588 9.3 Core Components Analysis
589 The ebXML Methodology for the Discovery and Analysis of Core Components describes the process
590 for identifying information components that are re-usable across industries (hence the term core
591 components). Core components are used to construct domain components and business information
592 objects. Business libraries, which contain libraries of business process specifications (such as the
593 ebXML Catalog of Common Business Processes ) are instrumental in the discovery and analysis of
594 core components and domain components.
595 The business process specifications contain values that describe the contextual use of core
596 components and the elements within core components. This is discussed further in Section 9.4, Core
597 Component Contextual Classification. Business library cross-references, such as the cross-reference
598 in the ebXML Catalog of Common Business Processes , assist the core component analysis effort by
599 identifying related business processes, transactions, and documents from various initiatives such as be
600 EDIFACT, X12, xCBL, RosettaNet, CII, and OAG.
601 9.4 Core Component Contextual Classification
602 The Meta Model specifies the information to be captured when modeling a business process. The
603 model contains a number of elements and attributes that are considered to be significant in effecting
604 the interrelated conditions of the other elements in business process and document models. It is useful
605 to understand this contextual dependency between the various model elements during the analysis

606 process. Furthermore, in the future, it MAY be possible to apply these contextual dependencies at
8
607 runtime .
608 The contextual dependency concept referred to as simply Context has been given in-depth
609 consideration by the ebXML Core Components Project Team as it has a significant role in the analysis
610 of reusable information components. When a business process is taking place, the context in which it
611 is taking place can be specified by a set of contextual categories and their associated values. For
612 example, if an auto manufacturer is purchasing paint from a chemical manufacturer, the context values
613 might be as follows:
Contextual Value
Category
Process Procurement
Product Paint
Classification
Region U.S.
Industry (buyer) Automotive
Industry (seller) Chemical
614 Figure 9.4-1, Example Context Values
615 The contextual categories, identified in The role of context in the re-usability of Core Components and
616 Business Processes simply map to existing elements and attributes within a business process model
617 that is conformant to the UMM Business Process Meta Model. For example, the contextual Category
618 Process maps to the Meta Model elements BusinessProcess, ProcessArea, and BusinessArea. A
619 mapping of Context Categories to Meta Model elements is provided in Appendix A.
620 9.5 Context and Common Business Processes
621 The role of Context with respect to business process models has not been formally addressed by
622 ebXML as it is out of scope for the ebXML effort. However, it is generally accepted that common
623 business process models can be extended or constrained based on their contextual usage. For
624 example, business process X could have constrained (or extended) behavior XY if the industry is
625 "Automotive" and constrained (or extended) behavior XX if the industry is "Retail." The context of the
626 business process is defined by the values of such modeling elements such as business area, process
627 area, industry, role, and, perhaps, the economic events and resources. This is analogous to the
628 concept of Context as it applies to core components and document specification. Refer to ebXML The
629 role of context in the re-usability of Core Components and Business Processes for more information on
630 Context and core components.
8
For further discussion on this topic with respect to document elements (core components), see ebXML The role of
context in the re-usability of Core Components and Business Pr ocesses .

631 10 Analysis Aids: Worksheets and Tools

632 People without the expertise in analysis and modeling will likely find that the UMM will be useful as a
633 reference manual. These people will use UMM compliant approaches or, even, alternative
634 methodologies during the analysis of business processes. Practical experience tells us that it will be
635 more useful to the electronic business community to have an approach that does not require such
636 analysis and modeling expertise. An approach that a businessperson can apply would be most useful.
637 The Business Process Analysis Worksheets and Guidelines provide such an approach.
638 10.1 Analysis Worksheets and Guidelines
639 The ebXML Business Process Analysis Worksheets are a set of business process analysis design
640 aids to be used with the UMM as a reference. The Worksheets allow users to capture all the
641 information that is REQUIRED to completely describe a business process. This Worksheet content
642 can be used to drive software, and can be registered, classified, discovered and reused.
643

643 10.1.1 Analysis Worksheets and Editor
644 It is intended that a browser-based form will be used to build the worksheets. The user can populate
645 the worksheets through searches of the business libraries (Registries/Repositories containing catalogs
646 of business process specifications) for items that have already been defined. This is shown in Figure
647 10.1.1-1. The items (e.g. business processes, business collaborations, document schemas, etc.) can
648 be referenced (re-used as is) or copied to the worksheets and changed as needed. Over time,
649 business process libraries will become populated with a sufficiently large number of business
650 processes. When this happens, the analysis process will often be a simple matter of validating pre-
651 defined business processes against requirements.
652
653
Enablement: Analysis Worksheets and Editor
Browser
Public and Private Libraries:

- Business Processes
- Domain Documents and Domain
Worksheets Components
- Core Components
Trading Partner Registries:
- Collaboration Protocol Profiles
654 Figure 10.1.1-1, Business Process Analysis Worksheets Usage
655
656

656 10.1.2 Business Process Editor and Document Editor
657 The creation and maintenance of the Business Process Analysis Worksheets and Business Process
658 and Component Modeling/Analysis are provided in a business person friendly manner by application
659 tools like Business Process Editors and Document Component Editors. These tools provide an
660 effective means for business process and information modeling since they can connect directly to
661 business libraries and trading partner directories. See Figure 10.1.2-1. The tools will support discovery,
662 user friendly forms-based modeling, business process and business information comparison,
663 documentation and help on the analysis process, and capabilities for submitting specifications to
664 controllers of the business libraries. Tool suites of business process editors, document & component
665 editors, and CPP/CPA editors will be instrumental in enabling ebXML based e-commerce.
Business Process and Document Editor
Business Process Editor Document and Component Editor
Public and Private Libraries:

- Business Processes
- Domain Documents and Domain
Components
- Core Components
Trading Partner Registries:
- Collaboration Protocol Profiles
666 Figure 10.1.2-1, Tool Interaction
667

667 11 References
668 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC
669 2119, March 1997.
670 [bpWS] ebXML Business Process Analysis Worksheets and Guidelines. V1.0, May 11 2001.
672 [ebBPSS] ebXML Business Process Specification Schema. Version 1.0 May 11 2001.
673 Context/Meta Model Group of the CC/BP Joint Delivery Team.
674 [ebPROC] ebXML Catalog of Common Business Processes. Version 1.0, May 11 2001. ebXML
675 CC/BP Analysis Team.
676 [bpPATT] ebXML Business Process and Simple Negotiation Patterns. Version 1.0, May 11 2001.
678 [IDEF0] Integration Definition For Function Modeling (IDEF0). Federal Information Processing
679 Standards Publication 183.1993 December 21.
680 [ISO14662] Information Technologies - Open-EDI Reference Model. ISO/IEC 14662:1997(E).

681 International Organization for Standardization (ISO) and International Electrotechnical
682 Commission (IEC).
683 [ebCCD&A] ebXML Methodology for the Discovery and Analysis of Core Components. V1.0, May 11
684 2001. ebXML Core Components Project Team.
685 [ebCNTXT] The role of context in the re-usability of Core Components and Business Processes.
686 Version 1.0, May 11 2001. ebXML Core Components Project Team.
687 [ebGLOSS] ebXML. TA Glossary. Version 1.0, May 11 2001 . Technical Architecture Project Team.
688 [ebTA] ebXML Technical Architecture Specification. Version 1.0.4. 16 February 2001. ebXML
689 Technical Architecture Project Team.
690 [ebCCDOC] ebXML specification for the application of XML based assembly and context rules.
691 Version 1.0, 11 May 2001. ebXML Core Components.
692 [UMM] UN/CEFACT Modeling Methodology. CEFACT/TMWG/N090R9. February 2001.

693 UN/CEFACT Technical Modeling Working Group.
694 12 Disclaimer
695 The views and specification expressed in this document are those of the authors and are not
696 necessarily those of their employers. The authors and their employers specifically disclaim
697 responsibility for any problems arising from correct or incorrect implementation or use of this design.

698 13 Contact Information

699 Business Process Project Team
700 Business Process/Core Components (BP/CC) Analysis Team Lead
701 Name: Brian Hayes
702 Company: Commerce One
703 Street: 4440 Rosewood Drive
704 City, State, ZIP/Other: Pleasanton, CA
705 Nation: USA
706 Phone: +1 (925) 788-6304
707 EMail: brian.hayes@UCLAlumni.net
708
709 Editor:
710 Name: Randy W. Clark
711 Company: Baker Hughes, Inc.
712 Street: 3900 Essex Lane, Suite 800
713 City, State, ZIP/Other: Houston, TX 77027
714
715 Phone: +1 (713) 439-8143
716 EMail: randy.clark@bakerhughes.com

717 Appendix A: Context Category Meta Model Cross-

718 reference
719 The following table cross-references Core Components contextual categories with Meta Model
720 elements.
Contextual Definition Meta Model Sources of Comments

Category Element Resources
Industry The industry or BusinessOper UN/CEFACT, Hierarchical values

sub-industry in ationalMap etc.
which the The BOM provides a logical
information categorization of a set of
exchange takes processes, these processes
place. MAY be organized in more
than one way (scheme) or from
more than one view including
industry.
Domain and industry are not

the same: an industry is a type
of domain which is not
necessarily industry specific.
Business The business BusinessProc ebXML Hierarchical values.

Process process ess Catalog of
enabled by the Common Cross-enterprise situations can
information Business be accommodated since
exchange. Processes Business Processes are
defined in context of Trading
UN Industry Partner Types.
Classes
Multiple values in a single
RosettaNet context category is permitted.
BPAWG
(UN/Cefact
process
group)
Business
Process
patterns
Product The goods or EconomicRes UN/SPCP Hierarchical values.

services that ource
the exchange of General Use standard classifications or
information Classifications define your own. The Meta
describes or from the UN Model permits this. It is likely
enables and general that various industry forums will
classifications define these.
from domains.
The kind of product influences


the kind of product information.
Physical The physical Geographic GPS, Hierarchical values.

Geography geography and and regional Aerospace,
/Conditions conditions categorization ISO Range of conditions are
/Region (weather, MAY be specified as constraints on the
altitude, climate) defined by the category element.
geographical category
context of the schema in the
information BOM.
exchange (not
geo-political)
Temporal The time-based EconomicCom It is a Not hierarchical.

context of the mitment.due conditional
information expression This can be a range of dates.
exchange that MAY be
evaluated
against a
multiplicity of
criteria.
Geo-Political Political Rules Geopolitical ATA, DOD, Hierarchical values - stop at

Legislative/ (usually defined and regulatory FAA, AECMA, high level (province, state or
Regulatory/ by Geography) categorization UN/Cefact. city level) - do not specify body
Cultural and Regulatory MAY be ISO of regulation.
Organizations defined by the
which are used. category
schema in the
NOTE: BOM.
External
influence to
business
conversation
Application The application Business UN economic Supports vendor and industry

Processing and/or system Service activity and/or sub-standards values.
context of the OAG: this is
information hierarchical.
exchange (Applications
within
There is some applications). -
agreed-upon *Broad*
level of support. definition of
"application".
Self-
registered by
external
bodies.
Business A business BOM Business Purpose and domain

Purpose purpose context MAY be defined and scoped by


Purpose purpose context MAY be defined and scoped by
/Domain unrelated to the the BOM categorization
business schema.
process. This is
the "purpose" of
the recipient(s)
of the business
information.
Partner Role Particular role Partner Role Non-hierarchical.

that a party
plays in a Is it defined in commercial
process. collaboration
Service Level Service level Agreement OTA, Credit Hierarchical.

(profiles not attached to agencies
preferences.) agreements of
either the
provider or
receiver of
products.
Virtual An environment Marketplace A market place and community

marketplace in which to do categorization are synonymous.
business MAY be
defined by the
category
schema in the
BOM.
Info. [The "element" Business Self-

Structural context of Document, referential,
Context information in InformationEnt MAY be
an XML sense] ity hierarchical.
Contracts/ Agreement,
Agreements EconomicCont
ract.
721

722 Copyright Statement

723 Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.
724 This document and translations of it MAY be copied and furnished to others, and derivative works that
725 comment on or otherwise explain it or assist in its implementation MAY be prepared, copied, published
726 and distributed, in whole or in part, without restriction of any kind, provided that the above copyright
727 notice and this paragraph are included on all such copies and derivative works. However, this
728 document itself MAY not be modified in any way, such as by removing the copyright notice or
729 references to ebXML, UN/CEFACT, or OASIS, except as REQUIRED to translate it into languages
730 other than English.
731 The limited permissions granted above are perpetual and will not be revoked by ebXML or its
732 successors or assigns. This document and the information contained herein is provided on an "AS IS"
733 basis and ebXML DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
734 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
735 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
736 FOR A PARTICULAR PURPOSE.
737

Business Process and Business Information Analysis Overview v1.0

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Business Process and Business Information Analysis Overview v1.0

Hochgeladen von

Copyright:

Verfügbare Formate

1 Business Process and Business Information

2 Analysis Overview v1.0

4 Business Process Team

7 1 Status of this Document

10 This document contains information to guide in the interpretation or implementation of ebXML

12 Distribution of this document is unlimited.

Business Process and Business Information Analysis Overview Page 1 of 40

Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

20 2 ebXML Business Process Analysis Participants

Business Process and Business Information Analysis Overview Page 2 of 40

Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

99 Data communication interoperability is ensured by a standard message transport mechanism with a

112 4.2 Scope and Audience

Business Process and Business Information Analysis Overview Page 4 of 40

Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

119 4.3 Related Documents

122 UN/CEFACT Modelling Methodology. CEFACT/TMWG/N090R9. February 2001. UN/CEFACT

124 Information Technologies - Open-EDI Reference Model. ISO/IEC 14662:1997(E). International

145 4.4 Document Conventions

Business Process and Business Information Analysis Overview Page 5 of 40

Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

Business Process and Business Information Analysis Overview Page 6 of 40

Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

153 5 Goal and Objectives

159 5.2 Objectives

161 Provide an overvi ew of electronic business collaboration

162 Discuss the role and use of business process modeling

163 Describe the analysis process

164 Discuss economic elements in Business Processes

165 Establish the relationship of core components to business processes

166 5.3 Caveats and Assumptions

Business Process and Business Information Analysis Overview Page 7 of 40

Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

173 6 Business Collaboration Overview

Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

Activity ebXML Project Team ebXML Document

Partner Discovery Technical Architecture, ebXML Tec hnical Architecture Specification,

Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

Electronic Plug-in Technical Architecture, Collaboration-Protocol Profile and Agreement

Process Execution Trading Partner, Collaboration-Protocol Profile and Agreement

Process None Information Technologies - Open-EDI Reference

Process Evolution None None not in scope of ebXML.

210 6.2 Economic Elements in Business Processes

217 Economic Resources: including products, services, and cash

218 Economic Events: including product or service deliveries, and payments

221 Using these elements, it will be possible to determine in a business collaboration:

222 When an Economic Contract is formed

223 When an Economic Event SHOULD be recognized

Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

226 Whether or not a delivery fulfills a commitment

228 When an exchange is complete from a business point of view

229 Many other aspects of typical business relationships

Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

Query Product Product Master

Create Order forms Purchase Order Line Item

Business Process and Business Information Analysis Overview Page 12 of 40

Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.

Business Business Core/Domain

Process Documents Components

Business Register &

Service Transport Service