Rollout-Szenarien: Big Bang, Parallel, Phasen

Das System ist fertig, die Daten sind migriert, die Anwender geschult – und jetzt: Wie kommt das neue System zu den Nutzern? Genau hier liegt die entscheidende strategische Wahl: das Rollout-Szenario. Wer alles auf einen Schlag umstellt (Big Bang), spart Aufwand, aber riskiert Chaos. Wer Alt- und Neusystem parallel laufen lässt, hat doppelte Kosten, dafür Sicherheit. Wer in Wellen umstellt, lernt aus jeder Welle – braucht aber viel Zeit. Diese Lektion zeigt dir die vier klassischen Rollout-Szenarien (Big Bang, Parallel-Lauf, Phasen-Rollout, Pilot), wie sie sich unterscheiden und welche Kriterien dir helfen, das richtige für dein Projekt zu wählen.

1) Die vier Rollout-Szenarien im Überblick

Klick durch die Varianten und sieh, wie sie als Verlauf aussehen – mit Stärken und Schwächen:

Rollout-Szenarien visuell

Verwechslung vermeiden: Migration-Strategie (aus L07) beschreibt, wie die Daten ins neue System kommen. Rollout-Szenario beschreibt, wie die Anwender das neue System nutzen. Oft überlappen sich die Begriffe (Big Bang gibt's bei beiden), aber die Entscheidungen sind unabhängig. Du kannst Daten Big-Bang migrieren und gleichzeitig die Anwender in Phasen umstellen, weil das neue System Multi-Tenant ist.

2) Direkter Vergleich der Szenarien

Hier eine Übersicht, wie die vier Szenarien in den wichtigsten Dimensionen abschneiden:

Szenario-Vergleich auf einen Blick

Kriterium	Big Bang	Parallel	Phasen	Pilot
Dauer	sehr kurz	lang	mittel	mittel
Risiko	hoch	niedrig	mittel	niedrig
Initialkosten	niedrig	hoch	mittel	niedrig
Doppel-Aufwand	keiner	groß	temporär	temporär
Rollback einfach?	schwer	einfach	welle-weise	einfach
Lerneffekt	keiner	begrenzt	stark	stark
Support-Last	spitz	mittel	verteilt	verteilt
Geeignet für ...	kleine, klare Systeme	geschäftskritisch	mehrere Standorte	unbekanntes Terrain

Diese Tabelle ist nicht „eine Spalte ist besser als andere" – sondern „für welches Risikoprofil passt was". Ein steuerlich getriebenes ERP-Update (alles muss zum Jahreswechsel da sein) kann nur Big Bang sein. Ein Filialroll-out über 100 Standorte kann nur Phasen sein. Geschäftskritische Anwendung mit unklarem Datenstand → Parallel-Lauf. Mehr in Warum Projekte scheitern.

3) Entscheidungshilfe – welches Szenario passt?

Beantworte die drei Fragen unten und bekomme eine Empfehlung. Es ist keine mathematische Antwort, sondern Orientierung – die echte Entscheidung berücksichtigt mehr Faktoren:

Entscheidungshilfe Rollout

1) Wie kritisch ist das System für das Tagesgeschäft?

2) Wie viele Anwender / Standorte sind betroffen?

3) Wie gut sind die Daten und Anforderungen verstanden?

0 / 3 beantwortet

Auch wenn der Trainer eine Empfehlung gibt – die Endentscheidung ist immer kontext-abhängig. Faktoren, die hier nicht abgefragt sind: vorhandenes Budget, Personalkapazität für Parallel-Lauf, Termin-Druck (steuerlich, regulatorisch), Reife der eigenen Change-Management-Organisation. Eine schlechte Entscheidung in der Rollout-Strategie ist eine der häufigsten Ursachen für IHK-typische „Projekt schief gegangen"-Aufgaben.

4) Hybride Szenarien – die Realität

In der Praxis sind reine Szenarien selten. Stattdessen werden sie kombiniert. Beispiele aus echten Projekten:

Pilot + Phasen: Erst eine Filiale 8 Wochen pilotieren, dann in monatlichen Wellen je 3 weitere Filialen, bis alle umgestellt sind. Standard bei Filialhandel.
Big Bang + Parallel für Reports: Anwender steigen am Stichtag komplett um (Big Bang), aber Reports und Schnittstellen laufen 3 Monate parallel auf beiden Systemen für Datenvergleich. Häufig bei Finanzen / Compliance.
Funktionale Phasen: Erst nur die Stammdaten-Pflege im neuen System, später Bestellprozess, dann Rechnungswesen. Modulares ERP-Rollout.
Geografische Phasen: Erst eine Region (Deutschland), dann andere Länder (Österreich, Schweiz, Frankreich). Internationale Konzerne.
Pilot mit Big Bang Backup: Pilot startet, mit der klaren Option, ihn abzubrechen und beim Altsystem zu bleiben. Falls Pilot erfolgreich: Big-Bang-Rollout für den Rest. Bei kleinen Mittelständlern.

Die Kunst ist, das Szenario zur Organisation passend zu wählen – und es im Lastenheft präzise zu beschreiben, damit beide Vertragsparteien wissen, worauf sie sich einlassen.

5) Beispiel-Rollout-Plan für ein ERP-Projekt

Wie sieht ein konkreter Rollout-Plan aus? Hier ein Beispiel: ein mittelständisches Unternehmen mit Hauptsitz und 6 Außenstellen will ein neues ERP einführen. Gewählt: Pilot + Phasen-Rollout:

