I realize the title of this article may be a bit dramatic, but it is true. I have seen companies that desparately needed to change their business model, upgrade their SAP ERP systems and implement new business processes, suddenly halt this effort due to the unexpected and unanticipated requirements to replace all of their existing EDI and B2B integrations.
Think of it this way, have you ever needed to move the entertainment system in your house? The mass of dust covered cords, wires and cables hidden behind it can be daunting. You may hesitate to even move the entertainment system out of fear that something will become disconnected and not work. It is the same process multiplied by 100,000 with your trading partners and their integration scripts.
Let’s say you have 1,000 suppliers. If you are going to upgrade, change or alter the data model of your ERP, it is highly likely you are going to quickly start breaking mission critical EDI data exchanges between you and your suppliers. This tends to enrage just about everyone in your company and at your suppliers.
OK, there is a challenge here, but there is also a very desparate need to upgrade or change the ERP so you can take advantage of all kinds of new business processes, technologies and application features. The problem is the ERP folks and the business managers didn’t talk to the EDI department when they purchased the new upgrade. Now the ERP is suppose to be functioning and in production in 5 months, but the EDI department is already buried under just routine operations and support.
At this point things get really crazy. The business managers start blaming the EDI department for obstructing progress, innovation and business transformation. The EDI team just looks up from their terminals and says, “huh?”
Now the CIO is in hot water. She calls the EDI Manager to her office and asks, “How come you are stopping the company from meeting their quarterly and yearly goals?” The EDI Manager says, “Not our fault. There is 20 years worth of custom and undocumented integration code that an upgrade to the ERP will break. Has nothing to do with us. The ERP folks are breaking what already works.”
The story gets darker. The CIO walks the green mile to the CEO’s office and says there is 20 years worth of EDI integration code and scripts that need to be replaced, and it will take 2 years worth of unbudgeted development to re-integrate and test all of these EDI integrations. The CEO steps around his desk and quietly shuts the door of his office.
When the CEO’s door reopens 3 hours later, the CIO has been tasked with re-introducing manual spreadsheets, phone calls, emails and faxes to the suppliers. This step 15 years back in time is needed to keep the ERP upgrade on schedule without EDI interference.
What the 3 hour meeting in the CEO’s office did not fully acknowledge or plan for is how much the supply chain, logistics department and customers would be effected by this return to manual systems. The downward spiral begins.
I have seen this process unveiled before my very own eyes. How can it be avoided? There needs to be a plan in advance to create a layer of separation between your ERP and your EDI translators and trading partners. This layer is a change management insurance policy. Custom EDI integration scripts need to be replaced with one integration per business process. This single integration needs to support all varieties of Purchase Orders, Invoices and other EDI messages. You cannot have a new integration to your ERP for every trading partner’s custom data file. The EDI integration needs to be a standardized process that connects to a canonical data model associated with the EDI translator. This is usually only possible if you are using a manage service from a large EDI/B2B hub. The alternative, is the situation documented above.
No related posts.