Welcome to my blog! Today, I’m presenting the first in a three-part article about Electronic Data Interchange (EDI). In my next three posts, I’ll be answering three crucial questions about EDI that have bedeviled technology experts for decades:
- Why is EDI so difficult?
- Why does EDI take so long?
- Why does EDI cost so much?
Until we answer these three questions, we will continue to commit the same blunders that make EDI so difficult and costly. Answering these questions helps us to identify the EDI problems that we need to solve.
Let’s look at Question #1: “Why is EDI so difficult?”
How many executives have thought about this very question? Every budget cycle, they review their EDI line item requirements. They have an ever-increasing number of EDI employees trying to make a dent in their EDI backlog, which sometimes sits at over 30 years. Often, their budget includes a request for a new EDI head count.
The executive shakes their head, bewildered and frustrated. Why is it so hard to send a purchase order? they wonder. It’s not that complicated. Why is my company spending millions of dollars to send a few simple business transactions?
And then they sign for the increase in budget and head count, because they have no choice. Business at this level requires EDI. Unfortunately, that’s usually where their questions stop.
A Look Back at EDI
When I started my career, back in the late 1980’s, EDI was a brand new technology. Our main problem was convincing “first adopters” that they needed EDI, that it would be a benefit to their company.
We used to describe the pre-EDI condition as “Point-to-Point,” meaning that every company has a different internal transaction format. Before EDI, it would require thousands of conversion programs to integrate data transaction systems between different companies, since each company had to convert data between their own format and the individual formats used by each of their partners, vendors, and customers.
In the early days, EDI promised simple, one-time integration between a standard format and your company’s ERP applications. Since every company uses the same standard, i.e. for a Purchase Order transaction, you only needed to integrate that standard to your ERP, and everyone would be good to go. You could easily share data transactions with your partners, vendors, and customers, since they would be using the same standard format. It was supposed to be a simple, fast, and low-cost solution.
So, back to our question: “Why is EDI so difficult?” We have no standard.
Now, as I write this, I can hear your minds saying, “What do you mean we have no standard? We have plenty of standards for EDI!”
Yes, and that’s exactly the problem. We have too many standards!
We have x12 and EDIFACT, OAGIS and xCBL and many more xml standards. When we must support all these standards for various partners, we end up with a map-per-partner-per-transaction. Today, we have thousands of maps, instead of thousands of format conversion programs. We simply traded Point-to-Point systems. We had too many file formats, now we have too many EDI standards.
A “standard” implies that you have one single way of doing things, one format or protocol that every company follows. If you have 23 “standards” for EDI, and different companies are following different EDI formats or protocols, then you don’t have a standard.
Not only that, EDI standards constantly change. Every year, and sometimes twice a year, we get a new version of EDI. If a company migrates to a newer version, they must re-map and re-test every transaction they make with every partner. This is why most companies are still using either EDIFACT 97B or X12 4010 – EDI standards that are 20 years old. It would take years and cost them millions of dollars to switch to another standard.
Imagine if we had one clear worldwide standard for EDI? How much simpler EDI could be! Are the standards bodies working on this? It seems to me they think more is better.
Now that I’ve identified the first and most pressing problem with EDI, let’s solve it. We don’t need anyone’s permission to start.