Phase	Zeitraum	Inhalt	Erfolgskriterien
Pilot	Mo 1 (4 Wo)	Eine Außenstelle (München, 12 Anwender), volle Funktion	Anwender-Akzeptanz > 80 %, < 5 kritische Tickets, Datenmigration korrekt
Welle 1	Mo 2 (4 Wo)	Hauptsitz Köln (80 Anwender)	Übergang ohne Geschäftsunterbrechung, Tickets < 30/Tag
Welle 2	Mo 3 (3 Wo)	3 weitere Außenstellen (Hamburg, Berlin, Stuttgart)	Wie Welle 1
Welle 3	Mo 4 (3 Wo)	Letzte 2 Außenstellen (Frankfurt, Düsseldorf)	Wie Welle 1
Stabilisierung	Mo 5 (4 Wo)	Hypercare, Bug-Fixing, Optimierung	Ticket-Rate < 5/Tag, keine Kritikalitätsstufe A offen
Abschluss	Mo 6	Altsystem-Abschaltung, Projektabschluss	Alle Daten archiviert, Lessons Learned

Was hier nicht steht, aber wichtig ist: Pufferzeit zwischen den Wellen. Mindestens 1 Woche pro Welle für Auswertung, Anpassungen, Mini-Schulungen. Wer Wellen ohne Puffer plant, schiebt Probleme von Welle zu Welle und verstärkt sie. Mehr in Projektauftrag und Phasen.

6) Risikomanagement im Rollout

Ein Rollout-Plan ohne Risikomanagement ist Wunschdenken. Die häufigsten Risiken und ihre Gegenmaßnahmen:

Risiko	Gegenmaßnahme
Schlüsselmitarbeiter fällt am Cutover-Tag aus	Vertretungsregelung, Wissen verteilt (Pair-Working in Vorbereitung)
Netzwerk fällt aus während Migration	Redundante Verbindung, Offline-Migration-Pfad vorbereitet
Externe Schnittstellen funktionieren nicht	Vorab-Test mit allen Partnern, Notfall-Kontakt bei jedem
Anwender-Akzeptanz mangelhaft	Power-User früh einbinden, Schulungen praxisnah, Hypercare-Hotline
Performance im Live-Betrieb deutlich schlechter als im Test	Last-Test mit realer Datenmenge, Skalierungs-Reserve
Datenmigration unvollständig	Validierungs-Tests (siehe L08), Stichproben, Rollback-Option
Geschäftsausfall durch nicht-funktionierendes Neusystem	Notbetrieb-Plan (manuelle Prozesse für 24 h), Eskalations-Hotline

Wer ein Risiko nicht behandelt, akzeptiert es im Voraus. Das ist eine bewusste Entscheidung – aber sie muss bewusst sein, nicht Versäumnis. Mehr in Warum Projekte scheitern und RTO/RPO.

7) Nach dem Rollout – Lessons Learned

Der eigentliche Rollout endet mit dem Abschluss der letzten Welle – aber das Projekt geht weiter. Wichtige Aktivitäten:

Lessons-Learned-Workshop: 4-6 Wochen nach Abschluss, alle wichtigen Beteiligten zusammen. Was lief gut, was lief schlecht, was würden wir anders machen? Schriftlich festhalten. Siehe Lessons Learned.
Erfolgsmessung gegen Ziele: Wurden die im Lastenheft formulierten Ziele erreicht? Quantifizierbar: KPI-Vergleich vor / nach Einführung.
Anwender-Befragung: Akzeptanz, Verbesserungsvorschläge, Schmerzpunkte. Wichtige Datenquelle für die Roadmap.
Altsystem ordentlich abschalten: Daten archivieren (langjährige Aufbewahrungsfristen!), Lizenzen kündigen, Hardware ausschalten. Mehr in DSGVO-Grundprinzipien.
Dokumentation finalisieren: Alle „TBD"s aus der Doku raus, alle WIPs schließen. Mehr in Warum IT-Dokumentation?.
Übergabe an Linien-Organisation: Projekt-Modus zu Ende, das System ist ab jetzt im normalen IT-Betrieb.

Zusammenfassung

Vier klassische Rollout-Szenarien: Big Bang (Stichtag, alle gleichzeitig – kurz, billig, aber riskant), Parallel-Lauf (Alt+Neu parallel – sicher, aber teuer und langwierig), Phasen/Wellen (stufenweise – Lerneffekt, lange Dauer), Pilot (kleine Gruppe testet, dann Voll-Rollout – niedriges Initialrisiko). Wahl hängt von Kritikalität, Größe, Bekanntheit des Terrains ab. In der Praxis sind hybride Szenarien die Regel (Pilot + Phasen, Big Bang + Parallel für Reports, funktionale/geographische Phasen). Rollout-Plan mit Phasen, Zeitraum, Inhalt, Erfolgskriterien. Pufferzeit zwischen Wellen einplanen. Risikomanagement: Schlüsselmitarbeiter-Vertretung, redundante Netzwerke, externe Schnittstellen vorgetestet, Anwender-Akzeptanz, Performance-Tests, Datenvalidierung, Notbetriebs-Plan. Nach dem Rollout: Lessons Learned, Erfolgsmessung gegen Ziele, Anwender-Befragung, Altsystem ordentlich abschalten, Doku finalisieren, Übergabe an Linien-Organisation.