Introduction to EDI - A Primer
5. THE TOOLS OF EDI
This section will review broadly the various types of "tools" required to implement EDI in a business. Since the range of software, hardware and service providers is extensive, a discussion of these areas can only provide the reader with an appreciation of the major standards, hardware, software, and communication options that may be open to them, or from which choices may be made.
The need for definition of and adherence to standards is paramount in assuring successful EDI. Without an agreed upon set of standards, EDI would be unworkable from the start. There is a comprehensive set of public standards that define the syntactical requirements for a wide variety of EDI transaction types, so that virtually any business need can 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 were left pretty much to themselves to determine mutually acceptable formats for the interchange of data. This resulted in the emergence of de facto 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 semblance of standards, real problems arose when equally stubborn partners with proprietary standards collided with each other. The consequence of such contention, 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 inevitable consequence was increased cost for EDI implementation.
As the various proprietary standards collided in the market place, the gradual 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. Other groups have addressed specific needs in such areas as the food services industry, the banking industry, and the automotive industry.
Beginning in the late 1980's, many of these standards bodies began to consolidate their separate standards under the auspices 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. These include, to name a few, SCC/JTC EDI in Canada, SITPRO in the United Kingdom, DIN in Germany.
The United Nations has provided a forum to provide a single set common set of international standards, under the general authority of the United Nations EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) group. ASC X12 has formal input into this process.
Obviously, EDI cannot be undertaken without software, or a service that will provide for the use of the software. For EDI users, 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.
This review will be directed largely towards the options available for EDI translation software. It will provide a broad overview of the software options a business might wish to consider as they introduce new or enhance existing EDI capabilities. A discussion of options or requirements for software to collect data internally is outside the scope of this study.
Definition, design and development of computer software is an expensive and time-consuming process. The ready availability of commercial third-party packages will generally dictate against the internal development of in-house translation packages, since the annual cost of software licensing for third-party software will be substantially less than the cost of developing and maintaining packages internally. In addition, the time required for internal software development will extend appreciably the time it will take to deploy an EDI package.
This does not say that internal development is out of the question. There may be compelling reasons for developing a translation package internally. If the FastPart company owned or controlled its distribution and 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 implementation of new transaction types will require additional development not only within the internal systems, but within the EDI translation software.
If FastPart wished to introduce EDI into their supplier relationships but found that a large number of their vendors had no EDI capability, an effective way for FastPart to gain a high level of subscription might be to provide a low-cost customized translation package to those customers which contained only those transaction sets that FastPart wished to utilize. If FastPart wished to add new transaction sets, these could be provided to partners as upgrades, or as low-cost enhancements, on a per-transaction basis.
This option can also prove to be cost-effective for a company that is already fully committed to trading partnerships with its major suppliers, but is having difficulty achieving complete coverage with the smaller suppliers. The cost to FastPart might be justifiable if it allowed them to convert a small hand-full of remaining traditional suppliers to electronic relationships. As FastPart becomes more and more committed to exclusively electronic partnerships, the cost of retaining tradition suppliers will increase, and it might at that point be cost-effective to offer such a packaged option to its traditional suppliers as an encouragement to covert.
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 scope of these packages ranges from modest PC-based translator packages to large-scale systems for proprietary minicomputers and mainframes, complete with embedded 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:
If FastPart is purchasing software to upgrade their information management systems, management should certainly include EDI capability as an important point in their evaluation criteria. They should look for packages that already contain an EDI translation module, or at minimum, provided for preparing output files for a translation module from a third party. Any EDI capability should meet not only current but planned needs. If the FastPart MIS department has to go back to the software vendor with a costly enhancement request every time a new EDI process is added, they will find their expansion requirements needlessly constrained both by cost and by the developer's schedule.
Before the widespread availability and acceptance of PC's and UNIX workstations, companies were pretty much bound by their existing proprietary hardware base. This dictated that EDI be implemented on whatever hardware was available and choice of software was severely limited by hardware options. If the company operated on a hardware platform for which many software packages could be obtained, there was little problem in finding an acceptable EDI solution.
However, if the hardware was old or manufactured by a company with small market presence, it could very well mean that no EDI software could be found that would run on the system. The alternatives in this situation were fairly well limited to in-house development for the existing platform, or acquisition of different hardware, with all the attendant problems of inter-operability between two different proprietary systems. Value-Added Networks can also be of assistance with this problem, since some offer all the features of EDI software 'on the network' by using their own computers to provide the EDI software. In this case it is only necessary to gain access to the VAN via standard communications software and allow the VAN to do all the EDI functions and translation.
Fortunately the options are considerably more flexible today. EDI options can be found for the complete spectrum of hardware, from small PC's to large mainframes. Because of the relatively low cost of implementing PC or workstation solutions, hardware options no longer constrain selection of software. In fact, it is difficult to discuss hardware options without considering software, as the reader will see from the following discussion.
The business seeking to implementing EDI for the first time probably already has a PC that can be used to run an EDI translation package and communications software. In addition, even if such hardware is either 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 companies that remain committed to a specific hardware platform, how limited their EDI choices are will be determined by the specific hardware. If the hardware manufacturer has a fairly large market presence, the chances are good that a package can be found to run on that hardware. But if the hardware platform is one for which there is little commercial software available, the selection is likely to be very limited.
For software packages designed specifically for proprietary hardware, the price-tag is likely to be significantly higher than for an equivalent package designed for a UNIX workstation, because of the more limited market and the more specialized technical expertise required. Also this disparity can be expected to grow, because as RISC-based open systems computers have gained popularity, many software vendors are turning from strictly proprietary 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.
RISC (Reduced Instruction Set Computing) 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.
These UNIX systems are available in a wide range of configurations that span the performance spectrum. At the low end the platforms are comparable in power to the larger PC's, with the added advantage of supporting multiple users. At the high end they compare favorably to mainframe capability.
This has helped companies that previously had difficulty finding third party packages. With widely available UNIX based packages, EDI solutions can be easily integrated into their existing hardware environment.
The last major component of the EDI tool set is communication capability. This aspect of EDI has evolved from one of the most unmanageable and complex to one of the easiest to cope with. Where the EDI trading partner is faced with too many choices in the areas of software and hardware, the evolution of the "Value-Added Network" or VAN service industry has greatly simplified the range of reasonable choices for telecommunications options and other Electronic Commerce capabilities.
Early pioneers in EDI were faced with technically complicated and costly choices when it came to communicating their trading partners. So early use of EDI tended to be within rather than between companies, and was limited to those who could afford to develop and maintain extensive internal electronic networks.
Single-user point-to-point networking is a workable option for an EDI user, provided that they are not expecting to deal with more than a few trading partners. Single-user connections can be as simple as a PC with a modem, or can rely on dedicated phone lines. Many companies, in their first trading partnership, chose this option because it is, for limited use, the quite cost-effective.
This means of exchanging electronic data quickly looses its charm as more trading partnerships are developed. Suppose that FastPart has no electronic trading partners. One of their key suppliers requests that they begin placing purchase orders electronically and provided FastPart with specialized PC software and modem access to transmit orders. While FastPart may not particularly care for this arrangement, it may be a pre-requisite to maintaining a business relationship with the supplier.
Now imagine FastPart a year later with a dozen different packages of software: a dozen different ways to enter orders, and a dozen different modem transmission schedules to observe. Very quickly this scenario becomes a major management issue.
Let's examine a slightly different scenario where FastPart is the company promoting EDI. In this situation, assume that FastPart already has a fairly extensive private network in place for exchanging data with their retail outlets. If they wish to encourage suppliers to link electronically with them, they understand that they must provide some sort of assistance to many of their suppliers.
FastPart chooses to integrate their suppliers into their private network. While this may seem at first glance to be a sound option, FastPart will probably be in for a rude awakening as they discover some of the draw-backs of maintaining a service network for their suppliers.
Fortunately, FastPart has a viable and cost-effective alternative to either of the two examples described above. The solution lies in the Value-Added Network, which grew directly out of the growth of private networks. Some companies that developed large internal networks saw the potential market opportunity in providing such services to external customers. This opportunity developed into a unique service industry - the "Value-Added Network" service provider, or VAN.
What would have become a serious overhead burden to the FastPart company as it extended its private network becomes an asset to the user of the VAN.
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.