The Impact SAP Upgrades Have on EDI and B2B Operations

Upgrades to SAP have the potential to break all or most of your current point-to-point EDI maps. If you have not already determined the impact, you may want to do it ASAP. No one likes surprises, unexpected project delays, costs and embarrassment.

Why would an SAP upgrade break your point-to-point EDI and B2B maps and communications with your trading partners? SAP upgrades often include new functions and features that both produce and consume new kinds of business data. The data in your IDocs and EDI messages may also need to be edited to accommodate these changes. In addition, the order and the location of data in your EDI/B2B files might change and the location of the data in your software application might have changed. Any of these changes will require changes to your EDI/B2B processes and maps.

There are 2 important terms EDI/B2B gurus often use when describing an EDI/B2B message:

1. Syntax
2. Semantics

Here are their definitions:
Syntax is used to refer directly to the rules and principles that govern the structure of a sentence or file (or the structure of an EDI message)
Semantics is the study of meaning in communication (in EDI - does the address mean Bill to, or Ship to?)

If there are any changes to the IDoc, EDI message, SAP application, business process, syntax or the semantics of the IDoc or EDI message data, then you will have changes to make to your EDI/B2B files and processes in addition to the upgrade of SAP. These changes may impact not only the EDI-to-SAP, SAP-to-EDI integration maps, but also the EDI-to-Trading Partner and Trading Partner-to-EDI messages. Let discuss a scenario:

1. Let's say you have 1,000 EDI/B2B trading partners exchanging at least 4 different EDI messages each (total 4,000 EDI/B2B messages). Some percentage will ask you to exchange a customized EDI message with them. This means they want unique data to be exchanged between your 2 companies that is different from other trading partners. This often means you must not only create, document and implement a new and unique EDI message for them, but you must also customize an IDoc just for them.
2. Let' say you have 500 custom EDI messages out of the 4,000 that are in production.
3. In this scenario you will be using a minimum of 504 unique EDI messages and 504 unique IDocs. That is 1008 mappings....a represents a significant effort in time and costs.
4. You spend several years customizing, testing and implementing all of these EDI messages and their associated IDocs, and then the business announces they are going to upgrade SAP to take advantage of new features, functionality and technologies.
5. You immediately research and analyze the impact the new upgrade to SAP will have on your IDocs and custom EDI messages and realize you will need to redo most of them....YIKES!
6. Someone needs to add this additional project to the SAP Upgrade project plan and budget.

There are ways to make upgrades to SAP less painful to both the business unit and the EDI/B2B department. It takes some foresight and planning, but there is an IT strategy that uses a "canonical data model" approach. The definition of a canonical data model is - a design pattern used to communicate between different data formats. Crossgate, a managed EDI/B2B service provider uses this strategy for SAP users. The use of an intermediary canonical data model in an EDI/B2B/IDoc scenario is as follows:

• All EDI/B2B messages are mapped to the canonical data model, NOT directly into IDocs or other SAP formats as you would in a point-to-point mapping scenerio.
• All IDocs are mapped into the canonical data model, NOT directly into EDI/B2B messages like you would in a point-to-point mapping scenario.

This may seem like extra work and an extra IT systems layer, which it is, but it reduces the work involved when changes are required to your SAP system in the future. Let me explain:

• You can set-up one Purchase Order IDoc between SAP and the Purchase Order in the canonical data model, which in turn can accommodate all of the customization required by suppliers, rather than going through all the effort of supporting hundreds of different IDocs
• Hundreds of customized Purchase Orders sent in via EDI messages can all interface with the one giant Purchase Order in the canonical data model as well.

In the above scenario - in the future when upgrades to SAP are required, only the one Purchase Order IDoc connected to the "canonical data model" needs updated, not hundreds of IDocs that a traditional point-to-point mapping environment would require.
In summary, upgrades to SAP can break many point-to-point IDoc to EDI processes. Companies must expect significant upgrades about every 5-7 years, so why not create an IT architecture that can make these upgrades much simpler and less painful? This is the strategy used by most EAI (enterprise application integration) solutions and large EDI/B2B managed services companies that must utilize these strategies to achieve economies of scale and reusability of processes.

If you would like to discuss these topics in more detail please contact me.