In diesem Artikel erfahren Sie:
• Warum Standard-Checklisten für die ERP-Bereitschaft die Lieferantendimension übersehen
• Wie ein lieferanteneinschließendes Bereitschafts-Framework in der Praxis aussieht
• Wie Sie einen Go/No-Go-Standard definieren, der das gesamte Handelspartnernetzwerk berücksichtigt
ERP-Migrationen (Enterprise Resource Planning) sind teuer, störend und mit hohem Risiko verbunden. Deshalb investieren Unternehmen enorme Energie in die Definition, wie „bereit“ vor dem Go-Live aussieht. Was die meisten Bereitschafts-Checklisten jedoch nicht
erfassen, ist, ob das Lieferantennetzwerk in der Lage ist, mit dem neuen System zu arbeiten.
Genau dort scheitern Migrationen tatsächlich: in den Wochen danach, wenn lieferantenbedingte Ausnahmefälle in die Ticket-Warteschlangen von Lager, Finanzabteilung und IT kaskadieren. Zu diesem Zeitpunkt gilt das Migrationsprojekt bereits offiziell als abgeschlossen, und die Fehler wirken wie operative Probleme. Der Grund ist
meist derselbe: Die Migration hat die Systemintegrationstests abgeschlossen, die bestätigen, dass die Verbindungen zwischen den Systemen funktionieren, aber nie die Geschäftsprozesstests, die bestätigt hätten, dass reale Supply-Chain-Transaktionen durchgängig korrekt ablaufen.
Eine ehrlichere Definition von Bereitschaft berücksichtigt das Gesamtbild: nicht nur, ob das System intern funktioniert, sondern ob Ihre Handelspartner vom ersten Tag an zuverlässig
damit arbeiten können. Dieser Standard, den man als ERP-Survivability bezeichnen kann, unterscheidet eine Migration, die technisch erfolgreich war, von einer, die sich tatsächlich langfristig bewährt hat.
Was ERP-Bereitschaft tatsächlich misst und was nicht
Für die meisten Einzelhändler ist das ERP das Rückgrat eines vernetzten Systemstapels, der in der Regel Auftragsmanagement-Software (OMS), Lagerverwaltungssoftware (WMS), EDI und die verbindenden Integrationen umfasst. Wenn dieser Stapel gut funktioniert, koordiniert er Einkauf, Fulfillment, Bestand und Finanzen im gesamten Betrieb,
sowohl für den Einzelhändler als auch, in der Folge, für jeden Lieferanten, der mit ihm Geschäfte abwickelt.
Weil dieser Stapel so breit angelegt ist, sind ERP-Migrations-Checklisten in der Regel sehr ausführlich. Systemkonfiguration, Integrationstests, Datenmigration, Cutover-Planung und die interne Nutzerakzeptanz: All diese Bereiche müssen doppelt geprüft werden, um sicherzustellen, dass sie wie vorgesehen funktionieren. Eine Migration, die einen dieser Punkte auslässt, riskiert Probleme, und die Checklisten existieren aus gutem Grund.
Die strukturelle Lücke besteht darin, dass die Checklisten an der Grenze der Systeme des Einzelhändlers enden. Sie messen nicht, wo die Verantwortung der Lieferanten beginnt, wo die Systemdurchsetzung des Einzelhändlers greift, oder ob das Lieferantennetzwerk
darauf vorbereitet wurde, die Anforderungen der neuen Umgebung zu erfüllen. Diese Verantwortungsgrenze, wer wofür zuständig ist und was passiert, wenn ein Lieferant den Erwartungen des neuen Systems nicht gerecht wird, taucht auf einer Migrations-Checkliste meist gar nicht erst auf.
Das Ergebnis ist vorhersehbar: Ein Einzelhändler kann jeden Punkt einer Standard-Checkliste erfüllen und trotzdem mit einem Handelspartner live gehen, der auf eine Änderung der Spielregeln nicht vorbereitet ist.
Die Lieferantenlücke: Wo sie entsteht und was sie kostet
Die Fehlerbilder sind vorhersehbar, sobald man weiß, wonach man suchen muss:
• Lieferanten, die EDI-Dokumente weiterhin nach alten Spezifikationen zuordnen, weil ihnen niemand mitgeteilt hat, dass die neuen bereits live sind
• DESADV-Formate, die den neuen WMS-Validierungsregeln nicht entsprechen und dadurch Ausnahmefälle am Wareneingang verursachen
• Artikel- und EAN/GTIN-Daten, die nicht mit dem neuen Artikelstamm übereinstimmen und dadurch den PO-Abgleich weiter unten in der Kette stören
Besonders kostspielig ist, dass diese Probleme zunächst nicht auf den ERP-Dashboards sichtbar sind. Bis die Fehler auf Systemebene sichtbar werden, sind sie bereits zu operativen Problemen geworden, und das Migrationsprojekt ist abgeschlossen.
Wenn die Bereitschaft der Lieferanten als Nebensache behandelt wird, enden hochqualifizierte IT-Mitarbeiter und Integrationsspezialisten damit, Streitigkeiten mit
Lieferanten zu vermitteln. Das ist eine teure Kapazitätanpassung, und sie summiert sich, je länger die Ausnahmefälle ungelöst bleiben.
Außerdem untergräbt dies die allgemeine wirtschaftliche Rechtfertigung für die Migration an sich. Viele ERP-Erneuerungen sind an Analytics- oder KI-Initiativen gekoppelt, Investitionen, die voraussetzen, dass saubere, zugängliche und vertrauenswürdige Daten durch das neue System fließen. Dieses Fundament bricht sofort, wenn die Lieferantenlücke beim Start noch besteht. Die KI-Initiative ist nur so gut wie die Lieferantendaten, die sie speisen, und lieferantenbedingte Ausnahmefälle verfälschen diese Daten von Anfang an.
Diese Probleme sehen wie Lieferantenprobleme, Betriebsprobleme und Finanzprobleme aus. Doch sie treten erst in den Wochen nach dem Go-Live auf, wenn das Zeitfenster, sie unauffällig zu beheben, bereits geschlossen ist.
Warum die Lieferantenbereitschaft nachrangig behandelt wird
Lieferanten-Onboarding, Dokumenten-Compliance und EDI-Support liegen in der Regel bei anderen Teams als denen, die das ERP-Projekt leiten. Sie stehen nicht im offiziellen Umfang der Migration, berichten nicht an denselben Projektleiter und werden nicht anhand
derselben Meilensteine verfolgt. Deshalb werden sie als Folgearbeit eingeplant, als etwas, das nach dem Go-Live aufgeräumt wird, sobald die eigentliche Migration abgeschlossen ist.
Die Annahme hinter dieser Reihenfolge ist, dass etwaige Ausfälle auf Lieferantenseite isoliert und beherrschbar bleiben. In der Praxis kaskadieren sie. Ein Lieferant, der falsch
formatierte DESADV's versendet, verursacht Ausnahmefälle im gesamten Wareneingang eines Verteilzentrums. Multipliziert man das über die gesamte Lieferantenbasis, während die Teams bereits stark ausgelastet sind und das System noch stabilisiert wird, wächst das Risiko schnell.
Das tiefere Problem ist, dass das Aufschieben der Lieferantenbereitschaft ein Vetorisiko schafft. Wenn die Lieferantenebene bis spät im Projektzyklus außer Betracht bleibt, tauchen Probleme, die während der Planung hätten gelöst werden können, stattdessen im
ungünstigsten Moment als nicht mehr umkehrbare technische Risiken auf. An diesem Punkt muss der CIO entscheiden: das Projekt verzögern oder Ausfälle in Kauf nehmen, deren Beseitigung Monate dauern wird.
Wie ein lieferanteninklusives Bereitschafts-Framework aussieht
Bereitschaft neu zu definieren bedeutet, Kriterien auf Lieferantenseite in dieselbe Checkliste wie die internen Meilensteine aufzunehmen. Die einzelnen Bestandteile sind nicht kompliziert, müssen aber ausdrücklich eingeplant werden:
• Zielvorgaben für den Abschluss des Lieferanten-Onboardings vor der Umstellung, mit ausreichend Vorlaufzeit für Tests und Nachbesserung.
• Validierung der Dokumenten-Compliance anhand der Spezifikationen des neuen Systems, um vor dem Go-Live zu bestätigen, dass Lieferanten die richtigen EDI-Versionen und -Formate verwenden.
• Geschäftsprozesstests, die über reine Konnektivitätsprüfungen hinausgehen und vollständige Supply-Chain-Workflows unter realen Bedingungen verifizieren (zum Beispiel tatsächliche Bestellungen, DESADVs und Rechnungen, die durchgängig gegen die neue Umgebung verarbeitet werden).
• Parallelbetriebsplanung, die Lieferantentransaktionstests während der Parallelphase einschließt, damit Fehler vor der Umstellung sichtbar werden und nicht erst danach.
• Im Voraus definierte Protokolle für den Umgang mit Ausnahmefällen, mit klarer Zuständigkeit dafür, wer Probleme auf Lieferantenseite löst und wie.
• Ein Kommunikationsplan für Lieferanten, der direkt an den Umstellungszeitplan gekoppelt ist, damit Handelspartner wissen, was sich wann ändert und was von ihnen erwartet wird.
Datenqualität verdient hier besondere Aufmerksamkeit. Saubere, zugängliche Lieferantendaten (korrekte Artikeldatensätze, aktuelle Handelspartnerprofile, validierte EDI-Zuordnungen) sind eine Voraussetzung dafür, dass das neue System korrekt funktioniert. Sie bilden zudem die Grundlage für jede Analytik, die mit der Migration verknüpft ist. Wenn diese Daten beim Start nicht vertrauenswürdig sind, sind es die darauf aufbauenden Investitionen ebenfalls nicht.
Was „bereit“ wirklich bedeutet
Ein ehrlicherer Go/No-Go-Standard stellt andere Fragen: Können Ihre Lieferanten Bestellungen bestätigen, konforme DESADVs senden und korrekte Rechnungen gegen die neue Umgebung einreichen, und zwar vom ersten Tag an? Ist die Antwort ungewiss, ist
die Migration nicht bereit, unabhängig davon, was die interne Checkliste aussagt.
Der Wert des ERP als Systemgrundlage hängt vollständig von der Qualität der Daten ab, die in es einfließen. Lieferantenbedingte Ausnahmefälle verfälschen diese Grundlage,
untergraben das Reporting und erodieren die Datenbasis, auf der Analytics- und KI-Initiativen aufbauen.
Es gibt einen praktischen Test dafür, ob ein Netzwerk tatsächlich bereit ist: Hat die IT Kapazität für Modernisierungsprojekte, oder wird sie weiterhin von Lieferantenausnahmen
aufgezehrt?
Ein System ist nicht bereit, wenn der CIO um zwei Uhr morgens wegen eines Problems angerufen wird, das ein Lieferant drei Tage zuvor verursacht hat. Das ist die Lieferantenlücke, weiterhin offen, nur von außen schwerer zu erkennen.
Gehen Sie nicht mit einer schließbaren Lücke live
SPS Commerce bietet vorgefertigte EDI-Integrationen für die ERP-, OMS- und WMS-Systeme, die bereits Teil Ihres Systemstapels sind, darunter SAP, Oracle, Microsoft Dynamics, NetSuite und weitere, sodass Lieferantentransaktionen vom ersten Tag an gegen Ihre neue Umgebung validiert und automatisiert werden.
Wenn Sie sich mitten in einer ERP-Migration befinden und die Lieferantenbereitschaftslücke vor der Umstellung schließen möchten, informieren Sie sich über SPS Commerce Integrationen.