Interenterprise Computing Enables Supply Chain Synchronization

Trading Data Between Computers

In an ideal world, the techniques of interenterprise computing would be driven by the needs of enterprises; in 1999, quite the reverse is happening. Technology companies are rapidly developing powerful interenterprise tools, and businesses are wondering what to do with them. Not surprisingly, some of the best ideas are ignored, while some of the worst are put right to use.

Currently, you can buy software that allows you and your trading partner to synchronize your activity around a single, shared demand forecast. You can buy software that allows your distributor to sell your baked goods off the back of his truck and his account is debited immediately. You can buy software that lets people requisition pencils and adds the demand immediately to a standing order from the best available supplier and pays the supplier when the order is delivered.

All these new tools have a very simple appeal: they help information in one company's computer get into the computer of its trading partner without a lot of fuss and fret.

Fuss and Fret

The trick, of course, is that when information crosses the borders of your enterprise, a certain amount of fuss and fret is entirely in order. One doesn't necessarily want all one's information blasting into other company's computers; one only wants selected information to move over. And for that information to be useful to your trading partner, a certain amount of work will have to be done. I know how many of my item number is needed, but what does that mean to the trading partner's computer, which identifies the same object with a completely different item? Data, in other words, can't just be pushed over; it has to be selected, extracted, modified, moved over, reinterpreted, and sucked up; and if any data has to come back, the same process must happen in reverse.

Is all this fuss and fret worth it? The simple and obvious answer is, "not if data transfer is all there is." Here, for instance, is how interenterprise computing works in the famously efficient Japanese auto industry. Toyota generates orders in its computer system and sends the orders electronically out to its trading partners over a dedicated wire attached to a special receiver. The trading partner gets the order, and somebody types the order into the partner's computing system. Typing kanji is not all that easy; yet it's more efficient to type than to develop a software program that does the translation automatically.

It isn't enough for an interenterprise application to make an existing business model run faster. For an interenterprise application to bring some serious return on investment, it must enable a different business model, one that couldn't work without the application.

Supporting New Business Models

We can now see why the applications are ahead of businesses. Interenterprise applications are often quite simple and easy to build. But new interenterprise business models never go in quickly.

Software companies respond to this fact in a fairly rational way; instead of building full support for a business model, they build what might be called "interenterprise middleware:" tools that allow the companies adopting business model to build the application they need. Like intraenterprise middleware, these tools provide the facilities for extracting data, transforming data, and transporting data, but they don't do so at a level that would allow a company to simply open the package and get to work. Why bother to do more, after all, if the processes themselves are in flux?

Of course, in the absence of a standard--de facto, like software, or agreed upon by industry groups--the business processes are likely to stay unstable. Without a standard, each bilateral relationship is subject to negotiation. Since all relationships have some uniqueness, the result will be in each case, a unique interenterprise computing relationship. The inefficiencies of this may be brutally obvious, but in fact, up until now, this level of inefficiency has been the rule, rather than the exception. Yes, there have been standards committees, and yes, in certain industries, interenterprise computing is quite common. But the industries where interenterprise computing is most common are those where certain trading partners have a great deal of power and they can use that power to enforce consistency on their side of the deal.

Will the Web change all this? Certainly, the wide availability of a cheap and simple medium for data transport will make for fewer inefficiencies. But if one looks back at the history of interenterprise computing before the Web, one can see that the most difficult problems will remain even after non-Web EDI has disappeared into the mists.

Before the Web: EDI

EDI (or electronic data interchange) is a system for passing orders or activity information (such as inventory withdrawals) from one company's computer system to a trading partner's computer system. EDI is most common and most advanced in the automotive and consumer packaged goods industries, but it is used more or less in every industry. In a typical EDI relationship, information is extracted by a separate system and put into a "standard" message format, that is, a format that will be understood by the trading partner. The message is typically sent by telephone either to the trading partner directly or to an intermediary (a VAN or Value Added Network) who guarantees later delivery.

In the automotive industry, EDI was forced on suppliers by the large automotive assemblers, who were trying to implement some form of Just In Time delivery to their factories. In one of its simplest forms, it was no more than a signal to deliver, let's say, four seats to the line in exactly two hours. As time went on, however, the number and complexity of messages increased substantially, and new kinds of messages emerged. The single request for a delivery still exists, but added to it are multiple forms of delivery schedules, which contain anticipated delivery amounts and delivery times extending as far out as a year.

This automotive business model had three advantages over later attempts: the business model itself (Just In Time) was already working in Japan, and American manufacturers were struggling to replicate it. (In Japan, of course, people were entering the data by hand-keying it in, but that detail is still not widely known.) The power relationships, moreover, were also well adapted to the adoption of interenterprise computing. Big companies could simply tell their smaller suppliers to use EDI, and since those suppliers often had only one customer, they were not burdened by having to adopt many different EDI standards.

Even so, there was some attempt at creating cross-industry (and, from there, multi-industry) standards. The Automotive Industry Action Group (AIAG) developed message format standards for specific industry requirements and, through standards organizations--naturally, different ones in the US and Europe--these standards were regularized. Today, an EDI 855 is a Delivery Forecast, as in "We'll send you an 855 every week," in many different industries.

