• EIDX Business Process Architecture and EIDX/CompTIA Scope
• EIDX Business Process Framework
• Electronic; between companies
• Guidelines for public processes
• Standards-neutral and technology-neutral
  • Standards-aware; technology aware; EIDX internet commerce model
• Component models, scenarios, sub-processes
  • Object-Oriented development approach
• Business Model Attributes

• Model Legends - Understanding EIDX Business Models
• Abbreviations and Conventions used when describing  business content standards (X12, EDIFACT, RosettaNet, OAGI, etc.)
• EIDX's Use of UML Class Diagrams
• Tour the Clickable Business Models
• The Glossary
• Acronyms and Abbreviations
• EIDX Development Process
• Class:  Introduction to EIDX Business Model Development Process

EIDX Business Process Architecture and EIDX/CompTIA Scope

When is it a component business process model and when is it a scenario?

When is it just an optional step in a business process, and when is it another, distinct business process?  When is it a component business process, and when is it a scenario that combines several component business processes?  The lines can be blurry sometimes, and no two organizations draw the lines in the same places.  EIDX has a few guidelines it uses when developing business models.

Object-Oriented Development Approach

Many people have a tendency to try and capture everything in a single model when they are trying to understand business processes.  Such a model ends up having a lot of optional steps if it is trying to represent all the different ways something can be done.  There are hundreds of possible scenarios when you combine quote scenarios with order scenarios with forecast scenarios, and so on.   EIDX uses a modular approach - software developers call this "object-oriented" design.   This means specifying something once, and then referring to it or including it as a component in one or more other specifications.

Business Model - A pictorial view of a business process at a high level.

• Should clearly identify the parties involved and how events flow.
• Ideal end goal: A user can look at the business model and supporting documentation and know what they need to do to implement the chosen business process.

Scenario - Description or outline of possible or hypothetical events or actions.  In business process modeling, a formal specification of a group of business activities that may take place between parties to achieve a particular business objective.

• For EIDX, a Component Business Process Model is like an "implementable chunk" of processing -  it represents how companies tend to partition implementations or automation of business processes.  It's really a "re-usable" chunk of business process steps.   In RosettaNet's legacy architecture, this equates to a Partner Interface Process (PIP™).  A Scenario will combine two or more of these component business process models. 

• Example:  Most partners implement  forecast-based replenishment in two steps:  Order Model 1 (Standalone Purchase Order) and Forecast/Planning Model 1 (Planning Forecast). These two component business models are combined into the common scenario EIDX calls Replenishment Model 1.

Some EIDX component models have sub-processes models that are repeated iteratively in real-world transacting; in RosettaNet, this equates to having some "one-way" PIPs.   This, again, represents how companies tend to partition implementations.

• Example: PO responses (acknowledgments) my be created, sent and processed multiple times for any given purchase order.

When is it "another model"?

Many processes are similar, many use similar business documents.   Some general guidelines for when a variation or difference should really be defined in a separate business model:

• There are significant differences in the process purpose or attributes.
  • Example:  Activity diagrams for EIDX Forecast/Planning Models 1 and 2 look similar graphically, but the attributes are different:
    • FC1:  Buyer generates Planning / Delivery Schedule (net rolling forecast) for information only and capacity or lead time planning purposes, to convey anticipated demand or run rates; no authorization to build or ship implied except per trading partner agreement.
    • FC2:  Buyer calculates requirements and generates blanket PO for stated period (such as yearly). Blanket includes authorization and other terms. Forecast becomes firm release within negotiated lead-time (releases "embedded" within forecast).
• A different business document is used for a specific purpose.
  • Example:  EIDX Forecast/Planning Models 1 and 3 both have some kind of forecast response document, but there are differences in which documents are used and for which purpose:
    • FC1:  A Response to Forecast is used to convey response to schedules of planned deliveries. 
    • FC2:  A Purchase Order Acknowledgment is used to convey response to firm (released) requirements.
• The same business document standard used for both but contents of the business documents are significantly different (so they really should be identified as two different business documents)
  • Example:  EIDX Forecast/Planning Models 1, 2 and 3 all have some type of forecast/planning document.   However, the contents are significantly different.
    • FC1:  Contains netted, planned requirements (planned delivery quantities); no firm requirements are included - firm requirements will have become open purchase orders.
    • FC2:  Contains netted, planned and firm requirements as well as firm requirements.  Instead of handling discrete purchase orders with high processing overhead, the forecast recipient identifies firm requirements in the forecast/planning document and ships against a blanket purchase order.
    • FC3:  Contains un-netted, gross requirements (planned consumption - what the buyer plans to use or sell), and any inventory data the recipient will need in order to do all the netting and determine the delivery schedules.
• Many partner applications use a different module or process to generate or process the data; processing is not easily handled with simple if/then/else routines in the application.
  • Example:  Sender's application creates discrete purchase orders and blanket purchase orders using different modules and by creating distinctly different output files.
  • Example:  Recipient's must use two different applications  to handle planning forecasts and supplier-managed inventory forecasts.

It may not be apparent that there are different attributes in the early part of the business model development process. Model building processes is not linear or straight forward. Be expected to step back from time to time.

Why do both component business process models and scenarios?

The component business process models represent the same implementable chunks most partners have available in their back-end applications.  Many, many scenarios are possible by combining business process models, but some have become best-practice in our industry, and EIDX models these best-practice scenarios.

EIDX Business Model Attributes