8/16/99

Where Might Standards Further Enterprise Integration? Analysis of Likely Possibilities

The challenge is to improve enterprise integration, i.e. to move supply chains towards the goal of timely, appropriate, and seamless information flow among trading partners. While the true nature of the problem will have to await empirical investigation, we do have a sense of where the problems will be found. They fall into two domains (Strictly speaking, there is an intermediate category wherein a computer works at one end and a person at the other. But the existence of this category does not change the fundamental dynamics which are described here.)

machine generated, machine read, and
person generated, person read.

In each case difficulties will undoubtedly be resolved through some combination of standards, technology (e.g. translation software), and labor (e.g. using people to organize information). Our task is to assess the problems and to determine the role of standards in developing solutions.

Machine Generated, Machine Read
The traditional method of electronic data exchange in the automotive industry (and indeed in all industry) has been Electronic Data Interchange (EDI). EDI is not synonymous with "sending business data in digital form". Rather it is defined specifically as the "standards based, machine-to-machine exchange of business data". The "standards" involved are usually either ANSI X.12 or EDIFACT, the European (and perhaps to become the World) standard. EDI had its history in the early days of batch process computing, at a time when it made sense to save time and effort by developing digital analogues of standard business documents -- purchase orders, notifications of payment, ship notices, and the like.

The result of the standards effort was a set of "transaction sets" whose content reflected traditional business documents, and whose structured form was loaded with shorthand symbols that only a computer could love. Paper purchase orders had dates, quantities, "ship to" instructions, part numbers, and the like. So did the resulting X.12 transaction sets. Transaction sets were ideal for the computing environment that existed at the time. Because they were structured, (date in field 1, quantity in field 2, etc.) it was possible to make sure they could be generated and read by computers. Because of the shorthand, computer resources were preserved.

