@ Supply Chain Management

REA (Resource-Event-Agent) is a semantic model for internet based Supply Chain collaboration developed by Dr. William McCarthy of Michigan State University. In this presentation for the ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2000), Dr. McCarthy and Robert Haugen, Logistical Software LLC outline a web-based semantic model for collaboration.
Before I dived into this thing – I asked myself what do these good people mean by using the word semantic in a semantic model for internet based supply chain collaboration? You can look up the definition here

se.man.tic: Spelled Pronunciation[si-man-tik]
– adjective
of, pertaining to, or arising from the different meanings of words or other symbols
Eg: semantic change; semantic confusion.

So in other words, a semantic model is really a language meaning based model. So, what do the authors mean by using the term sematic model?

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.

The authors also try to differentiate it from XML in the following way:

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.

The authors also supply an outline of the aims of using the REA semantic model:

1. supply chain collaboration requires a standard semantic model that all trading partners can use;
2. to achieve Tim Berners-Lee’s vision (in other words, so that anybody can do business with anybody anywhere), the model must be a generally-recognized, non-proprietary Internet standard;
3. the model must be broad (covering the whole supply chain) and deep (covering all relevant business activities);
4. REA is the broadest and deepest currently available semantic model for supply chain collaboration;
5. and REA is non-proprietary, in the public domain, open for developing into an Internet standard.

So what should the REA semantic model achieve in practical operational terms?

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.

The paper recounts a very instructive story about how change in the light of technological innovation really occurs across the business world and the world at large.

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.”

Now, that’s very good insight into how things work in practice. Allow me to speculate a little – I find that even the words we use to christen new ways of doing things, new processes, improvements or innovations often point to the extent of change that is really taking place even when new radical technologies appear on the scene. The concept of EDI highlights that – the change envisioned by promoters and early adopters of EDI is a limited one in the age of networks and computers – the time has come for the document to go electronic. That’s all. However, had these actors christened it EII (Electronic Information Interchange), it is not that the processes would have been structured differently but that EII would not have been the chosen word for something that had a foot firmly in the past. Today, we’re at the threshold of EII and perhaps its time to tack that name onto processes that will properly be electronic and informational and will constitute interchange.
In the ultimate sense, just as I do not write documents in order to inform my wife of my being late tonight or update my project manager about the status of the project, why do I particularily care that the order for a demanded product flow through multiple systems with approvals, checks and what not before it gets to the dispatcher – I’d like to speak with the dispatcher please!

Next, the authors provide a run through existing alternatives (software models) for supply chain management:

1. ERP, or Enterprise Resource Planning, as exemplified by SAP, BAAN, PeopleSoft, etc.
2. EDI, or Electronic Data Interchange, a set of standards for passing electronic versions of paper documents between companies.
3. XML-EDI, or using the eXtensible Markup Language for to represent EDI transactions, as exemplified by XML-EDI
4. XML for B2B ecommerce, or various initiatives to develop XML standards for ecommerce that are not explicitly based on EDI standards, including eCo, RosettaNet, and BizTalk.
5. APS, or Advanced Planning and Scheduling systems, as exemplified by i2.
6. Trading Hubs, as exemplified by Ariba, and Commerce One’s Market Site.
7. EAI, or Enterprise Application Integration software, as exemplified by CrossWorlds, Extricity, and Vitria.

But the authors argue that REA is not in competition with the above models. Why?

the REA supply chain model lives at a higher semantic level: that of the whole supply chain, across enterprises, including all resources, events and agents and the relationships between them. That is the level required for a semantic Web for supply chain collaboration.

To a certain extent, I find that if the REA does what it claims to do, then it would live at a higher semantic level but all of the above technologies (or mediums and protocols for communicating enterprise information) give rise to implicit semantic representation and those implicity semantic expressions ought to be compared with REA – an apples to apples comparison, so to speak.

Next, the authors ask what is precisely wrong with ERP+EDI, presumably because REA might address those very problems in an effective way.

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.

So, the problem with ERP is “E” or the Enterprise – it is narrowly focused in the sense that it forms the backbone of the enterprise and not that of the supply chain. Coupling the ERP with EDI allows for information exchange between ERP systems or other allied systems for the most part. To distill that to the practical level,

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.

Next, the authors inquire into the state of APS (Advanced Planning and Scheduling systems)
With the necessary caveat of this look into APS being dated, the authors note:

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.

The authors delve into other supply chain management technologies – EAI, Trading Hubs, XML-EDI, eCO, RosettaNet etc before getting into the nitty gritty of how REA works. So how does REA work?

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.

Furthermore,

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.

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.

All of the above reminds me of a software that I worked with for a while called ChangeEngine made/marketed by HP which had this sort of resource, event, agent model and could be used to design and power a business process.
Now, I am sure that ERP and other systems today would claim some sort of similarity to the state of operational activities described above and that is why I raised the point before that what REA seeks to make explicit is what is implicit in ERP, APS etc. Nevertheless, the exercise has me thinking more about how I might think about supply chain collaboration – in terms of people rather than documents i.e. people processes rather than document processes. I think that’s where the solution really lies.

Tags: ERP, APS, Supply Chain Management, Supply Chain Collaboration, REA, Semantic Model, OOPSLA, Resource, Event, Agent