Wir zeigen im Folgenden die wichtigsten Gründe auf, warum man EDI in einem SAP Business Blueprint unbedingt berücksichtigen sollte.
EDI SAP ERP-Umsetzungsprojekte
SAP ERP-Umsetzungsprojekte durchlaufen je nach Größe und Umfang zumeist die folgenden Phasen.
Während der Projektvorbereitung wird die initiale Planung des SAP-Projekts vorgenommen. Darauf folgt die Business Blueprint-Phase. Das Ziel dieser Phase ist es, ein gemeinsames Verständnis aller Key-Stakeholders über die Geschäftsprozesse zu erlangen, die im SAP-System abgebildet werden sollen. Das Ergebnis ist der namensgebende Business Blueprint, in welchem die Anforderungen an die Geschäftsprozesse detailliert beschrieben werden. Der Business Blueprint ist die Basis für weiteren Phasen der Umsetzung, Finalisierung und des Go-Live.
Integrationsherausforderungen
Bei der Umsetzung eines SAP-Projekts gibt es im Allgemeinen zwei große Integrationsherausforderungen.
Zum einen existiert ein SAP-System in den wenigsten Fällen als alleiniges System in einem Unternehmen, sondern parallel zu anderen Systemen wie CRM-Systeme (Customer-Relationship-Management), PDM/PLM-Systeme (Product Data Management / Product Lifecycle Management), MES-Systeme (Manufacturing Execution System) usw. Um einen Datenfluss zwischen diesen Systemen zu erlauben, müssen diese über passende Mechanismen miteinander verbunden werden. Man spricht in diesem Zusammenhang auch von Enterprise Application Integration (EAI).
Zum anderen existiert ein Unternehmen nicht alleine, sondern ist in eine Wertschöpfungskette aus Lieferanten und Kunden eingebunden. Um die Belegflüsse wie Bestellungen, Lieferabrufe, Lieferavis etc. zwischen Lieferanten und Kunden zu realisieren, kommt elektronischer Datenaustausch (EDI) zur Anwendung.
Im Gegensatz zum Thema EAI, wird bei der Planung eines SAP-Systems dem Thema EDI oft zu wenig Aufmerksamkeit geschenkt. Wir stellen im Folgenden sechs Gründe vor, warum man EDI als eines der zentralen Themen in einem SAP-Projekt betrachten sollte.
1 – Messaging als First-Class-Citizen einer ERP-Einführung
In den Anfangszeiten von ERP-Systemen wurden diese vor allem für die Verwaltung der unternehmenseigenen Daten wie Bestellungen, Rechnungen, Lohnbelege etc. verwendet. An dieser Tatsache hat sich bis zum heutigen Tage auch nichts geändert.
Geändert hat sich allerdings die Art und Weise, wie Daten in das Unternehmen kommen bzw. das Unternehmen wieder verlassen. Belege werden heute nicht mehr nur als Papier, Fax oder PDF empfangen und versendet, sondern immer häufiger in strukturierter maschinenverarbeitbarer Form – z.B. als EDIFACT, ZUGFeRD, CSV, XML etc. D.h. das Senden und Empfangen von strukturierten Daten ist nicht mehr eine prozessuale Randerscheinung eines ERP-Systems, sondern wird zur zentralen Funktion, die ein Funktionieren der Beschaffungs- und Vertriebsprozesse erst ermöglicht.
Messaging wird daher zum First-Class-Citizen eines ERP-Systems. SAP hat diese Bedeutung bereits sehr früh erkannt, und bietet heute mit IDocs ein umfangreiches Import- und Exportformat für Daten ab. Die Prozesserhebung im Rahmen der Business Blueprint-Phase darf jedoch nicht an der Grenze des ERP-Systems aufhören, sondern man muss den gesamten Prozess ganzheitlich betrachten.
Ganzheitlich bedeutet in diesem Zusammenhang, dass die inter-organisationalen Geschäftsprozesse mit den Lieferanten und Kunden aus einer globalen Vogelperspektive betrachtet werden und eine so genannte globale Prozesschoreographie erstellt wird. Diese Prozesschoreographie definiert den genauen Ablauf der ausgetauschten Dokumenttypen, wie Bestellungen, Lieferscheine, Rechnungen, etc. mit Kunden und Lieferanten. Dabei werden Fragen beantwortet wie „Was fordern unsere Kunden (z.B. Volkswagen oder BMW)?“ und „Was bieten wir unseren Lieferanten (z.B. Versand von Lieferabrufen, geforderter Empfang von Lieferavis-Dokumenten)?“ etc. Eine weitere wichtige Rolle spielt die Analyse der notwendigen Dokumenteninhalte, z.B. was ist genau in einem Lieferabruf enthalten, welche Daten müssen in einem Lieferavis gesendet werden, etc.
Die globale Prozesschoreographie definiert daher die prozessualen und inhaltlichen Anforderungen, welche nachgelagert von Sales und Distribution (SD), Materials Management (MM) und bei Rechnungen und Gutschriften auch von Finance (FI) abgebildet werden müssen. Durch die starke Verschränkung der Themen SD, MM, FI und EDI ist eine enge Kooperation zwischen diesen Teams während der gesamten Projektlaufzeit essenziell.
2 – Integration der Dokumentenflüsse in das SAP
SAP unterstützt im Hinblick auf die Verarbeitung von IDocs eine Vielzahl von Standardprozessen, wie Verarbeitung einer eingehenden Bestellung, Verarbeitung eines eingehenden Lieferabrufs, Versand eines Lieferavis etc.
Vor allem im Automotive-Bereich und im Handel gibt es je nach Automobilhersteller oder Handelsunternehmen gewisse Sonderanforderungen. So müssen bei manchen Automobilherstellern beispielsweise Daten aus Lieferabrufen wieder in Lieferavis-Dokumente übernommen werden — für bestimmte Felder wird dies standardmässig in SAP oft nicht unterstützt, was ein Customizing erfordert. Handelsunternehmen fordern spezielle Schlüssel, wie Hinweise auf Entgeltminderungen aufgrund von Rabatt- und Bonusvereinbarungen u.ä.
Diese Sonderanforderungen müssen frühzeitig erkannt werden und in den Business Blueprint aufgenommen werden. Dies ist nur dann möglich, wenn die geforderten EDI-Dokumente bereits in der Projektanalysephase vom zuständigen EDI-Team genau analysiert werden.
3 – Integration und Management der Austauschverbindungen
Bei der Umsetzung von EDI-Verbindungen müssen eine Vielzahl an verschiedenen EDI-Standards und EDI-Protokollen unterstützt werden. Die folgende Abbildung zeigt ein Beispiel für ein EDI-Setup.
Integration verschiedener EDI-Partner
Das SAP-System verarbeitet über die Import- und Exportschnittstellen IDoc-Formate. Diese werden nachgelagert von einem Konverter in die Zielformate der Geschäftspartner übersetzt werden und umkehrt. Der Versand bzw. der Empfang der Dokumente erfolgt über die verschiedenen EDI-Protokolle wie X.400, AS2, SFTP, OFTP2 etc. Oftmals ist nachgelagert auch die Anbindung eines VAN (Value-Added-Network) notwendig.
Wie aus der Grafik ersichtlich wird, steigt die Komplexität der EDI-Verbindungen mit der Anzahl an verschiedenen Geschäftspartnern schnell an. Um dieser Komplexität Herr zu werden, ist der Einsatz einer EDI-Konverter-Software notwendig. Die Konverter-Software übernimmt das Übersetzen von und zu den IDoc-Formaten des SAPs und steuert nachgelagert (oft wieder über eigene Software) die verschiedenen EDI-Protokolle an.
EDI-Konverter können lokal im Unternehmen betrieben werden oder als ausgelagerte Lösung bei einem externen Dienstleister im Einsatz sein. Die Vor- und Nachteile wurden bereits in einem vergangenen Beitrag vorgestellt. Im Folgenden ist beispielhaft die Anbindung von Kunden und Lieferanten mit Hilfe der ecosio.EDI-Lösung visualisiert.
Konsolidierung durch einen Dienstleister
Zwischen dem SAP-System und dem EDI-Dienstleister besteht lediglich eine einzelne Verbindung, über welche alle IDoc-Dokumente gesendet und empfangen werden. Der EDI-Dienstleister übernimmt dabei die Anbindung von Kunden und Lieferanten, führt die notwendigen Konvertierungen durch und überwacht den EDI-Verkehr.
In Hinblick auf den SAP Business Blueprint muss früh genug eine Entscheidung für den verwendeten EDI-Konverter bzw. EDI-Dienstleister getroffen werden, da dieser in die Business Blueprint-Phase eingebunden werden muss. Der EDI-Dienstleister wird daher idealerweise bereits in der Projektvorbereitungsphase ausgewählt.
4 – Zusammenspiel EDI + SAP
Das erfolgreiche Zusammenspiel zwischen EDI-Prozessen und einem SAP-System erfordert eine detaillierte Abstimmung im Hinblick auf die verwendeten Identifikationsnummern und Bezeichner. Diese Abstimmung erfolgt idealerweise bereits während der Blueprint-Phase. SAP-intern spricht man beispielsweise von Debitoren und Kreditoren, die anhand von eindeutigen Nummern identifiziert werden. In der EDI-Welt haben diese internen Nummern keinerlei Bedeutung, sondern es müssen globale Identifier wie DUNS oder GLN verwendet werden.
Des Weiteren müssen spezielle Kunden- und Lieferantenanforderungen in den EDI-Nachrichten berücksichtigt werden, was sich in den SAP-Prozessen und IDoc-Inhalten widerspiegeln muss. Als Beispiel kann hier wieder die Automobilindustrie herangezogen werden. Ford fordert bei Lieferungen aus Deutschland in die USA beispielsweise die Abbildung eines Intermediate Consignees in einer ASN-Nachricht, was eine Ausnahme zum regulären ASN-Prozess darstellt. BMW setzt in Lieferabrufen und Lieferavis auf die Angabe von NAEL und AI-Nummern, die auch entsprechend durch die ein- und ausgehenden SAP-Prozesse berücksichtigt werden müssen.
Diese Anforderungen müssen bereits während der Business Blueprint-Phase zwischen SD, MM und EDI geklärt werden, um später im Echtbetrieb die Kundenanforderungen erfüllen zu können.
5 – Test und Produktivstellung
Aufbauend auf den Anforderungen des Business Blueprints müssen für die verschiedenen EDI-Relationen mit Kunden und Lieferanten Testszenarien geschaffen werden, welche vor der Produktivstellung des Systems abgearbeitet werden.
Auch hier ist eine enge Zusammenarbeit zwischen SAP-Team und EDI-Team notwendig, da je nach Kunde und Lieferant völlig unterschiedliche Testanforderungen existieren. So betreiben manche Geschäftspartner eigene Test-Systeme, die mit dem eigenen SAP Test-System gekoppelt werden können, um Tests durchzuführen. Andere Geschäftspartner wiederum bieten keinerlei Testumgebungen, wodurch man sich auf sorgfältige Tests gegen die vorhandenen EDI-Spezifikationen verlassen muss.
6 – Betreuung während des laufenden Betriebs
Nach der erfolgreichen Produktivstellung des SAP-Systems gilt es den laufenden EDI-Nachrichtenverkehr im SAP zu überwachen. Dabei kommen Transaktionen wie BD87 bzw. eigene Transaktionen des EDI-Dienstleisters zur Anwendung, anhand derer man den Status von gesendeten und empfangenen IDoc-Nachrichten prüfen kann.
Die notwendigen organisatorischen Zuständigkeiten für die Überwachung des EDI-Verkehrs müssen bereits frühzeitig festgelegt werden. Nur so kann ein laufendes Monitoring und ein rasches Eingreifen im Fehlerfall ermöglicht werden.
Fazit und Ausblick EDI und SAP
Für die erfolgreiche Umsetzung eines SAP-Projektes ist eine frühzeitige Betrachtung der betroffenen EDI-Prozesse mit Lieferanten und Kunden unerlässlich. Nur wenn in der Business Blueprint-Phase die EDI-Anforderungen klar strukturiert und erfasst werden, kann später ein entsprechend strukturierter Prozess realisiert werden.
Anstatt von Silodenken bei den SD, MM, FI und EDI-Teams muss eine enge Zusammenarbeit stattfinden, um alle notwendigen Anforderungen im SAP ERP korrekt abbilden zu können.
Noch Fragen?
Sie haben noch Fragen zum Thema EDI und SAP oder interessieren sich für eine EDI-Anbindung an Ihr SAP ERP-System? Nehmen Sie mit uns Kontakt auf oder benutzen Sie unseren Chat — wir helfen Ihnen gerne weiter!
SAP ERP und SAP S/4HANA sind die Marken oder eingetragenen Marken der SAP SE oder ihrer verbundenen Unternehmen in Deutschland und mehreren anderen Ländern.
