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.
Additionally, the following
describe constraints on EIDX/CompTIA's scope:
- Focus is on the
electronic transacting between
- Focus is on developing implementation
- 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
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
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.
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
EIDX builds basic component
models that fit 80%+ of the electronics industry needs and identifies common
business process scenarios - the best-practice ways of combining component
When is it a component business process model and when is it a
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.
- A pictorial view of a
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
- 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
will combine two or more of these component business process models.
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
(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
differences in the process purpose or attributes.
Activity diagrams for EIDX
Forecast/Planning Models 1 and 2 look similar graphically, but the attributes are
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
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).
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.
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
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
- 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
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
- Standards-neutral, technology-neutral views include:
- Process and Flow
- Business Rules
- Data (i.e. content)
- Business Controls
- Business audit trails
- 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,
- Technical control points
- Technical audit trails
Additional details are at
EIDX Development Process and
Introduction to EIDX Business Model