Migration zu SAP S/4HANA bei laufendem B2B/EDI-Betrieb

Viele Unternehmen werden bis 2027 von ihrem SAP ECC-System auf das neue SAP S/4HANA-System migrieren, denn ab dann wird SAP ECC nicht mehr von SAP unterstützt. Die S/4HANA-Migration hat Auswirkungen auf den elektronischen Datenaustausch (EDI) mit Handelspartnern und die damit verbundene Konvertierung von Datenformaten. Erfahren Sie, wie Sie EDI optimieren können, während Sie die Brücke zu SAP S/4HANA überqueren.

EDI mit SAP S/4HANA – Schützen Sie Ihre Lieferkette

In einem früheren Beitrag haben wir die Vor- und Nachteile eines Greenfield- (von Grund auf neu beginnen) oder Brownfield-Ansatzes (schrittweise Migration vom bestehenden SAP ECC) beleuchtet. In einem weiteren Blog berichteten wir über die Vorteile einer echten Hybrid-Integrationsplattform (HIP), die den Datenfluss von und nach SAP S/4HANA ermöglicht und orchestriert:

• intern zu anderen SAP-Systemen,
• intern zu Nicht-SAP-Systemen,
• extern mit Handelspartnern (Kunden und Lieferanten), Clouds und Business-to-Government (z. B. B2G E-Invoicing).

Die Lieferketten in vielen Branchen basieren für die Herstellung von Verbindungen zu größeren externen Kunden und Lieferanten typischerweise auf EDI. An der Effizienz der zwischenbetrieblichen Anbindungen wurde im Rahmen dieser EDI-Partnerschaften lange Zeit – manchmal über Jahrzehnte –gefeilt, mit dem Ergebnis, dass viele Unternehmen mittlerweile hunderte von Handelspartnerverbindungen weltweit betreiben.

Die Datenformatstandards (ANSI X12, EDIFACT, VDA usw.) variieren je nach Branche und Land. Welche Nachrichtentypen verwendet werden, hängt vom Workflow und der Integrationstiefe zwischen den Handelspartnern ab. Die B2B/EDI-Integration muss jedoch während und nach der S/4HANA-Migration zu 100 % weiter funktionieren, damit die Lieferketten nicht gestört werden.

EDI einfach umschalten bei der Migration zu SAP S/4HANA

Ein SAP S/4HANA-Migrationsprojekt ist ein komplexes Unterfangen, daher sollte die EDI-Integration so einfach wie möglich sein. Modularisieren Sie das S/4HANA-Projekt wo immer möglich und erfinden Sie das Rad nicht um seiner selbst willen neu.

Betrachten wir dazu eine typische B2B/EDI-Anbindung zwischen einem SAP-Kunden und seinem Handelspartner, der sein eigenes ERP-System verwendet, wie unten dargestellt:

Stellen Sie sich vor, wie komplex es ist, auf SAP S/4HANA zu migrieren und parallel dazu die alte EDI-Lösung zu ersetzen, die Sie aktuell einsetzen. Ein sinnvoller Ansatz ist es, Ihre EDI-Lösung zu modernisieren und zu konsolidieren, falls dies vor der Migration auf SAP S/4HANA erforderlich sein sollte.

Stabile Verbindung zu EDI-Handelspartnern bei der Migration auf SAP S/4HANA

Betrachtet man den Datenfluss, so wird deutlich, dass die etablierten Nachrichtenstandards (ANSI x12, EDIFACT, VDA…) sowie die Nachrichtentypen und etablierten Protokolle (AS2, OFTP2, VAN…) eine Art Trennlinie zwischen dem SAP-Kunden und dem Handelspartner bilden. Es ist wichtig, dass diese etablierten Nachrichten und die Datenkonvertierung zwischen ihnen (wie auch die Protokolle und die Kommunikation) und dem Handelspartner möglichst unangetastet bleiben. Andernfalls muss man sich mitten im S/4HANA-Migrationsprojekt mit der Änderung von hunderten von Handelspartnerverbindungen befassen.

Idealerweise befindet sich die B2B/EDI-Integration mit Konvertierung und Kommunikation auf einer separaten Hybrid-Integrationsplattform(HIP), die den Informationsfluss entkoppelt. Ist das interne Format IDoc und wird weiterverwendet, ist nur die Verbindung zum EDI-System von SAP ECC auf S/4HANA umzustellen.

Vermeiden Sie direkte SAP IDoc 1:1 EDI-Mappings

Die Datenkonvertierung hin zum Partner sollte also erhalten bleiben.

Die gebräuchlichste Konvertierungsmethode besteht jedoch darin, Daten zwischen dem internen IDoc-Format auf den etablierten Nachrichtenstandard und Nachrichtentyp abzubilden, und zwar direkt auf die entsprechenden Felder, die vom Handelspartner erwartet werden.

Dies ist scheinbar einfach, aber während das interne IDoc-Format gleichbleibt, wird die Struktur der Daten im ERP-System anders sein. Folglich müssen im Rahmen des Migrationsprojekts alle direkten SAP IDoc 1:1 EDI-Mappings überarbeitet und erneut getestet werden.

