EIDX Business Process Architecture and EIDX/CompTIA Scope
EIDX develops standards-neutral business process models for its constituent members.  What does this mean? The EIDX business process framework is a means for categorizing business processes and functions that are within EIDX's scope. 

Click here to view a larger image.

Additionally, the following describe constraints on EIDX/CompTIA's scope:

• Focus is on the electronic transacting between companies (B2B).
• Focus is on developing implementation guidelines for public processes.
  • EIDX does not develop eBusiness standards
  • EIDX does not model the details of partners' private processes, but does indicate on models what activities must take place in the private process in order for the public process to succeed.
• EIDX models are standards-neutral - no assumptions are made about what particular B2B standard will be used to implement a process - and technology-neutral - no assumptions about which B2B technologies will be used to enable implementations.
  • This means that EIDX's models are conceptual - they illustrate the concepts (principles) of each business process.
  • However, EIDX models are standards-aware and technology-aware; requirements of key standards are be evaluated as business models are developed.  Part of the process of building business models and supporting documentation is to make recommendations on how to employ standards and technologies.  The standards and technologies in EIDX's scope are documented in the EIDX Internet Commerce Model.
    • Standard-specific views of a business process may be documented (in some cases, though, the relevant standards body may have already provided such documentation).
    • Technology-specific views of a business process may be documented.
• Models are to be focused on the best practice next step; in other words, the functionality that would be contained in the next back-end systems "rewrite", not necessarily the long-term "perfect" solution.  These are processes for which implementation costs can be reduced by agreeing on recommended scenarios.
  • EIDX models "as-is" processes when it is deemed to be of benefit to the constituents; for example, if many members have customers who are requiring that they implement a business process.  However, EIDX does not model "one-offs" - any one company's proprietary process, or processes that are limited to a minority of member companies, or processes that are technically possible but not best practice.
• Models are created for "common" exceptions that are good candidates for automation.  Not every possible exception situation is modeled, because there are events that are too rare to justify the cost of automation, or too complex to be automated - they require the intelligence of human beings for resolution.

EIDX builds basic component models that fit more than 80 percent of the electronics industry needs and identifies common business process scenarios - the best-practice ways of combining component business models.

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.

• A component business process model is 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 reiterated 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 considered 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.  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 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

• Standards-neutral, technology-neutral views include:
  • Process and Flow
  • Transactions/Messages
  • Business Rules
  • Data (i.e. content)
  • Business Controls
  • Business audit trails
  • Timing
• Standards-specific views and/or technology-specific views may be, but are not always provided.  If provided, they may include:
  • Version-specific information
  • Information about media (computer file, compact disc, tape, whatever)
  • Technical control points
  • Technical audit trails