Many companies will migrate from their SAP ECC system to the new SAP S/4HANA system by 2027 when SAP ECC will no longer be supported by SAP. The S/4HANA migration has implications on Electronic Data Interchange (EDI) with trading partners and the mapping of data formats. We explain how to optimize EDI when crossing the bridge to SAP S/4HANA.
EDI with SAP S/4HANA – Protect your Supply Chain Processes
In our previous blog, we discussed the pros and cons of a greenfield (start from scratch) or brownfield (migrate gradually from the existing SAP ECC) approach. In a second blog we spoke about the benefits of a true Hybrid Integration Platform (HIP) which connects and orchestrates the flow of data from SAP S/4HANA:
- Internally to other SAP solutions
- Internally to non-SAP systems
- Externally with Trading partners (customers and suppliers), Clouds, Business-to-Government (e.g. B2G E-Invoicing)
The reality in supply chain oriented industries is that SAP ECC typically uses EDI to connect to the larger external customers and suppliers. This intercompany efficiency has been fine-tuned for a long time – sometimes over decades – in these EDI partnerships, which for many supply chain companies has led to running hundreds of trading partner connections all over the place.
The data format standards (ANSI X12, EDIFACT, VDA etc.) vary depending on industry and geography. The message types used depend on the workflow and depth of integration between the trading partners. However the B2B/EDI integration needs to prevail 100% during and after the S/4HANA migration so that the supply chain processes are protected.
Keep the EDI part Simple when Migrating to SAP S/4HANA
A SAP S/4HANA migration project will most likely be a complex undertaking, therefore we suggest keeping the EDI aspects as simple as you can. Modularize the S/4HANA project wherever possible and do not reinvent the wheel just for the sake of it.
Consider a typical B2B/EDI partnership between a SAP customer and its Trading partner who uses their own ERP system as shown below:
Imagine the complexity to migrate to SAP S/4HANA and in parallel to replace the legacy EDI solution that you run today. A good approach would be to modernize and consolidate your EDI solution if this is needed before the SAP S/4HANA migration.
Keep EDI Trading Partner Connections Stable when Migrating to SAP S/4HANA
By looking at the data flow it is apparent that the established message standards (ANSI x12, EDIFACT…) together with the message types and the established protocols (AS2, OFTP2, VAN…) are a kind of demarcation line between the SAP customer and the trading partner. It is important that these established messages and the data conversion between them (as well as the protocols and the communication) remain as untouched as possible. Otherwise, one may need to deal with changing hundreds of trading partner connections in the middle of the S/4HANA migration project.
Ideally the B2B/EDI integration with conversion and communication are on a separate Hybrid Integration Platform (HIP) which decouples the flow of information. If the internal format is IDoc and stays the same, only the connection to the ERP system is changed from SAP ECC to S/4HANA.
Avoid Direct SAP EDI IDoc Mappings
Let’s have a closer look how the partner relevant data conversion can remain in place.
The most common conversion method is to map data between the internal IDoc format to the established message standard and message type, directly to the corresponding fields expected by the trading partner.
This is seemingly straightforward, however whilst the internal IDoc format remains the same, the structure of the data in the ERP system will be different. Consequently, as part of the migration project, all of the direct SAP EDI IDoc mappings will need to be revisited and re-tested.
Consider a rather simple case of the ERP-EDI connection just performing Order, Delivery Forecast, Despatch Advice and Invoice fulfilment with several hundreds of Trading partners. This can quickly result in over a thousand direct mappings.
Use a Canonical (Indirect) EDI IDoc Mapping Approach instead
Ease your mapping by double conversion with a ‘canonical master format’. SEEBURGER provides an extensive repository of more than 13,000 off-the-shelf trading partner profiles (including common and specialized maps together with communication profiles) across every industry. The maps reflect the typical data structures whilst the communication profiles provide the preferred communication methods. This approach can be used by all SEEBURGER customers either on-premises or in the Cloud.
For each ERP-system and business process, only one process map is created. On the partner side, one map per partner and process is provided by SEEBURGER. SEEBURGER treats these partner maps as ‘product with version’. Any changes to the partners are handled by a partner profile update under maintenance, whilst any changes to the backend simply requires a change to the process map as shown below:
With this approach, change and maintenance of the setup is much easier. Every time something on the ERP system or a business process changes, there is once again a potential change in the data structure. However, this time only the process maps need to be changed, i.e. neither the partner maps nor the communication method require changes. Therefore, the canonical (indirect) approach is very scalable on the trading partner side and consequently makes it easier to switch from ECC to S/4HANA. This is regardless of a greenfield or brownfield approach of the SAP S/4HANA migration and a good protection of your investment.
Move to API at Your Own Pace after Migrating to SAP S/4HANA
Our recommendation is to modernize and consolidate your EDI integration before the main S/4HANA migration project. By doing this, the overall project effort and risk will be much lower. From an operational perspective, the workflows and handling of EDI related content errors stays the same and thus the Line-of-Businesses processes will not need amending.
Internally, other SAP solutions or non-SAP systems as well as external 3rd party systems and services may use more traditional methods of connectivity. Examples would be EDI or simple file transfer, or emerging methods such as APIs. If you utilize a true Hybrid Integration Platform (HIP) with a solid B2B/EDI integration in place, you will protect your supply chain and you will have the flexibility to gradually add API integration and API management as the business needs it. Keep in mind though that workflows and handling of API related content errors takes place at different locations and thus the Line-of-Businesses processes may need to be amended.
Avoid the B2B/EDI Integration Pitfall when migrating to SAP S/4HANA
- Protect your Supply Chain Processes
- Keep the EDI simple: Stick to proven EDI standards for now
- If this is needed modernize and consolidate your EDI solution before the SAP S/4HANA migration
- Keep trading partner Connections stable
- Avoid direct SAP EDI IDoc Mappings
- Ease your SAP EDI IDoc Mappings by double conversion through SEEBURGER’s SEEXML
- Move to API at own pace and don’t over challenge your Line-of-Businesses
Consider engaging with an experienced HIP integration specialist like SEEBURGER to address the challenges that you will endure during your S/4HANA migration journey. With SEEBURGER you have very flexible deployment options on top: The SEEBURGER BIS can be used on-premises as an in-house operation, can be booked in a full service Cloud or as an iPaaS or in public cloud environments like the ones from Google, Azure, AWS etc.
Keep your deployment options open
Get in contact with us:
Please enter details about your project in the message section so we can direct your inquiry to the right consultant.
Written by: Frank StegmuellerFrank Stegmüller is one of the two corporate information security officers at SEEBURGER and has been with the company since 2008. He has over 25 years of experience in service, support and information security for Enterprise Application Integration, EDI, B2B, MFT, API, ITSM and digital transformation - both on in-house systems and from the cloud. He is involved in the ISO/IEC 27001, ISAE 3402 (SOC 1) Type 2 and TISAX certification for SEEBURGER Cloud Services and knows all about the intricacies of compliant data centre operations in international environments.