Skip to Content
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.

This is one of those things that no one likes to plan for, but the business depends on it.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Former Member
    Hi Kevin –
    This is a very interesting and realistic blog.
    Couple of points which caught my eye as i was reading the blog –
    “Upgrade, Change or Alter the Data model of your ERP” -> I am not so sure of upgrades as they generally work well for SAP and the different subscriptions / publications. Changes to data model would have significant bearing on EDI transactions.
    “20 years of Custom and Undocumented EDI integration code” => this is very true for Point to Point connections.
    You sum it up perfectly of having 1 publication per business object (the Hub-Spoke, Publication/Subscription, Web Services Whichever way the implementation needs to be). But that would entail some work at the subscribor’s end to pick and choose what they want (and in cases where the Semantics and the actual Values are different and misused [im sure you would have seen loads of those in your career]. These small “tweaks” and misuses cause major pain.

    My 2 cents -> do belive that in the time ahead, Integration needs of the organizations would need to come down from months of planning, designing and implementation time to a couple of weeks. Also, most of the EDI folks that I have worked with are “technically tuned” rather than using “common sense business logic” and these folks need to understand a business object completely.



Leave a Reply