Denken Sie nur an einen eher einfachen Fall, in dem die SAP-EDI-Verbindung lediglich die Auftrags-, Lieferprognose-, Lieferavis- und Rechnungsabwicklung mit mehreren hundert Handelspartnern durchführt. Dies kann schnell über tausend direkte Mappings nach sich ziehen.

Vorteil für kanonische (indirekte) SAP IDoc EDI Mappings

Erleichtern Sie Ihr Mapping durch doppelte Konvertierung mit einem ‚kanonischen Masterformat‘. SEEBURGER bietet eine umfangreiche Sammlung mit mehr als 13.000 Handelspartnerprofilen (einschließlich Mapping- und Kommunikationsprofilen) für jede Branche. Die Mappings spiegeln die typischen Datenstrukturen wider, während die Kommunikationsprofile die bevorzugten Kommunikationsmethoden bereitstellen. Dieser Ansatz kann von allen SEEBURGER-Kunden entweder vor Ort oder in der Cloud genutzt werden.

Für jedes ERP-System und jeden Geschäftsprozess wird nur ein Prozess-Mapping erstellt. Auf der Partnerseite wird pro Partner und Prozess ein Standard Partner-Mapping von SEEBURGER bereitgestellt. SEEBURGER Partner-Mappings sind „Softwareprodukte unter Wartung“. Änderungen an den Partnerprofilen werden nachgepflegt und ausgeliefert.

Dadurch wird bei Änderungen auf der ERP Seite lediglich eine Änderung des Prozess-Mappings erforderlich, wie unten dargestellt:

Mit diesem Ansatz ist die Änderung und Wartung der EDI-Anbindungen viel einfacher. Jedes Mal, wenn sich etwas am ERP-System oder an einem Geschäftsprozess ändert, kann es zu einer Änderung der Datenstruktur kommen.

Mit SEEBURGER müssen jedoch nur die Process-Mappings geändert werden, d. h., die Verbindungen zu Handelspartnern bleiben unangetastet. Daher ist der kanonische (indirekte) Ansatz auf der Handelspartnerseite sehr skalierbar und erleichtert somit den Umstieg von SAP ECC auf S/4HANA.

Dies gilt unabhängig von einem Greenfield- oder Brownfield-Ansatz der SAP S/4HANA-Migration und ist so ein guter Investitionsschutz.

Wechseln Sie nach der Migration auf SAP S/4HANA in Ihrem eigenen Tempo zur API

Es ist einfacher, Ihre EDI-Integration im Vorfeld, vor dem Hauptmigrationsprojekt S/4HANA zu modernisieren und zu konsolidieren, als während des Hauptprojekts. So sind der Gesamtprojektaufwand und das Gesamtrisiko wesentlich geringer. Aus betrieblicher Sicht bleiben die Arbeitsabläufe und die Behandlung von EDI-bezogenen Inhaltsfehlern gleich, so dass die Abläufe in den Fachabteilungen nicht geändert werden müssen.

Die interne Integration mit anderen SAP-Lösungen oder Nicht-SAP-Systemen sowie externen Systemen und Diensten kann entweder weiter mit EDI oder einfacher Dateiübertragung erfolgen, oder es erfolgt der Umstieg auf APIs.

Mit einer echten hybriden Integrationsplattform (HIP) haben Sie einerseits eine solide B2B/EDI-Integration und schützen so Ihre Lieferkette. Andererseits haben Sie die Flexibilität, API-Integration und API-Management nach und nach hinzuzufügen.

Bedenken Sie dabei jedoch, dass die Arbeitsabläufe und die Behandlung von API-bezogenen Inhaltsfehlern an verschiedenen Orten stattfinden und daher die Abläufe in den Fachbereichen möglicherweise geändert werden müssen.

Vermeiden Sie Fehler bei der Migration zu SAP S/4HANA

Wir empfehlen:

1. Schützen Sie Ihre Lieferkettenprozesse.
2. Halten Sie EDI einfach, indem sie an bewährten EDI-Standards festhalten.
3. Wenn erforderlich, modernisieren und konsolidieren Sie Ihre EDI-Lösung vor der SAP S/4HANA-Migration.
4. Möglichst keine Änderungen zu Handelspartnern hin.
5. Vermeiden Sie direkte SAP IDoc 1:1 EDI-Mappings.
6. Vereinfachen Sie SAP IDoc EDI-Mappings durch Doppelkonvertierung mit SEEBURGERs SEEXML.
7. Gehen Sie in Ihrem eigenen Tempo zu API über und überfordern Sie Ihren Fachbereich nicht.

Die Zusammenarbeit mit einem erfahrenen HIP-Integrationsspezialisten wie SEEBURGER bietet dabei viele Vorteile. Mit SEEBURGER haben Sie darüber hinaus sehr flexible Betriebsmöglichkeiten: Der SEEBURGER BIS kann vor Ort bei Ihnen selbst betrieben werden, wir bieten den Betrieb in einer Full Service Cloud oder als iPaaS oder in einer öffentlichen Cloud wie die von Google, Azure, AWS etc.