Customers often complain about the time and money it takes to integrate SAP EDI processes with partners. And they’re not wrong. Two things stand in the way of SAP EDI efficiency: using IDOC processes incorrectly and buying into the misconception that “this is the way it’s done.”
Here’s how SAP EDI works
Typical SAP EDI integration process
EDI is managed in SAP through IDOC technology, SAP’s oldest technology for application integration. An IDOC is a standard format developed to be sent to an external system. We can see how this is used for EDI by following the most common SAP transaction, the Logistics Execution delivery. Here’s how it works:
- First, a delivery is processed as normal. When complete, it generates an IDOC.
- The IDOC then collects all data described in the document and populates it into segments and field values.
- Next, the populated IDOC is sent to an external EDI subsystem. This could be an actual EDI application running in a customer’s network or a managed partner service.
- Using a mapping program, the IDOC is again transformed within the EDI subsytem to the destination partner’s required format. Locally maintained database tables might be needed to generate the final document in a standard EDI format.
- Finally, the document is sent to the partner.
Transformations require time to develop, maintain
As you can see, the final partner document requires multiple transformations. Each transformation requires time and effort to develop and maintain. Why is this a problem? IDOC technology was developed to generate a standardized document to send to an external application or partner. SAP provides some sample messages and document types to start the process. Companies have incorrectly used these samples to generate all types of partner documents, which require transformation layered on top of transformation. The end result is an unmanageable tangle that increases in complexity with the addition of each new EDI partner and standards. This has gotten even worse with the introduction of middleware like Biztalk and SAP PI because many companies have actually increased the number of transformations they perform instead of relying on a central transformation.
Setting up trading relationships
IDOC processing steps
In the above process, for instance, imagine setting up a trading relationship with a new partner. The change would require the following steps:
- First, the IDOC is most likely extended to add the new value the partner requires. (Remember that in the above example, because we have co-opted the DESADV message type and forced it to generate a completely different standard, every change will likely require an IDOC change and message type change.)
- The message program is then modified with a user exit to populate the new value into the IDOC. This requires a developer.
- Next, the EDI subsystem mapping is modified to transfer the value to the correct mapping field. Depending on the system, this requires a developer.
- Lastly, testing. Since we modified a message type and an IDOC used by another partner, we need to make sure that the user exits that house our business rules and customer-specific rules still work. This is ugly.
Improving your SAP EDI system
Above all, our goal with SAP EDI integration is to create a process that can be easily maintained. In most cases, this means reducing the number of transformations and centralizing control of the process. The source of the truth always lies in the originating system. In our example, it is SAP. To sum up, here are two key steps you can take to improve efficiency. First, perform transformations and data collection only in SAP. The goal is to eliminate ANY database of values outside of this system. Secondly, IDOC’s should not be transformed from one message type format only to be re-transformed into another format at a later step. This is a waste of development time and increases the need for long-term maintenance. Since the formats are typically incompatible, the development and testing involved increases exponentially depending on the differences.
SAP EDI integration – advanced
Slow migration to sustainable model pays off
In our recommended model above, based on the trading partner, an appropriate message type that matches the trading partner’s expected format is chosen in Step 2. The end result is to perform a straight 1:1 mapping in Step 3, with no business rule or customer-specific logic in any secondary system. This simplifies support and maintenance, and reduces overall costs.
Unfortunately, fixing the problem is not simple since companies have invested heavily in the “standard” model. But it’s always good to begin moving to a less inexpensive process. This can be done, for instance, by slowly migrating to a standard, sustainable model so that adding trading partners becomes a process that does not require development support and can take days instead of months to implement.
Contact us today to learn how to develop a better process to manage your SAP EDI infrastructure.
Phillip Avelar is a Managing partner at Advanced Solutions, based in Chicago. He works with SAP enterprises to optimize their supply chains, increase productivity and challenges the status quo. He shares his passion for solving customers problems in his blog posts, industry articles and conference talks.