I hear, “how can this matter?” Letting the borders of EDI fade overwhelms operational support as well as weakens EDI products and services.

Keeping clear what is and is not EDI is critical.

In the later portion of my career I spent a great deal of time at companies with EDI problems. Which is, of course, why I was hired. They needed someone with years of experience and knowledge. I love these opportunities. Many of these roles have been in EDI support. We used to lament about how much of what we did was not EDI. My purpose for this blog is helping companies keep EDI pure, simple and successful. Discerning what is EDI and what is not EDI without basic EDI knowledge and understanding is very confusing. The differences seem insignificant.

EDI is the methodology of translating between application data and EDI Standards so trading partners can integrate their systems. EDI and ERP applications should be lightly coupled. Meaning they sit next to each other communicating only through import and export files.

When a company allows their EDI system to take on ERP application functions soon everything becomes EDI. Much of the data that comes into any large company arrives via EDI. Because data came in through EDI does make EDI responsible for that data throughout the corporation. If we can keep EDI components unpolluted and lightly coupled; EDI is simple. Otherwise support becomes unmanageable.

Hello EDI Support; how can I help you?

…we got the wrong prices on your EDI.

I’m sorry this is EDI support?

…I told you we got them on EDI!

Ma’am, I have nothing to do with prices.

…well who does?

I don’t know? Your sales rep?

…Let me speak to your CEO!

CEO: Can you just help this woman,
so she stops calling me!
…Yes ma’am.

Accurately translating application content to standard structure and format is EDI. Any issue with the value of that content is not EDI. The simplest example is; sending a purchase order number is EDI. However, purchase order number, is not EDI.

There is additional confusion about EDI vs. data transport. I came up with this analogy after hearing plans to replace EDI with a web service where I was working. A web service is transport. EDI is structured content.

EDI and Transport are like water and hose.

  • The hose is the transport that moves the ‘water’.
  • The water is the content being ‘transported’.
  • One cannot replace water with a hose.
  • One cannot replace EDI with a web service.

They are not the same thing.

  • One cannot replace freight with a truck.
  • One cannot replace wine with a bottle.
  • One does not give a hose to the thirsty.

What is and is not EDI Responsibility?

  • Account number sent in wrong segment is EDI. Wrong Account number sent is not EDI.
  • Sending Invoices is EDI. Adding a 5 day hold before sending invoices, is not EDI.
  • Sending total amount due is EDI. Calculating the amount due is not EDI.
  • Sending a delivery date is EDI. When the product is to be delivered is not EDI.
  • Missing mandatory data is EDI if it is not mapped properly. Missing ERP data, is not EDI.
  • Holding data for a short time for operations is EDI. Being the ‘Process of Record’ is not EDI.
  • Transporting binary bar code images is EDI. Creating and printing bar codes is not EDI.
  • Integrating business data to your backend systems is EDI. Problems with that data is not EDI.
  • Sending an account number is EDI. Which account number is sent is not EDI.
  • Translation between EDI standards and applications is EDI. Paper processing is never EDI.
  • Integrating forecast data is EDI. Adjusting manufacturing schedules is not EDI.
  • Sending reference numbers is EDI. Correlating and reconciling them is not EDI.

EDI service providers cross these lines. They’ll do anything for a sale. They’ll build anything to get a client or get ahead of the completion. They become like printer-copier-scanner-fax machines which do all those things, badly. They will develop mini-ERP apps to enable those who are incapable of EDI. They’ll build ‘finishing’ modules invading the client’s applications to ‘complete’ EDI data. There is no end to what they will do. These enhancements eventually become impediments. I’ve had to unravel this clutter for clients.

Similarly, EDI software providers build extravagant capabilities to attract customers. Think of the leading EDI software today. It won’t be difficult to come up with examples of super cool enhancements that are not really useful or EDI. I cannot name them without inviting legal problems. But you know. 🙂

EDI is very simple. Convert this data to that data and send it to this partner. Without all the baggage it is quite possible to be fast, reliable and problem free. We must be vigilant and aggressive to keep EDI pure and simple. There will be no end to requests to cross the lines.

IEB3 will fulfill the original promise of EDI …

Simple standard based integration with all your trading partners.