Inhalt
Der EDI-Integrationsprozess ist umfassender als das Öffnen einer Verbindung zwischen zwei Systemen. Unter welchen Bedingungen eine Bestellung entsteht, wie Produktcodes abgeglichen werden und wer die abgewiesene Nachricht bearbeitet, wird gemeinsam entworfen. Werden diese Entscheidungen nicht zu Beginn getroffen, kann der Bestell-, Versand- oder Rechnungsfluss im Unternehmen auch dann keine Entsprechung finden, wenn die technische Verbindung funktioniert.
Ein gut geplantes Projekt schreitet von der Analyse bis zur Live-Überwachung in sieben Schritten voran. Der Output, der Verantwortliche und das Abnahmekriterium jedes Schritts sind klar. So erkennen die Teams Probleme nicht im Live-System, sondern in einer kontrollierten Testumgebung.
1. Bestimmen Sie das Geschäftsziel und den Projektumfang
Der erste Output des Projekts ist keine technische Dokumentation, sondern die Umfangsentscheidung. Es muss festgehalten werden, welche Handelspartner angebunden werden, welche Dokumente gesendet und empfangen werden und welches Geschäftsergebnis erwartet wird. Bestellung, Auftragsbestätigung, Versandbenachrichtigung und Rechnung müssen nicht gleichzeitig in den Umfang aufgenommen werden.
IBM nennt als ersten Schritt der EDI-Implementierung die Definition des Geschäftsziels. Der Implementierungsleitfaden des Unternehmens empfiehlt außerdem, den Umfang über Geschäftspartner, Transaktionsarten und Datenquellen abzugrenzen. Diese Abgrenzung verhindert, dass während des Projekts neue Dokument- und Partneranforderungen unkontrolliert hinzugefügt werden. IBMs EDI-Implementierungsleitfaden behandelt auch die unternehmensinterne Infrastruktur in vier Schichten: Laufzeitumgebung, Verbindung, Integration und Datenverwaltung.
Im Kick-off-Meeting müssen folgende Entscheidungen protokolliert werden:
- Die Geschäftspartner in der ersten Phase und die Prioritätsreihenfolge
- Die zu sendenden und zu empfangenden Dokumenttypen
- Das Quell-ERP-, WMS- oder Buchhaltungssystem
- Regeln für akzeptable Fehler, Verzögerungen und erneute Verarbeitung
- Die Entscheidungsverantwortlichen auf Seiten von Fachbereich, IT und Geschäftspartner
In der Türkei kann die erste Phase für einen Automobilzulieferer mit Bestellung und Versandbenachrichtigung beginnen. Bei einem Einzelhandelslieferanten können Bestellung, Lieferschein und Rechnung ein geeigneteres Startpaket sein. Der Umfang sollte sich nicht aus dem Branchennamen, sondern aus dem tatsächlichen Dokumentfluss ergeben.
2. Sammeln Sie die Anforderungen der Handelspartner
Selbst wenn jeder Geschäftspartner denselben Standard verwendet, kann er unterschiedliche Feld-, Code- und Zeitregeln verlangen. Daher muss das Team den Implementation Guide und die Testszenarien der Gegenseite vor Beginn des Mappings beschaffen. Dokumentversion, Pflichtfelder, Partner-IDs, Verbindungsprotokoll und Bestätigungsnachrichten werden hier geklärt.
IBMs EDI-Onboarding-Erklärung nennt als gängige Dokumentbeispiele drei X12-Transaktionssets: 850 Bestellung, 810 Rechnung und 997 funktionale Bestätigung. Bei Verbindungen in Europa und der Türkei können EDIFACT- oder branchenspezifische VDA-Nachrichten im Vordergrund stehen. Die OTOEDI-Seite von MAP listet neben EDIFACT- und VDA-Unterstützung auch die Konvertierung von IDOC, XML, CSV und TXT auf.
Die Anforderungsliste darf nicht nur aus dem Dateiformat bestehen. Auch die Eindeutigkeit der Bestellnummer, der Währungscode, die Maßeinheit, das Datumsformat und das Vorgehen bei unbekanntem Produktcode müssen festgehalten werden. Die Testumgebung, der Ansprechpartner und die Rückmeldezeit der Gegenseite sollten in den Projektkalender aufgenommen werden.
3. Richten Sie die Integrationsarchitektur und die Verbindung ein
Die Architekturentscheidung legt fest, wie die EDI-Plattform mit dem ERP kommuniziert und über welchen Weg die Nachricht zum Geschäftspartner gelangt. Bei der internen Verbindung kann API, Dateiübertragung oder Datenbankintegration verwendet werden. Bei der externen Kommunikation kann AS2, SFTP, OFTP2 oder ein anderes vom Geschäftspartner akzeptiertes Protokoll gewählt werden.
IBMs Onboarding-Leitfaden beschreibt vier gängige Kommunikationsoptionen: AS2, SFTP, MFT und SOAP. Die Auswahl sollte nach Sicherheit, Zustellbenachrichtigung, Zertifikatsverwaltung, vorhandener Infrastruktur und Partnerbedingungen getroffen werden. Die Protokollentscheidung allein ist nicht ausreichend. Endpoint, Zertifikat, IP-Berechtigungen, Dateiname, Ausführungshäufigkeit und Wiederholungsrichtlinie müssen ebenfalls in das Verbindungsdokument aufgenommen werden.
Das Unternehmen kann diese Schichten mit seinem eigenen Team verwalten oder einen Dienstleister nutzen. Die B2B/EDI-Integrationsseite von MAP sollte Inhaber der kommerziellen Lösung sein, die den automatischen Austausch von Geschäftsnachrichten wie Bestellung und Rechnung zwischen ERP-Systemen anstrebt.
4. Bereiten Sie die Quelldaten vor dem Live-Gang vor
Die Mapping-Tabelle kann unsaubere Quelldaten nicht korrigieren. Wenn dasselbe Produkt unter zwei Codes geführt wird, Steuerinformationen fehlen oder das Adressfeld inkonsistent ist, führt dies im Test zu einer Ablehnung. Das Team muss vor der EDI-Konvertierung die Stammdaten im ERP und die Regeln zur Dokumenterstellung prüfen.
IBM nennt schwache Datenqualität als eines der häufigen Probleme im EDI-Onboarding-Prozess. Doppelte Datensätze, fehlende Felder und inkonsistente Bezeichnungen können den Validierungsschritt verzögern. Selbst das einfache Datumsbeispiel im Leitfaden des Unternehmens zeigt den Unterschied: Wenn der Standard YYYYMMDD erwartet, kann das Senden eines Freitextdatums zur Ablehnung der Datei führen.
Bei der Datenvorbereitung sollten mindestens folgende Prüfungen durchgeführt werden:
- Sind Kunden- und Lieferantencodes eindeutig?
- Stimmt der interne Produktcode mit der Partner-SKU überein?
- Entsprechen Einheiten-, Länder- und Währungscodes den akzeptierten Listen?
- Sind die Pflichtfelder für Steuer, Adresse und Versand ausgefüllt?
- Sind Ausnahmen wie Storno, Teillieferung und Preisdifferenz definiert?
Diese Arbeit darf nicht allein dem IT-Team überlassen werden. Vertrieb, Logistik, Finanzen und Stammdatenverantwortliche müssen die Richtigkeit ihrer eigenen Bereiche bestätigen.
5. Entwickeln Sie das EDI-Mapping und die Geschäftsregeln
EDI-Mapping wandelt Felder im internen System in die Zielnachrichtenstruktur um. Ein malzeme_kodu in einem ERP kann auf der Gegenseite als SKU erwartet werden. Ein Feld kann bei manchen Partnern Pflicht und bei anderen optional sein. Daher ist für jeden Geschäftspartner eine versionierte Mapping-Definition erforderlich.
IBM beschreibt die Mapping-Arbeit als den Teil, der alle vier Infrastrukturschichten der EDI-Implementierung durchdringt und häufig die meiste Zeit in Anspruch nimmt. Für jedes Feld wird die Entsprechung im Implementation Guide gefunden; feste Werte, Codetransformationen und bedingte Regeln werden zusätzlich dokumentiert. Wird keine Änderungshistorie geführt, kann eine neue Partnerregel den bestehenden alten Ablauf stören.
Im Mapping-Dokument müssen Quellfeld, Zielfeld, Transformationsregel, Verpflichtungsstatus, Beispielwert und Fehlerverhalten enthalten sein. Anstatt dieselbe Geschäftsregel getrennt in Code, E-Mail und Excel-Dateien zu führen, sollte eine einzige kontrollierte Quelle verwendet werden. Die Mapping-Freigabe sollte zusammen mit dem technischen Entwickler auch von der Fachabteilung eingeholt werden, die das Dokument nutzt.
6. Testen Sie nicht das Dokument, sondern den End-to-End-Prozess
Dass eine Testdatei die Gegenseite erreicht, beweist nicht, dass die Integration bereit ist. Die Datei muss korrekt geparst werden, im ERP den richtigen Datensatz erzeugen und die erforderliche Bestätigungsnachricht zurückliefern. Danach sollten Ausnahmen wie Storno, fehlendes Feld, falscher Code, erneutes Senden und Verbindungsabbruch getestet werden.
IBMs Onboarding-Modell unterteilt den Test in vier Kategorien: Verbindung, Validierung, einzelne Transaktion und vollständiger Ablauf. Der Einzeltransaktionstest zeigt, dass die Nachricht hin- und zurückgeht. Der Vollablauftest bestätigt die Kette von der Erfassung der Bestellung im ERP bis zu den Schritten Versand und Rechnung. In Szenarien mit X12 ist die 997-Nachricht einer der technischen Nachweise, die den Annahme- oder Ablehnungsstatus des Dokuments melden.
Im Testplan müssen für jedes Szenario das erwartete Ergebnis, das tatsächliche Ergebnis, die verantwortliche Person und der Nachweis enthalten sein. Ohne gemeinsame Abnahme mit dem Geschäftspartner darf keine Produktionsverbindung geöffnet werden. Wenn ein Lieferant in der Türkei den E-Rechnungsprozess im selben Ablauf nutzt, dürfen die Verantwortlichkeiten von EDI-Dokument und steuerlichem Dokument nicht miteinander verwechselt werden.
7. Gehen Sie kontrolliert live und überwachen Sie die Nachrichten
Der Live-Gang ist kein einzelnes Datum, sondern eine kontrollierte Arbeitsphase. Die ersten Nachrichten können manuell verglichen werden; Volumen und Anzahl der Geschäftspartner können schrittweise erhöht werden. Wann der alte Kanal geschlossen wird und der Rückkehrplan muss vor Beginn festgelegt werden.
MAP gibt auf seiner Website an, jährlich 150 Millionen EDI-Nachrichten zu sammeln, zu verarbeiten und zu verteilen. In dieser Größenordnung beruht der Betrieb nicht nur auf dem Versand von Nachrichten, sondern auf einer sichtbaren Fehler- und Wiederaufbereitungsorganisation. Die Unternehmens-EDI-Daten von MAP veröffentlichen außerdem die Information von mehr als 1.500 Kunden und 30 Jahren EDI/B2B-Integrationserfahrung.
Das Monitoring-Dashboard muss mindestens gesendete, empfangene, ausstehende, abgelehnte und erneut verarbeitete Nachrichten anzeigen. Es muss definiert werden, an wen der Alarm geht, bei welchem Fehler die Fachabteilung eingreift und wie das Mapping aktualisiert wird, wenn sich eine Partnerregel ändert. Die Messwerte des ersten Monats sollten Teil der Projektabnahme sein.
Fazit
Der Erfolg der EDI-Integration wird nicht am Tag der Verbindungsaufnahme gemessen, sondern an der korrekten Verarbeitung echter Geschäftsdokumente. Umfang, Partneranforderungen, Quelldaten, Mapping und Testnachweise müssen vor dem Live-Gang abgeschlossen sein. Im Produktivbetrieb müssen Nachrichtenstatus, Fehlerverantwortung und Änderungsmanagement sichtbar bleiben.
Um den Ansatz zu bewerten, der zu Ihrer Geschäftspartner-, Dokument- und ERP-Struktur in Ihrem Unternehmen passt, können Sie die Seite MAP B2B/EDI-Integration ansehen. Weitere Inhalte zur EDI- und Lieferketten-Digitalisierung finden Sie über MAP Blog.
