Bei einem ERP-Rollout über mehrere Standorte darf die Datenmigration weder für jedes Werk neu erfunden noch unverändert kopiert werden. Ein bloßes Kopieren übersieht lokale Quellen und Besonderheiten. Ein vollständiger Neustart verschenkt dagegen das Wissen aus bereits abgeschlossenen Wellen.
Planbar wird der Rollout durch einen gemeinsamen Migrationskern und einen klar begrenzten Standortzusatz. Der Kern enthält die bestätigten Zielanforderungen, gemeinsamen Mapping- und Umwandlungsregeln, technischen Abläufe sowie Prüfungen. Der Standortzusatz beschreibt nur, was am jeweiligen Werk tatsächlich anders ist: Quellen, organisatorische Werte, lokale Ausnahmen, Verantwortliche und Cut-over-Termin.
Damit dieses Modell funktioniert, müssen Erkenntnisse aus jeder Welle bewusst eingeordnet werden. Nicht jede Besonderheit des Pilotwerks gehört in den gemeinsamen Kern. Umgekehrt darf ein Fehler in einer zentralen Regel nicht nur in der letzten Datei eines Standorts repariert werden.
Ein gemeinsamer Kern ist mehr als die Importvorlage des ersten Werks
Viele Rollouts beginnen mit einem Pilotstandort. Nach dessen Go-live wird der Projektordner kopiert und für Werk zwei angepasst. Das wirkt zunächst schnell. Nach wenigen Wellen liegen jedoch verschiedene Mappingdateien, Skripte und Importvorlagen nebeneinander. Niemand kann sicher sagen, welche Verbesserung zentral gilt und welche Änderung nur wegen eines lokalen Sonderfalls entstanden ist.
Ein wiederverwendbarer Migrationskern besteht deshalb aus verbundenen Ergebnissen:
- einer gemeinsamen Beschreibung der Zielobjekte und benötigten Informationen,
- bestätigten Regeln für gemeinsame Felder und Werte,
- einem reproduzierbaren technischen Weg vom Export bis zur aktuellen Importdatei,
- festen Mengen-, Wert- und Beziehungsprüfungen sowie
- klaren Übergaben zwischen Datenmigration, ERP-Team, Standort und Fachbereichen.
„Reproduzierbar“ bedeutet: Aus demselben bekannten Quellstand und derselben Regelversion entsteht erneut dasselbe Ergebnis. Manuelle Korrekturen in einer einzelnen Importdatei erfüllen dieses Merkmal nicht. Sie helfen vielleicht dem aktuellen Werk, gehen aber als unsichtbare Abweichung in die nächste Welle ein.
Der Materialstamm zeigt den Unterschied zwischen Kern und Standort
Ein Material kann unternehmensweit dieselbe Identität, Beschreibung und Basiseinheit haben. Trotzdem benötigt jedes Werk eigene Angaben, zum Beispiel Disposition, Beschaffungsart, Lagerorte, Produktionssteuerung oder Bewertung. Ein zentraler Materialkern und lokale Werkssichten gehören deshalb zusammen.
Für den Rollout bedeutet das:
Der gemeinsame Kern regelt, wie eine Materialidentität erkannt wird, welche allgemeinen Merkmale ins Ziel kommen, wie alte und neue Schlüssel verbunden werden und welche zentralen Werte zulässig sind.
Der Standortzusatz benennt die Quelle der Werkssichten, lokale Wertübersetzungen, benötigte Lager- und Dispositionsangaben sowie die verantwortlichen Keyuser des Werks.
Diese Trennung verhindert zwei gegensätzliche Fehler. Ohne gemeinsamen Kern entstehen je Standort unterschiedliche Definitionen desselben Materials. Ohne Standortzusatz wird ein technisch zentraler Materialstamm geladen, der vor Ort nicht beschafft, geplant, produziert oder gelagert werden kann.
Dasselbe Grundmodell gilt für weitere Objekte. Kunden besitzen allgemeine Identitätsdaten und lokale Vertriebs- oder Gesellschaftssichten. Lieferanten verbinden eine gemeinsame rechtliche Einheit mit unterschiedlichen Einkaufs- und Zahlungsangaben. Der Kern beschreibt die gemeinsame Logik; der Standort ergänzt die fachlich begründete Abweichung.
Das Pilotwerk liefert Messwerte – aber nicht automatisch die endgültige Vorlage
Ein Pilotstandort sollte ausreichend repräsentativ sein, damit das Projekt echte Datenbeziehungen, typische Mengen und reale Entscheidungswege kennenlernt. Das einfachste kleine Werk kann zwar schnell live gehen, liefert aber möglicherweise wenig Wissen für größere Produktionsstandorte. Umgekehrt überfordert ein besonders komplizierter Ausnahmebetrieb das erste Team.
Der Pilot beantwortet vor allem Fragen, die vorher nur angenommen werden konnten: Wie lange dauern Export, Umwandlung und Import? Welche Zielpflichtfelder werden mit echten Daten problematisch? Wie schnell entscheiden die Keyuser? Welche Prüfungen finden tatsächlich fehlende oder falsch verbundene Daten? Welche Aufgaben liegen zwischen ERP-Anbieter, zentralem Projekt und Standort?
Diese Erkenntnisse machen die nächste Welle nur dann besser, wenn sie in den gemeinsamen Ablauf zurückfließen. Ein korrigiertes Material im Zielsystem ist noch kein Lerneffekt für den Rollout. Erst die angepasste, getestete Regel sorgt dafür, dass derselbe Fall an allen folgenden Standorten richtig behandelt wird.
Jede Erkenntnis braucht genau eine von drei Einordnungen
Nach einem Test oder Go-live tauchen neue Anforderungen und Fehler auf. Für einen schlanken Rollout reicht eine einfache Einordnung:
- Änderung des gemeinsamen Kerns: Die bisherige Regel war allgemein falsch oder unvollständig. Sie wird zentral korrigiert, geprüft und gilt für alle kommenden Wellen.
- Genehmigte Standortausnahme: Das Werk hat eine fachlich notwendige Abweichung, die andere Standorte nicht betrifft. Sie wird als lokale Ergänzung geführt, ohne die zentrale Regel zu verändern.
- Einmalige Datenkorrektur: Die Ursache liegt in einem konkreten fehlerhaften Ausgangsdatensatz. Die Korrektur erfolgt möglichst in der Quelle oder über eine nachvollziehbare Bereinigungsregel, ohne daraus eine allgemeine Zielregel abzuleiten.
Diese Einordnung verhindert, dass eine Gewohnheit des Pilotwerks versehentlich zum Unternehmensstandard wird. Sie verhindert ebenso, dass ein allgemeiner Fehler an jedem Standort erneut entdeckt und lokal repariert werden muss.
Wenn sich das Zielsystem während des Rollouts verändert, braucht dieselbe Logik eine zusätzliche Wirkungskontrolle. Ein neues Pflichtfeld kann den gemeinsamen Kern betreffen; eine neue Werkseinstellung vielleicht nur einzelne Wellen. Der Beitrag Was bei Änderungen im Zielsystem mit dem Datenmapping geschieht zeigt, wie diese Auswirkungen kontrolliert werden.
Eine kurze Versionskette ersetzt unübersichtliche Ordnerkopien
Für jede Welle muss nachvollziehbar sein, welcher Stand tatsächlich getestet und freigegeben wurde. Dafür ist kein schweres zusätzliches Migrationstool zwingend nötig. Entscheidend ist eine einfache Versionskette, die fünf Dinge miteinander verbindet:
Quellstand → Mappingstand → Umwandlungslogik → Importvorlage → Prüfergebnis
Vor einem Standorttest wird diese Kette festgehalten. Ändert sich danach eine zentrale Regel, erhält der Kern eine neue Version. Die nächste Welle verwendet nicht irgendeine kopierte Datei, sondern genau den freigegebenen Stand. Gleichzeitig bleibt sichtbar, ob ein bereits produktiver Standort von einer später entdeckten zentralen Korrektur betroffen sein könnte.
Das ist besonders wichtig, wenn mehrere Wellen zeitlich überlappen. Werk drei kann bereits Daten vorbereiten, während Werk zwei noch testet. Ohne klaren Stand übernimmt Werk drei möglicherweise eine halbfertige Änderung. Mit einer freigegebenen Kernversion kann die Vorbereitung weiterlaufen, während neue Erkenntnisse kontrolliert in den nächsten vorgesehenen Stand gelangen.
Ein Standort ist erst bereit, wenn seine Datenstrecke vollständig funktioniert
Ein zugesagter Termin oder eine ausgefüllte Importvorlage beweist noch keine Standortbereitschaft. Vor dem produktiven Wechsel sollten mindestens folgende Ergebnisse vorliegen:
- Die für das Werk benötigten Datenobjekte und bewussten Ausschlüsse sind bestätigt.
- Alle Quellen sind zugänglich, und der Export lässt sich mit einem bekannten Stichtag wiederholen.
- Gemeinsame Regeln und genehmigte Standortausnahmen sind in einer eindeutigen Version umgesetzt.
- Ein Test mit eigenen Daten hat Mengen, Werte, Beziehungen und wichtige Geschäftsprozesse geprüft.
- Offene Fehler besitzen Verantwortliche, Fristen und eine klare Entscheidung über ihre Bedeutung für den Go-live.
- Der Cut-over wurde mit realistischen Laufzeiten, letzten Änderungen und fachlichen Freigaben vorbereitet.
Besonders der Test mit eigenen Daten ist nicht durch eine erfolgreiche vorherige Welle ersetzbar. Die zentrale Regel kann stimmen, während im neuen Werk eine zusätzliche Quelltabelle fehlt, ein lokaler Code anders belegt ist oder ein bisher unbekannter Sonderfall vorkommt. Wie Keyuser reale Zusammenhänge im Ziel prüfen, beschreibt der Beitrag zur ERP-Testmigration mit eigenen Daten.
Mehrere Standort-Cut-over brauchen einen gemeinsamen Takt
Jedes Werk benötigt einen eigenen ausführbaren Ablauf für Datenstopp, letzte Exporte, Umwandlung, Import, Prüfung und Freigabe. Gleichzeitig teilen die Wellen häufig knappe Ressourcen: dieselbe Zielumgebung, denselben ERP-Anbieter, zentrale Fachverantwortliche und das Datenmigrationsteam.
Darum dürfen Standorttermine nicht unabhängig voneinander geplant werden. Zwischen zwei Wellen muss ausreichend Zeit liegen, um Erkenntnisse zu bewerten, zentrale Regeln anzupassen, die nächste Kernversion zu testen und das vorherige Werk zu stabilisieren. Werden zu viele Wellen parallel gestartet, verliert der Rollout genau den Lernvorteil, für den das schrittweise Vorgehen gewählt wurde.
Eine zentrale Programmübersicht braucht dafür keine tausend Einzelaufgaben. Sie sollte je Welle zeigen: verwendete Kernversion, lokale Ergänzungen, aktueller Teststand, offene Go-live-Hindernisse, geplantes Zeitfenster und benannte Freigabeverantwortliche. Die genaue Reihenfolge jedes Produktivwechsels gehört anschließend in den jeweiligen ERP-Cut-over-Plan.
Der nächste Standort darf nicht nur schneller, sondern muss sicherer werden
Ein erfolgreicher ERP-Rollout zeigt sich nicht daran, dass jede Welle exakt gleich aussieht. Er zeigt sich daran, dass gemeinsame Arbeit nicht wiederholt werden muss und lokale Unterschiede trotzdem früh sichtbar werden.
Der gemeinsame Migrationskern sorgt für stabile Zielbedeutungen, wiederholbare Regeln und gleiche Prüfmaßstäbe. Der Standortzusatz begrenzt die echten lokalen Aufgaben. Eine klare Einordnung neuer Erkenntnisse hält beides auseinander. So wird aus dem Pilot kein starres Muster, sondern eine wachsende, kontrollierte Grundlage für die folgenden Werke.
Falls die grundsätzliche Entscheidung zwischen einem gemeinsamen Go-live und mehreren Wellen noch offen ist, sollte sie vorher geklärt werden. Der Beitrag Big Bang oder schrittweise ERP-Migration ordnet diese vorgelagerte Strategiewahl ein.
ERP-Rollout über mehrere Standorte: Planbar durch Kern, Zusatz und Freigabestand
Die leichtgewichtige Lösung besteht nicht in einer eigenen Methodik für jedes Werk. Sie besteht aus einem geprüften gemeinsamen Kern, einem kleinen Standortprofil und einer eindeutigen Version je Test und Go-live.
Damit wird jede Welle vollständig genug für eine eigene fachliche Abnahme und zugleich anschlussfähig an das Wissen der vorherigen Standorte. Genau so bleibt die Datenmigration über mehrere Werke hinweg effizient, ohne lokale Realität oder zentrale Nachvollziehbarkeit zu verlieren.