Retail EDI

Gap Analysis is an integral part of any EDI (Electronic Data Interchange) implementation, as well as any replacement to a company's existing software base. Analysts need to identify points where there is a difference between the existing solution and the replacement software.

When it comes to EDI, there are identification codes / qualifiers that are frequently either not present or do not match existing codes already in use with a particular document or perhaps data currently sent that a “Trading Partner” (EDI term for a supplier / customer / etc) is not making use of or perhaps data that a Trading Partner needs that's not currently being sent with your existing solution. Or perhaps it's the other way around and you're the one receiving the data. There's also the issue of which EDI transaction set to use to represent your document and also which EDI standard set to use. If you're located in Europe, you most likely will use the EDIFACT ( United Nations/Electronic Data Interchange For Administration, Commerce and Transport ) standards; in the United States, you'll most likely use X12 standards, but if you are located in either one and your trading partner is in another, you may need to support both standards. And then, there's which version of the standards you will use and if your industry has its own guidelines and/or government regulations, you'll want to investigate that as well. All these are valid questions and need to be addressed. {jcomments on}

EDI will bring you into a much closer relationship with your trading partners. In order to successfully implement an EDI process, you may need to modify your existing business processes internally. You might want to implement a payment processing process to reduce the lead time on payments from your customers... but should you also consider implementing an invoicing process to get your invoices to your customers more quickly as well? How about a process to receive Advance Shipment Notices from your suppliers? Would they also not like to receive your Orders electronically? And then, which trading partners do you want to implement with? Which are even capable of sending/receiving EDI? To get the most bang for your buck, you'll probably want to concentrate on your major trading partners first but, once that is in place, what about those trading partners you deal with only infrequently? Do you want to be the “800 lb gorilla” that forces your trading partners to deal with your EDI system your way (and the reputation that will give you) or can you be more accommodating to what your trading partners can accept or provide to you? These are all decisions that need to be made by your management team before you even begin the implementation. For an example of EDI Gap Analysis, we'll start working with a Health Care Services Request for Review document. This document is mandated in the US by HIPAA requirements (Health Care Portability and Accountability Act) using Transaction Set 278 under the X12 standards group using version 4010 of the standards (at least as of this writing). In this document there is an NM1 segment that is used to identify a provider or facility name or organization name and an identification code associated with the provider or facility. You, as a health care provider, have a number assigned by the Health Care Financing Administration that identifies your clinic. Since you only have one clinic using your Patient Administration Software, you do not store this information in your patient records. When you begin to use EDI to transmit information to insurance companies for preauthorization of medical treatments, you will need some method of including this information. This example is a place where your EDI translation software can help... because this information will never change, it can be “hard-coded” into the map that converts your records to EDI information that will be sent to the insurance company.

Again, the same document that you need to send to the insurance carrier also has a place to send the patient's policy number... your system stores that information as part of a POL record (a policy record). The EDI document requires that the POL number identified in your system be called a Member Identification Number. When the EDI file is created from your internal system's record, your EDI translation software can pull the policy number and place it in the proper “element” (roughly equal to a field in a flat file) in the EDI document with an “MI” qualifier.

Another example of outbound data... when I was representing Houston Lighting & Power Company at the Utility Industry Group meetings, the Public Utility Commission of Texas required that certain Terms & Conditions information be printed on every printed invoice. Because the EDI 810 invoice was a replacement for that paper document, our management said that we were required to include this same information on every EDI invoice. I had to convince the UIG membership that we needed to include a place to put this information into the standards, despite the fact that no one would ever read it. The EDI document was being processed automatically after all....

On the inbound side, suppose your bank wants to send payment information to you. Gap Analysis will tell you that if the bank sends a customer's bank account number and your system only keys on the social security number, something has to give. You, as the EDI Analyst, must negotiate between your Information Systems group and the bank for a way to reconcile the payments to your accounts receivable system... EDI will bring you into a much closer relationship with your trading partners.
________________________________________
Harold DeWayne is an EDI Analyst/Consultant with more than 15 years experience with raw data analysis, data testing/researching, producing and documenting new and existing procedures, supporting thousands of trading partners and multiple transaction sets. A presenter at the 1997 CIS Users Conference in Nashville, TN, he has worked in multiple industries and with multiple EDI translation tools. Familiar with Windows, Unix/Linux and mainframe environments, he has also written his own EDI tools when the need arose.