We need languages for expressing the relationships between different
sorts of data: a "semantic Web" which will let all the data be seen as one
big database. The semantic Web will be revolutionary for
ecommerce.--Tim Berners-Lee (Source)

This paper will argue that REA is the appropriate model for
creating a semantic Web for Internet supply chain collaboration,
because:

REA refers to the Resource-Event-Agent business model developed by
Professor William E. McCarthy. REA was originally designed for accounting.
Robert Haugen collaborated with McCarthy to extend REA for supply chain
management. The key extension was the Dependent Demand relationship as
defined by MRP systems.

As a semantic Web, REA can link economic events together across
different companies, industries, and nations. The links are
activity-to-activity or agent-to-agent or person-to-person, not just
company-to-company. This means each individual in a REA supply chain can
be linked directly to each other individual. We'll see below how these
direct links make supply chain collaboration faster and more
effective.

REA is a minimal model. Professor McCarthy and his colleagues have
spent years distilling business relationships down to the smallest set of
objects required to do the job. Other data may well be required in
particular industries or situations, which the REA model permits, but
there is no extra baggage to get in the way. For example, Purchase Orders
may be used, but are not needed. Alternatively, other control mechanisms
such as blanket releases or electronic Kanbans may be substituted without
changing the basic REA model.

It is easier to adapt a minimal model which provides for extensions,
than a complicated model with assumptions that do not fit particular
situations. The difference has been experienced in costly projects to work
around traditional purchasing software in fast-moving supply chains (for
example retail Quick Response projects).

By "supply chain" we mean all of the activities involved in satisfying
an end-user demand for a product. That includes manufacturing,
distribution, transportation and retailing. Some of the significance of
supply chain collaboration can be seen in the current problems with order
fulfillment in consumer ecommerce. However, the full significance will be
seen as manufacturing is brought into the Web in make-to-order
environments. Dell and Ford are examples of individual companies that are
integrating their component suppliers via the Internet. These private
initiatives are important, but the full benefits will come from a public
standardized semantic Web.

(Some authors use "supply chain" to mean manufacturing procurement and
"demand chain" to mean distribution and retail. This paper uses "supply
chain" for all of the above.

Other related phrases include "value chain" or "value system". The
"value system" concept of Michael Porter is close to what we mean here by
"supply chain".)

By "semantic model" we mean a computer software model of real-world
supply chain activities. Another term for semantic model from the field of
knowledge representation is "ontology": the set of classes, relationships,
and functions in a universe of discourse.

We use the term "semantic model" to differentiate from something like
XML, the eXtensible Markup Language, which is often touted as the language
of the semantic Web. XML is just a format; it has no content. A semantic
model describes the content of the semantic Web: that is, what classes of
objects, relationships, and functions are involved in supply chain
collaboration. The REA semantic model can be expressed in many formats:
XML, UML (the Universal Modeling Language), a relational database, and/or
an object-oriented programming language. Using XML as the lingua
franca, any REA-based system should be able to interoperate with any
other REA-based system, because they understand business objects and
events in the same way.

We use the word "Web" to mean that each activity in an REA supply chain
is linked together, similarly to the way that documents are hyperlinked
together in the World Wide Web. Individual participants need to be able to
track events beyond their own activities: for example, manufacturers can
plan better if they are notified about retail point-of-sale events
affecting their products. Like a spider web, events in one activity may
have ripple effects on other linked activities.

As a computer network that interconnects an increasing proportion of
the businesses of the world, the Internet makes possible new ways of doing
business. The new ways are much speedier than the old, as the concept of
"Internet years" illustrates.

The existence of the internet changes everything. None of our existing
enterprise software is a fit platform, for dialogue with the other
enterprises in our market space, even with the additional help from hubs
and portals.--Todd Boyle, General Ledger Dialtone

The old ways, of paper documents or their electronic equivalents, are
too slow to keep up with the accelerated pace of the most-wired
businesses. Yet most Internet business applications are still based on the
same old paper documents.

At the Graphic Communications Association's (GCA's) executive
conference last year, Gerry Galewski, a philosopher on information
technologies, gave a provocative explanation on why it often takes years
to truly appreciate the full potential of new technology:

"Now let's look at how we do business in the 1990s. In the 30s and 40s
and 50s and 60s professional managers defined the common business
processes that we use to this day. Then computers and networks were
developed. And we set out to take advantage of this new technology and
automate our processes, and naturally we did that based on a cultural
context. Therefore we called this new capability 'Electronic Document
Interchange.'

"But the underlying document model driving the process stayed the same.
We called it 'Paperless ordering,' or 'Paperless invoicing,' yet the
fundamental process flow stayed the same. Even though it enabled entirely
different business methods such as 'just in time inventory,' we still had
not reached that next fundamental level of understanding. This is now
changing. Eureka events have taken place.

"The existence of the Internet has created the ability to re-invent the
way that we fundamentally do business to make us all more interconnected,
closer in time and space, with less manual work, our processes more
timely, and our operations more and more streamlined." Source

Business deals on the Internet can be "hyperlinked" (speaking
metaphorically) like Web pages. These "hyperlinks" are formed by the
chains of transactions that animate supply chains. They are traversed by
business messages, not people.

The REA business model contains an object called a Stock Flow that is
the equivalent of a hyperchannel for business messages. REA Stock Flows
can connect all of the activities in a multi-company supply chain in one
simple and uniform way: one end of a Stock Flow "hyperlinks" to the
previous activity, the other end "hyperlinks" to the next activity.

(If the metaphorical use of "hyperlink" seems too strained for you,
think "link for business messages" instead.)

An enterprise system (such as ERP) is a system for a single company,
attempting to integrate most of the business activities within that
company.

A supply chain almost always spans across multiple companies, but
involves only a relatively few people and resources within each
company.

One enterprise may be involved in many supply chains, for different
product lines or different markets for the same product line.

A supply chain is much like a river system with raw materials at the
headwaters and customers at the delta, with products floating down the
river toward the customers.

A supply chain system is a computer network connecting all of the
people along the river.

A supply chain semantic model is a model of the information flows that
accompany the real-world supply chain material flows: the demand flows,
the material movements, the process activities, and the cash
flows.

A supply chain semantic model should look like a supply chain, not a
single company. ERP systems do not actually have any model of a supply
chain, nor does EDI, nor do the two of them together.

To use ERP as a semantic model is to break up the supply chain into a
network of individual companies, whereas the real supply chain is a
network of individual people within the companies.

This is a big difference: it can take many complex steps for
information to get from the gateway of a company to an individual within
the company. If the individual is in customer service, and EDI is a daily
batch job, it may take only one day. If the individual is in
manufacturing, it can take several days. If the individual is in a
different company (for example a component supplier), the time multiplies.
Each company boundary is a hindrance to the supply chain information
flow.

To use ERP+EDI as a semantic model for a supply chain involving
manufacturing, the demand flow would go like this:

This is not a simple linear flow. MPS, MRP and CRP are usually batch
computer jobs that run at night. Often they must be reiterated several
times before a stable production schedule is achieved. Likewise EDI is
often run as a daily batch process.

That means a single demand signal can take days to go from EDI input to
production in a single manufacturing plant.

It means a single demand signal can take weeks to travel across a
multi-plant supply chain, even if the multiple plants belong to the same
company.

Moreover, order changes go through the same tedious process. And there
is no way in the ERP-EDI information flow for upstream schedule problems
to travel downstream. For example, a raw material supplier’s inability to
meet a delivery schedule could have severe ripple effects on order
fulfillment to the end customer. Those ripple effects cannot be
transmitted through the ERP-EDI information flow.

The ERP-EDI information flow cannot possibly keep up with the actual
events in the real-world supply chain. The information lag can be days or
even weeks, not just minutes or hours.

Jac Nasser, Ford's CEO, reports in ComputerWorld that "to process
orders through the network of suppliers… can take a month or more in some
cases now."

Besides slowness, ERP systems are proprietary. Whereas their internal
semantic models are similar, especially if they come from an MRP
background, they are certainly not identical or easily
inter-operable.

