Ob eine ERP-Datenmigration als Big Bang oder schrittweise erfolgen sollte, entscheidet sich nicht an der Zahl der Standorte allein. Maßgeblich ist, ob Prozesse, Daten und Verantwortlichkeiten während einer Übergangszeit sauber voneinander getrennt werden können.
Ein Big Bang passt eher, wenn alte und neue Arbeitswelt stark miteinander verbunden sind und ein längerer Parallelbetrieb mehr Risiken erzeugen würde als ein gemeinsamer Wechsel. Eine schrittweise Migration passt eher, wenn sich Werke, Gesellschaften oder Prozessbereiche wirklich abgrenzen lassen und das Unternehmen Erkenntnisse aus einer ersten Welle für die nächsten nutzen möchte.
Damit ist die Entscheidung aber noch nicht vollständig. Besonders gemeinsame Stammdaten, standortübergreifende Aufträge und Änderungen zwischen den einzelnen Go-lives können einen scheinbar einfachen Wellenplan kompliziert machen.
Was Big Bang und schrittweise Migration konkret bedeuten
Bei einem Big Bang wechseln alle vorgesehenen Bereiche zu einem gemeinsamen Termin auf das neue ERP. Das heißt nicht, dass die Daten nur einmal vorbereitet oder getestet werden. Auch ein Big Bang benötigt mehrere Testmigrationen. Lediglich der produktive Wechsel wird gebündelt.
Bei einer schrittweisen Migration erfolgt der produktive Wechsel in mehreren Wellen, zum Beispiel Werk für Werk, Gesellschaft für Gesellschaft oder Prozessbereich für Prozessbereich. Während dieser Zeit arbeiten Teile des Unternehmens bereits im neuen ERP, andere noch im alten System.
SAP nennt neben Big Bang und gestaffelten Einführungen auch Pilot-, Regionen- und vorlagenbasierte Ansätze. Zugleich weist SAP darauf hin, dass die passende Wahl von Reifegrad, Zielen und Einsatzbereitschaft des Unternehmens abhängt. Der entscheidende Zusatz aus Sicht der Datenmigration lautet: Jede gewählte Grenze muss nicht nur organisatorisch, sondern auch in den Daten funktionieren.
Ein Standort ist nicht automatisch eine saubere Migrationsgrenze
Nehmen wir ein Unternehmen mit drei Werken. Jedes Werk hat eigene Bestände und Fertigungsaufträge. Der Materialstamm wird jedoch zentral gepflegt, Kunden bestellen für mehrere Werke und ein Werk liefert Halbfabrikate an ein anderes. Auf dem Organigramm lassen sich die Standorte leicht trennen. In den Geschäftsvorgängen hängen sie trotzdem zusammen.
Geht Werk A zuerst live, müssen deshalb konkrete Fragen beantwortet werden: Wo werden neue Materialien angelegt? Welches System führt während der Übergangszeit den gültigen Kundenstamm? Wie werden Umlagerungen zwischen Werk A im neuen und Werk B im alten ERP gebucht? Was geschieht mit einem Auftrag, der vor dem ersten Go-live begonnen und danach von mehreren Standorten weiterbearbeitet wird?
Bleiben diese Fragen offen, reduziert eine Welle nicht einfach das Risiko. Sie verschiebt es in Übergabeschnittstellen, doppelte Pflege und schwer abstimmbare Datenstände. Darum beginnt die Entscheidung nicht mit „Wie viele Wellen wollen wir?“, sondern mit „Welche Geschäftsvorgänge können während der Übergangszeit ohne widersprüchliche Zustände getrennt werden?“
Wann ein Big Bang die klarere Lösung sein kann
Der größte Vorteil eines gemeinsamen Wechsels ist die eindeutige Systemgrenze. Nach dem Go-live gibt es für den vereinbarten Umfang ein führendes ERP. Gemeinsame Stammdaten müssen nicht über Monate zwischen zwei Arbeitswelten abgeglichen werden, und laufende Prozesse benötigen weniger vorübergehende Verbindungen zwischen Alt und Neu.
Das spricht besonders für einen Big Bang, wenn:
- zentrale Prozesse und Daten stark über Gesellschaften oder Standorte hinweg verbunden sind,
- das alte und das neue ERP nicht sinnvoll parallel zusammenarbeiten können,
- eine vorübergehende doppelte Pflege fachlich oder organisatorisch kaum beherrschbar wäre,
- ausreichend Test-, Entscheidungs- und Unterstützungskapazität für einen gemeinsamen Wechsel bereitsteht.
Der Preis dafür ist eine starke Bündelung. Datenexport, letzte Änderungen, Beladung, Prüfung und Freigabe müssen in einem gemeinsamen Zeitfenster funktionieren. Fehler betreffen nicht nur eine einzelne Welle. Ein Big Bang verlangt deshalb belastbare Testläufe mit vollständigen Datenbeziehungen, realistische Laufzeitmessungen und einen ausführbaren ERP-Cut-over-Plan.
Wichtig ist außerdem: Ein Big Bang wird nicht dadurch sicher, dass der Stichtag früh feststeht. Sicherer wird er, wenn die wiederholten Testläufe zeigen, dass Export, Transformation, Import und fachliche Prüfung innerhalb des vorgesehenen Zeitfensters beherrscht werden.
Wann ein schrittweiser Wechsel besser passt
Eine schrittweise Migration kann den unmittelbaren Umfang eines Go-lives verkleinern. Das Projektteam begleitet zunächst einen begrenzten Bereich, sammelt echte Betriebserfahrung und verbessert den Ablauf vor der nächsten Welle. Für Unternehmen mit vielen Standorten oder begrenzter interner Kapazität kann das entscheidend sein.
Der Ansatz passt besonders gut, wenn Werke oder Gesellschaften weitgehend eigenständige Prozesse haben, lokale offene Vorgänge klar zugeordnet werden können und die Zusammenarbeit zwischen altem und neuem ERP für die Übergangszeit planbar ist. Dann ist die erste Welle nicht nur ein kleinerer Go-live, sondern auch ein belastbarer Lernschritt.
Dieses Lernen hilft allerdings nur, wenn Änderungen in die wiederholbaren Migrationsregeln einfließen. Wird beim ersten Werk beispielsweise erkannt, dass eine Einheit bei bestimmten Materialien falsch umgerechnet wird, muss die Transformationsregel korrigiert, versioniert und erneut getestet werden. Eine manuell reparierte Datei für Werk A verbessert Werk B noch nicht.
Schrittweise bedeutet außerdem mehrere vollständige Freigabepunkte. Jede Welle braucht einen bekannten Quellstand, eine bestimmte Version der Regeln, einen daraus erzeugten Zielbestand und eine fachliche Abnahme. Die Arbeit wird verteilt, aber nicht auf eine einzige Prüfung verkürzt.
Die eigentliche Zusatzaufgabe heißt Zusammenleben von Alt und Neu
Oracle beschreibt als Vorteil des Big Bang, dass keine länger laufenden Verbindungen zu bald abgeschalteten Altsystemen nötig sind. Genau darin liegt umgekehrt die zusätzliche Aufgabe eines schrittweisen Vorgehens: Für die Zeit zwischen den Wellen muss feststehen, welches System welche Information führt und wie notwendige Änderungen weitergegeben werden.
Vier Arten von Daten brauchen dabei besondere Aufmerksamkeit:
- Gemeinsame Stammdaten: Kunden, Lieferanten, Materialien oder Konten werden oft von mehreren Einheiten genutzt. Eine einzige führende Stelle und eine klare Änderungsrichtung verhindern widersprüchliche Varianten.
- Offene Vorgänge: Aufträge, Bestellungen, Fertigungsaufträge und Bestände können über die gewählte Wellengrenze hinauswirken. Sie müssen entweder vollständig einer Welle zugeordnet oder über eine ausdrücklich geplante Übergabe weitergeführt werden.
- Neue und geänderte Daten: Zwischen einer Vorabladung und dem jeweiligen Go-live entstehen weitere Datensätze. Eine Delta-Migration übernimmt diese Veränderungen ab einem festgehaltenen Ausgangsstand.
- Nummern und Schlüssel: Wenn Alt- und Neusystem unterschiedliche Nummern verwenden, brauchen standortübergreifende Prozesse eine verlässliche Verbindung zwischen beiden Welten.
Eine wechselseitige Pflege in beiden Systemen ist nur selten eine einfache Dauerlösung. Je mehr Informationen in beide Richtungen abgeglichen werden müssen, desto stärker schrumpft der Vorteil kleiner Wellen. In manchen Projekten ist dann eine größere, fachlich zusammenhängende Welle sicherer als mehrere künstlich getrennte Teilumstellungen.
Fünf Prüfungen führen zu einer belastbaren Entscheidung
Bevor das Projekt Big Bang oder Wellen festlegt, sollte es einen typischen Geschäftsvorgang durch die geplante Übergangszeit verfolgen. Ein offener Kundenauftrag eignet sich gut: Er verbindet Kunde, Material, Preis, Bestand, Lieferung und Buchung. Bleibt dieser Vorgang innerhalb einer Welle vollständig bearbeitbar, ist die Grenze plausibel. Springt er mehrfach zwischen altem und neuem ERP, entsteht zusätzlicher Übergangsaufwand.
Danach lassen sich fünf Punkte bewerten:
- Fachliche Trennbarkeit: Können die vorgesehenen Bereiche während der Übergangszeit eigenständig arbeiten?
- Führung gemeinsamer Daten: Ist für jeden gemeinsam genutzten Bestand genau ein führendes System benannt?
- Behandlung offener Vorgänge: Lassen sich laufende Geschäfte eindeutig übernehmen, abschließen oder kontrolliert verbinden?
- Wiederholbarkeit: Werden Erkenntnisse aus Test und erster Welle in dieselben Regeln für alle folgenden Wellen übernommen?
- Organisatorische Tragfähigkeit: Reichen Keyuser, IT, Fachbereiche und Partner für einen großen gemeinsamen Wechsel oder für mehrere nacheinander laufende Cut-over?
Kein einzelner Punkt entscheidet allein. Wenn jedoch eine schrittweise Einführung nur mit vielen doppelt gepflegten Stammdaten, vorübergehenden Sonderprogrammen und unklaren offenen Vorgängen funktioniert, ist sie möglicherweise komplexer als der Big Bang. Umgekehrt ist ein gemeinsamer Termin riskant, wenn die Organisation die nötigen Prüfungen und Entscheidungen nicht gleichzeitig bewältigen kann.
Auch eine Mischform braucht eine eindeutige Datenlogik
Zwischen den beiden Grundmodellen sind Mischformen möglich. Ein Unternehmen kann beispielsweise gemeinsame Stammdaten zentral vorbereiten und lokale Bewegungsdaten werkweise übernehmen. Oder es startet mit einem Pilotwerk und fasst die übrigen Standorte später zu größeren Wellen zusammen.
Solche Modelle sind sinnvoll, wenn die Grenze fachlich begründet ist. Sie dürfen aber nicht nur aus einem Kalender entstehen. Für jede Phase muss sichtbar sein, welche Daten bereits produktiv geführt werden, welche noch im Altsystem bleiben, wie Änderungen fließen und welcher Datenstand bei der Abnahme geprüft wird.
Die Zahl der Testläufe ergibt sich ebenfalls nicht pauschal aus der Zahl der Wellen. Jede Welle muss die für sie kritischen Datenbeziehungen schließen. Der Beitrag Wie viele Testmigrationen ein ERP-Projekt braucht zeigt, warum nicht die Laufzahl, sondern das geschlossene Risiko entscheidet.
Die bessere Strategie erzeugt weniger unklare Übergänge
Big Bang und schrittweise Migration sind keine Abstufung von mutig und vorsichtig. Beide verteilen Risiken unterschiedlich. Der Big Bang konzentriert den produktiven Wechsel, vermeidet dafür eine längere Mischwelt. Das Wellenmodell verkleinert einzelne Go-lives und ermöglicht Lernen, verlangt aber eine beherrschbare Daten- und Prozesslogik zwischen Alt und Neu.
Eine gute ERP-Datenmigrationsstrategie wählt deshalb nicht zuerst die angenehmere Bezeichnung. Sie prüft die tatsächlichen Abhängigkeiten und entscheidet dann, welche Variante weniger künstliche Übergaben, weniger widersprüchliche Datenstände und eine realistischere fachliche Abnahme erzeugt.