Introduction to EDI - A Primer
6. IMPLEMENTING EDI
This review of EDI has stressed the numerous advantages of employing electronic data interchange in a wide range of business activities. This section will provide an overview of the major requirements for EDI implementation, with some observations about some land mines that can be avoided along the way.
Implementing EDI in a business need not be difficult, and the benefits can be substantial. To assure success there are several key areas where some understanding and advanced planning is required. Recognizing some of the potential pitfalls and avoiding them, especially with an initial implementation, will go a long way toward assuring success.
It is important from the outset to understand that EDI is a tool. It is not a panacea. As a company's management team begins to plan it's EDI strategy a careful assessment of the problems the company wishes to address is critical. Such a review can help to insure that applying an EDI solution will actually contribute to solving problems and rather symptoms.
Without a strategic analysis it is very easy to solve the wrong problem. If FastPart successfully implements a project that reduces retail order processing time from days to hours, but has failed to understand that reducing delivery time from weeks to days is the real problem, the benefits of the improvement will go un-noticed. Or, worse yet, the effort put into an EDI implementation will be written off as a bad investment, and further implementations may be curtailed or eliminated.
SEEK OBJECTIVES OF MUTUAL BENEFIT
EDI is first and foremost an enterprise requiring partnership. Nothing is guaranteed to quell enthusiasm for an EDI project more quickly than the perception that benefits and costs are not shared equally within the partnership. Setting forth objectives that are advantageous to only one partner is a sure-fire method of guaranteeing failure.
Returning to the FastPart company, suppose that a major customer has required that they be invoiced electronically. The advantage to the customer is a major reduction in the overhead in processing their invoices. The problem with this approach is that FastPart will obtain no benefit from the exchange. While it will help the customer, it will not guarantee that FastPart gets paid any sooner. If the customer is an important one, FastPart may have little choice but to implement the transaction.
This is not an ideal method for encouraging and developing a true business partnership. A more realistic approach to this EDI partnership would be to offer, in exchange for electronic invoicing, automatic fund transfer for payment, thereby helping the FastPart to reduce the cycle of their accounts receivable. Everybody goes home a winner.
Everyone has had contact at one time or another with a sales representative who was pitching a product that would solve every problem put to it, and insure proper weather on the weekend for the company golf outing. So even if the product did everything it was designed to, if it rained on the golf outing, the product would be perceived as a failure.
For initial EDI projects, limited objectives with perceivable benefits should be sought out. If FastPart selects, 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. A more realistic initial project would be to automate customer order processes, along with providing order confirmations and delivery notifications.
An even more realistic objective would be to implement a project that can be undertaken on a pilot basis, to clearly demonstrate benefits, with very limited risk. A properly selected and limited pilot project will be easier to implement with minimal impact. The success of the pilot will surely be an asset in selling expansion of the project to company-wide application.
Of the many entries on "the most frustrating experience" list, one of them has surely got to be completing a project and not knowing whether it was a success. A key factor in insuring success is defining the objectives in terms that can be measured.
If management proposes to install an EDI system, but fails to adequately identify why it is doing so, and what specific benefits should be achieved, the targeted user community will quickly define its own objectives, with little guarantee that any can actually be met.
If, on the other hand, the objective of a project is stated as reducing a specific expense, or specific transaction cycle time by some amount, when the project is complete, the numbers will bear out the success.
Much of the work of planning an implementation can be eased if objectives have been carefully defined. Implementing a company-wide comprehensive EDI solution cannot be integrated into the existing framework of a company's business in one step. It must be applied carefully, step by step.
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. In most cases, 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 cost exposures are obvious, such as hardware and software. This list is certainly not definitive, but may provide some direction in anticipating costs that are not so obvious.
ENCOURAGE WIDE-SPREAD PARTICIPATION
EDI is a process that can touch many parts of a business. It is crucial to get involvement of all affected parties within the business. Also it is equally important to develop a good working relationship with the individuals and groups that will be affected within the new trading partner's organization.
It is important to remember that EDI implementation will be eliminating paper documents that have probably been the single most visible focus of many jobs. Removing that paper will generate a considerable degree of insecurity. It must be replaced with the confidence that "the system" has the paper, all the time, every time. Extended involvement of the user community in requirements definition, pilot projects, testing, and parallel testing is vital, and should be a high priority consideration for the EDI coordinator.
Most companies understand that training is an integral part implementing any new process or procedure in their business. EDI is no exception. Training will be required in the user community because job functions will change, sometimes dramatically. Training may be required in several different areas: