1
2
Business Process
Analysis Worksheets & Guidelines
3
Business Process Team
Version 1.03
4 April 2002
Work-In-Progress
4
5
6
7
8
9
Procedures for developing business process models in ebXML
10
11
1. Status of this Document
12
13
14
15
This Technical Report document has been approved by the eBTWG Business Collaboration
Patterns and Monitored Commitments Project Team and has been accepted by the ebXML
Plenary. This document contains information to guide in the interpretation or implementation of
ebXML concepts.
16
Distribution of this document is unlimited.
17
The document formatting is based on the Internet Society’s Standard RFC format.
18
This version:
19
20
21
http://home.attbi.com/~brianhayes/TR/2002/bpWS-1.01-WIP.zip
Latest version:
http://www.ebxml.org/specs/bpWS.pdf
22
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
2
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
23
January 2002
2. ebXML participants
24
eBTWG Business Collaboration Patterns and Monitored Commitments Team Lead
25
David Welsh, Nordstrom.com
eBTWG Editors
26
Brian Hayes, Commerce One.
27
28
29
30
We would like to recognize the following ebXML participants for their significant participation to the
development of this document.
31
32
Business Process Project Team Co-Leads
33
Paul Levine, Telcordia
34
Marcia McLure, McLure-Moynihan, Inc.
35
36
Editors
37
Charles Fineman, Arzoon.
38
Brian Hayes, Commerce One.
39
Jennifer Loveridge, Nordstrom.com.
40
William E. McCarthy, Michigan State University
41
42
David Welsh, Nordstrom.com.
Contributors
43
Jim Clark, International Center of Object Technology.
44
Randy Clark, Baker Hughes, Inc.
45
Bob Haugen, Logistical Software.
46
Larissa Leybovich, Vitria
47
Nita Sharma, Netfish Technologies.
48
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
3
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
49
3. Table of Contents
50
1.
STATUS OF THIS DOCUMENT
2
51
2.
EBXML PARTICIPANTS
3
52
3.
TABLE OF CONTENTS
4
53
4.
INTRODUCTION
6
4.1.
4.2.
4.3.
4.4.
54
55
56
57
58
5.
62
6.
75
7.
8.
91
BUSINESS PROCESS IDENTIFICATION AND DISCOVERY
BUSINESS PROCESS ELABORATION
8.1.
GOALS
8.2.
WORKSHEETS
8.2.1
Business Process Use Case
8.2.2
Business Process Activity Table
86
87
88
89
90
WORKSHEET BASED ANALYSIS OVERVIEW
7.1.
GOALS
7.2.
GUIDELINES
7.2.1
How does one decide how big to make the various groupings at this level?
7.2.2
What is the boundary of the business area?
7.3.
WORKSHEETS
7.3.1
Business Reference Model
7.3.2
Business Area
7.3.3
Process Area
7.3.4
Identify Business Processes
76
77
78
79
80
81
82
83
84
85
GOALS/OBJECTIVES/REQUIREMENTS/PROBLEM DESCRIPTION
THE ANALOGY
CAVEATS AND ASSUMPTIONS
6.1.
BASIC GUIDELINES FOR FILLING OUT WORKSHEETS
6.1.1
Focus on public Business Processes
6.1.2
The REA Ontology
6.1.3
Use the worksheets in the order that makes the most sense for you
6.1.4
The worksheets can be used for projects of various scopes
6.1.5
Think how will people use what you construct
6.1.6
Re-use is one of the primary goals of ebXML
6.1.7
Worksheet Name, Form Id, and Identifier Fields
6.1.8
Note on optional fields in the worksheets
6.1.9
Number your worksheets
6.2.
WORKSHEETS TO METAMODEL MAPPING
6.3.
MODEL PROPERTIES
63
64
65
66
67
68
69
70
71
72
73
74
9.
6
6
7
7
DESIGN OBJECTIVES
5.1.
5.2.
5.3.
59
60
61
SUMMARY
AUDIENCE
RELATED DOCUMENTS
DOCUMENT CONVENTIONS
ECONOMIC ELEMENTS
9.1.
GOALS
7
7
10
10
11
12
12
12
12
12
13
13
13
14
15
15
17
18
18
19
19
19
19
19
21
22
23
23
23
24
24
25
27
27
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
4
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
9.2.
GUIDELINES
9.3.
WORKSHEETS
9.3.1
Economic Contract
9.3.2
Economic Resource Type
9.3.3
Economic Event Resource Type
10.
BUSINESS COLLABORATION
10.1.
GOALS
10.2.
GUIDELINES
10.3.
WORKSHEETS
10.3.1
Business Collaboration
10.3.2
Business Collaboration Activity Table
11.
January 2002
27
28
28
29
30
32
32
33
33
33
34
BUSINESS TRANSACTIONS AND AUTHORIZED ROLES
36
11.1.
GOALS
11.2.
GUIDELINES
11.2.1
Use Transaction Patterns
11.2.2
Detail Transaction Activities Only If Necessary
11.3.
WORKSHEETS
11.3.1
Business Transaction
11.3.2
Business Transaction Property Values
11.3.3
Business Transaction Activity Table
11.3.4
Initiating and Responding Activity Key Informational Elements
36
36
36
36
37
37
39
39
40
12.
BUSINESS INFORMATION DESCRIPTION
12.1.
GOALS
12.2.
GUIDELINES
12.3.
WORKSHEETS
12.3.1
Business Information Context
12.3.2
Document Content Description
12.3.3
Content Mapping
42
42
42
43
43
46
46
120
APPENDIX A THE PORTER VALUE CHAIN
49
121
APPENDIX B DISCLAIMER
52
122
APPENDIX C CONTACT INFORMATION
52
123
124
Figures
125
Figure 5-1, Worksheets Architectural Context................................................................................9
126
Figure 6-1 Overview of mapping from Worksheets to Metamodel............................................. 11
127
Figure 2, Example Worksheet Name and Identifiers .................................................................. 13
128
Figure 7-1 Business Process Identification and Discovery Worksheet to Metamodel Mapping18
129
Figure 8-1 Mapping from business processes to the BRV ......................................................... 23
130
Figure 10-1 Mapping from Business Collaboration to BRV ........................................................ 32
131
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
5
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
132
4. Introduction
133
4.1. Summary
134
135
136
137
138
139
January 2002
The primary goal of the ebXML effort is to facilitate the integration of e-businesses throughout the
world with each other. Towards this end much of the work in ebXML has focused on the notion of a
public process: the business process(es) by which external entities interact with an e-business.
The specification and integration to such public processes has long been recognized as a
significant cost to such businesses. In order to reduce this cost ebXML is recommending the use of
Business Libraries. The principle goals of these libraries are to:
140
a) Promote reuse of common business processes and objects
141
142
b) Provide a place where companies and standards bodies could place the specifications of
their public processes where appropriate trading partners could access them.
143
144
145
146
In order to realize these goals, a lingua franca needed to be leveraged so that all users of this
repository could understand what each other are specifying. The ebXML community has decided
to use as its lingua franca the semantic subset of the UMM Metamodel, specified by the
UN/CEFACT Modeling Methodology in the N090 specification.
147
148
149
150
The UMM “is targeted primarily at personnel knowledgeable in modeling methodology who
facilitate business process analysis sessions and provide modeling support. It also serves as a
checklist for standardized models when a previously specified business process is contributed to
UN/CEFACT for inclusion and incorporation as a standard business process model.” [UMM]
151
152
153
154
155
156
This document contains several worksheets that guide analysts towards UMM compliant
specifications of their business processes. We have tried to provide tools for users regardless of
whether we’re working on behalf of a standards body or an individual company. Furthermore, we
provide a variety of scenarios guiding how one might go about filling out these worksheets (e.g.
top-down vs. bottom up). The UMM can be used as a reference for understanding the details of
the underlying Metamodel and UMM methodology.
157
158
159
160
161
Different degrees of rigor are required within these worksheets. As we approach the lower level,
certain elements and organization of the specification are required to meet the requirements of the
ebXML technical framework. At higher levels there is a good deal of latitude about the way
concepts are grouped. In many cases, things such as assumptions and constraints will be
specified in natural language rather then in a formal one.
162
4.2. Audience
163
164
165
166
We do not expect the users of these worksheets to be experts in business modeling, however it is
expected that they are subject matter experts in their respective areas of practice. They should
have detailed knowledge of the inter-enterprise business processes they use to communicate with
their trading partners.
167
168
This document could also be used by industry experts to help express their sectors business
processes in a form that is amenable to the goals of the ebXML registry and repository.
169
170
Of course, software vendors that are supplying tools (modeling and otherwise) in support of the
ebXML framework will find useful information within.
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
6
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
171
January 2002
4.3. Related Documents
172
173
[ebCNTXT] ebXML Concept - Context and Re-Usability of Core Components. Version 1.01.
February 16, 2001. ebXML Core Components Project Team.
174
[ebCPPA]
175
176
[ebRIM]
ebXML Registry Information Model. Version 0.56. Working Draft. 2/28/2001. ebXML
Registry Project Team.
177
178
[ebRS]
ebXML Registry Services. Version 0.85. Working Draft. 2/28/2001. ebXML Registry
Project Team.
179
180
[ebTA]
ebXML Technical Architecture Specification. Version 1.0. 4 January 2001. ebXML
Technical Architecture Project Team.
181
182
[bpOVER] Business Process and Business Information Analysis Overview. Version 1.0. Date 11
May 2001. ebXML Business Process Project Team
183
184
[bpPROC] ebXML Catalog of Common Business Processes. Version 1.0. Date May 11, 2001.
ebXML Business Process Project Team
185
186
[PVC]
Michael E. Porter, Competitive Advantage: Creating and Sustaining Superior
Performance, 1998, Harvard Business School Press.
187
188
189
[REA]
Guido Geerts and William.E. McCarthy "An Accounting Object Infrastructure For
Knowledge-Based Enterprise Models," IEEE Intelligent Systems & Their Applications (July-August
1999), pp. 89-94
190
191
[SCOR]
Supply Chain Operations Reference model, The Supply Chain Council
(http://www.supply-chain.org/)
192
193
[UMM]
UN/CEFACT Modeling Methodology. CEFACT/TMWG/N090R9.1. UN/CEFACT
Technical Modeling Working Group.
194
ebXML Collaboration Protocol Profiles and Agreements….
4.4. Document Conventions
195
196
197
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT,
RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be
interpreted as described in RFC 2119.
198
199
Heretofore, when the term Metamodel is used, it refers to the UMM e-Business Process
Metamodel as defined in [UMM].
200
5. Design Objectives
201
5.1. Goals/Objectives/Requirements/Problem Description
202
203
ebXML business processes are defined by the information specified in the UMM e-Business
Process Metamodel (hereafter referred to as the “Metamodel”). The Metamodel specifies all the
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
7
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
204
205
206
207
information that needs to be captured during the analysis of an electronic commerce based
business process within the ebXML framework. ebXML recommends the use of the UN/CEFACT
Modeling Methodology (UMM) in conjunction with the Metamodel. The UMM provides the
prescriptive process (methodology) to use when analyzing and defining a business process.
208
209
210
211
212
213
The ebXML Business Process Worksheets are a set of business process design aids, to be used
with the UMM as a reference. It is intended that the worksheets be extensible to meet specific
business needs. An ebXML business process, that is defined based on the UMM Metamodel, will
sufficiently reflect all the necessary components of a business process and enable its registration
and implementation as part of the ebXML compliant electronic trading relationship. The Worksheet
based approach that provides an easier way of applying the UMM and the UMM Metamodel.
214
215
216
The intent of the worksheets (or a business process editor4) is to capture all the bits of information
that are required to completely describe a business process so that it can be registered, classified,
discovered, reused and completely drive the software.
217
218
219
220
To develop company business processes for an ebXML compliant electronic trading relationship,
use the UMM as a reference guideline plus the ebXML Business Process Worksheet to create the
necessary business process models. These are the recommended steps for using the ebXML
Business Process Worksheets
221
1. A business need or opportunity is identified and defined before using these procedures.
222
223
224
2. A Focus Project Team, usually representing a multifunctional set of experts from IT, business
process ownership and business process experts needed to work out the business process
using the ebXML Business Process Worksheet.
225
226
227
228
3. Using the ebXML Business Process Worksheets, the Focus Project Team will be able to
develop an ebXML Business Process Specification that can be reviewed and verified by the
business. In addition, all necessary information to populate the ebXML Metamodel will be
made available to enable an ebXML trading relationship.
4
A group of ebXML contributors are working on a prototype of an editor that uses wizards to guide the user through the
construction of a UMM compliant Business Process.
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
8
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
Browser
Worksheets
229
Public and Private Registries:
- Business Processes
- Document &
Component
and
Component
DomainLibraries
Libraries
Domain
- Core Component Libraries
- Collaboration Protocol Profiles
Figure 5-1, Worksheets Architectural Context
230
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
9
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
231
232
233
234
January 2002
5.2. The Analogy
The following analogy is useful in understanding the role of the Worksheets and other
documentation and tools to the ebXML Business Process Collaboration Metamodel and the
UN/CEFACT Modeling Methodology.
Item
United States Internal Revenue Service (IRS)
Tax System
Entire tax code
UN/CEFACT Modeling Methodology (UMM) and
UMM Metamodel.
Worksheets and Templates
IRS Forms
Methodology Guidelines (as in this document or
similar documenation)
IRS Instruction Booklets
Business Process Editor Tool Suite
Something like TurboTax and other software
packages for preparing personal or business tax
forms where these packages would have on-line
access/search of all your tax and tax related
records and the Tax code.
Repository of Business Process Specifications,
Core Components, etc.
235
236
237
238
239
240
241
242
In order to actually specify a business process all we really need is the Worksheets and
Templates5. However, in order to ensure that we fill in the forms properly we will need to have a set
of instructions that augment the templates and provide some of the rationale behind the templates.
5.3. Caveats and Assumptions
This document is non-normative; the documents identified above should be considered the
authority on the definitions and specifications of the terminology used herein. This document is
intended to be an application of those principals and technologies.
243
5
A template is a document or file having a preset format that is used as a starting point for developing human-readable
versions of the business process specifications so that the format does not have to be recreated each time it is used.
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
10
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
244
245
246
247
248
January 2002
6. Worksheet Based Analysis Overview
As stated above, the purpose of this document is to provide worksheets that guide the user
through the construction of a UMM compliant specification of their business processes. The
following diagram shows mapping from the worksheets to the high level components of the UMM.
Note, the document definition worksheet is currently not included in the set of worksheets.
Worksheets
249
UMM Metamodel View
Business Reference Model
Business Process
Identification and Discovery
Business Operations Map
Model
Business Process Ellaboration
Business Collaboation
Construction
Business Requirements View
Model
Business Transaction
Definition
Business Transaction View
Model
Business Information
Definition
Business Service View
Model
250
Figure 6-1 Overview of mapping from Worksheets to Metamodel
251
252
253
The expectation is that after the worksheets have been completed, there will be sufficient
information to mechanically produce a Metamodel based specification of the modeled business
process(es). The worksheets given above are:
254
255
256
Business Reference Model – Use this to define the “frame of reference” of the rest of the
worksheets. This provides definitions of terms and, perhaps, canonical business processes (e.g.
[SCOR]6)
257
258
259
Business Process Identification and Discovery – Use this to do an inventory of the business
processes. This is really just a set of high-level use cases merely to identify the existence of
processes and the stakeholders without going into detail.
260
261
262
Business Process Elaboration – These worksheets are used to flesh out the business
processes. This identifies the actual actors as well as pre and post conditions for the business
process.
6
Defines plan, source, make and deliver business areas in their Supply Chain Operations Reference (SCOR) model
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
11
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
263
264
265
Business Collaboration Definition – In these worksheets we define the economic events that
take place to fulfill the business process. This is where one defines the system boundaries and the
protocols that govern the flow of information.
266
267
268
Business Transaction Definition – These worksheets are more technically oriented than the
others (which have a decidedly more “modeling” orientation). At this stage one defines the actual
activities and authorized parties within the organization that initiate these transactions.
269
270
271
272
Business Information Definition – In these worksheets one defines the contents of the
information field widths, data types, descriptions, requirement traceability and, perhaps, the
additional context ([ebCNTXT]) necessary to construct the document from the Core Components
subsystem.
273
6.1. Basic Guidelines for filling out Worksheets
274
6.1.1 Focus on public Business Processes
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
While these worksheets could be used to model any kind of business process, the focus of the
ebXML effort is to make trading partner integration easier, cheaper, and robust. Therefore the
expectation is that the primary focus will be on public faces of your business processes.
6.1.2 The REA Ontology
The UMM and ebXML groups are recommending the use of the Resource-Economic Event-Agent
Ontology for the formalization of business collaborations. Please refer to [BPAO] and [REA] for
further information on this topic7 and associated worksheets.
6.1.3 Use the worksheets in the order that makes the most sense for you
For the purposes of this document we proceed from the top-level step (Business Reference Model)
down to the lowest-level step (Business Transaction). It is important to note, however, that these
worksheets can be filled out in whatever order makes the most sense from the user’s perspective.
For example, a person who is trying to retrofit an existing document based standard (e.g.
EDIFACT) might want to start by filling in the Business Transaction Definition worksheets (perhaps
only specifying trivial definitions for the higher level worksheets). A person looking to formalize the
definitions for an entire industry may very well start from the Business Reference Model worksheet.
6.1.4 The worksheets can be used for projects of various scopes
Although the Metamodel has definite requirements on what objects need to be present to comprise
a complete specification, it says little about the scope of what those specifications represent. For
example, if you are only trying to model a specific interaction with one of your trading partners, you
do not need to include a complete Business Reference Model for your entire industry, just include
the parts that are directly relevant for the interaction you are modeling. Similarly, if you are just
doing a small set of interactions for your company, you might choose to have the Business Area or
Process Area just be your own company.
7
Worksheets will be made available in a future version of this document.
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
12
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
298
January 2002
6.1.5 Think how will people use what you construct
As you fill in these worksheets please keep in mind how the generated UMM specification will be
used by a user of the repository. The two principal uses envisioned are:
299
300
301
302

To determine if a given collaboration is appropriate for reuse (or at least is a close enough
match for subsequent gap analysis)
303
304
305

To be used as an on-line implementation guide. A potential trading partner (or a 3rd party
on their behalf) could examine the public processes/collaborations you provide and
construct an integration plan.
This means trying to use industry wide terms (or at least Business Reference Model terminology)
to increase the comprehensibility and specificity. .
306
307
308
6.1.6 Re-use is one of the primary goals of ebXML
As stated above, the hope is that users will develop models that are reusable by others. Towards
that end, it is intended that the Worksheets be used in conjunction with a browser that lets the user
search business process libraries for items that have already been defined. The items (e.g.
business processes, business collaborations, document schemas, etc.) can be referenced (reused as is) or copied to the worksheets and changed as needed. Over time, business process
catalogs will become populated with a sufficiently large number of business processes. When this
happens, the analysis processes will often become a matter of validating pre-defined business
processes against requirements.
309
310
311
312
313
314
315
316
317
6.1.7 Worksheet Name, Form Id, and Identifier Fields
Each worksheet (form) has a name field, and Form Id field. Many of the worksheets have an
Identifier field. This is shown in the figure below. The Form Id and Identifier fields are shaded to
indicate that they can be programmatically generated or provided based on the worksheet name,
worksheet type, and other information.
318
319
320
321
Form: Business Transaction
322
Business Transaction
Name
[Provide the common name for the business transaction.]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Identifier
[This is a unique identifier that follows the Business Process Identifier
Naming Scheme. This can be provided when the business process
description is submitted to a business process library. See Appendix
A for a more detailed discussion.]
Field A
[Description of Field A]
…
…
Figure 2, Example Worksheet Name and Identifiers
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
13
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
323
324
325
326
327
328
329
330
331
332
333
334
335
336
The name field (e.g. Business Transaction Name) is the common named use by people for the
entity being modeled. For example, “Create Order” is a common name for a business transaction
in which a buyer submits a purchase order to a seller. It is recommended that the name be unique
for a given worksheet/form type and collection of worksheets (perhaps in a single word processing
document). The Form Id field is to uniquely identify the form, within a collection of worksheets, so it
can be referenced by other forms and by people. For example, you could write, “see BT-1.1Create-Order” (where BT-1.1-Create-Order is a Form Id) rather than “see the Create Order
business transaction form.” The Form Id is also useful for heading titles in documentation that
contains the worksheets. While it is expected that the name field value will be usually be unique
within a collection of worksheets, the Form Id field allows names to be repeated for the same
worksheet (form) type. It is recommended that the Form Id follow the numbering scheme
described in Section 6.1.9, Number your worksheets. It is possible to
systematically/programmatically generate Form Ids based on the worksheet name, worksheet
type, and, perhaps, a numbering scheme.
337
338
339
340
341
342
343
344
345
Some worksheets have an Identifier field. The Identifier field is the globally unique identifier for the
entity being modeled. A business library where the model is registered may assign the identifier;
alternatively, it may be assigned automatically by a modeling tool, or by a user. It is recommended
that the Business Process Identifier Naming Scheme be followed (See Appendix A, Error!
Reference source not found.). Form Ids should not be used as Identifier values since a Form Id
is not intended to be globally unique. Once the Identifier has been provided, the need for the Form
Id is lessened; however, as described above, the Form Id is still a useful reference. It is possible to
systematically/programmatically generate Identifiers following the BPINs scheme based on the
worksheet name, worksheet type, and other information.
346
347
When referencing a worksheet from another worksheet, the recommended format for providing a
worksheet name and its corresponding Form Id or Identifier is as follows:
348
<name> [<form-id>]
349
<name>[<identifier>]
350
For example,
351
Create Order [BT-2.3-Create-Order]
352
Change Order [urn:btid:iacann:ebxml.org:ChangeOrder$1.0]
353
354
355
356
357
358
359
360
361
Since Form-Ids do not have colons (:) and are not prefixed by “urn:”, it should be easy to
programmatically differentiate between Form Ids and Identifiers.
6.1.8 Note on optional fields in the worksheets
Some of the worksheets contain entries that are labeled as optional for ebXML. These are
attributes that appear in the UMM but are not required as part of the ebXML Specification Schema.
These are typically business objective/justification topics. While these are obviously very important
aspects of any modeling endeavor, ebXML is oriented towards exposing an organization’s public
processes to their trading partners. Advertising that organizations justifications for such interfaces
could potentially publicize strategic information that said organization would prefer to keep private.8
362
8
There has been discussion on private vs. public repositories where some or all aspects of the model are stored in a
restricted access repository.
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
14
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
363
January 2002
6.1.9 Number your worksheets
364
365
366
367
Each of the worksheets has an entry for a Form Id. This identifier can be used to reference one
form from another. In addition, if you use an outline numbering scheme, it will be easy for the
reader to determine parent-child relationships between elements of the model (of course, if you do
a bottom up approach this will be significantly harder to do up front!).
368
The recommended format is:
369
370
<Form Type>-<Number>-<Description>
Where <Form Type> is
371
BRM for Business Reference Model
372
BA for Business Area
373
PA for Business Process Area
374
BPS for Business Process Summary
375
BPUC for Business Process Use Case
376
BPAT for Business Process Activity TableEE for Economic Exchange
377
EA for Economic Agreement
378
BC for Business Collaboration
379
BCPT for Business Collaboration Protocol Table
380
BT for Business Transaction
381
BTTT for Business Transaction Transition Table
382
IAKE for Initiating Activity Key Elements
383
RAKE for Responding Activity Key Elements
384
BIC for Business Information Context
385
CD for Content Description
386
CM for Content Mapping
387
388
<Number> is, perhaps, an outline entry number
389
<Description> is some descriptive name.
390
Please see the example in the Appendix for an illustration of this in practice.
391
392
393
394
395
396
6.2. Worksheets to Metamodel Mapping
The following diagram sketches out a more detailed mapping from the Worksheets Model to the
Metamodel defined by the UMM. The leftmost column is the selection of the main elements that the
Worksheets need to specify or edit. The rightmost column shows significant Metamodel elements.
The middle column is the other elements that are part of the Worksheets. They are the same as
the Metamodel elements of the same name.
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
15
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
Worksheet
Model
January 2002
Metamodel
Business
Reference Model
BOM
Model
Business Area
Business Area
Model
Process Area
Process Area
Model
Business Process
Identification
Business Process
(Use Case)
BRV
Model
Business Process
Elaboration
Business Process
(Use Case)
Business Actor
Business
Collaboration
Different path for
single transaction
collaborations.
Partner Type
Business Collaboration
Use Case
(Use Case)
Business Transaction
Use Case
(Use Case)
Choreography states, transitions, etc.
Business Collaboration
(Collaboration)
BTV
Model
Business Transaction
Business Collaboration
Protocol
(Activity Graph)
Business Activity
BusinessTransaction
Activity
(Action State)
Authorized
Role
397
Document Envelope
BusinessTransaction
(Activity Graph)
Business Document
Business Document
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
16
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
398
January 2002
6.3. Model Properties
399
400
Model properties provide general information about the model. These properties include
information for tools that transform the worksheets to another format.
401
[It might be good to make this section Heading Level 1. This could be the first worksheet to fill out.]
Form: Model Properties
Analysts/Modelers
[Provide a list of names of people who are participating in the
business process analysis effort. Specify email addresses between
angle brackets. For example, Brian Hayes
<brian.hayes@commerceone.com>]
Model Owner
[Name of the organization sponsoring the analysis activities or that
will own the resultant model. For example, UN/CEFACT.]
Identifier Information
Agency Id
[The identifier of the organization that owns the business process
model (or some subset there of). This is used in conjunction with
the Agency field. This information is case sensitive; lower case is
recommended. Examples are EAN identifiers and internet domain
names.]
Agency
[The name of the agency which owns or controls the Agency Id
values. This information is used to create the BPINs identifiers.
This information is case sensitive; lower case is recommended. For
example, icann (for ICANN internet domain names) or eann (for
EAN identifiers).]
402
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
17
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
403
7. Business Process Identification and Discovery
404
7.1. Goals
405
406
407
The first set of worksheets helps the user begin formalize the domain they are trying to model
processes in. The first stage in the methodology is to identify the “top level” entities and organizing
concepts in the domain.
BP Identification and
Discovery
BOM
Business
Reference Model
BOM
Model
Business Area
Business Area
Model
Process Area
Process Area
Model
Business Process
Identification
Business Process
Use Case
408
Figure 7-1 Business Process Identification and Discovery Worksheet to Metamodel Mapping
409
410
411
At this stage we define terminology and identify the participants as well as which business
processes those players interact with. To quote the UMM, at this stage in the model the goal is to:
412

To understand the structure and dynamics of the business domain,
413
414

To ensure that all users, standards developers and software providers have a common
understanding of the business domain,
415
416

To understand the daily business in the business domain independent of any technical
solution,
417
418

To create categories to help partition the business domain that enables an iteration plan to
complete the model,
419

To structure the model in the form of a Business Operations Map (BOM),
420

To capture the justification for the project,
421
422

To identify the stakeholders concerned with the modeled domain, some who will be
independent of the processes within the domain.
423
The modeling artifacts that correspond to the UMM are:
424

Business Area [Package]
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
18
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
425

Process Area [Package]
426

Process(es) [Use Cases]
427
428
429
January 2002
7.2. Guidelines
7.2.1 How does one decide how big to make the various groupings at this
level?
430
431
432
433
434
435
436
Referring back to the primary guidelines, think about what you are trying to communicate. If you
are more focused on identifying the public processes, then think about grouping them by partner
type or, perhaps by the area of your business these partners interact with. If you are trying to
formalize an entire business sector, determine the archetypes (patterns) that are prevalent in that
sector and group them by business function area. These are just rules of thumb and this is still
largely an “art”. Keep in mind your potential audience and think what would make the most useful
organization for them.
437
438
439
440
441
The activity diagrams in this workflow will likely discover more refined business process use cases.
The Business Operations Map (BOM) Metamodel allows a business process to be represented by
more refined business processes. NOTE: At the point where the business process can not be
broken down into more child business processes, the parent business process can be called a
business collaboration use case as specified in the Requirements workflow.
442
7.2.2 What is the boundary of the business area?
443
According to the [UMM] the following guidelines are to be used in defining a business area:
444
445
446
447
448

The business area can be defined by the stakeholders that have direct or immediate indirect
influence on the business domain. A stakeholder is defined as someone or something that is
materially affected by the outcome of the system but may or may not be an actor. Actors are
stakeholders that are involved in the business process and are thus part of the business
model.
449
450
451

The business area can be defined by the information passing into or out of the business
domain. Where possible, the domain boundaries should be chosen so that a business
transaction is logically or organizationally initiated and concluded within them.
452
453
454

The business area can be defined by key business entity classes. (i.e., things that are
accessed, inspected, manipulated, processed, exchanged, and so on, in the business
process)
455
456
457
458
459
460
461
7.3. Worksheets
The examples given in the following worksheets more or less come from the hypothetical business
process described in section 8.4 of [bpPROC].
7.3.1 Business Reference Model
Often times it is useful to define a “frame of reference” for the business processes being identified.
This frame of reference might define basic terms accepted by the given industry segment. For
example the SCOR model defines a frame of reference for supply chain. VICS defines a frame of
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
19
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
462
463
January 2002
reference for trading partners in the retail industry. It also might be a more horizontal view such as
the Porter Value Chain [PVC] (see table Appendix B).
Form: Describe Business Reference Model
Business Reference Model
Name
[Provide a name for the reference model. You can use an existing
reference model such as the Supply Chain Council or the Porter’s
Value Chain or create your own name.] DOTCOM DROP SHIP
RETAIL MODEL
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Industry Segment
[Provide the name of the industry segment that this business applies
to. Search the business process library for a list of possible industry
segments. If the industry segment does not exist, then provide an
appropriate name/label for the industry segment.] Retail.
Domain Scope
[Provide a high level statement that encapsulates the scope of all the
business areas.] Online catalog, distribution center, delivery, billing.
Business Areas
[List the business areas within the scope. A business area is a
collection of process areas. A process area is a collection of
business processes. You may wish to refer to the ebXML Catalog of
Business Processes that provides a list of normative categories that
may be used as business areas.] Order Management, AR.
Optional for ebXML
Business Justification
[Provide the business justification for the collection of business
processes] Define more efficient on-line retailer/vendor interaction.
464
465
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
20
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
466
467
468
469
470
January 2002
7.3.2 Business Area
As mentioned in the guidelines section, there are no hard and fast rules for how to divide up the
model into different business areas. One suggestion is to group business processes according to
the primary business function. You might consider using the Porter Value Chain [PVC]
classification scheme (see Appendix B).
Form: Describe Business Area
Business Area Name
[Provide a name for the business area. This should be listed in the
Business Areas section of at least one Business Reference Model.]
Direct to Customer Retail
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Description
[A brief summary of this functional area. ]
Scope
[Provide a high level statement that encapsulates the scope of all the
business areas. The scope of the business area must be within the
scope of the encompassing business reference model. Typically the
scope of the business area will be more constrained or limited than
the scope of the business reference model.] Online catalog, order
placement, distribution center, delivery, billing.
Boundary of the Business
Area
[Describe the boundary of the business area. This defines the entities
that interact in this business area; actors, organizations, possibly
systems] Customer, Retailer, DSVendor, Carrier, Credit Authority.
References
[Any external supporting documentation.] VICS, SCOR
Constraints
[Identify any constraints on the process areas (and, thus, business
processes) within this business area.] 1. Completely automated
system. 2. Web browser limitations. 3. Domestic orders only
Stakeholders
[Identify the practitioners that care about the definition of this business
area. At this level, this is likely to be some participants in an industry
group (perhaps a standards body or an enterprise). These are the
people who will define the BRV.] Customer, Retailer, DSVendor,
Carrier, Credit Authority.
Process Areas
[List the process areas within the scope. A process area is a
collection of business processes. You may wish to refer to the ebXML
Catalog of Business Processes that provides a list of normative
process groups that may be used as process areas.] Customer
Commitment, Order fulfillment, Billing, Inventory Management.
Optional for ebXML
Objective
[Describe the objective of this business area.] To deliver a product to
a customer in a timely efficient manner.
Business Opportunity
[Describe the business opportunity addressed by this business area.]
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
21
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
471
472
473
474
475
7.3.3 Process Area
Typically a business reference model would define a canonical set of process areas (see the
Porter or SCOR reference models for examples). A process area consists of a sequence of
processes that are combined to form the “value chain” of the given business area.
Form: Describe Process Area
Process Area Name
[Provide a name for the process area. This should be listed in the
Process Areas section of at least one Business Area.] Order
Fulfillment
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Objective
[Describe the objective of this process area.] To deliver the goods
ordered to the customer.
Scope
[Provide a high level statement that encapsulates the scope of all the
business areas. The scope of the business area must be within the
scope of the encompassing business reference model. Typically the
scope of the process area will be more constrained or limited than the
scope of the corresponding business area.] To fulfill customer’s order
using the third party supplier for a drop ship delivery.
References
[External supporting documentation.]
Boundary of the Process
Area
[Describe the boundary of the process area. The communicating
services.] Retailer and third party vendor.
[Issue: How is this different than Scope?]
Constraints
[Identify any constraints on the business processes within this
process area.] Inventory availability. On time delivery. System
constrain.
Stakeholders
[Identify the practitioners involved in this process area. Question: is
this a subset of those listed in the Business Area?.] Retailer, Third
party vendor
Business Processes
[List the business processes within the scope of this process area.
You may wish to refer to the ebXML Catalog of Business Processes
that provides a normative list of business processes.] Manage
Purchase Order.
Optional for ebXML
Business Opportunity
[Describe the business opportunity addressed by this process area.]
476
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
22
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
477
7.3.4 Identify Business Processes
478
479
480
481
482
For each business process in the process area fill in the following worksheet. A suggested rule of
thumb for the appropriate granularity for a business process is that it is the smallest exchange of
signals between stakeholders that has an identifiable economic value (cref. [REA]). Note that this is not
always appropriate since “negotiation” could be a valid business process but it doesn’t really result in an
economic consequence.
483
484
Be sure to validate the information in the process area against the encompassing business area. For
example, validate that the scope of the process area is within the scope of its business area.
Form: Identify Business Process
Business Process Name
[Provide a name for the business process. You may wish to refer to
the ebXML Catalog of Business Processes [bpPROC] that provides
a suggested set of commonly used business processes.] Manage
Purchase Order
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Process Area
[A process area is a group of business processes. Complete a
Process Area form.] Order Fulfillment
Business Area
[A business area group together related process areas. Create a
Business Area form.] Direct to Customer Retail
485
486
8. Business Process Elaboration
487
8.1. Goals
488
489
At this stage we begin to move from requirements analysis to design analysis. Consider the
following diagram:
Business
Process
Elaboration
BRV
Model
Business Process
Elaboration
Business Actor
BRV
Business Process
(Use Case)
Business Actor
490
491
492
493
Figure 8-1 Mapping from business processes to the BRV
A business process is the collaborative effort performed by two or more stakeholders to achieve
some business goal. Business processes are composed of business collaborations and business
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
23
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
494
495
496
497
498
499
January 2002
processes. Business collaborations are composed of business transactions and business
collaborations. Business collaborations and business transactions can be modeled using the
worksheet forms described in Sections 10 and 11, respectively. Business process use cases are
used to gather requirements about the business processes. Inputs to the business process must
be specified in the preconditions and outputs from the business process must be specified in the
post-conditions.
500
8.2. Worksheets
501
8.2.1 Business Process Use Case
502
503
504
One of these is filled out for each business process. Business process can be nested. You should
use whatever organization makes sense for your purposes (though you might want to think in
terms of reuse when considering possible decompositions).
505
506
507
508
A suggested rule of thumb for the appropriate granularity for a business process is that it is the
smallest exchange of signals between stakeholders that has an identifiable economic value (cref.
[REA]). In some cases, such as with negotiation business process, this heuristic does not appliy
since the process doesn’t result in an economic consequence.
Form: Business Process Use Case
Business Process Name
[Provide a name for the business process. This should be a name
identified on the form “Identify Business Process” and on a
“Describe Process Area” form. If you are starting with this form, you
may wish to refer to the ebXML Catalog of Business Processes that
provides a normative list of business processes.] Manage Purchase
Order.
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Identifier
[This is a unique identifier that follows the Business Process
Identifier Naming Scheme. This can be provided when the business
process description is submitted to a business process library. See
Appendix A for a more detailed discussion.]
bpid:ean.1234567890128:ManagePurchaseOrder$1.0
Description
[A set of simple sentences that state the actions performed as part
of the use case. Include references to use cases at extension
points.] A valid Purchase Order placed by retailer with the vendor
and a PO Ack is received from the vendor.
Actors
[List the actors involved in the use case.]
Performance Goals

Retailer

Vendor
[A specification of the metrics relevant to the use case and a
definition of their goals. Non-functional requirements may be a
source of performance goals. For each performance goal, provide
a name of the performance goal and a brief description of the
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
24
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
performance goal.]
Preconditions
[Preconditions are constraints that must be satisfied starting the use
case.]
1. Valid Sales Order
2. Valid Vendor Relation
Begins When
[Describe the initial event from the actor that starts a use case.]
Sales Order Validation (expressed as events)
Ends When
[Describe the condition or event that causes normal completion of
the use case.] PO Acknowledged returned to retailer.
Exceptions
[List all exception conditions that will cause the use case to
terminate before its normal completion.]
1. PO Rejected (Failure state of a process)
2. Late PO acknowledged
Postconditions
[Post-conditions are states that must be satisfied ending the use
case.]
1. Valid PO
2. Allocated Product
Traceability
[These are the requirements covered (as shown in Annex 4, Use
Case Specification Template, in the UMM).] PRD-SC-6.5.4
(meaning requirement 6.5.4 of the Product Requirements
Document for the Supply Chain project).
Supporting Business
Collaborations and
Business Processes
[List the business collaborations and business processes that
support (are part of) this use case.]

Manage Order
509
510
8.2.2 Business Process Activity Table
511
512
513
514
[Editor Note: Remove this section may not be needed: At the business process use modeling
level, it may not be important to have a formal model of how the sub-processes are
choreographed. The business process use case description should be sufficient to give a rough
idea what the flow is (can the description contain a list of steps?)]
515
516
517
Business processes can encapsulate other business processes and business collaborations. The
Business Process Activity Table worksheet is used to capture the choreography of business
processes and business collaborations that are sub-ordinate to the business process.
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
25
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
518
519
[Editor Note: we need to provide an example on how a business process activity graph can be
described the table]
520
A business process must contain at least one business collaboration.
Form: Business Process Activity Table
Business
Process Name
[Provide the name of the business process. Note that there should be a
corresponding Business Process Use Case form.]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Identifier
[Enter the Identifier from the associated Business Process Use Case form.
Transitions
From Business
Activity
(Transaction)
Initiating
Actor/Partner
Type
To Business
Activity
Responding/
Receiving
Actor/Partner
Type
Transition
Condition
[START for the
first activity or the
name of
originating
business process
or business
collaboration.]
[Actor or partner
type name or
NOTAPPLICABLE.]
[Name of
destination
activity (business
process or
business
collaboration).]
[Actor or partner
type name or
NOTAPPLICABLE.]
[A boolean
expression
defining or
describing the
condition for the
transition or
NONE.]
[Name of an
activity (business
process or
business
collaboration).]
NOTAPPLICABLE
SUCCESS
NOTAPPLICABLE
[A boolean
expression
defining or
describing the
condition for the
transition.]
[Name of an
activity (business
process or
business
collaboration).]
NOTAPPLICABLE
FAILURE
NOTAPPLICABLE
[A boolean
expression
defining or
describing the
condition for the
transition.]
521
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
26
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
522
9. Economic Elements
523
9.1. Goals
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
January 2002
These worksheets develop the economic elements of business processes as elaborated in the
REA ontology [REA]. The intent is to conform to the specific modeling elements of the Business
Requirements View (BRV) of the UMM. Not all business processes include economic exchanges
as defined by REA, so the use of these worksheets will occur in only a portion of business
processes and business collaborations. The semantics of legal ownership and GAAP (generally
accepted accounting principles) financial reporting depend upon correct modeling and
understanding of the BRV elements in this section.
9.2. Guidelines
There are three worksheets in this section. These worksheets model the following economic
entities: Economic Events, Economic Resources, Partner Types, Business Events, Agreements,
Economic Contracts, and Commitments. Building an Economic Exchange model with these
elements normally involves specification of two matching components of a marketplace exchange.
For example:
A shipment (economic event) of goods (economic resource) between a supplier and a
customer (partner types) occurs. This is normally followed by a payment (economic
event) involving cash (economic resource) between the same two parties (partner
types). This shipment for cash might have been preceded by quotes and pricing
exchanges (business events). The shipment might also be governed by a purchase
order (agreement or economic contract). This purchase order (economic contract)
might specify the expected types of goods (economic resource types) and the
expected dates of the shipments and payments (commitments).
The worksheets specify the items for an economic exchange and economic primitives for the
agreement that might govern that exchange. Not all economic exchanges are governed by
agreements or contracts, so the second worksheet will be used less frequently. Business
Collaborations as defined in the next section of worksheets might correspond to an entire
economic exchange, an economic event, or a business event. Collaborations may also
correspond to agreements or economic contracts.
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
27
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
551
9.3. Worksheets
552
9.3.1 Economic Contract
January 2002
Form: Economic Contract
Economic Contract Name
[The name of the economic contract. For example, Order or Order
Line.]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Business Object Type
[Name of the business construct (object) associated with the used
to convey the economic contract. For example,
PostpaidGoodsOrderLine.]
Document Type
Parties
Shipment Terms
Payment Terms
[List the party types associated with the economic contract. For
example, OrderDocument.ShipToParty,
OrderDocument.BillToParty, OrderDocument.ShipFromParty,
OrderDocument.RemitToParty.]
[Describe the shipment terms associated with the economic
contract. For example:
Customer takes ownership on receiving dock after counting
goods.
Carrier = OrderDocument.Carrier.
Delivery window 15 minutes before and after
GoodsCommitment.DueDateandTime.]
[Described the payment terms associated with the economic
contract. For example, “Net 30 days after Invoice.accepted.”]
Goods Commitment
[Identify the information location of the ship-to party. For example,
“defaults to Order.ShipToParty.”]
[Example, “refer to GoodsSpecification.”]
Ship To Party
What
How Much
When
Shipment Terms
[Describe the information element that specifies the quantity of
goods being committed. For example,
“OrderLineDocument.Quantity within tolerance.”]
[Describe the information element that specifies when the goods
are to be delivered. For example,
“OrderLineDocument.DueDateandTime adjusted by
GoodsCommitment.ShipmentTerms.”]
[Describe the shipment terms associated with the economic
contract. For example:
Customer takes ownership on receiving dock after counting
goods.
Carrier = OrderDocument.Carrier.
Delivery window 15 minutes before and after
GoodsCommitment.DueDateandTime.]
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
28
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
Exceptions
Name
[For example, timeConstraintViolation.]
Expression
[For example, “System.Time > GoodsCommitment.When.”]
Action
[For example, “trigger NotifyOfPenalty activity.”]
…
…
Name
[For example, “PartialFulfillment.”]
Expression
[For example, “GoodsTransfer.Quantity <
GoodsCommitment.HowMuch.”]
[For example, “GoodsCommitment.State := PartiallyFulfilled.”]
Action
Payment Commitment
What
[Identify how the payment commitment is to be fulfilled. For
example, “ElectronicFundsTransfer.”]
How Much
[Describe the informational element(s) that determine how much is
to be paid. For example, “OrderItemDocument.UnitPrice *
GoodsTransfer.Quantity.”]
Remit To Party
[Identify the informational element(s) that identify the remit-to party.
For example, “defaults to Order.RemitToParty.”]
Payment Terms
[Identify the informational element(s) that describe the payment
terms. For example, “Order.PaymentTerms.”]
553
554
9.3.2 Economic Resource Type
Form: Economic Resource Type
Economic Resource Type
Name
[The name of the economic resource type. For example, :Product
For Resale.”]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Business Object Type
[Name of the business construct (object) associated with the used
to convey the economic contract. For example, ProductForResale.]
Source
Goods Identifier
[Identify the informational element the identifies the goods or
services. For example, OrderItemDocument.ProductID.]
Description
[Identify the informational element that contains the description of
the goods. For example, OrderItemDocument.ProductDescription.]
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
29
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
Specifications
Specification Type
[Provide a name/label for an attribute of the goods type. For
example, Color.]
Test
[Describe how goods are validated against values of the
specification type. For example, “visual comparison to swatch.”]
Value
[Identify the informational element that contains the value
corresponding to the specification type. For example,
OrderItemDocument.Color.]
…
…
Specification Type
[Provide additional Specification Types and corresponding Tests
and Values as needed.]
Test
[Provide additional Specification Types and corresponding Tests
and Values as needed.]
Value
[Provide additional Specification Types and corresponding Tests
and Values as needed.]
555
556
9.3.3 Economic Event Resource Type
Form: Economic Event
Economic Event Name
[The name of the economic event. For example, :Goods Transfer.”]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Business Object Type
[Name of the business construct (object) associated with the used
to convey the economic contract. For example, GoodsTransfer.]
Document Type
Economic Commitment
Parties
[List the informational elements that identify the parties associated
with the economic event. For example:
GoodsTransferDocument.ShipToParty
GoodsTransferDocument.ShipFromParty
Economic Resource Type
[Identify the informational element(s) that specify the economic
resource type. For example, GoodsTransferDocument.ProductID.]
Event Time
[For example, GoodsTransferDocument.EventTime.]
Quantity
[Identify the informational element(s) that specify the amount of
economic resources associated with the economic event. For
example, GoodsTransferDocument.Quantity.]
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
30
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
557
558
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
31
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
559
10. Business Collaboration
560
10.1.Goals
561
January 2002
These worksheets develop the Business Requirements View (BRV) of a process model.
562
Business
Collaboration
BRV
Business Collaboration Use Case
Use Case
Business Transaction Use Case
Use Case
Business Collaboration
Partner Type
Business Collaboration
Collaboration
Partner Type
Choreography states, transitions, etc.
563
564
565
Figure 10-1 Mapping from Business Collaboration to BRV
The following items are specified:
566

The business collaboration protocols that tie economic events together
567

The system boundaries between which the protocols flow
568

The input and output triggers of these collaborations
569

The roles and constraints associated with the collaboration
570
The purpose of the Partner Collaboration Worksheets is:
“… to capture the detailed user requirements, specified by the stakeholders, for the businessto-business project. … This workflow develops the Business Requirements View (BRV) of a
process model that specifies the use case scenarios, input and output triggers, constraints and
system boundaries for business transactions (BTs), business collaboration protocols (BCPs)
and their interrelationships.” ([UMM, 3.1])
571
572
573
574
575
576
The modeling artifacts to be identified are:
577

Business Transactions [Use Case]
578

Business Collaboration [Use Case]
579

Business Collaboration Use Case [Use Case Realization, Activity Diagram]
580

Economic Consequences of Business Collaborations
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
32
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
581
582
583
10.2.Guidelines
The Initiating Partner Type and the Responding/Receiving Partner Type in the Business
Collaboration form and the Business Collaboration Protocol Table forms must be the same.
584
10.3.Worksheets
585
10.3.1 Business Collaboration
586
587
January 2002
Detail the information in the table below for each business collaboration. Note that it may make
sense to use UML diagrams to convey some of this information.
Form: Business Collaboration
Business Collaboration
Name
[Provide a common name for the business collaboration.]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Identifier
[This is a unique identifier that follows the Business Process Identifier
Naming Scheme. This can be provided when the business process
description is submitted to a business process library. See Appendix A
for a more detailed discussion.]
Description
[Provide a descriptive overview of the collaboration.]
Preconditions
Begins When
Ends When
Exceptions
Postconditions
Initiating Partner Type
[This is the entity that initiates (and participates) in the collaboration.
These participants exchange the events that form the collaboration.
These partner types will be found in the corresponding Business
Collaboration Protocol Table.]
Responding/Receiving
Partner Type
[This is a list of entities that respond to or are on the receiving end of
transaction activities in the collaboration. These participants exchange
the events that form the collaboration. These partner types will be
found in the corresponding Business Collaboration Protocol Table.]
Authorized Roles
[These are the roles that a partner must be authorized to play to issue
specific transactions in the collaboration (by sending certain signals).]
Legal Steps/Requirements
[If any step in the collaboration has any legal standing, it should be
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
33
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
captured here.]
Economic Consequences
[If any step in the collaboration has and economic consequence, it
should be captured here.]
Initiating Events
[List the event(s) that initiates this collaboration. If the collaboration
can be initiated by more than one event, separate the event conditions
by an “OR” or list them in a bulleted list.]
Terminating Events
[List the event(s) that terminate this collaboration. If the collaboration
can be terminated by more than one event, separate the event
conditions by an “OR” or list them in a bulleted list.]
Scope
[Specify the set of business actions this collaboration encapsulates.]
Boundary
[Specify the systems and users that communicate with each other
over he course of this collaboration.]
Constraints
[Spell out any special constraints that are relevant to this collaboration
(e.g. business scenario, pre-conditions.)]
Supporting Business
Transactions and Business
Collaborations
[List the business transactions and business collaborations that
support (are part of) this business collaboration.]
588
589
10.3.2 Business Collaboration Activity Table
Form: Business Collaboration Activity Table
Business
Collaboration
Name
[Provide the name of the business collaboration. Note that there should be a
corresponding Business Collaboration form.]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Identifier
[Enter the Identifier from the associated Business Collaboration form.
Transitions
From Business
Activity
(Transaction)
Initiating Partner
Type
To Business
Activity
Responding/
Receiving
Partner Type
Transition
Condition
[START for the
first activity or the
name of
originating
business activity.]
[Partner type
name or NOTAPPLICABLE.]
[Name of
destination
business activity.]
[Partner type
name or NOTAPPLICABLE.]
[A boolean
expression
defining or
describing the
condition for the
transition or
NONE.]
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
34
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
[Name of an
activity.]
NOTAPPLICABLE
SUCCESS
NOTAPPLICABLE
[A boolean
expression
defining or
describing the
condition for the
transition.]
[Name of an
activity.]
NOTAPPLICABLE
FAILURE
NOTAPPLICABLE
[A boolean
expression
defining or
describing the
condition for the
transition.]
590
591
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
35
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
592
11. Business Transactions and Authorized Roles
593
11.1.Goals
January 2002
594
595
596
The goal of this worksheet is to identify the individual transactions that implement the workflow of a
Business Collaboration. A transaction is made up of several activities and each activity has an
authorized role that the signaler must have in order to initiate that activity.
597
598
The modeling artifacts generated as a result of this worksheet is the BusinessTransaction Activity
Diagram. Fill out one worksheet for each transaction in the collaborations
599
11.2.Guidelines
600
11.2.1 Use Transaction Patterns
601
602
603
The UMM has defined several transaction patterns that should be used to define business
transactions. By the use of these patterns one can be assured that the transaction is legally binding
in accordance with current global and regional legal writings (see UMM for further details).
604
605
606
607
608
609
610
611
612
613
614
These patterns have intrinsic semantics (e.g. property-values such as non-repudiation and
authorization) associated with them. If you choose to base the transaction on one of these patterns
you do not have to repeat the property values here (although you may wish to do so that all
information is specified in one place). However if you do not base the transaction on an UMM
pattern, described the property values in the Business Transaction Property Values form. Note
that if you do not follow a prescribed pattern, the business transaction may not comply with
generally acceptable legally binding transaction semantics. If you wish to “override” the semantic
property-values, use the Business Transaction Property Values form and keep in mind that when
you change the property values, the pattern may no longer be applicable. In this case, you should
not specify a pattern name. Do not provide values for Non-Repudiation Of Receipt and
Recurrence for Responding Business Activity (this is specified by the UMM).
615
616
617
618
619
620
621
11.2.2 Detail Transaction Activities Only If Necessary
The transaction patterns defined in the UMM should be sufficient to cover most business cases.
However, it may be necessary or desirable to describe the business transaction activity in terms of
the allowable transitions between the activities. An UMM compliant activity diagram (UML) can be
created or a Business Transaction Transition Table can be used to convey the same information.
Refer to the examples in Appendix C, to see how Business Transaction activity diagrams are
represented in Business Transaction Transition Table forms.
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
36
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
622
11.3.Worksheets
623
11.3.1 Business Transaction
January 2002
Form: Business Transaction
Business Transaction
Name
[Provide the common name for the business transaction.]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Identifier
[This is a unique identifier that follows the Business Process
Identifier Naming Scheme. This can be provided when the business
process description is submitted to a business process library. See
Appendix A for a more detailed discussion.]
Description
[Provide a descriptive overview of this transaction.]
Pattern
[If you have chosen to follow one of the canonical transaction
patterns in the UMM9 (or elsewhere) denote it here. If not and you
have special semantics (as mentioned above), describe them here.]
Business activities and
associated authorized roles
[List each activity (along with its initiator) and the role required to
perform that activity]
Constraints
[Any constraints should be listed here.]
Initiating/Requesting
Partner Type
[Partner type from collaboration.] Customer
Initiating/Requesting
Activity Role
[These are the roles that a partner must be authorized to play to
issue specific transitions in the transaction (by sending certain
signals).] Buying Customer
Initiating/Requesting
Activity Document
[Document initiating the transaction. Might reference a standard
document (e.g. an X12 document). ] Sales Order
Initiating/Requesting
Activity
[Optional. Name of the initiating activity. This should be provided if
the activity is known to be common to other business transactions.]
Submit Sales Order
Responding Partner Type
[See above.] On-line Retailer
Responding Activity Role
[See above.] Customer Service
Responding Activity
Document
[See above.] Confirmation email
Responding Activity
[Optional. Name of the responding activity. This should be
provided if the activity is known to be common to other business
transactions.] Process Sales Order
9
See chapter 4 in [UMM].
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
37
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
Predecessor Transactions
[Optional. List
that typically
information is
collaboration,
information.]
the business transactions or “transaction families”10
occur before this business transaction.
This
helpful in understanding the overall business
business process, and the flow of business
Successor Transactions
[Optional. List the business transactions or “transaction families”
that typically occur after this business transaction. This information
is helpful in understanding the overall business collaboration,
business process, and the flow of business information.]
624
10
Need a good definition for transaction family and how one would indicate in the form that something was a business
transaction and that something was a transaction family. Do transaction families align with process areas?
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
38
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
625
626
627
628
January 2002
11.3.2 Business Transaction Property Values
Complete the following property-values for requesting business activities and responding business
activities if they differ from the default values defined in the UMM transaction patterns. You may
wish to copy the values from the UMM as a convenience to the readers.
Form: Business Transaction Property Values
Business Transaction
Name
[Provide the common name for the business transaction. The name
should be the same as the Business Transaction Name in the
corresponding Business Transaction form.]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
System Flow Of Control
[ASYNCHRONOUS, SYNCHRONOUS, AS-AGREED-BY-PARTIES.
In asynchronous communication, the communication channel is closed
after each business message is transmitted. In synchronous
communication, the communication channel is left open until after the
response business message is received. Specify AS-AGREED-BYPARTIES to indicate that the flow of control will be specified in trading
partner agreements (e.g. ebXML Collaboration Protocol
Agreements).11]
Non-Repudiation
of Receipt
Recurrence
Non-repudiation
of Origin and
Content
[time]
Authorization
Required
[time]
[time]
Time to Perform
Responding
Business
Activity
[time]
Time to
Acknowledge
Acceptance
Time to
Acknowledge
Receipt
Initiating
Business
Activity
[time]
[true or
false]
[true or
false]
[true or
false]
[whole
number]
[time]
[true or
false]
[true or
false]
NOTAPPLICA
BLE
NOTAPPLICA
BLE
629
630
631
632
11.3.3 Business Transaction Activity Table
Provide a Business Transaction Activity Table if needed. See guidelines section “Detail
Transaction Activities Only If Necessary.”
Form: Business Transaction Activity Table
11
Although system flow of control is a Collaboration Protocol Profile/Agreement parameter, it is provided in this table
since it may be discussed during the analysis of the business transaction. If your audience is familiar with collaboration
protocol profiles and agreements, you many want to remove this field from the worksheet.
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
39
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
Business
Transaction
Name
[Provide the common name for the business transaction. The name should be the
same as the Business Transaction Name in the corresponding Business
Transaction form.]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Transitions
From Activity
From Role
Document
To Activity
To Role
Guard
Condition
[Name of the
“from” activity.
The keyword
START shall
be used for
the first
activity.]
[A
Requesting/Ini
tiating Activity
Role or NOTAPPLICABLE.
NOTAPPLICABLE
is to be used
when the
From Activity
is START.]
[Document
name or
NONE.]
[Name of the
destination
activity or
keyword END
or keyword
CONTROLFAILED.]
[A
Responding
Activity Role
or NOTAPPLICABLE.
]
[A boolean
expression
defining or
describing the
condition for
the transition
or NONE.]
[Name of the
last activity
before the
END state]
[Appropriate
role name.]
NONE
END
NOTAPPLICABLE
[Expression of
the guard
condition.]
[Name of the
last activity
before the
CONTROLFAILED
state.]
[Appropriate
role name.]
NONE
CONTROLFAILED
NOTAPPLICABLE
[Expression of
the guard
condition.]
633
634
11.3.4 Initiating and Responding Activity Key Informational Elements
635
636
637
638
Two worksheets are provided for documenting the key informational elements that are important to
a transaction. These worksheets are optional; however, they can be very helpful in achieving
document element level interoperability (particularly in cases where document schemas are used
in different business transactions). Key elements include, but are not limited to, the following:
639
640

Information that is necessary or helpful in correlating the exchanged business documents
within the same transaction or across multiple transactions
641
642

Information that is critical or has proven to be problematic in the past for integration and
interoperability of the services participating in the business transaction
643

Specification of code lists and subsets of code lists
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
40
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
644

645
646
Do not use these worksheets for specifying all the required informational elements in business
messages. Instead use the Document Content Description form in Section 12.3.2.
647
648
649
Note that this information in these worksheets may ultimately be specified as part of a
Collaboration Protocol Profile or Collaboration Protocol Agreement [ebCPPA] rather than as part of
a more generic business process model.
650
651
652
These worksheets are completed for each activity that has key elements. Document elements
within document sub-structures are described at the activity level rather than in separate tables (as
with the Content Description forms in section 12).
Constraints on the values in the business documents or message headers
Form: Initiating Activity Key Informational Elements
Business
Transaction Name
[Provide the common name for the business transaction. The name should be
the same as the Business Transaction Name in the corresponding Business
Transaction form.]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Content Description
Name
[A name for the content. For example, “Order.” For document schema specific
modeling you may also provide the schema reference/namespace.] Order
Status Enquiry [UNEDIFACT:D.10B:OSTENQ]
Components
Name
Notes
Path
[Provide a name for
the
element/component.
For example, “Order
Summary” or “Issued
Date.”]
[Describe the semantics of the
element within the initiating
business transaction activity.
Describe any constraints on its
value and any relationship to other
elements in the same or different
documents in the same or different
transaction.]
[For XML documents, provide the
XPATH to the element name and the
associated namespace. For non-XML
documents, provide an XPATH
equivalent to the element.]
653
[Notes from Brian Hayes:
654
655
656
657
658
659
1. The path entry needs some more thought since a path is associated with a specific
document schema or, possibly, some accepted business object model of the data. The
schema/namespace is identified in the Content Description Name field (as described above)
or in new fields at the header level (see fields Standard and Version in the Content Mapping
form). Clearly this form has its limitations if you want specify paths in other schemas – which
might be best done with the Content Mapping form in section 12.3.3.
660
661
662
663
664
2. What kind of relationship, if any, should there be between the Element/Component Name
field values and the Element/Component Name field values in the Content Description forms
(section 12.3.2) and the Content Mapping form (section 12.3.3)? If there should be a
relationship, then there is a relationship challenge since we have currently defined that there
is only a single key element table per business document and there can be multiple Content
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
41
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
Description forms per business document. Should a path notation be used in the key
element forms?
665
666
]
667
Form: Responding Activity Key Informational Elements
Business
Transaction Name
[Provide the common name for the business transaction. The name should be
the same as the Business Transaction Name in the corresponding Business
Transaction form.]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Content Description
Name
[A name for the content. For example, “Order.”]
Components
Name
Notes
Path
[Provide a name for
the
element/component.
For example, “Order
Summary” or “Issued
Date.”]
[Describe the semantics of the
element within the responding
business transaction activity.
Describe any constraints on its
value and any relationship to other
elements in the same or different
documents in the same or different
transaction.]
[For XML documents, provide the
XPATH to the element name and the
associated namespace. For non-XML
documents, provide an XPATH
equivalent to the element.]
668
669
12. Business Information Description
670
12.1.Goals
671
672
673
The goal of this set of worksheets is to identify the information requirements for the business
documents specified in the business transactions.
12.2.Guidelines
674
675
676
677
678
679
680
The first step in specifying business documents in a business process and information model, is to
attempt to reuse business information objects in a Business Library. If an existing business
document cannot be found then, domain components from Domain Libraries and core components
from the Core Library can be used. Until the Business Library is built up, or imported from a
creditable source, core components are likely to be referred to frequently, to first add to the
repertoire of business information objects in the Business Library, and second, to create business
documents.
681
The steps for completing these worksheets are as follows:
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
42
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
682
683
1. See what attributes are available in business information objects in the available Business Libraries
that can be used in a business document.
684
685
2. If business information objects with appropriate attributes as required for business documents are
not available, new business information objects must be created.
686
687
688
689
3. Look for re-usable information components in the business library and the Core Library as
candidates for business information object attributes. Take context into account, as specified in the
business process and information models. Extend existing business information objects, domain
components, and core components as required.
690
691
4. Add the new attributes to existing business information objects, or introduce new business
information objects through a registration process that manages changes to the Business Library.
692
693
5. Use the new attributes, now in the Business Library, as needed in creating the business
documents.
694
12.3.Worksheets
695
12.3.1 Business Information Context
696
697
698
699
700
The Business Information Context form is provided as convenience for aggregating contextual
values that effect the analysis of business information. It is intended that this information be
obtained from other forms. For example, Industry Segment is specified in the Business Reference
Model form. If there is no value for an entry, enter NOT-APPLICABLE or NONE which ever is
appropriate.
Form: Business Information Context
Business Information
Context Name
[Provide a name for the business information context. Typically this
is the name of the associated business transaction. However, it
may be appropriate to name it after the name of the associated
business collaboration, or higher-level business process construct.]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Industry Segment
Business Process
Product
Physical Geography
/Conditions /Region
Geo-Political Legislative/
Regulatory/ Cultural
Application Processing
Business Purpose /Domain
Partner Role
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
43
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
Service Level (profiles – not
preferences.)
Contracts/Agreements
701
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
44
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
702
703
704
705
706
707
708
709
710
May 2001
12.3.2 Document Content Description
Describe each element or group of elements in the document. Logically related elements can be placed in separate forms (For example, a
document may have logically three parts, a header, body, and summary. The body may have further logical partitioning.). Possible values for
Occurs include: 1 (one instance), 0..1 (zero on one instance), 0..* (zero or more instances), 1..* (one or more instances), or n..m (n to m
instances where n is less than m). Information “looping” is specified through appropriate occurs values. Possible values for Data Type include
primitive data types – such as integer, string, date-type – or a Form Id of another Content Description Form. Referencing another Content
Description Form Id represents information hierarchy and nesting. If you happen to know the name of a reusable component from an domain
library or the Catalog of Core Components, then you MAY reference it. The Semantic Description SHALL be stated in business terms and
SHALL be unambiguous.
Form: Content Description
Content Description Name
[A name for the content. For example, “Order Header.”]
Form Id
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Description
[Provide a semantic description of the information collection]
Components
Name
Occurs
Data
Type
Field
Width
Semantic Description
Notes
[Provide a name for the
element/component. For
example, “Order Summary”
or “Issued Date.”]
711
712
713
714
715
12.3.3 Content Mapping
These forms SHOULD be completed. This information is very important as it shows that the documents have a basis in existing standards.
Furthermore, the information will be used to create document transformations. Standards to map to include EDIFACT, X12, xCBL,
RosettaNet, and other standards such as OBI. Use XPATH and XSLT notation for referencing XML elements and describing the mappings.
46
Business Process Analysis Worksheets and Guidelines
Copyright © ebXML 2001. All Rights Reserved.
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
716
717
If a new document schema is created to fulfil the content requirements specified in the Document Content Description forms, then a set of
Content Mapping forms should be completed for that schema (the component names in the forms are simply requirements for information)
718
For each Content Description form, complete a Document Content Mapping form for each standard to be cross-referenced.
Form: Content Mapping
Content Description
Name
[Provide the name of the associated content. For example “Order Header.”]
Form Id:
[Provide an ID for this form so other forms can reference it (§6.1.9)]
Content Description
Form Id
[Provide the identifier of the associated Content Description form]
Standard
[Name of the standard. For example, UN/EDIFACT]
Version
[Standard version number. For example, D.01A]
Components
Name
Mapping/Transformation
Note
[Enter
element/component
name from
corresponding Content
Description form]
[Mapping or transformation. If the element/component is a
complex structure, this entry should reference the appropriate
Content Mapping form.]
[Any useful mapping notes.]
719
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
47
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
January 2002
720
Appendix A The Porter Value Chain
721
722
723
The following table shows the categories of the Porter Value Chain [PVC] and how they map to
Economic Elements concepts. This is included as an aid to help users formalize their classification of
the elements of a business process specification.
Normative
Category
Normative SubCategory
Resource inflows &
outflow
Major types of
events
Economic Agents &
Roles
Procurement
Bid Submission
Money
Payments
Buyer
Contract
Negotiation
Raw materials
Purchase
Seller
Human Resources
Facilities
Purchase Orders
Vendor
Purchase Order
Preparation
Services
Price Quotes
Cashier
Receiving
Technology
Contract
Negotiation
Hiring
Money
Cash Payments
Employee
Training
Purchased training
materials
Acquisition of labor
Student
Training
Beneficiary
Payroll
Management
Personnel
Deployment
Transportation
Purchased benefit
packages
Loading
Raw Materials
Shipment
Buyer
Shipping
Delivered Raw
Materials
Warehousing
Tasks
Vendor
Manufactured
Goods
Material Handling
Packaging
Logistics Worker
Trucker
Trucking
Delivered
Manufact. Goods
Manufacturing
Product
Development
Facilities &
Technology
Manufacturing
Operation
Product Design
Labor
Raw Material Issue
Assembly
Raw Materials
Manufacturing Job
Quality control
Finished Goods
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
Factory Worker
Supervisor
QC Inspector
49
Business Process Project Team
January 2002
Normative
Category
Normative SubCategory
Resource inflows &
outflow
Major types of
events
Economic Agents &
Roles
Marketing & Sales
Advertising Use &
Campaigning
Labor
Cash Payment
Customer
Customer Service
Advertising Service
Customer Invoice
Salesperson
Marketing
Management
Delivered Goods
Sale Order
Cashier
Sales Calling
Product Services
Price Quotes
Customer Credit
Management
Cash
Contract
Negotiation
After Sales Service
Labor
Service Call
Warranty
Construction
Purchased
Services
Product Repair
Service Contract
Customer Service
Agent
Customer
Product Warranties
and Services
Financing
Loan Management
Cash
Interest Payments
Stockholders
Stock Subscriptions
and Sales
Bonds
Stock Subscriptions
BondHolders
Stocks
Dividend
Declarations
Investment Brokers
Dividend Policy
Administration
Accounting
Derivative
Instruments
Employee Labor
Financial Reporting
Executive
Management
Financial Managers
Cash Receipts
Employee Service
Managers
Management
Projects
Clerks
724
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
eBTWG Business Collaboration Patterns and Monitored Commitments Project Team
May 2001
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
Appendix B Disclaimer
The views and specification expressed in this document are those of the authors and are not
necessarily those of their employers. The authors and their employers specifically disclaim
responsibility for any problems arising from correct or incorrect implementation or use of this
design.
Appendix C Contact Information
Business Process Project Team
Core Components/Business Process (CC/BP) Analysis Team Lead
Name:
Brian Hayes
Company:
Commerce One
Street:
4440 Rosewood Drive
City, State, ZIP/Other: Pleasanton, CA
Nation:
USA
Phone:
+1 (925) 788-6304
EMail:
brian.hayes@UCLAlumni.net
Editors
Name:
Company:
Street:
City, State, ZIP/Other:
Phone:
EMail:
Charles Fineman
Arzoon
1950 Elkhorn Court
San Mateo, CA 94403
+1 (650) 357-6052
fineman@arzoon
Name:
Company:
Street:
City, State, ZIP/Other:
Nation:
Phone:
EMail:
Brian Hayes
Commerce One
4440 Rosewood Drive
Pleasanton, CA
USA
+1 (925) 788-6304
brian.hayes@UCLAlumni.net
Name:
Company:
Street:
City, State, ZIP/Other:
Nation:
Phone:
EMail:
Jennifer Loveridge
Nordstrom.com
600 University Street, Ste. 600
Seattle, WA
USA
Jennifer.Loveridge@Nordstrom.com
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
52
Business Process Project Team
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
January 2002
Name:
University:
Street:
City, State, ZIP/Other:
Nation:
Phone:
EMail:
William E. McCarthy
Michigan State University
N270 North Business Complex
East Lansing, MI
USA
+1 (517) 432-2913
mccarth4@msu.edu
Name:
Company:
Street:
City, State, ZIP/Other:
Nation:
Phone:
EMail:
David Welsh
Nordstrom.com
600 University Street, Ste. 600
Seattle, WA
USA
+1 (206) 215-7293
David.Welsh@Nordstrom.com
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
Business Process Project Team
January 2002
783
Copyright Statement
784
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.
785
786
787
788
789
790
791
This document and translations of it may be copied and furnished to others, and derivative works
that comment on or otherwise explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such as by removing the copyright
notice or references to ebXML, UN/CEFACT, or OASIS, except as required to translate it into
languages other than English.
792
793
794
795
796
797
The limited permissions granted above are perpetual and will not be revoked by ebXML or its
successors or assigns. This document and the information contained herein is provided on an "AS
IS" basis and ebXML DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
798
Business Process Analysis Worksheets and Guidelines
Copyright © UN/CEFACT and OASIS, 2001, 2002. All Rights Reserved.