Transmission of EDI documents took place in two ways. (Remember, the system was established at a time when Arpanet was only a gleam in DARPA's eye.) When very high volume was required, many companies found it economical to establish direct connections with their trading partners. In other cases a networking industry grew to handle the demand. These "value added networks" (VANs) provided mailboxes to hold messages as well as a variety of tracking and security services. Pricing plans varied, but were usually based on some combination of setup fee, monthly maintenance, transaction volume, and services provided (e.g. did the client want message tracking). Until the widespread diffusion of the Internet and the Web, EDI was what passed for electronic commerce (EC). This is still largely the case in the automotive industry today.

EDI suffers from three critical deficiencies (and a variety of smaller ones which we will not bother to discuss here). The first problem is that because the X.12 standard provides lots of options, it is quite possible (indeed likely) that hundreds of transaction sets are 100% certifiable X.12 kosher, and yet none can be understood by the other. To solve this problem the automotive industry (through the efforts of the AIAG) set an industry standard which constrains X.12 choices. That effort helped, but not enough. Even within the AIAG framework, individual companies, and often divisions within companies, configured transaction sets in different ways. Because of standards diversity, EDI users resort to translation software that has to be customized for each trading partner.

Second, EDI is only useful in cases where volume is high enough, and information predictable enough, that a business case can be made for machine-to-machine communication. EDI shines when trading partner's have internal systems that are able to automatically generate, transmit, and use information. In most situations these conditions are not met. Either internal systems are not capable, or traffic volume is too low, or the information is too diverse and unpredictable.

A third problem is the expense of transmitting EDI data. Not only are VANs expensive, but they are single-purpose. An investment in a VAN cannot be amortized over many different communication activities. (The situation is in flux because VANs are moving in the direction of providing ISP services, and technologies are emerging which allow EDI transactions to be sent over the Internet. Still, the situation is basically as we have described it, and its not clear how much changes in EDI technology and the VAN industry will substantially improve the situation.)

As a result of these problems, we are in a situation where the few companies with high data transmission needs see EDI as a competitive advantage, while most of their trading partners see it as a cost of doing business. This is not a good formula for widespread technology diffusion. In fact even companies with clout have trouble getting their trading partners to use EDI. We have been analyzing market research data which shows that even for big companies, "resistance from trading partners" is the most important barrier to doing EDI. (The data come from Faulkner and Gray EC Resources, with whom we have a strategic business partnership.)

There are work-arounds to the problem. For instance, a company may invest in minimal EDI technology and print out incoming X.12 messages in English. Its an expensive fax machine, but its often worth a few thousand dollars to keep an important customer. A second approach is to use the emerging technologies which allow a company to generate EDI messages which others can read through a browser. Because of this second solution, its possible that expense alone may decline as an inhibiting factor in the use of EDI. But even with these economies, classic EDI will never make business sense outside of settings characterized by high volume, predictable information flow, and internal applications that are capable of automatically transmitting and using the information.

Person Generated, Person Read
Business is replete with situations which require human judgement. Information can be unpredictable. Situations can be non-routine. Uncertainty may be high. Decision consequences may be grave. These and myriad other criteria demand human participation. When people are involved, the concept of "enterprise integration" means information flow among trading partners that can assist in decision making. We know the critical aspects of this flow for business as a whole. Empirical analysis will be needed to ascertain their importance in automotive enterprises.

It is important to bear in mind that many companies and not-for-profit organizations are presently developing solutions to the "person to person" elements of enterprise integration. Many solutions are commercially available and many others are the subjects of active research and development.

Thus for many aspects of the problem, the question will be whether standards can further activities that are already well under way. For each task, will be to assess the potential value of new standards in light of

current state of commercially available technology
structure of the vendor market
likely technological developments
evolving business needs

Major aspects of "person to person" enterprise integration are:

Nomenclature Because industries do not have standard names or part numbers, the same object is often referred to in different ways. This makes it extremely difficult to know what people are asking for, to search for information or to compare across suppliers. Also, diversity in nomenclature requires multiple systems to be maintained for multiple vendors. The activities of RosettaNet (http://www.rosettanet.org/) in electronics are an encouraging model for dealing the costs of multiple nomenclatures.
Catalogues On-line catalogues are by now ubiquitous. What is not so common is the ability to search multiple catalogues for the same item, with assurance that timely information will be found on price, specifications, and availability. The problem goes beyond a common method of representing items in hypertext. For instance, suppliers often have different per-unit prices or volume discounts for different customers. How can such a suppler contribute a catalogue to a public search engine and still be assured that different viewers will see unique information? The present state of commercially available solutions to this problem is exemplified by the services provided by UPC Express
Resource Searching Companies often use the Web to find suppliers of products and services. Typical reasons for searching include shopping for price, dissatisfaction with existing quality, need for something special, and need for more capacity. Existing search engines can work for this purpose, but they are limited. As one example of their shortcomings, consider two cases where adequate solutions are presently lacking. First, it would be helpful to search only among companies who have been "qualified" to provide a particular product or service. Or, it may be useful to constrain searches by factors such as geography or experience in a particular industry.
Bidding and Negotiation Information and networking technology can be enormously helpful both in developing business relationships with new partners, and with establishing new arrangements with existing partners. RFPs can be broadcast, bids can be accepted, terms can be negotiated. The commercial world is providing these services, as for example, in the case of GE Information Services' Trading Partner Network
Security In the world of electronic commerce, the term "security" usually connotes encryption, authentication, and maintaining the integrity of messages. Despite may people's misgivings, existing technologies are well on their way to dealing with these issues. Other elements of security, however, are less certain. For instance, if I find a new company on the Web, how can I be sure they are who they say they are?
Product Data A great deal of inter-organizational information exchange involves product data. Especially in manufacturing, trading partners must exchange CAD files, product specifications, engineering change notices, and manufacturing process instructions. The need is to get correct information to the right place at the right time. To make the problem even more difficulty, product data files are notorious for imperfect translation between the many systems in which they can be generated, and for the time consuming and expensive errors that imperfect translation can cause. The industry solution is to develop a common standard, known as STEP. (See / for good background on this standard development activity.)

Person and Machine -- Looking at the System as a Whole

The categorization of integration issues in terms of "machine to machine" vs. "person to person" is useful in describing the most common manner in which information may be used. In reality, though, its an artificial distinction because depending on circumstances, a "person to person" exchange can be transmuted into a "person to machine", or even a "machine to machine" context. For instance, an inventory planning system might interface directly to a multi-catalogue search system, so that orders can be automatically placed to the lowest priced vendor who can deliver at the desired deadline.

When should "person to person" transactions be nudged toward automation? Put another way, when does it make business sense to increase the level of enterprise integration? The justification appears when the cost of information handling by a machine dips below the cost for manual handling. This condition is met when the joint levels of information "predictability" and "volume" are relatively high, as depicted in the dark gray region of Figure 1. We believe that there may be cases where standards can allow this business case to be made at lower levels of volume and predictability, as depicted in the lighter gray area in Figure 1. A search for these cases must be included in any analysis of how standards can support enterprise integration.