Why does EDI take so long?

Welcome back! This is the second post in my three-part blog about the most frustrating questions of Electronic Data Interchange (EDI). To review, the questions I’m examining are:

Why is EDI so difficult?
Why does EDI take so long?
Why does EDI cost so much?

Today, let’s look at Question #2: “Why does EDI take so long?”

On a basic level, the answer to Question #2 is the same as the answer to Question #1, “Why is EDI so difficult?” There is no standard. As it is, companies are using different versions of EDI (i.e. x12, EDIFACT, OAGIS, xCBL, etc.). This slows everything down, and puts roadblocks in the way of successful EDI deployment.

EDI Roadblocks

The #1 roadblock of EDI is the map-per-partner-per-transaction methodology. Under current EDI conditions, every partner transaction mandates new EDI map development, followed closely by map testing. This is one of the costliest and most time-consuming on-boarding delays. If we had a standard version of EDI, we just might be able to process every trading partner with a few well-designed maps.

Roadblock #2 to EDI deployment is corporate bureaucracy. For one employer, I used a proof-of-concept project to demonstrate that I could deploy a partner in a day, even under old EDI conditions. At another, many of us could easily ready a partner a day for User Acceptance Testing. The key is that we were allowed to do all the tasks without corporate bureaucratic policies and delays.

Today, when I ready a partner for EDI on-boarding, I’m required to write a spec and hand it off to some developer. Then I have to wait for that developer to get around to the EDI project. Then I have to answer endless questions about why this segment? what is that XML tag? where does this field go? where does this loop start? I haven’t been allowed to do fast EDI partner deployment for decades.

With proper methods, documentation, and tools, any company can ready a partner for customer testing in a day or two rather than months. Of course, partner testing always depends on the partner’s speed, which we can’t control.

Roadblock #3 is extravagant software design. In the early days of EDI translation, software providers started including “Mapping Tools,” which allowed business units to deploy EDI without IT and developers. But this concept has been forgotten. It’s been a couple of decades since I saw simple design EDI software.

Today, EDI software companies seem to think that complex is better, and their mapping tools are not very user-friendly. It started out with simple lines linking source and target. Then they added to these ‘lines’ if then else logic and string manipulation and looping functionality. We ended up with C# or Java code inserted into the ‘lines’. This resulted in mapping requiring developers anyway. As a result, many companies have completely given up on mapping tools, and just write .xslt code. They enter into Software Development Life Cycle (SDLC) projects for partner on-boarding, when what they really need are simpler mapping tools.

Outsourcing is the current trend. We see large companies outsourcing their entire EDI departments, hoping these service offerings can speed up their deployments. The problem is, the outsourcing companies are using the same EDI tools and methodologies, so they’re just as slow at EDI on-boarding as any other company. Outsourcing itself is not a cause of slow deployments, but it doesn’t provide the EDI solution that companies are looking for.

The final roadblock – Roadblock #4 – is a lack of EDI knowledge. Many companies don’t have the expertise at EDI that they really need to successfully deploy it. This leads to several problems: