Electronic Data Interchange (EDI)
One of the first major attempts to electronically enable the supply chain was the development of the Electronic Data Interchange (EDI) specification. Although computers had been introduced into the supply chain since almost the first year they had been commer-cially available, processes and methods were far from standard. In addition, these sys-tems needed an effective way of communicating between disparate points in the supply chain. Using telecommunications, companies could transmit data electronically over reg-ular telephone lines or private networks and have the resultant data inputted directly into their trading partners’ business applications.
However, this means of computer telecommunications only solved part of the problem in tying together the parts of the supply chain. These early electronic interchanges were based on proprietary formats agreed to in advance between trading partners. As the num-ber of trading partners increased, it became increasingly more difficult to exchange data in a reliable manner. Estimates suggest that 70 percent of all computer input has previ-ously been output from another computer. Each reentry of data is a potential source of error. It has also been estimated that the cost of processing an electronic requisition can be one tenth the cost of handling its paper equivalent. Therefore, a standard format for the exchange of data was needed. Work began in the 1960s as a cooperative effort between industry groups mainly in the transportation sector to produce such a standard format. In 1968 the United States Transportation Data Coordinating Committee (TDCC) was formed to coordinate the development of translation rules among four existing sets of industry-specific standards. It evolved to become the EDI specification in the 1970s, gaining first national and then international standard status in subsequent years. The stated goals of the EDI format were as follows:
To reduce the labor-intensive tasks of exchanging data, including data reentry
To be hardware independent and unambiguous in message content so that these messages could be used by trading partners of all types
To provide a reliable means for the delivery of transactions and messages
One of the major features EDI has enabled is a concept called vendor-managed inventory (VMI). The concept around VMI is to shift the responsibility for analyzing sales and for deciding when the buyer will receive new product to the seller rather than the buyer. Using raw sales data sent by the buyer in EDI format, the seller is enabled to make judg-ments as to which products should be produced for sale. In this manner, risks and responsibilities are shifted from the buyer to the seller.
There are two primary syntaxes for EDI: The Accredited Standards Committee (ASC) X12, used mainly in North America, and the Electronic Data Interchange For Administration, Commerce, and Transport (EDIFACT), used in Europe and Asia.
EDI has historically used a standardized, secure, and reliable electronic transmission medium, originally known as the value-added network (VAN), to transmit individual EDI messages between participants in the supply chain process. The VAN provides a common connection point for participants by means of electronic mailboxes. The VAN functions in much the same way as a post office, providing not only a means to get messages from point to point, but also providing a means to guarantee that a message is received in a secure and robust manner. EDI participants dial in to a VAN, deposit all their outbound EDI messages, and simultaneously pick up any EDI messages destined for them.
VANs provide basic services, such as message tracking, that record whether and when messages arrive, are transferred, and are picked up. Faults and disputes can easily be resolved by referring to VAN audit trails. VANs also have the capability to deal with a wide variety of different computers and communication protocols. In effect, the VAN serves as an intermediary that helps to assist in the communication process by serving as a standard, neutral transportation layer—much the same role that the Internet plays today.
Although the VAN is considered by many to be an outdated mode for transportation of EDI messages, it nonetheless is in widespread use. There have been many efforts to move EDI transmission to the Internet, based on its capability for delivering messages at a relative low cost and with simplicity. However, many companies still rely on the VAN for reliable, robust, and secure transmission of their documents. Perhaps that may change in the future, but the VAN will have long-lasting influence as long as EDI remains in use.
EDI messages are text-based, positional, structured messages that are arranged into trans-action sets. Each transaction set represents an exchange between supply chain partners in order to execute some business process. As a result, transaction sets are very focused in nature. The X12 Release 3030 contains 161 transaction sets. Many of them are quite spe-cific; some are shown in Table 20.1.
TABLE 20.1 Sample EDI Transaction Sets
Transaction Set : Description
130 Student educational record (transcript)
819 Operating expense statement
822 Customer account analysis
830 Planning schedule
832 Price/sales catalog
837 Healthcare claim
840 Request for quotation
843 Response to request for quote
844 Product transfer account adjust
845 Price authorization acknowledgment
846 Inventory inquiry
849 Response to product transfer
850 Purchase order
855 Purchase order acknowledgment
856 Ship notice/manifest
860 Purchase order change
861 Receiving advice
862 Shipping schedule
863 Report of test results
865 Purchase order change acknowledgment
867 Product transfer and resale report
869 Order status inquiry
870 Order status report
997 Functional acknowledgment
EDI transactions are processed by a well-choreographed set of software applications and systems. EDI software packages perform two fundamental tasks: encoding data into the EDI format and subsequently decoding response messages. Major components of this system include “translators” to go between EDI and non-EDI systems, “mappers” to associate differing versions of EDI transaction sets, connection software to facilitate
and enable the use of VAN or Internet-based transfers, and internal software integration applications.
Despite the lofty goals of EDI, many of its core benefits have not come without costs and challenges. EDI systems aren’t inexpensive to set up. Most EDI “hub” implementations average over $1 million to set up, whereas individual “spokes” require an investment averaging over $45,000—and these are just the primary implementation costs. Maintenance and ongoing services easily double this figure. In addition, systems take between several days to months before trading partners are up and running.
systems also suffer from a shortage of skilled laborers who have the knowledge
and education to support these systems, as well as the inability and
unwillingness of trading partners to locate and hire these resources to manage
their own implementations. In addi-tion, EDI’s long legacy has given it the
sense of being an “old” technology whose time as come to be replaced by the
“newer, better” thing. However, perhaps the largest chal-lenge to EDI is its
history of implementation. Traditional EDI implementations could only enlist 20
percent of a company’s trading partners, which may account for a signifi-cant
volume but still not enable a company to take full advantage of an
electronically enabled supply chain. After all, these companies still have to
support paper processes for these non-EDI-enabled partners.