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 to “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. The Kroger Company “experimented with VAN, but quickly purchased the software package Chain-Tracks”. 8
Are there special tools required to implement EDI? Yes they are standards, software, hardware, and service providers. The need for definition of standards is absolute in assuring successful EDI. Without an agreed upon set of standards, EDI would be unworkable from the start. There is a set of public standards that define the requirements for a variety of EDI transaction types, so that any business concerns will be addressed within the guidelines of an internationally accepted set of standards.
Companies have been exchanging data electronically for over three decades. Before the existence of national and international standards, companies wishing to exchange information had to determine themselves acceptable formats for the interchange of data. This resulted in the emergence of “in fact” standards defined by those companies with the financial clout to impose the requirement for data interchange on their suppliers or customers. They essentially dictated the terms under which electronic trading would take place.
While this did provide some standards, real problems arose when equally stubborn partners collided with each other. “The result of such conflicts was that the smaller or newer players in the EDI market place were forced to observe a variety of conventions, depending on who the recipient of the information was to be. Confusion aside, an unavoidable consequence was increased cost for EDI implementation.”11
As the various standards collided in the market place, the result was the development of industry interest groups formed to try to reduce the chaos and confusion to manageable levels. The first was the Transportation Data Coordinating Committee, whose interest area was the standardization of the transactions required for trade and transportation.
Beginning in the late 1980’s, many of these standards bodies began to combine their separate standards under the agency of the American National Standards Institute. All major American EDI transaction groups are now covered under the general umbrella of the Accredited Standards Committee, (ASC), and are referred to as the X12 group of standards.
The ASC X12 Standards apply only for the United States. However, more and more companies are required to participate in the international exchange of electronic data. The increasingly global extent of many business enterprises requires that companies may have to at least be aware of the other major standards groups.
The United Nations has provided a forum to provide a common set of international standards, under the general authority of the United Nations. Thus the Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) group was formed.
EDI cannot be undertaken without software. “There is a broad range of options available, whether for low-cost first-time implementation or for the integration of EDI into a comprehensive portfolio of existing software.”7
“Design and development of computer software is an expensive and time-consuming process. The ready availability of commercial third-party packages or VAN’s will dictate against the internal development of in-house translation packages, since the annual cost of software licensing for third-party software will be less than the cost of developing and maintaining packages internally. The time required for internal software development will extend the valuable time it will take to deploy an EDI package.”4
There may be other reasons for developing a translation package internally. “If The Kroger Company owned or controlled its distribution like it controls its retail outlets; it could be cost effective to create a customized EDI package tailored specifically to the company’s distribution needs. The major drawback to such an approach is that performance of new transaction types will require additional development not only within the internal systems, but also within the EDI translation software.”7
With the continuing growth of EDI has also come the growth of a comprehensive library of EDI translation software packages with price tags that range from very inexpensive to significant. The extent of these packages ranges from modest PC-based translator packages to large-scale systems for proprietary minicomputers and mainframes, complete with firm communications features, and job and transmission scheduling capability. Basically a package can be found for just about every budget.
Third-party translation packages offer several advantages over in-house development, which are: comprehensive standards coverage, cost effectiveness, and reduced maintenance
Before the widespread availability and acceptance of PC’s and UNIX workstations, companies were pretty much bound by their existing restrictive hardware base. This dictated that EDI be implemented on whatever hardware was available and choice of software was severely limited by hardware options
A business seeking to start EDI for the first time probably already has a PC that can be used to run an EDI translation package and communications software. Even if such hardware is not available, or is outdated, it can be obtained at a relatively small cost. The principal requirements for installing most PC-based packages are not any more demanding than today’s word-processing or spreadsheet packages.
For software packages designed specifically for restrictive hardware, “the price-tag is likely to be higher than for a package designed for a UNIX workstation, because of the more limited market and the more specialized technical expertise required. Also this difference can be expected to grow as Reduced Instruction Set Computing (RISC) based open systems computers have gained popularity. Many software vendors are turning from strictly exclusive software to development of packages that will run under the UNIX operating system on a variety of RISC platforms with only minor modifications and differences.”5
RISC computers, because of their power, have put mainframe computing in a PC-sized package. They have gained popularity for client-server applications where a local PC will contain a software package that accesses remote databases.
Another feature of the RISC/UNIX systems is their “open architecture” design. “Open Architecture for the EDI user means that the data on the system can be much more easily shared with software on other platforms through standardized file access protocols.”5
These UNIX systems are available in a wide range of performance configurations. At the low end the platforms are comparable in power to the larger PC with the added advantage of supporting multiple users. At the high end they compare favorably to mainframe capability.
Early pioneers in EDI were faced with technically confusion and a costly choice when it came to communicating with their trading partners. So early use of EDI tended to be “in-house” rather than between companies, and was limited to those who could afford to develop and maintain extensive internal electronic networks.
Implementing EDI in a business does not need to be difficult, and the benefits can be tremendous. It is important to understand that EDI is a tool, and not a cure-all. EDI is an undertaking requiring a partnership; nothing can stop its potential. A good example would be between Kroger and it’s vendors and the exchanging of electronic invoicing, and automatic fund transfer for payment helps Kroger reduce the cycle of their account receivables. In this case, everybody goes home a winner.
For start-up EDI projects, limited objectives with visible benefits should be sought out. If Kroger had selected, for its first project, an ambitious plan to completely overhaul their entire retail distribution process, they may well be attempting too large a first step. Kroger selected a more realistic initial project this was computer assisted ordering (CAO).
CAO assists the retail store in ordering product when the purchased product is scanned at the checkstand. The CAO system keeps track of all daily product movement within a certain time frame (usually twenty-eight days). The CAO system produces a recommended order of products for store personal to review. They verify accuracy of on-hand product level, future promotions and adjust accordingly. The one draw back to CAO is the cashier. For instance, if the customer buys six different flavors of Kool-Aid, and the cashier scans all as cherry, CAO will recommend buying just the cherry flavor; when in fact cherry is not the only flavor needed.
An important aspect of implementation planning is involving all concerned parties at all steps of the project. Good communication is essential, so that newly installed EDI capabilities will change the way business is done, not disrupt it.
One of the most valuable ways of providing good communication and project management is to define an EDI coordinator’s position. This position should be filled by an individual with strong knowledge of both the business requirements being addressed, and the technical requirements of EDI.
A critical step in implementation planning is the testing process. Before users are actually committed to depending on their new EDI function, they must be comfortable that the process actually works reliably, all the time. This must be proven beyond doubt by carefully constructed testing and validation procedures. Since data is being transferred to another trading partner, it will be necessary to assure both internal and external users that correct information is being traded.
In any project, it is necessary to know what the true cost of implementation will be, and it is no different with EDI implementations. Some of the costs are obvious, such as hardware and software. The unknown cost factor is training your staff.
In conclusion, EDI requires a large number of choices. What are the business objectives? What tools should be used? How large is the intent? Hopefully, the one choice that will be easy to make will be the choice to take the first step with EDI.
It is important to reiterate that EDI is only a tool, and if that tool is started without carefully defining objectives, it will not live up to expectations. A key point to remember is when tools are applied to the wrong process; it can complicate a business and frustrate its users. With correctly defined objectives, and a carefully considered plan of execution, it is a tool of great power. EDI will add speed and improve accuracy in any business.
2 Bridge Software Home page 22 January 2000
*http://www.edi-bridge.com/edi-bridge/Education.html*
1 Compaq Corporation. Home page. 21 January 2000
*http://www.compaq.com/corporate/edi/*
3 National Institute of Standards and Technology, Home Page. 22 January 2000
* http://www.itl.nist.gov/div896/ipsg/eval_guide/tableofcontents3_1.html*
5 QRS Corporation. Home Page 22 January 2000
*http://www.ediconnection.com/contents.htm*
6 Simplix Corporation. Home Page 23 January 2000
* http://www.simplix.com/index.shtml*
4 TIE Corporate. Home page. 22 January 2000
*http://www.edi-tie.com/*
10 Bouden, Scott. Personal interview. 20 January 2000
9 Bramlett, Rusty. Personal interview. 21 January 2000
8 Coffey, Tracey. Personal interview. 20 January 2000
11 Holder, Thomas. Personal interview. 24 January 2000
13 Tegl, Eric. Personal interview. 26 January 2000
12 Winkler, Lisa. Personal interview. 25 January 2000
7 White, Bill. Personal interview. 20 January 2000
Business and Technology
Electronic Data Interchange
Andy Schoen
Communication and Technology, Comm 106
Professor Jack Miller
15 February 2000