Logistics Management 

Perhaps the biggest mistake that could be made in designing your EDI information processing would be to attempt to feed the EDI data directly into your current information systems and to generate EDI data directly from your current information systems. As mentioned above, many different versions exist for each EDI transaction set and many options exist within the standards for conveying the same information. You probably won't have enough clout to dictate to each of your trading partners the exact format for each transaction set. You probably won't even be able to standardize on what character is used to separate the elements within an EDI segment and what character is used to signify the end of the segment.

It is far better to map your incoming EDI data into messages that you specify for your internal systems, and to translate the

partner-supplied information into standards that your systems will understand. For example, most freight firms have an additional charge for pickups or deliveries on Saturdays or holidays, but there is no standard code to signify this charge. One firm may use SAT, another firm 665, and yet another might use WEEKEND. If you translate your partner's code for this service into an internal code that you recognize as this service regardless of trading partner, you'll be in a position to answer the question How much did we spend last month on Saturday service with our freight suppliers?

Several off-the-shelf software packages already exist for doing this chore and are well worth the price. Many of these packages run on personal computers, so, with minimal expense, you can have the additional security of isolating your communications with outsiders to a different platform from the ones on which you run your internal applications. Computer hackers won't be able to get directly into your accounts payable system by going through the dial-up lines you've set up to communicate with your trading partners, and your EDP auditors will thank you for that.

In addition, separating the EDI data from your applications via internal message formats also allows you to change your applications relatively easily. If you were exchanging EDI data with fifty customers all using slightly different EDI formats, but you mapped them all into a common message format for your order entry system, you could change to a completely different order entry system by modifying the new system to accept the single message format you generate from the incoming EDI. Similarly, if one of your customers decided to upgrade to a new release level of their EDI transaction sets to you, you'd only need to change the mapping of their data to your internal format; you'd never need to touch your business application program.

If the business application system that will be driven by EDI data is a new application or an extension of an existing application, give careful thought to what new data might be available and how the data might best be presented to the users of that information. For example, an electronics firm used to enter all freight invoices directly into their accounts payable system running on a minicomputer. This served the purpose of adequately paying the bills on time and allocating the freight costs across cost centers.

They could have designed their EDI process to receive and pay invoices to directly mimic the old paper process, but the Logistics department realized that much additional data were available to them by receiving EDI invoices. Data would now be available to them about the exact freight services that were performed, pickup and delivery performance on each shipment, and volume of shipments along each freight lane. This additional data would put them in a better position to choose freight suppliers for each shipment that they make, but storing and processing these data on the Accounts Payable minicomputer would overburden that system.

They decided on a distributed processing approach. They designed a system to store and process this additional information on personal computers. By using fourth-generation languages graphical user interfaces, they were quickly able to store and process the new information effectively for the Eogistics department, and to feed the existing accounts payable system automatically. They are now able to track the quality of each of their freight suppliers as well as to resolve problems on the freight invoices quickly, and they're even able to see the freight bills on their workstation screens in formats that totally mimic the old paper invoices they used to receive from these partners. Future extensions to the system can automate the process of choosing a vendor for each shipment based on several quality and price criteria, notify the vendor via EDI of the shipment awaiting pickup, and track the shipment to its destination via EDI, as well as pay the invoice for the shipment.

Electronic Data Interchange is critical in establishing partnerships with suppliers and customers for time-based competition. The actual implementation of EDI must begin slowly and carefully, but can yield benefits to all of the trading partners. Care should be taken in the design of your information systems to make the best strategic use of the data available to you with EDI, and you must think beyond the traditional bounds of your existing infor­mation systems to leverage that information.

Lean Six Sigma Training   Thinking Out of the Box   
Balanced Scorecards  Strategic Tactical Planning  
Supply Chain Inventory Management  Total Quality Management Principles
Lean Manufacturing Implementation  Lean Manufacturing Principles