Summary
The primary objective of the ebXML initiative is to enhance global e-business integration by focusing on public processes that govern interactions between external entities and e-businesses Recognizing the significant costs associated with specifying and integrating these processes, ebXML advocates for the use of Business Libraries These libraries aim to promote the reuse of common business processes and objects while providing a centralized location for companies and standards bodies to share their public process specifications, ensuring that appropriate trading partners can easily access them.
To achieve its objectives, the ebXML community has chosen to utilize the semantic subset of the UMM Metamodel as a common language, ensuring that all users of the repository can clearly understand one another's specifications.
UN/CEFACT Modeling Methodology in the N090 specification.
The UMM is designed for professionals skilled in modeling methodologies who lead business process analysis sessions and offer modeling assistance Additionally, it acts as a checklist for standardized models when a defined business process is submitted to UN/CEFACT for integration as a standard business process model.
This document offers a collection of worksheets designed to assist analysts in creating UMM-compliant specifications for their business processes It aims to provide valuable tools for users, whether representing a standards body or an individual company Additionally, it includes various scenarios to illustrate different approaches to completing the worksheets, such as top-down and bottom-up methods The UMM serves as a reference for comprehending the intricacies of the underlying Metamodel and UMM methodology.
Worksheets require varying degrees of rigor, with lower levels necessitating specific elements and organization to align with the ebXML technical framework Conversely, higher levels allow more flexibility in how concepts are grouped, often leading to the use of natural language for specifying assumptions and constraints instead of formal language.
Audience
Users of these worksheets are not required to be experts in business modeling; however, they should possess in-depth knowledge of their specific fields It is essential for them to understand the inter-enterprise business processes that facilitate communication with their trading partners.
Industry experts can utilize this document to articulate their sector's business processes in a manner that aligns with the objectives of the ebXML registry and repository.
Of course, software vendors that are supplying tools (modeling and otherwise) in support of the ebXML framework will find useful information within.
Related documents
[ebCNTXT] ebXML Concept - Context and Re-Usability of Core Components Version 1.04 11 May, 2001 ebXML Core Components Project Team.
[ebRIM] ebXML Registry Information Model Version 1.0 11 May 2001 ebXML Registry Project Team.
[ebRS] ebXML Registry Services Version 1.0 11 May 2001 ebXML Registry Project Team.
[ebTA] ebXML Technical Architecture Specification Version 1.0.4 16 February 2001 ebXML Technical Architecture Project Team.
[bpOVER] Business Process and Business Information Analysis Overview Version 1.0 Date 11 May 2001 ebXML Business Process Project Team
[bpPROC] ebXML Catalog of Common Business Processes Version 1.0 Date May 11, 2001 ebXML Business Process Project Team
[PVC] Michael E Porter, Competitive Advantage: Creating and Sustaining Superior
Performance, 1998, Harvard Business School Press.
[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
[SCOR] Supply Chain Operations Reference model, The Supply Chain Council
(http://www.supply-chain.org/)
[UMM] UN/CEFACT Modeling Methodology CEFACT/TMWG/N090R9.1 UN/CEFACT Technical Modeling Working Group.
Document conventions
In this document, the terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be understood according to the definitions provided in RFC 2119.
Heretofore, when the term Metamodel is used, it refers to the UMM e-Business Process
Metamodel as defined in [UMM].
Goals/objectives/requirements/problem description
ebXML business processes are outlined through the UMM e-Business Process Metamodel, which details the essential information required for analyzing electronic commerce processes within the ebXML framework This Metamodel serves as a guideline to ensure comprehensive data capture during the evaluation of e-business activities.
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.
The ebXML Business Process Worksheets serve as essential design tools for creating business processes aligned with the UMM Metamodel These worksheets are designed to be adaptable to meet unique business requirements By utilizing the UMM Metamodel, an ebXML business process can effectively encompass all critical elements necessary for registration and implementation within an ebXML-compliant electronic trading environment This worksheet-based methodology simplifies the application of the UMM and its Metamodel, enhancing usability for businesses.
The purpose of worksheets, or a business process editor, is to gather all necessary information to thoroughly define a business process This comprehensive documentation enables effective registration, classification, discovery, and reuse, ultimately facilitating the complete automation of software operations.
To establish business processes for an ebXML compliant electronic trading relationship, utilize the UMM as a guiding framework alongside the ebXML Business Process Worksheet to formulate essential business process models Following these recommended steps will ensure effective use of the ebXML Business Process Worksheets.
1 A business need or opportunity is identified and defined before using these procedures.
A Focus Project Team, composed of multifunctional experts from IT, business process ownership, and business process specialists, is essential for effectively developing business processes utilizing the ebXML Business Process Worksheet.
The Focus Project Team will utilize the ebXML Business Process Worksheets to create a comprehensive ebXML Business Process Specification for business review and verification Furthermore, essential information will be provided to populate the ebXML Metamodel, facilitating the establishment of an effective 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.
The analogy
The analogy presented highlights the significance of Worksheets and various documentation tools in relation to the ebXML Business Process Collaboration Metamodel and the UN/CEFACT Modeling Methodology, illustrating their essential roles in enhancing understanding and implementation.
Item United States Internal Revenue Service (IRS) Tax
System ebXML Business Process Collaboration Metamodel
Worksheets and Templates IRS Forms
Methodology Guidelines IRS Instruction Booklets
Business Process Editor Tool Suite
Repository of Business Process Specifications, Core
TurboTax and similar software solutions offer online access to personal and business tax forms, enabling users to efficiently search and manage their tax records and related information These tools simplify the tax preparation process by providing comprehensive resources, including the latest tax code updates, ensuring users stay informed and compliant with tax regulations.
In order to actually specify a business process all we really need is the Worksheets and
To effectively utilize templates, it is essential to have comprehensive instructions that not only guide us in filling out the forms accurately but also explain the reasoning behind their structure.
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
Caveats and assumptions
This document serves as a non-normative reference, with the aforementioned documents being the authoritative sources for the definitions and specifications of the terminology used Its purpose is to apply the principles and technologies outlined in those authoritative texts.
This document aims to offer worksheets that assist users in creating a UMM-compliant specification for their business processes The accompanying diagram illustrates how these worksheets correspond to the key components of the UMM Please note that the document definition worksheet is not included in this set.
Figure 5-2: Overview of mapping from Worksheets to Metamodel
Upon completing the worksheets, we anticipate having enough information to automatically generate a Metamodel-based specification of the modeled business processes The provided worksheets serve as essential tools in this process.
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 )
Business Process Identification and Discovery
Business process identification and discovery involves conducting an inventory of existing business processes This step primarily focuses on outlining high-level use cases to recognize the presence of various processes and their associated stakeholders, without delving into intricate details.
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.
Business collaboration refers to the economic events essential for executing business processes, where the system boundaries and information flow protocols are clearly defined.
A business transaction refers to the specific activities and authorized individuals within an organization that initiate these transactions Unlike other worksheets that focus more on modeling, these are designed to provide a technical understanding of the processes involved.
Business information definition involves outlining the essential elements such as information field widths, data types, descriptions, and requirement traceability Additionally, it may include the necessary context ([ebCNTXT]) needed to effectively construct the document from the Core.
Basic guidelines for filling out worksheets
Focus on public business processes
The ebXML initiative aims to simplify and enhance trading partner integration by providing worksheets that can model various business processes The emphasis is on improving the public-facing aspects of these processes, making them more accessible and cost-effective for businesses.
The REA ontology
The UMM and ebXML groups advocate for utilizing the Resource-Economic Event-Agent Ontology to formalize business collaborations For more details and related resources, please consult [BPAO] and [REA].
Use the worksheets in the order that makes the most sense for you
This document outlines a structured approach that moves from the Business Reference Model to the Business Transaction level, while allowing users the flexibility to complete the worksheets in an order that best suits their needs For instance, someone updating an existing document-based standard like EDIFACT may choose to begin with the Business Transaction Definition worksheets, potentially providing only basic definitions for the higher-level worksheets.
7 Worksheets will be made available in a future version of this document. formalize the definitions for an entire industry may very well start from the Business Reference Model worksheet.
The worksheets can be used for projects of various scopes
The Metamodel outlines essential objects required for a complete specification but offers limited guidance on the scope of these specifications When modeling a specific interaction with a trading partner, it is unnecessary to include a comprehensive Business Reference Model for the entire industry; instead, focus on the relevant components for that interaction Likewise, if you are addressing a limited set of interactions within your company, you may opt to define the Business Area or Process Area to reflect your organization's specific needs.
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:
To determine if a given collaboration is appropriate for reuse (or at least is a close enough match for subsequent gap analysis)
This online implementation guide allows potential trading partners or their representatives to review the public processes and collaborations you offer, enabling them to develop an effective integration plan.
This means trying to use industry wide terms (or at least Business Reference Model terminology) to increase the comprehensibility and specificity .
Re-use is one of the primary goals of ebXML
The goal is to encourage users to create reusable models that can benefit others To achieve this, Worksheets should be utilized alongside a browser that allows users to search existing business process libraries for predefined items, such as business processes, collaborations, and document schemas Users can reference these items directly or copy them into their Worksheets for modification As business process catalogs grow over time, the analysis will increasingly focus on validating these predefined processes against specific requirements.
Note on optional fields in the worksheets
Some worksheets include optional entries for ebXML, which are attributes found in the UMM but not mandated by the ebXML Specification Schema These attributes often relate to business objectives and justifications, which, while crucial for modeling, may expose an organization’s public processes to trading partners Sharing justifications for interfaces could inadvertently reveal strategic information that organizations might wish to keep confidential.
Number your worksheets
Each worksheet includes a Form ID that allows for easy referencing between forms Utilizing an outline numbering system simplifies the identification of parent-child relationships within the model, although this may be more challenging to establish initially with a bottom-up approach.
BRM for Business Reference Model
PA for Business Process Area
BPS for Business Process Summary
BPUC for Business Process Use Case
BCPT for Business Collaboration Protocol Table
BTTT for Business Transaction Transition Table
BIC for Business Information Context
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.
is, perhaps, an outline entry number
is some descriptive name.
Please see the example in the Appendix for an illustration of this in practice.
Worksheets to metamodel mapping
The diagram illustrates a detailed mapping from the Worksheets Model to the UMM-defined Metamodel The left column highlights the key elements that the Worksheets must specify or edit, while the right column presents significant elements of the Metamodel The middle column contains additional elements that correspond to the Metamodel elements of the same name.
Different path for single transaction collaborations.
6 Business Process Identification and Discovery
Goals
The initial worksheets assist users in formalizing the domain for process modeling by identifying key "top level" entities and organizing concepts within that domain.
Figure 6-3: Business Process Identification and Discovery Worksheet to Metamodel Mapping
In this phase, we establish key terminology and identify the participants involved, along with the specific business processes they engage in According to the UMM, the objective at this stage is to clarify these interactions and roles within the model.
To understand the structure and dynamics of the business domain,
To ensure that all users, standards developers and software providers have a common understanding of the business domain,
To understand the daily business in the business domain independent of any technical solution,
To create categories to help partition the business domain that enables an iteration plan to complete the model,
To structure the model in the form of a Business Operations Map (BOM),
To capture the justification for the project,
To identify the stakeholders concerned with the modeled domain, some who will be independent of the processes within the domain.
The modeling artifacts that correspond to the UMM are:
Guidelines
How does one decide how big to make the various groupings at this level?
When organizing information, consider your communication goals and audience needs If your focus is on public processes, group them by partner type or relevant business areas For formalizing a business sector, identify prevalent archetypes and categorize them by function These guidelines serve as a framework, but remember that effective organization is often an art that requires thoughtful consideration of what will be most beneficial for your audience.
The activity diagrams within this workflow are expected to unveil more detailed business process use cases The Business Operations Map (BOM) Metamodel facilitates the representation of business processes through increasingly refined processes It is important to note that when a business process can no longer be subdivided into smaller child processes, it is designated as a business collaboration use case, as outlined in the Requirements workflow.
What is the boundary of the business area?
According to the [UMM] the following guidelines are to be used in defining a business area:
The business area is shaped by stakeholders who directly or indirectly influence its domain A stakeholder is defined as an entity that is significantly impacted by the system's outcomes, regardless of their role as an actor Actors, on the other hand, are stakeholders actively engaged in the business process and are integral to the business model.
The business domain is defined by the flow of information entering and exiting it, with boundaries ideally set to encompass the logical initiation and conclusion of business transactions.
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)
Worksheets
Business reference model
Establishing a clear "frame of reference" is essential for identifying business processes, as it defines fundamental terms recognized within specific industry segments For instance, the SCOR model provides a framework for supply chain management, while VICS offers guidelines for trading partners in the retail sector Additionally, broader perspectives like the Porter Value Chain (PVC) can also be utilized to enhance understanding across various industries.
Form: Describe Business Reference Model Form ID [Provide an ID for this form so other forms can reference it (§5.1.8)]
The DOTCOM DROP SHIP RETAIL MODEL is an innovative approach to e-commerce that leverages drop shipping to streamline supply chain management This model allows retailers to sell products without holding inventory, significantly reducing overhead costs By partnering with suppliers who handle inventory and shipping, retailers can focus on marketing and customer service The DOTCOM DROP SHIP RETAIL MODEL enhances operational efficiency and offers a broader product selection, catering to the evolving demands of online consumers.
The retail industry segment encompasses businesses involved in the sale of goods and services directly to consumers This sector plays a crucial role in the economy by facilitating the distribution of products and enhancing customer experiences Retailers operate through various channels, including physical stores and online platforms, to meet diverse consumer needs and preferences.
Domain Scope [Provide a high level statement that encapsulates the scope of all the business areas.] Online catalog, distribution center, delivery, billing
Business areas encompass various process areas, which in turn consist of specific business processes For instance, key business areas include Order Management and Accounts Receivable (AR) To explore a comprehensive list of normative categories for defining business areas, you may refer to the ebXML Catalog of Business Processes.
Business Justification [Provide the business justification for the collection of business processes]
Define more efficient on-line retailer/vendor interaction.
Business area
According to the guidelines, there are flexible approaches to segmenting the model into various business areas A recommended method is to categorize business processes based on their main functions, potentially utilizing the Porter Value Chain (PVC) classification scheme for better organization.
Form: Describe Business Area Form ID [Provide an ID for this form so other forms can reference it (§5.1.8)]
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.]
Description [A brief summary of this functional area ]
The scope of the business area encompasses key functions such as online catalog management, order placement, distribution center operations, delivery logistics, and billing processes This scope is designed to align with the overarching business reference model, ensuring that each aspect is effectively constrained and focused within the broader framework of the organization.
[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 in this business area include key practitioners such as customers, retailers, DSVendors, carriers, and credit authorities These participants, often found within industry groups or standards bodies, play a crucial role in defining the Business Requirements Vision (BRV) for the industry.
The identified process areas within the scope include Customer Commitment, Order Fulfillment, Billing, and Inventory Management These areas represent a collection of essential business processes that can enhance operational efficiency For a comprehensive overview of normative process groups, you may refer to the ebXML Catalog of Business Processes, which serves as a valuable resource for defining process areas.
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.]
Process area
A business reference model outlines a standardized set of process areas, exemplified by models such as Porter or SCOR Each process area comprises a series of interconnected processes that collectively create the "value chain" for a specific business domain.
Form: Describe Process Area Form ID [Provide an ID for this form so other forms can reference it (§5.1.8)]
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
Objective [Describe the objective of this process area.] To deliver the goods ordered to the customer.
The business scope focuses on efficiently fulfilling customer orders through third-party suppliers for drop ship deliveries, aligning with the overarching business reference model while maintaining a more defined process area.
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
The management of purchase orders is a crucial business process within this area, as outlined in the ebXML Catalog of Business Processes, which offers a standardized list of essential processes for effective business operations.
Optional for ebXMLBusiness Opportunity [Describe the business opportunity addressed by this process area.]
Identify business processes
To effectively analyze each business process, utilize the provided worksheet for the process area A helpful guideline for determining the appropriate granularity of a business process is to consider it as the smallest exchange of signals between stakeholders that holds identifiable economic value, as referenced in the REA framework However, it is important to recognize that not all processes, such as "negotiation," may lead to direct economic consequences, yet they can still be considered valid business processes.
It is essential to ensure that the information within a specific process area aligns with the broader business area For instance, confirm that the scope of the process area falls within the defined boundaries of its corresponding business area.
Form: Identify Business Process Form ID [Provide an ID for this form so other forms can reference it (§5.1.8)]
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
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
Goals
At this stage we begin to move from requirements analysis to design analysis Consider the following diagram:
Figure 7-4: Mapping from business processes to the BRV
A business process serves as a use case for collecting requirements related to business operations It is essential to define the inputs in the preconditions and outline the outputs in the post-conditions to ensure clarity and effectiveness in the process.
Worksheet
Each business process requires a dedicated form, and these processes can be organized hierarchically It's essential to adopt a structure that aligns with your specific needs, while also considering the potential for reuse when determining how to break down these processes.
Form: Business Process Use Case Form ID [Provide an ID for this form so other forms can reference it (§5.1.8)]
The business process is named "Manage Purchase Order," as identified in the "Identify Business Process" and "Describe Process Area" forms For those initiating this process, it is advisable to consult the ebXML Catalog of Business Processes, which offers a standardized list of business processes.
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
Actors [List the actors involved in the use case.] Retailer, Vendor
Performance goals are essential metrics tailored to specific use cases, defining clear objectives for system performance These goals can often stem from non-functional requirements, ensuring that all aspects of performance are considered Each performance goal should include a distinct name and a concise description, outlining its significance and expected outcomes.
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
Definition [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.
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
Traceability [These are the requirements covered (as shown in Annex 4, Use Case
Specification Template, in the UMM).] "PRD-FOO-6.5.4" (meaning Product Requirements Document for FOO project/solution, requirement 6.5.4).
Goals
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
The Business Requirements View (BRV) of the UMM highlights that not all business processes involve economic exchanges as defined by REA, meaning that these worksheets will only be applicable to certain business processes and collaborations Accurate modeling and comprehension of the BRV elements are essential for understanding the semantics of legal ownership and for adhering to GAAP (generally accepted accounting principles) in financial reporting.
Guidelines
This section contains two worksheets that model key economic entities, including Economic Events, Economic Resources, Partner Types, Business Events, Agreements, Economic Contracts, and Commitments Creating an Economic Exchange model typically requires defining two corresponding components of a marketplace exchange.
A shipment of goods takes place between a supplier and a customer, representing a key economic event involving the exchange of resources This transaction is typically followed by a cash payment between the same parties, completing the economic interaction.
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 first worksheet outlines the items involved in an economic exchange, while the second worksheet details the economic primitives that may govern such exchanges Although not all economic exchanges are regulated by agreements or contracts, the second worksheet will be utilized less frequently Space is provided for cross-references between exchanges and their governing agreements, and agreements can recursively reference other agreements Business collaborations, as described in the subsequent worksheets, may represent an entire economic exchange, an economic event, or a business event, and can also relate to agreements or economic contracts.
Worksheets
Form: Economic Exchange Form ID [Provide an ID for this form so other forms can reference it (§5.1.8)]
Economic Exchange Name [Provide a name for the exchange (like “cash purchase” or “credit acquisition of services”)]
Identifier [This is a unique identifier that follows the Business Process Identifier
Initiator Economic Event (s) [Provide the business name for the economic event (shipment, service, payment, etc.)]
Initiator Economic Resource(s) [Describe the goods or services (inventory, transportation, cash, etc.) to be exchanged.]
Type [Describe the party who supplies the economic resource.]
[Describe the party who receives the economic resource.]
Initiator Exception Events [Describe the events that constitute the exceptions to the expected exchange and explain their consequences (incomplete shipment or disallowed payment, etc.).]
Terminator Economic Event(s) [Provide the business name for the economic event (shipment, service, payment, etc.)]
Resource(s) [Describe the goods or services (inventory, transportation, cash, etc.) to be exchanged.]
[Describe the party who supplies the economic resource
Type [Describe the party who receives the economic resource.]
Terminator Exception Events [Describe the events that constitute the exceptions to the expected exchange and explain their consequences (incomplete shipment or disallowed payment, etc.).]
Business events play a crucial role in facilitating economic exchanges, including essential activities such as querying availability, accessing supply catalog information, and verifying credit These processes are vital as they typically occur prior to the shipment of goods for cash transactions, ensuring a smooth and efficient operation.
Normal Terms of Settlement [Describe normal settlement arrangements (payment upon receipt, etc.).]
Recognition of Claim [Describe whether or not an incomplete (unrequited) state of the exchange needs to be explicitly recognized with a claim (like an invoice).]
Agreement [Indicate whether or not this exchange is to be governed by an economic agreement or contract If necessary, complete the next worksheet.]
Form: Economic Agreement Form ID [Provide an ID for this form so other forms can reference it (§5.1.8)]
Economic Agreement Name [Provide a name or a specific identifier for the agreement that usually governs the economic exchange from the linked worksheet.]
Identifier [This is a unique identifier that follows the Business Process Identifier
Economic Exchange [Provide the Identifier for the governed economic exchange (as identified in prior worksheet).]
[Describe and provide Identifier for any longer term agreement that governs the operation of this specific (shorter-term) agreement.]
(Lower Order) [Describe and provide Identifier for any shorter term agreement that are governed by the operation of this specific (longer-term) agreement.]
Economic Contract [Describe whether or not this agreement meets the conditions for an enforceable legal contract.]
[Identify the Partner Types resonsible for the establishment of the agreement.]
Establishing Event [Identify the Business Event which establishes this agreement.]
Enabling Business Events [Describe the set of Business Events that enabled the establishment of this agreement (from the negotiation pattern for example).]
Initiator Commitment(s) Describe the nature of the initiating commitment for the governed exchange
(for example: ship inventory according to a certain schedule).]
Initiator Resource Types [Describe the Economic Resource Types for the initiating commitment and projected quantities if appropriate.]
Initiator Partner Type [Identify the Partner Type responsible for the initiating commitment in the governed exchange.]
Terminator Commitment(s) [Describe the nature of the terminating commitment for the governed exchange (for example: submit payment within 30 days of receipt).]
Terminator Resource Types [Describe the Economic Resource Types for the terminating commitment and projected quantities if appropriate.]
Terminator Partner Type [Identify the Partner Type responsible for the terminating commitment in the governed exchange.]
Goals
These worksheets develop the Business Requirements View (BRV) of a process model
Figure 9-5: Mapping from Business Collaboration to BRV
The following items are specified:
The business collaboration protocols that tie economic events together
The system boundaries between which the protocols flow
The input and output triggers of these collaborations
The roles and constraints associated with the collaboration
The purpose of the Partner Collaboration Worksheets is:
To effectively gather detailed user requirements outlined by stakeholders for a business-to-business project, the workflow creates a Business Requirements View (BRV) within a process model This model defines use case scenarios, input and output triggers, constraints, and system boundaries for business transactions (BTs) and business collaboration protocols (BCPs), as well as their interrelationships.
The modeling artifacts to be identified are:
Business Collaboration Use Case [Use Case Realization, Activity Diagram]
Economic Consequences of Business Collaborations
Worksheets
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 Form ID [Provide an ID for this form so other forms can reference it (§5.1.8)]
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.]
Partner Types [This is a list of entities that participate in the collaboration These participants exchange the events that form the collaboration.]
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 captured here.]
Economic Consequences [If any step in the collaboration has and economic consequence, it should be captured here.]
Initial/Terminal Events [List the events that initiate this collaboration and how it terminates.]
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.)]
Form: Business Collaboration Protocol Table Form Id [Provide an ID for this form so other forms can reference it (§5.1.8)]
Identifier [Enter the Identifier from the associated Business Collaboration form.
To initiate the first activity, identify the partner type and the name of the destination Utilize a boolean expression to clearly define or describe the originating business activity associated with this partner type.
APPLICABLE.] business activity.] APPLICABLE.] condition for the transition or NONE.]
[Name of an activity.] NOT-
APPLICABLE [A boolean expression defining or describing the condition for the transition.]
[Name of an activity.] NOT-
APPLICABLE [A boolean expression defining or describing the condition for the transition.]
10 Business Transactions and Authorized Roles
Goals
This worksheet aims to pinpoint the specific transactions that facilitate Business Collaboration workflows Each transaction consists of multiple activities, and each activity requires an authorized role that the signaler must possess to initiate it effectively.
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
Guidelines
Use transaction patterns
The UMM has established specific transaction patterns essential for defining business transactions, ensuring their legal validity in line with current global and regional legal standards For more information, refer to the UMM guidelines.
When utilizing specific patterns in transactions, intrinsic semantics such as property-values related to non-repudiation and authorization are inherently linked If a transaction is based on a UMM pattern, it is not necessary to repeat these property values, although doing so can consolidate information Conversely, if a transaction does not adhere to a UMM pattern, it is crucial to outline the property values in the Business Transaction Property Values form to ensure compliance with legally binding transaction semantics If you decide to override the semantic property values, remember that altering them may render the pattern inapplicable, and in such cases, refrain from specifying a pattern name Additionally, do not provide values for Non-Repudiation Of Receipt and Recurrence for Responding Business Activity, as these are dictated by the UMM.
Detail transaction activities only if necessary
The transaction patterns outlined in the UMM are designed to address a wide range of business scenarios To effectively illustrate business transaction activities, it may be beneficial to detail the permissible transitions between these activities This can be achieved by creating a UML-compliant activity diagram or utilizing a Business Transaction Transition Table to present the same information For visual examples of how Business Transaction activity diagrams can be represented in table format, please refer to Appendix C.
Worksheets
Form: Business Transaction Form ID [Provide an ID for this form so other forms can reference it (§5.1.8)]
Description [Provide a descriptive overview of this transaction.]
Pattern [If you have chosen to follow one of the canonical transaction patterns in the
UMM 9 (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.]
Type [Partner type from collaboration.] Customer
[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
Activity Document [Document initiating the transaction Might reference a standard document (e.g an X12 document) ] Sales Order
Responding Partner Type [See above.] On-line Retailer
Responding Activity Role [See above.] Customer Service
To request and respond to business activities effectively, ensure that you complete the necessary property-values, especially when they differ from the default values specified in the UMM transaction patterns For the convenience of readers, consider copying the relevant values directly from the UMM.
Form: Business Transaction Property Values Form Id [Provide an ID for this form so other forms can reference it (§5.1.8)]
Time to AcknowledgeReceipt Time to AcknowledgeAcceptance Time to Perform AuthorizationRequired Non-repudiation ofOrigin and Content Non-Repudiation ofReceipt Recurrence
Activity [time] [time] [time] [true or false] [true or false] [true or false] [whole number]
Provide a Business Transaction Transition Table if needed See guidelines section “Detail Transaction Activities Only If Necessary.”
Form: Business Transaction Transition Table Form Id [Provide an ID for this form so other forms can reference it (§5.1.8)]
From Activity From Role Document To Activity To Role Guard Condition
START shall be used for the first activity.]
Initiating Activity Role or NOT- APPLICABLE NOT- APPLICABLE is to be used when the From Activity is START.]
[Name of the destination activity or keyword END or keyword CONTROL- FAILED.]
[A Responding Activity Role or NOT-
[A boolean expression defining or describing the condition for the transition or NONE.]
[Name of the last activity before the
[Appropriate role name.] NONE END NOT-
APPLICABLE [Expression of the guard condition.]
[Name of the last activity before the
[Appropriate role name.] NONE CONTROL-
APPLICABLE [Expression of the guard condition.]
Goals
The goal of this set of worksheets is to identify the information requirements for the business documents specified in the business transactions.
Guidelines
To effectively specify business documents within a business process and information model, the initial step is to leverage existing business information objects from a Business Library If no suitable business document is available, domain components from Domain Libraries and core components from the Core Library should be utilized During the development of the Business Library, core components will frequently be referenced to enhance the collection of business information objects and facilitate the creation of business documents.
To complete the worksheets, first, identify the available attributes in business information objects within the Business Libraries for use in business documents If suitable attributes are lacking, create new business information objects Next, search for reusable information components in both the business and Core Libraries, considering the context outlined in the business process and information models, and extend existing objects as necessary Then, incorporate the new attributes into existing business information objects or register new ones to manage changes in the Business Library Finally, utilize the newly added attributes from the Business Library when creating business documents.
Worksheets
Business information context
The Business Information Context form serves as a helpful tool for collecting contextual values that influence the analysis of business information This information is primarily sourced from other forms, such as the specification of the Industry Segment 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 Form Id: [Provide an ID for this form so other forms can reference it (§5.1.8)]
Service Level (profiles – not preferences.)
Document content description
The document comprises distinct elements organized into logical sections, typically including a header, body, and summary, with the body potentially divided into further subsections The occurrence of elements can vary, with options such as 1 (one instance), 0 1 (zero or one instance), 0 * (zero or more instances), 1 * (one or more instances), or n m (between n and m instances) Information looping is indicated through specific occurrence values Data types may include primitive types like integer, string, or date, as well as Form Ids from other Content Description Forms, illustrating information hierarchy and nesting If applicable, reusable components from a domain library or the Catalog of Core Components may be referenced The Semantic Description must be articulated in clear business terms and should be unequivocal.
Form: Content Description Form Id: [Provide an ID for this form so other forms can reference it (§5.1.8)]
Element/Component Name Occurs Data
[Provide a name for the element/component
For example, “Order Summary” or “Issued
Content mapping
It is essential to complete these forms, as they provide crucial information that supports the documents' alignment with existing standards This information will facilitate the creation of document transformations, adhering to standards such as EDIFACT, X12, xCBL, RosettaNet, and OBI When referencing XML elements and describing mappings, XPATH and XSLT notation should be utilized Additionally, if a new document schema is developed to meet the content requirements outlined in the Document Content Description forms, a corresponding set of Content Mapping forms must be filled out, with the component names serving as necessary information requirements.
For each Content Description form, complete a Document Content Mapping form for each standard to be cross-referenced.
Form: Content Mapping Form Id: [Provide an ID for this form so other forms can reference it (§5.1.8)]
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]
[Enter element/component name from corresponding
[Mapping or transformation If the element/component is a complex structure, this entry should reference the appropriate Content Mapping form.]
Appendix A Business Process Identifier Naming
The Business Identifier Naming Scheme outlined in this appendix is essential for uniquely identifying key objects within an ebXML compliant business model These objects are directly associated with the layers of the UMM Metamodel, particularly the Business Operations Map (BOM), utilizing a Business Process Identifier naming scheme for effective organization and identification.
(BPINS), the Business Requirements View with a Business Collaboration Identifier Scheme (BCINS) and the Business Transaction View with a Business Transaction Identifier Scheme (BTINS).
A BPINS naming scheme format is defined by : bpid:::$.
A BCINS naming scheme format is defined by : bcid:::$.
A BTINS naming scheme format is defined by : btid:::$.
bpid is the fixed string “bpid” indicating the entire identifier is a business process identifier
bcid is the fixed string “bcid” indicating that the entire identifier is a business collaboration identifier.
btid is the fixed string “btid” indicating that the entire identifier is a business transaction identifier.
agency identifier or name of the agency that owns the agency-ids and must be a globally unique identifier For example, DUNS and EAN.
agency-id identifer of the organization that owns the business process and must be a globally unique identifier No other entity SHALL use the agency identification of another entity
Major and minor version numbers are each integers and need to respect any specific Registry Authority conventions defined.
When naming the business process, collaboration, and transaction, it is essential to use descriptive names in camel-case format These names should avoid spaces, periods, colons, or dollar signs Additionally, the organization or agency responsible for the business transaction must ensure that the identifier remains unique.
Valid examples of business processes using the identifier naming scheme include: btid:ean.1234567890128:DistributeOrderStatus$1.0 bpid:icann:my.com:NewBusinessProcess$2.0
With respect to the ebXML Registry Information Model specification 10 the definition is as follows:
The BPINS Registry Information Model includes key elements such as the bpid, bcid, and btid, all categorized under ExtrinsicObject.objectType It also features essential organizational details, including the agency's name and UUID, as well as the business process, collaboration, and transaction names Additionally, the model specifies versioning with major and minor version numbers for each ExtrinsicObject.
An ExtrinsicObject is a specific kind of ManagedObject that follows a defined life cycle, but it is not essential for the primary operations of a registry In contrast, an Organization is classified as an IntrinsicObject, which is fundamental to the registry's functionality.
Appendix B The Porter Value Chain
The table below illustrates the categories of the Porter Value Chain (PVC) and their correlation with Economic Elements concepts, serving as a helpful resource for users to effectively classify the components of a business process specification.
& outflow Major types of events Economic Agents &
Money Raw materials Facilities Services Technology
Payments Purchase Purchase Orders Price Quotes
Cash Payments Acquisition of labor Training
Shipment Warehousing Tasks Material Handling Trucking
Buyer Vendor Logistics Worker Trucker
Development Product Design Assembly Quality control
Technology Labor Raw Materials Finished Goods
Manufacturing Operation Raw Material Issue Manufacturing Job
Labor Advertising Service Delivered Goods Product Services Cash
Cash Payment Customer Invoice Sale Order Price Quotes Contract
Customer Service After Sales Service
Service Call Product Repair Service Contract
Stockholders BondHolders Investment Brokers Financial Managers
Appendix C Drop Ship Scenario Example
This appendix presents a worksheet-based analysis for the "Direct to Customer Drop Ship Retail" business reference model, often accompanied by UMM UML diagrams As this document is a work in progress, we aim to assist you in effectively utilizing these worksheets for your needs.
1.# Top level of Business Reference Model : defines the “frame of reference” of all worksheets. 2.# Business Process Area : Form that defines the scope of the business area
3.# Business Process Identification and Discovery : Forms that inventory all business processes.
4.# Business Process Summary Name form
5.# Business Process Elaboration : Forms used to describe the business processes and identify actors as well as pre and post conditions for the business processes (use cases)
6.# Business Collaboration Definition : define the economic events that take place to fulfill the business process, including system boundaries and the protocols that govern the flow of information.
8.# Business Transaction Definition : Forms that defines the actual activities and authorized parties within the organization that initiate these transactions.
Business process identification and discovery: BRM-1.0-direct-to-customer-drop-ship-retail- model 48
This article explores various business areas, including direct-to-customer retail processes, financial process management, and customer order management It provides summaries of customer order fulfillment and vendor inventory management processes, as well as insights into product catalog exchange and payment business processes Each section highlights key aspects of operational efficiency and customer satisfaction in today's competitive marketplace.
BPUC-5.1-Firm-sales-order 58 BPUC-5.2-Customer-credit-inquiry 59 BPUC-5.3-Customer-credit-payment 59 BPUC-5.4-Purchase-order-management 60 BPUC-5.5-Ship-goods 61 BPUC-5.6-Inventory-management 61 BPUC-5.7-Sales-product-notification 62 BPUC-5.8-Present-invoice 63
Business collaboration and economic events 63
The process begins with creating a customer order (BC-6.1), followed by checking the customer's credit (BC-6.2) and processing the credit payment (BC-6.3) Next, a vendor purchase order is created (BC-6.4), and shipment instructions are issued (BC-6.5) After confirming the shipment (BC-6.6), vendor inventory reporting is conducted (BC-6.7) alongside requests for inventory reports (BC-6.8) The sales product offering is then presented (BC-6.9), culminating in the invoice presentment (BC-6.10).
Business transactions and authorized roles 78
The article outlines key processes in sales and inventory management, including the firm customer sales order (BT-8.1), checking customer credit (BT-8.2), and charging customer credit (BT-8.3) It also covers the creation of vendor purchase orders (BT-8.4) and generating vendor inventory reports (BT-8.5) Additional topics include requesting inventory reports (BT-8.6), shipment notifications (BT-8.7), confirming shipments (BT-8.8), product offerings (BT-8.9), and presenting invoices (BT-8.10).
Business process identification and discovery: BRM-1.0-direct-to- customer-drop-ship-retail-model
Direct To Customer Drop Ship Retail : Transaction and Physical Goods Flow Overview
1) B T- Pr od uc t-O ffe rin g
2) B T- Ve nd or - In ve nt or y- Re po rt
5) B T- Cr ea te -V en do r- Pu rc ha se -O rd er
7) B T- Co nf irm -S hi pm en t
9) B T- Pr es en t-I nv oi ce
Notes: Sequencing is approximate Transactions 1 & 2 can occur multiple times and in parallel to the other transactions
Figure 11-6: Direct To Customer Retail Transaction and Physical Goods Flow Overview
Form: Business Reference Model Form Id BRM-1.0-Direct-To-Customer-Drop-Ship-Retail-Model
DIRECT TO CUSTOMER DROP SHIP RETAIL MODEL
Domain Scope Internet retail, catalog, distribution center, delivery, billing
Business Areas Direct To Customer Retail
Optional for ebXML Business Justification Define more efficient on-line retailer/vendor interaction Reduce inventory carrying costs.
Figure 11-7: Direct To Customer Drop Ship Retail
BA-2.0-Direct-to-customer-retail
Form: Business Area Form Id BA-2.0-Direct-to-Customer-Retail
Business Area Name Direct to Customer Retail
Description This is a demonstrative business process model, to illustrate ebXML business process modeling, and based on actual business practice conventions today. See ‘Objective’ section below in this form.
Scope Internet based retail, mail order catalog, direct to customer product fulfillment logistics, single piece product delivery from a distribution center to an end customer.
Direct Supply Retail Vendor (DSVendor)
“my company typical Vendor Compliance Manual”
Constraints Internet based retail customer service system
Direct Supply Retail Vendor (DSVendor)
Process Areas Customer Order Management
The goal is to efficiently deliver a commercial product straight to the customer from the supply source, utilizing an online retailer that manages customer orders and provides direct customer service.
Business Opportunity Reduce retailer inventory carrying costs Shorten the supply chain from a domestic vendor to a domestic customer; thus save trees, energy and lives.
Note The Business Area diagram (below) shows all the process areas in this business area.
Figure 11-8: Direct to Customer Retail
Direct Supply Retail Vendor (DSVendor)
Direct Supply Retail Vendor (DSVendor)
Direct to customer retail process areas
Form Id PA-3.1-Customer-Order-Management
Process Area Name Customer Order Management
Objective Take a sales order from an Internet based customer
Validate a customer’s ability to pay for product upon delivery
Take payment from a customer’s credit card after a product has been delivered directly to a customer
Scope Fulfill customer orders using a 3rd party supplier for drop ship (customer direct) delivery.
References “my company Vendor Operations Compliance Manual”
Boundary of the Process Area
Constraints Customer promise of product availability most likely true at a vendor location when a customer order is accepted by the retailer.
Customer must have sufficient credit to eventually pay for the product after the product has been shipped.
Business Processes Firm Sales Order
Optional for ebXMLBusiness Opportunity
Customer (from Actors) Firm Sales Order
Figure 11-10: Customer Order Management
Form: Business Process Area Form Id PA-3.2-Customer-Order-Fulfillment
Process Area Name Customer Order Fulfillment
Objective Allow a retailer to instruct a direct supply vendor to deliver (within specific delivery times) specific product to a specific customer.
References “my company Vendor Compliance Operating Manual”
Boundary of the Process Area Activities directly pertaining to the registration of firm customer sales orders, and credit payment of delivered customer sales orders.
Constraints On hand product allocation to a customer order by a vendor immediately after processing a retailer’s purchase order.
On time product delivery from vendor to customer.
Immediate notification by a vendor to a retailer of a direct to customer product delivery; with customer service details.
Business Processes Purchase Order Management
Optional for ebXML Business Opportunity
Figure 11-11: Customer Order Fulfillment
Form Id PA-3.3-Vendor-Inventory-Management
Process Area Name Vendor Inventory Management
Objective To allow a direct supply vendor to report “available on-hand” inventory to a retailer.
References “my company Vendor Compliance Operating Manual”
Boundary of the Process Area
Constraints Inventory, by product SKU identification, is “available on-hand” within the direct supply vendor’s inventory management system.
Optional for ebXMLBusiness Opportunity
Figure 11-12: Vendor Inventory Management
Form Id PA-3.4-Product-Catalog-Exchange
Process Area Name Product Catalog Exchange
The objective is to ensure an accurate catalog of a vendor's products within a retailer's business operating system, particularly as new products are launched or existing products necessitate updated specifications between the vendor and the retailer.
References “my company Vendor Compliance Operating Manual”
Boundary of the Process Area
To establish a successful partnership, there must be a valid business relationship between a vendor and a retailer, enabling the retailer to offer the vendor's products directly to end customers.
Business Processes Sales Product Notification
Optional for ebXMLBusiness Opportunity
Figure 11-13: Product Catalog Exchange
Objective For the vendor to invoice the retailer for goods shipped and services provided.
Scope The scoped is defined by the following business processes:
References “my company Vendor Compliance Operating Manual”
Boundary of the Process Area
Optional for ebXMLBusiness Opportunity
Customer-order-management business process summaries
Form Id BPS-4.1-Firm-Sales-Order
Business Process Name Firm Sales Order
Process Area Customer Order Management
Business Area Direct to Customer Retail
Form: Business Process Summary Form Id BPS-4.2-Customer-Credit-Inquiry
Business Process Name Customer Credit Inquiry
Process Area Customer Order Management
Business Area Direct to Customer Retail
Form Id BPS-4.3-Customer-Credit-Payment
Business Process Name Customer Credit Payment
Process Area Customer Order Management
Business Area Direct to Customer Retail
Customer order fulfillment business process summaries
Form Id BPS-4.4-Purchase-Order-Management
Business Process Name Purchase Order Management
Process Area Customer Order Fulfillment
Business Area Direct to Customer Retail
Form Id BPS-4.5-Ship-Goods
Business Process Name Ship Goods
Process Area Customer Order Fulfillment
Business Area Direct to Customer Retail
Vendor inventory management processes summaries
Form Id BPS-4.6-Inventory-Management
Business Process Name Inventory Management
Process Area Vendor Inventory Management
Business Area Direct to Customer Retail
Product catalog exchange business processes summaries
Form: Business Process Summary Form Id BPS-4.7-Sales-Product-Notification
Business Process Name Sales Product Notification
Process Area Product Catalog Exchange
Business Area Direct to Customer Retail
Form Id BPS-4.8- Present-Invoice
Business Process Name Present Invoice
Form: Business Process Use Case
Form Id BPUC-5.1-Firm-Sales-Order
Business Process Name Firm Sales Order
To enhance customer satisfaction, it is essential to swiftly accept sales orders for products and provide an accurate delivery time along with a total sales amount, including all applicable taxes, within seconds of the customer making their selection and entering their personal information while online.
Preconditions Valid customer details (name, address, credit card)
Valid product details (product SKU details)
Begins When Customer completes all personal identity data for Retailer.
Customer successfully selects valid product to be purchased and specifies valid product quantity.
Customer accepts terms of sale.
A retailer must verify a customer's credit limit with a Credit Authority to ensure there is sufficient credit available for the intended purchase Once confirmed, the retailer will proceed to accept the customer's firm sales order.
Ends When Valid customer sales order is created in Retailer’s business operating system.
Exceptions Customer fails internal credit check; ie fraud.
Customer delivery needs violate Retailers standard terms of sale.
Postconditions Valid customer sales order.
Customer is notified of positive sale, and can expect delivery within promised delivery time.
Form: Business Process Use Case
Form Id BPUC-5.2-Customer-Credit-Inquiry
Business Process Name Customer Credit Inquiry
Performance Goals Retailer expects the Credit Authority to perform a credit card check for a specified sales amount and in seconds.
Preconditions Customer credit card details known.
Total sales price, including taxes, known.
Begins When Retailer can present both all customer credit card details and a requested total credit amount to be checked against this customer.
Definition Retailer requests Credit Authority to authorize the total sales amount against the customer’s credit amount.
The Credit Authority responds to the Retailer with either a positive or negative credit report on the customer.
Ends When Credit Authority returns either a positive or negative Customer report.
Exceptions Credit Authority fails to respond to Retailer within an acceptable period.
Postconditions Customer has a reserved credit cash equal to the total purchase amount authorized to the Retailer for a 24 hour period.
Form: Business Process Use Case
Form Id BPUC-5.3-Customer-Credit-Payment
Business Process Name Customer Credit Payment
Performance Goals Retailer expects Credit Authority to positively charge the Customer’s credit for the total sales amount immediately upon request.
Preconditions Confirmed shipment, by Vendor, of purchased product direct to Customer.
Begins When Vendor confirms to Retailer that the specified product prescribed on the current updated version of a DSVendor’s purchase order has been actually shipped to the specified customer.
Definition Credit Authority makes a credit charge against the Customer’s account, on behalf of the Retailer.
Credit Authority reports, to Retailer, the status of the credit charge.
Ends When Credit Authority reports back to the Retailer that the customer’s credit has been charged for the total sales amount; and thus credited to the Retailer’s account.
Exceptions Credit Authority reports to Retailer that the customer’s credit account cannot be charged with total sales price.
Postconditions Credit Authority transfers total sales amount from the Customer’s account to the Retailer’s account.
Form: Business Process Use Case
Form Id BPUC-5.4-Purchase-Order-Management
Business Process Name Purchase Order Management
Performance Goals DSVendor returns a PO Acknowledgment to the Retailer within 4 hours of receipt of the Purchase Order.
Preconditions Valid Customer sales order with Retailer.
Valid Retailer–DSVendor relation; ie terms and conditions.
Begins When Retailer has created a valid Purchase Order Request.
Definition Upon receiving a Purchase Order Request, the DSVendor does a product allocation to the PO against available inventory and returns a positive PO Acknowledgment to the Retailer.
Ends When Valid positive PO Acknowledgment returned from the DSVendor to the
Exceptions DSVendor does not return any PO Acknowledgment
DSVendor returns a negative Purchase Order Acknowledgement
Postconditions DSVendor has allocated correct product to fill Purchase Order
DSVendor has created all correct instructions for its warehouse management system to pick, pack and ship
Form: Business Process Use Case
Form Id BPUC-5.5-Ship-Goods
Business Process Name Ship Goods
Performance Goals Transport Carrier informs DSVendor within seconds of PO pickup, and
DSVendor registers PO transport tracking number within its business operating system within seconds.
Preconditions PO has been picked, packed and is ready to be shipped.
Begins When DSVendor informs Transport Carrier of a PO needing to be delivered to a specific Customer address.
Definition DSVendor manifests PO with Transport Carrier
Transport Carrier registers transport, checks “ship to” details and assigns a tracking number for the shipment.
Ends When Transport Carrier confirms PO pickup to DSVendor and begin of ordered goods delivery to Customer.
Exceptions Transport Carrier detects that “Ship To” address is invalid.
Transport Carrier fails to confirm PO pickup.
Postconditions Carrier assigns Transport tracking number to Purchase Order and informs
Form: Business Process Use Case
Form Id BPUC-5.6-Inventory-Management
Business Process Name Inventory Management
Performance Goals Once a day, the DSVendor reports their “available on-hand” inventory to the
Begins When Repeating event, occurs unsolicited from DSVendor to Retailer
Definition DSVendor reconciles “available on-hand” inventory and reports only product availability for those products which are agreed upon between Retailer and DSVendor.
Ends When Retailer has received a valid “available on-hand” inventory report from
Exceptions No “available on-hand” inventory report received.
Reported product quantiry on hand with DSVendor is less than any prior agreed Safety Stock level with Retailer.
Postconditions Retailers business operating system has recorded new “available on-hand” inventory by product.
Form: Business Process Use Case Form Id BPUC-5.7-Sales-Product-Notification
Business Process Name Sales Product Notification
Preconditions Valid DSVendor – Retailer business relationship
Begins When Initial start of the business relationship, for all related products.
Whenever DSVendor has a product specification change or addition that applies to the Retailer.
Definition DSVendor initiates a product specification request to “offer for sale” the
Retailer either accepts product offer, or rejects the offer.
Ends When Retailer responds to DSVendor acceptance or rejection of product offer for sale.
Postconditions On product acceptance, Retailer can register product for sale to Customers.
Form: Business Process Use Case
Form Id BPUC-5.8-Present-Invoice
Business Process Name Present Invoice
Preconditions Valid DSVendor – Retailer business relationship
Corresponding Purchase Order was accepted
Related Advance Shipment Notification was sent
Begins When Whenever DSVendor wants to invoice the Retailer for goods shipped.
Business collaboration and economic events
Form Id BC-6.1-Create-Customer-Order
Description The customer enters a sales order using on-line store-front application.
SUCCESS [ BusinessTranaction("FirmCustomerSalesOrder").State=END ]
[ BusinessTranaction("FirmCustomerSalesOrder").State=CONTROL-FAILED ]