Introduction to EDI - A Primer
4. HOW EDI WORKS
So far we have described the general scope of EDI, and how electronic commerce has and can shape the business world. But how does EDI actually work? Let us follow the steps that have been discussed above in a bit more detail, using the relatively simple process of generating electronic purchase orders for vendors of the FastPart automobile parts distributor. FastPart will, on a nightly basis, place over 100 purchase orders, with 50 different manufacturers. At each step we will review in general some of the requirements for EDI. Following sections will deal with several of these topics in more detail.
While this example shows a supplier and its vendors, the process will be similar in a wide variety of other business relationships, whether for goods or services. This same process would illustrate perfectly the interchange of data between an FastPart and their distributors and retail outlets. The only differences would be the type of transactions used.
Now let's take a more detailed look at these steps, to get a better idea of the range of possibilities and situations where EDI can be implemented.
PREPARATION OF ELECTRONIC DOCUMENTS
The business of preparing the electronic documents is easily the most demanding part of implementing EDI in any business. The variety of methods available to generate the electronic documents are as varied as there are businesses and applications. They can include:
Transcribing data: Users may manually enter their data from printed reports into a small PC-based software package. Many small businesses are required to communicate information electronically to their customers or vendors, but do not have the computing resources to automatically generate information. Their only computer resource may be a PC. In this case, a business can make use of relatively inexpensive "off-the-shelf" EDI software packages that requires only a modem and a PC. Most such products include options to allow users to generate entry forms, permitting them to enter information via the keyboard.
Reformatting existing PC-based data: Small business using PC's frequently have access to commonly used database products, or spreadsheets, from which they can export data such for their EDI transactions. It is also possible with inexpensive commerciallyavailable PC software, to read electronic report files from other applications, and re-format them into data files that can be used by EDI packages.
Enhancing existing applications: For businesses that have existing application systems, regardless of the platform, they can consider having the applications enhanced to generate output in a format that is easily translatable. This approach necessarily requires custom software development. If the application is purchased, enhancements can be requested from the developer. With custom software, enhancements may be done internally if such expertise is available, or it can be developed on a contract basis.
The extent to which software may have to be enhanced or developed will depend on the extent of the existing software portfolio. Generation of purchase order data may require a program to read existing files from a purchasing system and extract the necessary information. Or it may require that the purchasing software be modified to create new output files.
Purchasing software: If a business is in the market to purchase software, insuring that it will meet their EDI requirements should be stipulated as an evaluation requirement. Many software vendors include such capability in packages of basic software. If they do not, it is possible that the vendor can provide the additional functionality at a cost that will be less expensive than in-house modifications.
It should be apparent from this
discussion that participation in EDI trading partnerships can be accomplished by any business. Initial entry into EDI does NOT require a heavy investment in computing resources, and a sophisticated portfolio of business applications software. But by the same token, if a business has already developed its business applications, the capabilities of that software can be enhanced to provide even more benefits.
At the beginning EDI was described in it's simplest format as an electronic exchange of data in a mutually agreed-upon format. Since there are countless application software packages creating purchase orders, all constructed for specific needs and based on different industry and data requirements, the need to provide a common definition of data formats is fundamental to successful EDI. However, the difficulty of accomplishing this is obvious. Ten different companies will almost certainly yield ten different definitions of how a part number should be formatted.
In a simple one-to-one EDI relationship, this problem could be avoided by providing the schematic layout of the data to the receiver, and simply sending the data on it's way without any translation. The receiver could alter and reformat the data to suit their purpose. Alternatively, the two information traders could agree upon a common file definition for their use. Many EDI relationships started out using just such a method.
However, FastPart has several hundred suppliers, and the chance of getting them all to agree upon the FastPart definition of a purchase order format is quite small, particularly if those suppliers are also dealing with hundreds of other customers. This would require a unique set of rules for each partnership. The resulting chaos would quickly drive customers and suppliers alike to return to paper forms regardless of the benefits or savings.
The solution has been found in the evolution over the last two decades of a comprehensive set of national and international standards. These standards, typically developed by specific industry or business groups, have provided commonly agreed upon formats for use in virtually every type of business communication.
These standards provide a structured way of organizing information in a "transaction" format with definitions for the format and placement of each separate piece of data. Translation to a standard format can be accomplished by internal systems or it can be done by a separate package of software. Regardless of the means you choose for translation, the end result of the process will be an output file generated in a specific format that any subscriber
to the standard can understand.
In a simple one-to-one EDI relationship, transmitting data can be as simple as making a modem connection, and sending the file. However, this would become impractical with more than just a small number of vendors. If a manufacturer has to send out thousands of PO's each week to hundreds of suppliers, it would requirea small army and a very exacting schedule, to transmit all of their PO's. Even if the manufacturer had an extensive private network available, successful transmission would require that all vendors be linked into the network.
Providing a connection to the sender's computer to allow receivers to log on and collect their data would be one way to avoid these problems, but it poses a serious security problem. It will work on a limited basis, but only with careful controls, including separate hardware to isolate the system being accessed by third parties. Few companies could accept these approaches, for any extensive use of EDI. If these alternatives were required, chaos would reign, and once again most EDI users would quickly return to preparing printed documents, so that they could rely on the mail to distribute all their documents.
Fortunately, the EDI user doesn't have to rely on either of these alternatives. They can turn to third-party network services, commonly referred to as "Value Added Networks" or VAN's. The VAN functions as a clearing house for electronic transactions, in effect serving as a private electronic mail service. Utilizing a VAN, FastPart can send all of their PO files to a single destination. The VAN then routes each vendor's data to their own electronic mailbox. If the recipient of the file does not subscribe to the particular VAN used by the sender, the transaction can be routed from on VAN to the other.
The VAN provides an answer to the pressing problem of security. It allows trading partners to be secure in the knowledge that the can trade information, but at the same time avoid giving information away. Neither party has access to the other's systems, but can still freely exchange agreed-upon information. In addition, a full service VAN can provide other services, including translation, standards compliance checking, and EDI software to ease the implementation process.
This process is the reverse of outbound translation. Once the PO's have been placed in the electronic mailboxes by the VAN, the vendor can retrieve them at their convenience. The next step in the process is the "de-map" the file, translating it into the specific format required by the vendor's application(s). Since a standard format has been used, the vendor will easily be able to first recognize which company the transaction is from, and then which type of transaction it is. When translation is complete it can be made usable in any desired format to the receiver's internal applications.
PROCESSING THE ELECTRONIC DOCUMENTS
For a large manufacturer, their vendor base will surely range from large corporations with sophisticated application systems, to small "mom-and-pop shops" with only a modem and a PC. The vendor with a highly automated process may process the information directly into their applications and act upon it without intervention. The small business may do little more than print reports. In either case, and regardless of the scale, EDI can be successfully implemented. The final step in the process may be to transmit an acknowledgment transaction back to the vendor to close the loop.