Last month, my son junked his 92’ Geo Prizm. The beater had 250k+ miles on it, no heating or air conditioning, and broken door handles which resulted in manual window cranking in order to enter and exit the car. But it still ran, right? As a car, it was able still able to do what cars do — it still had basic functionality on the road. I begin with this example to illustrate that while there IS some truth to the old adage, “If it ain’t broke, don’t fix it,” the term “broken” can have a wide interpretation.
While my son could have kept driving his car to get from point A to point B, I’m relieved that he finally put it to rest because I worried for his safety (and that of his family) every time he got into that beater that technically wasn’t “broke.”
Unfortunately, this idea that a tool with basic functionality is good enough is everywhere in corporate IT. A solid example of this is with EDI integration software. So many businesses don’t realize how broken their solution really is because it can still perform its basic function of automated EDI document processing. Here are a few major limitations of many EDI tools that should give you pause about the whole ‘ain’t broke, so no need to fix’ mentality:
If a business partner does not support EDI, then a huge volume of documents are going to be unable to run through the EDI software interface. To get these documents into a usable format, you either need to contract with a VAN, use manual processes, or write custom scripts. In each case, it means that you have documents flowing through entirely different processes for EDI and non-EDI business partners, significantly complicating matters and adding unexpected costs.
You may well have underestimated the amount of bad data you receive. Even though automating the exchange of data between companies does greatly reduce errors, they do still occur. In fact, 3% or more of EDI transmissions can contain errors. Instead of being able to address this with automated exception handling, every instance of bad data has to be corrected manually. At $60 or more per error to correct, the costs quickly rack up.
Even when business partners do support EDI, onboarding is no picnic. EDI is not the same everywhere — there are different implementations of the standard, different software versions, different file transfer methods. Therefore, there are always multiple tests that have to be run to check file transfer, security, data validation, mapping rules, etc. to ensure a smooth computer-to-computer connection.
EDI software does not provide visibility and reporting for non-EDI trading partners. At best, you will have separate reporting processes for EDI and non-EDI reporting. And in addition, for your non-EDI partners, there is no way to know if an input error has been made. If such an error is discovered, there is then no way to know where the error came from — a manual typo, or bad data from the business partner.
Just because your EDI integration tool is able to automate EDI processing does not mean that it’s not broken. There has to come a certain point where you realize that there are enough ‘broken’ aspects to deserve a real fix. Like my son with his junker car.
I’m usually a man of few words, but I’m not done waxing eloquent on this subject. There’s a part two to this post that I hope you’ll check out, and it’s all about the benefits of fixing your EDI Integration software, even if it “ain’t technically broke.
Stay tuned for the next article in this series: “Why You Should Fix Your EDI Integration Even If It Ain’t Broke Part Two: Benefits”
To learn more about the challenges of EDI Integration, check out:
Everything Is Going Fine With EDI Mapping And Then Along Comes Walmart
Coroners Say Cause of Death Was Choosing The Wrong EDI Integration Solution
I Bought EDI Software, But I'm Still Up A Creek!