To be fair, there are several indications that ERP systems are evolving
past their current model:

Each of the leading ERP vendors has either purchased or partnered
with an APS vendor, and is swiftly developing Internet versions of their
supply chain offerings.

PeopleSoft bought Red Pepper, and indicated at one time that they
would build their supply chain software on top of Red Pepper's APS
system. (However, thereafter the president of Red Pepper, Monte Zweben,
left PeopleSoft; PeopleSoft has purchased other APS vendors; and the
rest of their system appears to be order-based.)

SAP broke off a relationship with i2 and then announced that they
would build their own supply chain software based on components from
ILOG that are compatible with REA.

BAAN bought Berclain, an APS vendor whose internal model is
compatible with REA, and may be using the Berclain model as the basis
for their Internet supply chain offerings. Incidentally, BAAN has always
been a little different internally from the other leading ERP systems:
while the others were built on top of an MRPII core, BAAN was developed
from a project management system.

The APS and Demand Flow models are a lot like REA without the cash flow
side. (See Eli Goldratt's Haystack Syndrome for published details
of one very REA-like APS model that was a precursor to i2.) To the extent
that the ERP vendors evolve in this direction, their systems will become
more like REA (or at least they will become more capable of Internet
supply chain collaboration).

However, unless they adopt a non-proprietary Internet standard semantic
model, they will still not achieve Tim Berners-Lee's vision of
revolutionized ecommerce. The Open Application Group is an
attempt of the various ERP companies to move toward a non-proprietary
standard for application integration, somewhat like a standard set of EAI
interfaces. However, the OAG standards assume a generic ERP model, not a
multi-company supply chain model. They may be useful to connect existing
ERP systems to a cross-company semantic Web, but they are not capable of
being the semantic Web themselves. (This is not to denigrate OAG: they did
what they set out to do - develop open interfaces - and an REA semantic
Web will certainly want to use them.)

Advanced Planning and Scheduling systems were designed to compensate
for the weakness in schedule speed and precision of ERP systems. They are
usually add-ons to ERP systems. Although most ERP companies have now
purchased APS systems, they are still add-ons.

Lately, APS systems such as i2 have graduated to the supply chain
management arena, attempting to use their considerable scheduling skills
across the whole supply network.

APS systems can keep up with the flow of events inside a single
company. But like ERP systems, they too are essentially single-company
systems. Even if all supply chain partners adopted the same APS software,
they would still be running separate systems with some kind of EDI-like
gateway between them.

Moreover, APS systems are proprietary. Their vendors usually provide
interfaces to selected ERP systems, but seldom to another APS system.

Also, APS systems, coming from a focus on capacity scheduling, tend to
be weaker on material planning than the MRP module of an ERP system. And
they usually have no process execution or cash flow management
capabilities. So they are usually still dependent on a legacy ERP system
for critical supply chain functions.

Enterprise Application Integration systems like Vitria have a
cross-company messaging component that can keep up with the actual events
of the real-world supply chain.

But EAI systems are still usually lacking some of the key features of
an REA model:

Because their focus is to integrate other applications, they do not
do very much themselves, delegating actions to the separate
sub-applications that they connect.

The level of integration may be little more than passing information
from one sub-application to another.

They may not understand the relationships between supply chain
objects like material flows and cash flows.

Their idea of a supply chain model may still be designed for a
single company, with messages going from one company gateway to another.
Thus, they are still subject to getting bogged down in the ERP system.
(One exception to this problem is Extricity, which has an explicit
multi-company software model.)

Most EAI systems provide a scripting language and a scriptable object
model, so it would be possible to create an REA supply chain model using
the EAI system. However, once again, the EAI scriptable object models are
proprietary.

The problem with trading hubs was described by Walid Mougayar in a
recent Business 2.0 article entitled "Open Market Misnomer":

Internet pundits long have preached a vision in which all online
businesses and marketplaces enjoy interoperable connectivity and
spontaneous brokering of electronic services among dozens of far-flung
companies.

But this dream may remain only a dream because the top two forms of
business-to-business commerce models both exhibit classic private club
characteristics: By invitation only.

...Assume you are a production goods supplier to one of the top B-to-B
companies - Dell Computer, Cisco Systems, or Intel. The way you
electronically connect to each company is radically different. From
product catalog searching to inventory status inquiries or order
management, each company demands adherence to its own set of ebusiness
methods and technologies. It is agony for the supplier that has to deal
with three different integration processes, some requiring changes in
internal practices or costly human intervention.

...Trading hubs such as Ariba's Ariba Network and Commerce One's
MarketSite.net are emerging as another popular B-to-B model. They have the
potential to be the cutting edge of ecommerce, but they currently are
costly and require proprietary linkages, practices similar to restricted
clubs with private access and participation.

The fast-growing electronic trading marketplaces are also riddled with
rigid rules of participation and operation. That's what makes them
efficient. On the other hand, they seem to have attracted only the elite
of ecommerce participants, and that's detrimental to the evolution of
healthy marketplaces. The result is a private network of companies - which
sounds like old-style electronic data-interchange networks. Most walk-ins
would probably fail the entrance exam. --Walid Mougayar Source

Walid Mougayar's perceptive analysis contrasts with the cheerleading
going on in most other current B2B writings, for example BusinessWeek.
If Ford and GM use two different B2B systems - as BusinessWeek
uncritically exclaims - what does Bosch do, who supplies both of them and
Toyota, Nissan and Daimler-Chrysler as well?

Each of these groups represents an attempt to develop a non-proprietary
Internet standard for business-to-business ecommerce. To that extent, they
are moving in the right direction.

However, none of these initiatives has a semantic supply chain model
with anywhere near the breadth and depth of REA.

All of these Internet B2B e-commerce "standards" have focused on
purchasing (in other words, Exchanges in the REA model (see below)). But
there is a lot more to the world than purchasing: there is also
manufacturing, and transportation, and all of the links between all of the
processes in the supply chain.

Purchasing is a point-to-point relationship between two companies, and
it cannot give an overview of a supply chain. The action is in the whole
supply chain, not just two isolated points.

Some of these initiatives (for instance eCo) have richer models that
could easily accommodate an REA supply chain model. The proposal for REA
standardization below recommends building an REA-XML model on top of one
or more of these initiatives. Of course, it would be easier if there
weren't so many of these "standards"...

the REA model has been validated for correctness by peer review in
the leading accounting journals, and accounting is among the most
meticulous of business professions;

the REA model accommodates continuous updates of accounting and
performance reports of any kind, as in Cisco Corporation’s "virtual
closing" where business managers can get instant business overviews that
drill down to details;

an REA model can encapsulate other business models and use them as
subsidiary components;

an REA semantic Web would not need to be developed all at once, in
an impossible engineering feat – it can be developed by piecemeal
growth, as long as a core standard is preserved;

an REA supply chain model can either work well with other systems,
like EAI, or it can grow into the whole business system on its own, for
a seamless combination of supply chain and enterprise systems;

an REA model can perform planning functions like MRP and APS itself,
or it can delegate these functions to other systems.

REA works by give and take. Remember the acronym: Resources, Events and
Agents. In an economic Event, an economic Agent gives one economic
Resource (for example, a product) and takes in return a different economic
Resource (for example, cash).

In an REA economic exchange between two companies, the Supplier agent
gives a product, which is taken by the Customer agent. In return, the
Customer agent gives cash, which is taken by the Supplier agent.

In an REA production process, components, labor and machine time,
energy, etc. are given (consumed, input) , and completed products are
taken (produced, output) in return.

REA activities are either Exchanges, which trade Resources between
Agents; or Processes, which consume input Resources and produce output
Resources.

REA activities are connected by Stock Flows, which represent one
Resource moving from one activity to the next.

In planning, one Stock Flow represents one dependent demand or one line
item if you want to think in terms of orders.

By means of these simple components, REA can represent any business
process. You can put orders on top of REA (Exchanges = purchase and
customer order line items, Processes = work orders) but REA does not
require orders. REA was designed for computer-to-computer communication –
not to mimic paper systems.

There is a lot more to making a whole system out of REA components, but
the basic components are very simple – a lot simpler than ERP systems.
Which means that REA software can also be simpler to develop and
implement.

Also, because all REA activities are uniform and connected by Stock
Flows, information flows can be fast and simple.

Each Event on an REA supply chain knows what other events it is
connected to, via the Stock Flows.

Changes, such as demand or schedule changes, can ripple across the
Flows to all affected Agents.

Each Stock Flow has one or more roles for Agents.

The Responsible Agent is responsible for handling Events that require
human judgment. In an Internet-hosted REA network, these Events would
arrive at the Agent’s ToDo List with a set of Feasible Actions that could
be selected by a mouse click.

Each Agent can be accountable to superior Agents, giving an
organizational structure. The superior Agents may be notified of
subordinate activities that they wish to monitor. A Superior Agent can
have a near-real-time overview of all business events in her span of
control.

REA Processes can be nested: for example, one Process at the supply
chain level can expand into all of the activities in a manufacturing plant
at a lower level. This process-nesting allows each level of an REA supply
network to be relatively small, but contain all the required detail at
lower levels by dividing and conquering.

Logistical Software LLC was formed to develop Internet supply chain
software based on the REA model. Here are some screen shots from
Logistical’s Supply Chain Action Network.

First is the Business Model. The model depicted is for a computer
supply chain.

There are two main sections to the model: Agents (called Parties in
this model) and Resources. Only Product resources are shown here. The
Party section of the model has more hidden detail in the form of an
organization chart with positions and employees.

The Resource section also contains the business model for Processes and
their input and output Stock Flows. Note that the business model contains
multiple companies, and the process flows span all of the companies.

Interactions between the participants in the supply chain is very
simple: each party works off an Internet ToDo List. Because REA is an
event-driven system, users mostly just respond to business events. Rules
can be set up to handle some events automatically. Other events are put on
ToDo Lists for human judgment.

The different ToDo Lists are connected by REA Stock Flows on which
dependent demands and other business transactions travel, for example:

Here we see the ToDo List for the OEM supply chain planner. There is
one unsatisfied demand to deal with. This business event came to the OEM
planner automatically, over an REA Stock Flow link from another
process.

The OEM planner takes action, planning a supply process for the
required PCs. No orders are needed.

When the Submit button is clicked, dependent demands will be instantly
propagated to the next agents in the chain.

Here a dependent demand for motherboards to be assembled shows up on
the Contract Electronics Manufacturer’s ToDo List. When the CEM takes
action, more dependent demands will be sent to the next agents, etc. Rules
can be set up to propagate transactions automatically where human judgment
is not needed, bypassing ToDo Lists altogether.

All information flows move across companies very quickly. Changes and
problem alerts move from agent to agent in the same way that demands flow.
Everything is connected by REA Stock Flows in the background.

These interconnected ToDo Lists amount to a multi-company workflow
system driven by business events.

But it is different from most workflow systems, which are really just
document flows that route a document around until it is completed. The REA
Stock Flows generate the next dependent events triggered by the current
event. For example, the Motherboard demand triggers the dependent demand
for the Motherboard components.

REA is a superior accounting model, but its popular acceptance has been
held back by the conservativism of the accounting profession. (Needless to
say, accountants are conservative for good reasons, among them legal
constraints.)

Internet supply chain collaboration and Internet trading communities
may be a more fertile field for the REA model to gain popular acceptance.
The REA model is much better than any competing semantic model for
multi-company supply chain collaboration. The Internet as a means of
coordination is driving supply chain collaboration very quickly, but there
is no accepted standardized semantic model that can actually encompass all
supply chain activities. A standard, non-proprietary semantic model can
make supply chain collaboration more like a public utility (the semantic
Web) that businesses plug into than the current slow and expensive
collaboration projects.

REA can become the semantic Web for supply chains. But it will take the
concerted efforts of the REA community (and new recruits) to make it
happen. This paper is intended to further that effort.