Warum Ihre EDI-Integration an Ihr altes ERP gebunden ist
EDI-Verbindungen (Electronic Data Interchange) scheinen zum Partner zu gehören. In der Praxis gehören sie zu dem System, das dahintersteht.
Ein Kunde, der Ihnen eine Bestellung schickt, sendet sie in einem vereinbarten Format, mit vereinbarten Kennungen, an einen vereinbarten Endpunkt. Diese Kennungen stammen aus Ihrem ERP. Artikelnummern, Kundencodes, Mengeneinheiten und Steuercodes sind das Vokabular Ihres Systems, einmal übersetzt, als die Verbindung gebaut wurde, und seitdem eingefroren.
In dieser Übersetzung stecken meist vier Dinge:
- Produktkennungen: Ihre Artikelnummern, Artikel für Artikel den eigenen Katalogreferenzen des Partners zugeordnet
- Partner- und Standortcodes: welcher Kunde, welche Lieferadresse, welche Filiale, ausgedrückt in Codes, die Ihr ERP vergeben hat
- Dokumentstruktur: welche Felder in einer Bestellung, einem Lieferavis oder einer Rechnung Pflicht sind und in welcher Reihenfolge
- Validierungsregeln: was der Partner ablehnt, einschließlich Toleranzen bei Menge, Preis und Lieferfenster
In den meisten Unternehmen ist nichts davon an einer Stelle dokumentiert. Es steckt in der Verbindung selbst und im Gedächtnis der Person, die sie gebaut hat. Das wird zum Problem, sobald sich das System darunter ändert.
Was bricht, wenn sich das ERP darunter ändert
Ein neues ERP vergibt eigene Kennungen. Artikelnummern ändern sich, Kundencodes ändern sich, und das Datenmodell, auf dem das ursprüngliche Mapping beruhte, gibt es nicht mehr.
Der Fehler ist selten dramatisch. Eine Bestellung kommt an und wird abgelehnt, weil ein Feld, das der Partner erwartet, jetzt leer ist. Eine Rechnung wird angenommen und dann angefochten, weil der Steuercode anders zugeordnet wird. Ein Lieferavis geht mit einer Mengeneinheit hinaus, die der Partner als Kartons statt Paletten liest.
Diese Fehler treten Partner für Partner auf, und genau das macht sie teuer. Ein Unternehmen mit Dutzenden EDI-Partnern bekommt nicht einen Fehler. Es bekommt eine Warteschlange davon, und jeder braucht eine andere Person in einem anderen Unternehmen, die eine Korrektur bestätigt.
Dasselbe Muster gilt allgemeiner für Datenmigrationen, wie in der Migration von ERP- und WMS-Daten mit einer Integrationsplattform beschrieben. EDI ist die Variante, bei der jemand außerhalb Ihres Unternehmens zustimmen muss, bevor etwas behoben wird.
Was die Überarbeitung der EDI-Integration wirklich kostet
Das Neu-Mapping ist nicht der teure Teil. Ein Analyst baut ein Mapping in wenigen Stunden neu. Was es das Unternehmen kostet, liegt rund um diese Arbeit:
- Beim Partner abgelehnte Bestellungen: Durch ein fehlendes Feld erreicht die Bestellung Ihr System nie, und der Kunde wendet sich an Sie statt an sein eigenes EDI-Team
- Angefochtene statt bezahlte Rechnungen: Ein anders zugeordneter Steuercode wird zur Gutschrift, zu einem Gespräch mit der Buchhaltung und zu Geld, das einen Monat später eingeht
- Ihre größten Kunden um einen Gefallen gebeten: EDI-Änderungen erfordern Tests auf Partnerseite, sodass ein Systemwechsel zur Bitte an genau die Unternehmen wird, denen Sie verkaufen wollen
- Dieselbe Arbeit beim nächsten Mal: Auf das neue ERP neu gebaute Mappings sind genauso fest daran gebunden, sodass der nächste Wechsel gleich viel kostet
- Wechsel verschoben oder vermieden: Unternehmen mit großen EDI-Landschaften verschieben Systemwechsel oft wegen der Kosten der Überarbeitung
Das Letzte ist der eigentliche Preis. EDI ist dann keine technische Pflicht mehr, sondern ein Grund, das System überhaupt nicht zu wechseln.
Wie eine Integrationsplattform die EDI-Integration handhabt
Ein iPaaS (integration Platform as a Service) gibt einem Unternehmen einen Ort, an dem alle seine Systeme zusammenkommen. Jedes System wird einmal daran angebunden statt direkt an die anderen, und die Plattform bewegt die Daten zwischen ihnen und formt sie um. Unternehmen nutzen es für die tägliche Arbeit: Bestellungen vom Webshop ins ERP, Bestände zurück, Versanddaten an einen Spediteur.
EDI läuft nach demselben Prinzip, mit einem Unterschied, der hier zählt. Der Partner verbindet sich mit der Plattform statt mit dem ERP. Das Mapping zwischen dem Format des Partners und Ihrem Datenmodell liegt in der Plattform, nicht in der Verbindung, sodass eine Änderung dahinter nichts an dem ändert, was der Partner sieht.
Die Alumio-Integrationsplattform bietet Funktionen, die sich so konfigurieren lassen, dass EDI-Verbindungen einen ERP-Wechsel stabil überstehen:
- Der Partner-Endpunkt bleibt bestehen: Partner senden weiter an dieselbe Stelle im selben Format, sodass ein Wechsel hinter der Plattform keine Änderung auf Partnerseite erfordert
- Mappings sind sichtbar und bearbeitbar: Ein Transformer enthält die Übersetzung zwischen Partnerformaten und Ihren Kennungen, sodass das Neu-Mapping auf ein neues ERP eine Konfigurationsänderung ist, die Ihr eigenes Team vornehmen kann
- Beide Systeme können parallel laufen: Datenflüsse können während der Umstellung auf das alte und das neue ERP zeigen, sodass niemand von einem einzigen Umstellungsdatum abhängt
- Sie sehen, was jeder Partner gesendet hat: Nachrichtenprotokolle zeigen genau, was ankam und was zurückging, und das klärt einen Streit mit einem Partner, statt ihn zu verlängern
Alumio bietet außerdem einen EDI Broker für Unternehmen, die die Verbindung lieber verwalten lassen als selbst bauen. Dasselbe Prinzip gilt auch außerhalb von EDI. AGU verbindet sein Centric ERP über Alumio statt direkt mit Adobe Commerce und Akeneo, mit normalisierten Daten, die sich später an weitere Tools anbinden lassen. Neue Kanäle lassen sich dann als zusätzliche Routes ergänzen, ohne das Bestehende neu zu bauen.
Was partnerunabhängige EDI-Integration Ihnen bringt
EDI wird meist als Altlast behandelt, die man pflegt, weil große Kunden sie verlangen. Diese Sicht ist der Grund, warum sie im Plan zuletzt und bei der Verzögerung zuerst kommt.
Das ERP ist ebenfalls nicht das Problem. Ein Unternehmen sollte es ersetzen können, wenn das alte nicht mehr passt, und den Großteil dieses Projekts hat es selbst in der Hand. Was die Entscheidung schwerer macht als nötig, ist, dass das ERP Übersetzungen für Systeme weit über sich selbst hinaus enthält: die Handelspartner, aber auch den Webshop, das Lager und die Spediteure. Werden diese Übersetzungen in eine Integrationsschicht verlagert, trennt das beides, sodass Partner ihren Endpunkt behalten und das ERP wieder ein ERP ist.
Was das Unternehmen bekommt, ist eine Systemlandschaft, die es in seinem eigenen Tempo verändern kann, in der der Austausch des ERP ein Projekt statt einer Verhandlung ist und in der die EDI-Integration das System überdauert, für das sie ursprünglich gebaut wurde.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