The word, "standard," however, is a term of art, one that masks a good deal of sweat. For any two trading partners to agree to exchange 855s, they must agree on which version of the standard they'll use and, because business relationships and personalities vary, these versions vary. In the automotive industry, most "standard" EDI messages use some fields (globs of information) in the prescribed way, ignore others, and use still others in ways that are completely non-standard. EDI translation programs exist to transform one "standard" version into another, but that is only a start. Effectively, those suppliers that supply to several different customers must manage multiple EDI relationships.

Automotive EDI is, of course, only one example, but the many others follow a similar pattern. In Consumer Packaged Goods, vendor-managed inventory (VMI) is a fairly common business process that is supported by EDI. The idea of the process is that the supplier monitors inventory levels at the customer's warehouse and ships the correct amount whenever more is needed. In a VMI relationship, warehouse withdrawal messages (EDI ???) are almost always used, and in some advanced systems, forecasts of future demand (EDI ???) are also passed. The VMI idea actually emerged from a group that represented many different industry players (the Efficient Consumer Response or ECR group), but even so, most VMI relationships differ significantly from the others, and they have often become an opportunity for cost shifting, not cost reduction.

In this section, we will describe three new areas for interenterprise computing: open purchasing; collaborative forecasting, and shared computing. We will also mention some software companies that provide capability in the area and focus on one.

Open Purchasing

Large companies are big shoppers, so big that they feel that they must create groups whose sole responsibility is to find the right supplier, send the supplier orders, and, ultimately, pay the supplier. No one likes this system: it separates the buyers from the buying process; it slows down acquisition; and for small, irregular purchases, it is enormously expensive. One company we know with $3 billion in purchases has 65,000 suppliers, with a great number of them accounting for only $200-$400 worth of purchases. Since it costs some fairly large percentage of that amount just to maintain the supplier in their lists and create the orders, it is hard for these to be economic relationships.

Is there anything to be done about this? Enterprising software companies have invented a new term, Operational Resource Management (ORM). They promise that with ORM software, their customers will be able to streamline purchasing processes, especially for so-called "indirect materials" purchases, purchases of paper, pens, wrenches, screws, etc., which tend to be far more difficult to control than raw material purchases.

The truth is, of course, more complicated. As always, it is not worthwhile simply to automate the process; the ORM vendors are actually pushing a new business model. Their idea is to tie the actual buyer in the company and the vendor tightly together, but keep the purchasing department somewhat in the loop. They do this by allowing companies to build electronic catalogues of approved items and letting the buyer requisition the items while browsing through the catalogue. In many cases, the requisition can pass directly to the vendor over the Internet and the delivery can be made directly to the buyer's organization.

Certainly the old process is streamlined, but this is done by substituting a new business process: the creation of catalogues and the negotiation with vendors to receive requests electronically. Catalogues turn out to be difficult to create and use because people have lots of different names for the same thing and lots of special requirements. If the catalogue doesn't allow them to express their needs, they won't use them, and all you'll have is a very expensive way of streamlining the old process.

There are many companies that are experimenting with some form of this business-to-business e-commerce: PeopleSoft has something called Business to Business; SAP has adopted pieces of the old CommerceOne product for electronic catalogues; Extricity helps manage complex purchasing processes; Netscape's Actra (purchased from GE) focuses on electronic purchasing.

A rather small California software company called Ariba focuses on requisition management. The user can requisition any resource, internal or external, using a browser; the resources include people or machines as well as purchased items, and, in a soon-to-be released version, travel and entertainment requirements. Like the other ORM vendors, access to information about externally supplied resources is provided through catalogues. The idea is that the job of purchasing shifts to negotiating with the vendors their position in the catalog and method of responding to catalog requests. The difficulty is that the system fits uneasily with existing purchasing systems from an ERP system.

Ariba and its ilk will succeed if they do in fact make purchasing more open, but this will almost certainly involve some relinquishing of control on both ends of the transaction. On the catalogue end, large companies can probably afford to build their own, but medium-size companies will have to get some that are pre-assembled. Both Dun & Bradstreet and Aspect Development already offer services in this area (in addition to those companies that simply outsource purchasing). More are surely coming. On the requisition end, it will be difficult to write computer-based rules for purchasing that actually fit most real situations. In order to keep people using the requisition system, they will have to loosen the rules.

Collaborative Forecasting

One of the most important, but least visible costs of doing business is the cost of dealing with one's business partner's unreliability. My supplier is pretty good, but 10% of the time they deliver late. OK. Keep enough inventory on hand to cope with the lateness, because you never know when it will happen. Sometimes my customer asks for 20% more than we expected. OK. Keep some supply on hand; this is a good customer.

One could rid oneself of a large part of this expense if one could just cut down on the surprises--or at least share the expense of dealing with them. If one had a better view of the trading partner's demand (or supply) and they had a better view of yours, perhaps you could cooperate, so as to reduce the amount one budgets for protection and share the costs, when demand fails to match supply.

