ERP-Rollout: alle Länder gleichzeitig oder nacheinander?

Für die meisten Mittelständler ist der Wellen-Rollout mit Pilotland der richtige Weg: erst ein repräsentatives Land beweisen, dann in Gruppen ähnlicher Länder ausrollen. Der Big Bang über alle Länder gleichzeitig lohnt nur, wenn ein hartes Datum ihn erzwingt, etwa ein Carve-out oder ein Support-Ende. Er bündelt das gesamte Risiko in einem Wochenende.

Wann ist der Big Bang trotzdem richtig?

Es gibt legitime Gründe für den Start aller Länder am selben Tag: ein Carve-out mit Stichtag, ein auslaufender Altvertrag, ein Support-Ende ohne Verlängerung oder untrennbar verwobene Intercompany-Prozesse, die einen Mischbetrieb unmöglich machen. Dann ist der Big Bang keine Mutprobe, sondern die ehrliche Antwort auf einen Zwang.

Der Preis ist klar: keine Lernkurve, keine zweite Chance, Spitzenlast für Key User in allen Ländern gleichzeitig. Wer den Big Bang wählt, braucht mehr Generalproben, mehr Cutover-Übung und ein belastbares Rückfall-Szenario.

Wenn der Big Bang erzwungen ist, verschiebt sich die Vorbereitung nach vorn statt zu verschwinden. Dann braucht es zwei vollständige Migrations-Testläufe statt einem, eine Cutover-Generalprobe je Land und eine Hypercare-Mannschaft, die zwei Wochen nichts anderes tut.

Der ehrliche Satz dazu lautet: Ein Big Bang ist teurer, nicht schneller. Er spart die Zeit des Mischbetriebs und bezahlt sie mit Vorbereitung und Risiko.

Wie schneidet man die Wellen richtig?

Nicht nach Größe, sondern nach Ähnlichkeit. Länder mit gleichem Geschäftsmodell und ähnlicher Lokalisierung gehören in eine Welle, denn dort wiederholt sich die Arbeit statt sich zu multiplizieren. Ein bewährtes Muster für den DACH-Mittelstand: Welle 1 das Pilotland, Welle 2 die DACH-Nachbarn, Welle 3 Westeuropa, danach die komplexeren Märkte.

• Pilot: repräsentativ, aber nicht der komplexeste Markt und nicht das Headquarter
• Frühe Wellen: hohe Ähnlichkeit zum Pilot, geringe Lokalisierungstiefe
• Späte Wellen: komplexe Lokalisierung, eigene Werke, schwierige Altdaten
• Pro Welle: Erkenntnisse einarbeiten, dann Template einfrieren

Die Länge des Gesamtprogramms ist der Gegenspieler: Wer zu viele kleine Wellen plant, betreibt jahrelang zwei Systemwelten parallel. Jede Welle kostet einen eigenen Cutover, eigene Schnittstellen-Übergangslösungen und eigene Doppelpflege in den Stammdaten.

Was passiert im Mischbetrieb zwischen den Wellen?

Die unbequeme Wahrheit des sequenziellen Rollouts: Zwischen erster und letzter Welle leben Sie mit zwei Systemwelten. Intercompany-Belege laufen über Schnittstellen oder Handarbeit, Konsolidierung braucht Überleitungen, und Stammdaten müssen doppelt gepflegt werden.

Dieser Zwischenzustand gehört geplant wie ein eigenes Teilprojekt: mit klaren Regeln, wer führendes System für welche Daten ist, und mit einem Enddatum. Mischbetrieb, der sich einrichtet, wird zum Dauerzustand.

Konkret gehören drei Dinge festgelegt, bevor die erste Welle live geht: welches System für welches Datenobjekt führend ist, wie Intercompany-Belege zwischen alter und neuer Welt laufen, und wie der Konzernabschluss in dieser Phase entsteht.

Das Enddatum ist dabei nicht Kosmetik. Ohne Datum wird der Mischbetrieb zum Dauerzustand, und Doppelpflege gilt nach zwei Jahren als normal. Wer das Datum verteidigt, spart mehr als jede Optimierung innerhalb der Übergangsphase.

Wer entscheidet die Reihenfolge, und woran erkennt man die falsche?

Die Reihenfolge ist eine Geschäftsentscheidung, keine IT-Entscheidung: Sie verteilt Risiko, bindet Führungskräfte und bestimmt, wann welche Gesellschaft ihre Zahlen aus dem neuen System bekommt. Sie gehört auf Programmebene entschieden, mit dem CFO am Tisch.

Warnsignale für eine falsche Reihenfolge: Der Pilot ist das schwierigste Land und kommt nicht zum Abschluss. Oder die einfachen Länder sind live, aber niemand traut sich an die komplexen, und das Programm schläft ein. In beiden Fällen hilft eine externe Standortbestimmung mehr als eine weitere Planungsrunde.

Ein drittes Warnsignal ist leiser: Wenn die Reihenfolge im Programm nie begründet wurde, sondern sich aus Verfügbarkeiten ergeben hat, ist sie mit hoher Wahrscheinlichkeit falsch. Risikoverteilung entsteht nicht aus Kalenderlogik, sondern aus einer bewussten Entscheidung darüber, welches Land welches Risiko trägt.