Der Versuch eines Vergleichs
Vor 25 Jahren kam der Film „Home Alone“ (dt. Kevin – Allein zu Haus) in die Kinos. Die Geschichte ist relativ schnell erzählt – eine Familie aus Chicago bricht zum Weihnachtsurlaub nach Paris auf. Alles ist perfekt geplant und organisiert und alle freuen sich auf schöne Ferien — im Trubel des Abreise vergisst man jedoch versehentlich den kleinen Sohn zu Hause. Das wird allerdings erst im Flugzeug nach Paris bemerkt — eine Umkehr ist zu diesem Zeitpunkt naturgemäß nicht mehr möglich. Nach mühsamen Hin und Her findet mann dann doch wieder zusammen. Happy End mit viel Witz und Slapstick — 90er Jahre Kino von seiner besten Seite.
Im Hinblick auf ERP-Systeme und EDI lässt sich folgender Vergleich anstellen — leider im Gegensatz zu Hollywood oft ohne Happy End.
Auch bei ERP-Systemen wird viel in die Planung und Vorbereitung des Roll-Outs gesteckt. Nach dem erfolgten Roll-Out bemerkt man erst später — vorrangig durch Anforderungen von möglicherweise neuen Geschäftspartnern, dass eine EDI-Unterstützung für das ERP-System notwendig ist. Verfügt das ERP-System dann nicht über die notwendige Unterstützung von EDI-Prozessen, beginnen die Schwierigkeiten. Schnittstellen müssen nachimplementiert werden, Stammdatenprozesse müssen neu aufgesetzt werden und passende Dienstleister für die EDI-Abwicklung müssen gesucht werden. Dadurch entstehen hohe Kosten, die bei einer entsprechend frühen Berücksichtigung von EDI hätten vermieden werden können.
ERP-Systeme und EDI
ERP-Systeme und elektronischer Datenaustausch stehen in einer symbiotischen Beziehung zueinander. Ohne ein ERP-System, welches strukturierte Daten importieren und exportieren kann, ist die Umsetzung von EDI-Prozessen schwierig. Es gibt zwar Lösungen auf Basis von Web EDI, diese eignen sich allerdings nur für geringe Belegvolumen. Umgekehrt braucht es strukturierte EDI-Prozesse um Daten aus einem ERP-System in ein anderes ERP-System zu bekommen. Das eine geht also ohne das andere nicht.
Bei der Einführung eines ERP-Systems sollten daher bereits jene Anforderungen berücksichtigt werden, die mit EDI-Prozessen in einem ERP-System verbunden sind. Wir haben im Folgenden die wichtigsten Anforderungen kurz zusammengefasst.
Strukturierte Import- und Exportformate
Kern einer jeden EDI-Anbindung an ein ERP-System ist der Import und Export von strukturierten Daten. Wie in der folgenden Abbildung ersichtlich, ist die Import- und Exportschnittstelle in einem ERP-System für die Verarbeitung von externen Daten zuständig. Üblicherweise erfolgt die Datenübergabe an einen EDI-Konverter, welcher die weitere Verarbeitung der Daten übernimmt. Die Datenübertragung an den EDI-Konverter kann dabei auf unterschiedliche Weise erfolgen — z.B. per SFTP-Server oder mit fortgeschritteneren Konzepten, wie beispielsweise einer direkten API-Integration wie bei ERPEL-fähigen ERP-Systemen.
Exportinterface in einem ERP-System
Der EDI-Konverter nimmt die exportierten Daten entgegen und konvertiert sie in das vom Geschäftspartner erwartete EDI-Format (zumeist irgendeine Art von EDIFACT). Den Geschäftspartnern werden die EDI-Daten anschließend über verschiedene Protokolle zugestellt. Umgekehrt werden von den Geschäftspartnern EDI-Daten entgegen genommen, vom EDI-Konverter konvertiert und anschließend wieder in dem Importformat zu Verfügung gestellt, welches das ERP-System importieren kann.
Wie ersichtlich, kann keine vernünftige EDI-Integration ohne eine Import-/Exportschnittstelle im ERP-System durchgeführt werden.
Stammdatenumfang im ERP-System und Exportierbarkeit
Sobald das Thema Import-/Exportschnittstelle geklärt ist, muss im Detail untersucht werden, welcher Datenumfang über die Schnittstelle importiert und exportiert werden kann. Je nach Geschäftspartner werden unterschiedliche Arten von Daten in den EDI-Dokumenten erwartet, welche auch entsprechend aus dem ERP-System exportiert bzw. in dieses importiert werden müssen.
Ein Beispiel für ein besseres Verständnis: Um eine EDIFACT-Rechnung für einen Geschäftspartner erstellen zu können, sind üblicherweise die folgenden Felder notwendig (gekürzte Darstellung):
- GLN des Senders des Dokuments
- GLN des Empfängers des Dokuments
- Rechnungsdatum
- Rechnungsnummer
- Nummer der dazugehörigen Bestellung
- Datum der dazugehörigen Bestellung
- Nummer des dazugehörigen Lieferavis
- Datum des dazugehörigen Lieferavis
- Rechnungspositionen
- Rechnungsbeträge wie Netto, USt, Brutto usw.
Die oben genannten Elemente kommen in so gut wie jeder EDIFACT-Rechnung vor. Soll die Rechnung aber an EDEKA gehen, so sind zusätzliche Angaben notwendig. So muss beispielsweise eine Abkommensnummer mit übermittelt werden, sowie am Ende der Rechnungsübermittlung eine eigene Rechnungsliste (also eine Zusammenfassung der vorher übermittelten Rechnungen) übermittelt werden.
Der EDI-Konverter kann die EDEKA EDIFACT-Rechnung nur dann erzeugen, wenn alle von EDEKA geforderten Daten im Exportformat des ERP-Systems enthalten sind. Doch nur dann, wenn (i) das Exportformat den notwendigen Umfang hat und (ii) die Daten auch im ERP-System gepflegt werden, funktioniert dieser Export.
Auch diese Anforderung sollte bei der Anschaffung eines ERP-Systems bereits früh in die Anforderungsanalyse mit einbezogen werden, um später eine böse Überraschung zu vermeiden.
Prozessabbildung im ERP-System
Ein weiterer wichtiger Aspekt ist das Zusammenspiel der externen EDI-Prozesse mit den internen Prozessen des ERP-Systems. Die folgende Abbildung zeigt einen EDI-Prozess, wie er beispielsweise im Handel sehr oft verwendet wird.
Der Geschäftspartner bestellt mittels EDIFACT ORDERS, welche anschließend konvertiert und in das ERP-System importiert werden. Um doppelte Dateneingabe zur vermeiden und die Vorteile von EDI so gut wie möglich ausnutzen zu können, werden die Bestelldaten übernommen und eine Bestellbestätigung wird generiert. An der Bestellbestätigung können vom ERP-Benutzer (zumeist ein Sachbearbeiter) noch Änderungen vorgenommen werden. Anschließend wird die Bestellbestätigung versendet.
EDI-Prozesse in einem ERP-System
Die Bestellbestätigung wird vom EDI-Konverter in eine EDIFACT ORDRSP-Nachricht (Order Response) übersetzt und zugestellt. Bevor die eigentliche Ware versendet wird, muss an den Geschäftspartner ein Lieferavis übermittelt werden. Auch hier werden die Daten wiederum aus der Bestellbestätigung übernommen, um doppelte Dateneingabe zu vermeiden. Anschließend übernimmt der EDI-Dienstleister wieder die Konvertierung und Zustellung.
Am Ende wird auf Basis der Lieferavis-Daten die Rechnung erstellt und an den Geschäftspartner übermittelt.
Wie auf der linken Seite der Grafik abgebildet, wird die ursprüngliche Bestellung schrittweise zur Rechnung verfeinert, wobei immer eine Datenübernahme aus dem darüberliegenden Dokument erfolgt. Bei EDI spricht man in diesem Zusammenhang auch vom so genannten Turnaround-Verfahren. Durch dieses Verfahren werden notwendige Daten automatisch aus den vorangegangenen Dokumenten übernommen (eine Rechnung braucht beispielsweise eine Referenz auf die Bestellnummer, das Bestelldatum sowie die Lieferscheinnummer und das Lieferscheindatum) und Eingabefehler durch manuelle Verarbeitung können vermieden werden.
Voraussetzung für das Turnaround-Verfahren ist die entsprechende Umsetzung der Prozesse im ERP-System. Auch dies sollte während der ERP-Anforderungsanalyse bereits früh beachtet werden.
Zusammenarbeit mit einem EDI-Dienstleister
Eine weitere wichtige Überlegung ist die Wahl eines geeigneten EDI-Dienstleisters, um die notwendigen Konvertierungen und Anbindungen der Geschäftspartner umzusetzen. Hier gibt es prinzipiell zwei verschiedene Möglichkeiten:
- Anschaffung eines eigenen lokalen EDI-Konverters
- Auslagerung der EDI-Abwicklung an einen externen Dienstleister
Anschaffung eines eigenen lokalen Konverters
Die Anschaffung eines eigenen lokalen EDI-Konverters lohnt sich nur für Unternehmen, die im Unternehmen selbst über ein hohes Maß an EDI-Know-How verfügen. Der EDI-Konverter muss von geschultem Personal bedient werden, sodass Wartungsarbeiten (z.B. Anpassungen von EDI-Formaten) möglichst rasch umgesetzt werden können. Zusätzlich zum lokalen Konverter muss noch ein eigener EDI-Dienstleister beauftragt werden, der die Anbindung der Geschäftspartner über die geforderten Protokolle vornimmt (AS2, X.400, OFTP, SFTP, etc.). Ein lokaler Konverter kostet einen fünfstelligen Eurobetrag, wobei bei größeren Lösungen auch sechststellige Beträge eher die Regel, als die Ausnahme sind. Neben den Anschaffungskosten werden bei den meisten Lösungen auch jährliche Wartungspauschalen fällig.
Auslagerung an einen externen Dienstleister
Besser skalierend ist die Auslagerung der EDI-Prozesse an einen externen Dienstleister, der neben der Datenkonvertierung auch gleich die Datenübermittlung an die einzelnen Partner vornimmt. Der externe EDI-Dienstleister arbeitet eng mit dem EDI-Customizer zusammen, sodass der Datenaustausch zwischen ERP-System und EDI-Konverter möglichst reibungslos funktioniert. Im Unterschied zu einem lokalen Konverter fallen keine hohen Einmalkosten für die Beschaffung oder Wartungskosten an — bezahlt wird nur die Einrichtung der jeweiligen Dokumentenkonvertierung.
Moderne Lösungen, wie beispielsweise ecosio.ERPEL (ERPEL = ERP Exchange Language), ermöglichen eine zusätzliche Minimierung von Reibungsverlusten, indem die Import- und Exportschnittstellen in Richtung EDI-Dienstleister bereits Teil des ERP-Systems sind. Somit ist eine direkte Datenübergabe ohne zwischengeschaltete Lösungen, wie beispielsweise einem SFTP-Server, möglich.
Noch Fragen?
Sie evaluieren die Einführung eines neuen ERP-Systems und haben noch Fragen zur Integration von EDI-Prozessen? Wir helfen Ihnen gerne weiter — nehmen Sie mit uns Kontakt auf oder benutzen Sie unseren Chat!