This is the idea of CPFR (Collaborative Forecasting and Replenishment), a business practice originally invented by a group of software companies, trading partners, and consultants and now adopted as a standard by VICS (Voluntary Interenterprise Commerce Standards), a committee of major players in retail and consumer packaged goods.

In operation, a CPFR relationship between two trading partners means that the two share both demand and delivery forecasts, discuss them, and agree, finally, on numbers that both parties will then use. The forecasts can extend out any length of time, but in the near term, the forecast numbers become committed delivery numbers.

CPFR involves much the same information as the EDI delivery schedules described above that are used in automotive. The difference is one of power. In CPFR, both parties collaborate on a final delivery number, based on their information about the market, their estimates of demand, and their ability to deliver. In automotive, the delivery schedule is dictated by the customer; if the customer wants to change it, he does.

The difference also involves significant differences in the computing power required to support it. A schedule sent to an automotive supplier may be received and retyped into a new system. A schedule of future demand may be received by one person, circulated to others, put into a new system for examination and simulation, compared to other forecasts, and then returned (multiple times) with comments about specific numbers.

The simplest possible system that could support this is e-mail with attached spreadsheets. But this system has very limited security and workflow and is overwhelmed by large numbers of entries or large numbers of forecasts. It also leaves aside the problem of inserting the data into other systems.

Because of this last problem, several of the major enterprise software or demand management software companies (a partial list includes SAP, PeopleSoft, i2 Technologies, and Manugistics) have announced and partially delivered capability in this area. In addition, one company, Syncra, has announced a set of software tools that support the CPFR standard, but are designed to work with any other major software package.

In one sense, Syncra is comparable to an EDI translation software provider. It takes messages from one system, transforms them, and delivers them to another system. But it does so in the context of a business understanding of the process. Shared forecasts need to be circulated and approved; accordingly, workflow management is included. Shared forecasts typically require comments only on a few numbers, the exceptions; accordingly, Syncra provides tools for finding and highlighting the exceptions. Shared forecasts require the ability to compare current forecasts with past forecasts; that ability is provided automatically.

The risk that Syncra (and all the others) runs is that it may end up supporting the wrong business processes or be unable to adapt to the way that the CPFR standard is actually implemented. Syncra's software would then be less able to support the standard than less complex middleware. The risk is lessened because there is a clear, but not terribly detailed CPFR standard, but it is a risk.

Multi-Enterprise Shared Computing

In typical distribution chains, many people handle a product, but at each point where the product is transferred, ownership is transferred too, and the pass-off is clean. In these days of disintermediation, more and more distribution chains are being set up where the pass-off is not clean. Take a simple example, the case where a bakery makes bread and gives it to an independent distribution truck. The guy on the truck sells it to somebody who sees him stopped at a traffic light and thus that loaf doesn't go to the bakery at the end of the line.

Technically, the driver never owned the bread, so there was no pass-off. But he will take a commission on it. At present, let's say, he returns the unused bread and any cash and is paid a commission on the amount of bread sold. In more complex versions of this distribution chain, however, each of the processes may need to be tracked by the computers of all the companies involved. One possibility might be that each of the computers registers each transfer and then uses a complex system of chargebacks to sort out what happened (commission, price, failure to meet demand).

Another possibility, however, is to manage the distribution chain with a single computing environment, but make available to each party only what is interesting to them. Several companies are proposing models for doing this; among the most interesting is a company called Descartes. They are now beginning to market a model that promises to manage this in a particularly interesting way. Based on a system developed by the Dutch telephone company, they actually store each new transaction (the transfer to the driver, the sale) in its own place; at the same time, they store pointers from each of the transactions to all the other relevant ones.

This is actually a new computing paradigm being put at the service of a new business model. The business model involves a level of shared activity heretofore impossible (because it was impossible to sort out); computing model involves distributed data managed by a shared application.

Unfortunately, this is an example of an application that may be ahead of the business model. Complex distribution chains abound, but they typically involve people who are not able to use the power that this kind of system offers.

CONCLUSION

Shared computing does not even begin to exhaust the realm of way-out (and possibly wonderful) ideas that are being seriously considered in the age of the Internet. A company called IndX is developing viewers that allow you to feed multiple data sources from inside and outside the enterprise into a single data-warehouse-like environment. PeopleSoft demonstrated a system that allows people to select benefits based on a real-time evaluation of the various choices conducted automatically over the Internet by a completely separate evaluation package. SAP demonstrated a Coke machine that feeds data about sales to the Coke distributor. Especially when any idea even smacking of the Internet can grab a market cap of nine figures without any business at all, there will be lots of good notions being thought up.

It is, however, relatively easy to tell which notions have some traction today and which notions will have some traction tomorrow. If there is a confluence of a new business model, an interenterprise standards body, and software, then it is likely that people will adopt it and even gain benefit from it. The result may not be what the standards body envisioned, at least if EDI is any indication. But it will be a result worth knowing about.