4. Rollout-Strategien

Lernziele

Nach diesem Kapitel können Sie: - Die verschiedenen Einführungsstrategien beschreiben und voneinander abgrenzen - Für ein gegebenes Projekt die passende Rollout-Strategie auswählen und begründen - Vor- und Nachteile jeder Strategie bewerten - Rollout-Risiken identifizieren und Gegenmaßnahmen ableiten - Rollout-Planung systematisch durchführen - Die Strategie-Auswahl mit Stakeholdern kommunizieren

Modul Übersicht

Modul 11 - Kapitel 4 Lesezeit: ~15-20 Min Quelle: 11 - Projektsteuerung in IT-Projekten.pdf, FS-ITB-11_Steuerung-01_v0c.pdf

1. Einführung: Die Bedeutung der Rollout-Strategie

1.1 Warum die Strategie entscheidend ist

Der Rollout einer neuen bzw. geänderten IT-Lösung ist ein entscheidender Schritt bei der Einführung im Unternehmen. Die Wahl der richtigen Strategie kann über Erfolg oder Misserfolg des Projekts entscheiden.

Erfolgsentscheidung

"Ein schlecht geplanter Rollout kann ein ansonsten erfolgreiches Projekt zum Scheitern bringen. Die Strategie ist wichtiger als die Technologie."

1.2 Risiken eines schlecht geplanten Rollouts

Risikoart	Beispiele	Konsequenz
Betriebsausfall	System ist nach Go-Live nicht verfügbar	Verlust von Umsatz, Kundenunzufriedenheit
Datenverlust	Datenverlust bei Migration	Finanzielle Schäden, Compliance-Verletzungen
Akzeptanzprobleme	Anwender lehnen neue Lösung ab	System wird nicht genutzt, Investition verloren
Performance-Probleme	System ist zu langsam	Produktivitätsverlust, Frust der Anwender
Funktionale Mängel	Kritische Funktionen fehlen oder sind fehlerhaft	Prozessstopps, manuelle Workarounds
Kostenüberschreitung	Rollout dauert länger und kostet mehr als geplant	Budgetüberschreitung, Verlust von Management-Vertrauen

1.3 Kontext im Projektzyklus

timeline
    title Rollout im Projektzyklus
    section Vorbereitung
        Entwicklung & Test : Realisierung und Qualitätssicherung
        Rollout-Planung : Strategie-Auswahl, Detailplanung
    section Rollout (FOKUS)
        Rollout-Vorbereitung : Schulungen, Daten- vorbereitung
        Go-Live : Produktivstart
        Hypercare : Intensive Nachbetreuung
    section Nachbereitung
        Nachbetreuung : Stabilisierung
        Übergabe an Betrieb : Wartung & Support

2. Die fünf Haupt-Strategien

2.1 Übersicht der Strategien

Es gibt fünf grundlegende Einführungsstrategien, die je nach Projekt und Situation ausgewählt werden können:

mindmap
  root((Rollout-Strategien))
    Big Bang
      Stichtagseinführung
      Alle gleichzeitig
    Pilotierung
      Testlauf in Teilbereich
      Lernen & Anpassen
    Sukzessiv
      Schrittweise Einführung
      Zeitlich gestaffelt
    Paralleleinführung
      Altes und neues parallel
      Höchste Sicherheit
    Sandbox
      Isolierte Laufzeitumgebung
      Test vor Live

2.2 Entscheidungsmatrix für Strategie-Auswahl

Faktor	Big Bang	Pilotierung	Sukzessiv	Parallel	Sandbox
Zeit	Schnellster Start	Mittel	Langsamster	Langsam	Mittel
Komplexität	Hoch (alles gleichzeitig)	Mittel	Gering	Sehr hoch	Gering
Risiko	Höchstes Risiko	Mittleres Risiko	Geringes Risiko	Geringstes Risiko	Sehr gering
Ressourcen	Hoch (Peak bei Go-Live)	Mittel	Gering (verteilt)	Sehr hoch (2 Systeme)	Gering
Kosten	Gering (einmalig)	Mittel	Mittel	Hoch (2 Systeme parallel)	Mittel
Benutzerbelastung	Hoch (alle gleichzeitig)	Gering (nur Pilot)	Gering (verteilt)	Sehr hoch (2 Systeme)	Gering
Flexibilität	Gering	Hoch	Hoch	Mittel	Hoch
Rollback-Möglichkeit	Schwierig	Einfach	Einfach	Einfach	Einfach

3. Big Bang (Stichtagseinführung)

3.1 Definition

Die Stichtagseinführung (Big Bang) bedeutet, dass die Umstellung des neuen Verfahrens zu einem festen Zeitpunkt für alle Benutzer gleichzeitig erfolgt.

Charakteristik

"Big Bang" - Alles auf einmal. Am Stichtag wird das alte System abgeschaltet und das neue System gestartet.

3.2 Wann ist Big Bang sinnvoll?

Bedingung	Beispiel
Gesetzliche Vorgaben	Anwendung einer neuen gesetzlichen Regelung zum 01.01.
Dringlichkeit	System muss aufgrund von Compliance-Gründen zwingend bis zu einem Datum eingesetzt werden
Einfache Systeme	Systeme mit geringer Komplexität und wenigen Benutzern
Keine Parallelbetriebs-Möglichkeit	Altes und neues System können nicht parallel betrieben werden
Eindeutiger Schnitt	Klare, unumkehrbare Entscheidung

3.3 Beispiel: Gesetzliche Lohnabrechnung

Ein Unternehmen muss ab dem 01. Januar eine neue gesetzlich vorgeschriebene Lohnabrechnungssoftware nutzen.

Aspekt	Details
Gesetzliche Vorgabe	Neue gesetzliche Regelung zum Datum X
Zwang zur Einführung	Keine Option für sukzessive oder parallele Einführung
Strategie	Big Bang zum Stichtag
Vorbereitung	Intensive Tests, Backup-Strategie, Notfallplan
Risiko	Hoch - bei Problemen Auswirkungen auf Lohnabrechnung aller Mitarbeiter
Gegenmaßnahmen	Testlauf mit Testdaten, Intensive Hypercare, Hotline

3.4 Vor- und Nachteile

Vorteile	Nachteile
Klarer Schnitt	Keine Mischung alter und neuer Prozesse
Kosteneffizient	Nur ein System muss betrieben werden
Schnell	Alle Benutzer arbeiten ab Tag 1 mit dem neuen System
	Schwieriger Rollback
	Hohe Ressourcenspitze
	Hohe Benutzerbelastung
	Keine Lernerfahrung

3.5 Best Practices für Big Bang

Best Practice	Beschreibung
Umfassende Tests	Alle Szenarien vor Go-Live testen
Backup-Strategie	Vollständige Backups des alten Systems
Notfallplan	Detaillierter Notfallplan mit Eskalationspfaden
Rollback-Plan	Möglichkeit zur schnellen Rückkehr zum alten System
Intensive Hypercare	Aufgestelltes Hypercare-Team für die ersten Tage
Vorbereitende Schulung	Alle Benutzer vor Go-Live schulen
Kommunikation	Klare Kommunikation an alle Beteiligten
Go-Live-Team	Spezielles Team für den Go-Live-Tag

4. Pilotierung

4.1 Definition

Bei der pilotierten Einführung wird das neue System in einer Region, Abteilung oder einem Funktionsbereich als Pilot getestet. Die gewonnenen Erfahrungen können genutzt werden, um Prozesse, Abläufe und Planungen anzupassen.

Charakteristik

"Lernen durch Tun" - Ein Teilbereich als Pilot, Erfahrungen sammeln, dann Rollout auf alle Bereiche.

4.2 Formen der Pilotierung

Form	Beschreibung	Beispiel
Regionale Pilotierung	Pilot in einer Region oder einem Standort	ERP-Rollout zunächst am Standort München, dann Berlin und Hamburg
Funktionale Pilotierung	Pilot für einen Funktionsbereich bei allen Benutzern	Einführung des Moduls "Rechnungswesen" im gesamten Unternehmen
Benutzer-Gruppen-Pilotierung	Pilot mit einer Benutzergruppe	Key User und Power-User nutzen das neue System zuerst
Prozess-Pilotierung	Pilot für einen Geschäftsprozess	Einführung des Prozesses "Bestellung" im Einkauf

4.3 Vorteile der Pilotierung

Vorteil	Erklärung
Risikominimierung	Probleme im Pilot-Entdeckung verhindern Ausfälle im Rollout
Lernerfahrung	Erfahrungen aus Pilot nutzen, um System zu verbessern
Nutzerverhalten analysieren	Verständnis für Reaktionen und Bedarfe der Anwender
Technische Umsetzbarkeit prüfen	Überprüfung, ob System technisch funktioniert
Schulung optimieren	Lernen, was in der Schulung besser gemacht werden kann
Training für Rollout-Team	Rollout-Team gewinnt Erfahrung vor dem Haupt-Rollout
Ressourcen-Management	Ressourcen werden besser verplant nach Piloterfahrungen

4.4 Nachteile der Pilotierung

Nachteil	Erklärung
Zeitaufwand	Gesamtdauer des Projekts verlängert sich
Doppelte Arbeit	Daten und Prozesse müssen eventuell doppelt geführt werden
Komplexität	Management von Pilot- und Nicht-Pilot-Bereichen
Kommunikations-Herausforderung	Unterschiedliche Systeme für verschiedene Benutzer
Potentielle Enttäuschung	Wenn Pilot nicht gut läuft, kann das Projekt in Verruf kommen
Anpassungsaufwand	Änderungen nach Pilot erfordern zusätzliche Arbeit

4.5 Beispiel: ERP-Einführung mit Pilot

Ein mittelständisches Unternehmen führt ein neues ERP-System ein.

Phase	Beschreibung	Dauer
Vorbereitung	Auswahl Pilot-Standort, Vorbereitung Testdaten	4 Wochen
Pilot-Go-Live	Produktivstart am Pilot-Standort (100 Benutzer)	Tag 0
Hypercare Pilot	Intensive Nachbetreuung am Pilot-Standort	2 Wochen
Erfahrungen sammeln	Dokumentation von Learnings, Verbesserungsvorschlägen	1 Woche
Anpassung	Implementierung von Verbesserungen aus Pilot	2 Wochen
Haupt-Rollout 1	Rollout auf Standort 2 (200 Benutzer)	1 Woche
Haupt-Rollout 2	Rollout auf Standort 3 (150 Benutzer)	1 Woche
Hypercare alle	Intensive Nachbetreuung aller Standorte	3 Wochen

4.6 Best Practices für Pilotierung

Best Practice	Beschreibung
Sorgfältige Auswahl des Pilot-Bereichs	Typischer, repräsentativer Bereich
Realistische Bedingungen	Pilot sollte unter realistischen Bedingungen stattfinden
Aktives Lernen	Systematische Erfassung von Erfahrungen und Verbesserungen
Schnelle Anpassung	Verbesserungen aus Pilot zügig umsetzen
Kommunikation der Learnings	Transparente Kommunikation der Ergebnisse
Vergleichsgruppe definieren	Nicht-Pilot-Bereiche als Kontrollgruppe
Mitarbeiter einbinden	Pilot-Teilnehmer aktiv bei Verbesserungen einbinden
Exit-Kriterien definieren	Wann ist Pilot erfolgreich?

5. Sukzessive Einführung (Step by Step)

5.1 Definition

Die sukzessive Einführung (step by step) bedeutet, dass die Umstellung auf das neue Verfahren zeitlich gestaffelt erfolgt. Der Zweck ist die Vermeidung der Überbeanspruchung von Personal oder Ressourcen.

Charakteristik

"Schritt für Schritt" - Phasenweise Einführung, Ressourcen und Teams werden geschont.

5.2 Formen der sukzessiven Einführung

Es gibt drei Hauptformen der sukzessiven Einführung:

5.2.1 Vertikaler Rollout (Regional gestaffelt)

Ein Benutzer oder eine Benutzergruppe führt alle Funktionen des Anwendungssystems ein.

graph LR
    A[Zeit] --> B[Phase 1<br/>Standort München]
    B --> C[Phase 2<br/>Standort Berlin]
    C --> D[Phase 3<br/>Standort Hamburg]
    D --> E[Alle Standorte]

    style B fill:#e3f2fd
    style C fill:#fff9c4
    style D fill:#ffecb3
    style E fill:#c8e6c9

Beispiel: ERP-System in der Buchhaltung am Standort München, dann Berlin, dann Hamburg

5.2.2 Horizontaler Rollout (Funktional gestaffelt)

Ein Funktionsbereich des Anwendungssystems wird bei allen Benutzern eingeführt.

graph LR
    A[Zeit] --> B[Phase 1<br/>Modul: Stammdaten<br/>bei allen]
    B --> C[Phase 2<br/>Modul: Bestellung<br/>bei allen]
    C --> D[Phase 3<br/>Modul: Rechnungswesen<br/>bei allen]
    D --> E[Alle Module]

    style B fill:#e3f2fd
    style C fill:#fff9c4
    style D fill:#ffecb3
    style E fill:#c8e6c9

Beispiel: Stammdatenverwaltung des ERP-Systems bei allen Benutzern, dann Bestellwesen, dann Rechnungswesen

5.2.3 Prozessorientierter Rollout

Ein Geschäftsprozess des Anwendungssystems wird bei allen Benutzern eingeführt.

graph LR
    A[Zeit] --> B[Phase 1<br/>Prozess: Eingangsrechnung]
    B --> C[Phase 2<br/>Prozess: Ausgangsrechnung]
    C --> D[Phase 3<br/>Prozess: Lohnabrechnung]
    D --> E[Alle Prozesse]

    style B fill:#e3f2fd
    style C fill:#fff9c4
    style D fill:#ffecb3
    style E fill:#c8e6c9

Beispiel: Prozess "Bearbeitung Eingangsrechnungen" bei allen Benutzern, dann "Ausgangsrechnungen", dann "Lohnabrechnung"

5.3 Vor- und Nachteile

Vorteile	Nachteile
Ressourcen-schonend	Keine Überlastung an einem einzigen Zeitpunkt
Kleinere Fehlerauswirkung	Probleme nur in einer Phase
Lernerfahrung	Erfahrungen aus früheren Phasen nutzen
Bessere Steuerung	Schrittweises Vorgehen erlaubt besseres Controlling
Geringeres Risiko	Fehler wirken sich nicht auf alle aus

5.4 Beispiel: CRM-Einführung sukzessiv

Ein Unternehmen führt ein neues CRM-System ein.

Phase	Modul/Prozess	Benutzer	Dauer
Phase 1	Modul: Kontakte	Alle Vertriebsmitarbeiter (20)	2 Wochen
Phase 2	Modul: Aktivitäten	Alle Vertriebsmitarbeiter (20)	2 Wochen
Phase 3	Modul: Opportunities	Alle Vertriebsmitarbeiter (20)	3 Wochen
Phase 4	Modul: Angebote	Alle Vertriebsmitarbeiter (20)	3 Wochen
Phase 5	Integration: Marketing	Marketing-Team (5)	2 Wochen
Phase 6	Integration: Kundenservice	Kundenservice-Team (10)	2 Wochen
Phase 7	Integration: Management	Management (5)	1 Woche

5.5 Best Practices für sukzessive Einführung

Best Practice	Beschreibung
Klare Phasenplanung	Detaillierter Plan mit klaren Übergängen
Abhängigkeiten klären	Welche Phasen voneinander abhängen?
Datenkonsistenz sicherstellen	Daten über Phasen hinweg konsistent halten
Doppelte Prozesse vermeiden	Minimierung von Parallelbetrieb
Benutzer-Erwartungen managen	Klare Kommunikation über Zeitplan
Ressourcen-Planung	Ausreichende Ressourcen für jede Phase sicherstellen
Flexibilität einplanen	Puffer für Verzögerungen
Erfahrungen nutzen	Erfahrungen aus frühen Phasen in späteren Phasen nutzen

6. Paralleleinführung

6.1 Definition

Trotz Umstellung auf ein neues Verfahren wird das bisherige Verfahren beibehaltet. Zweck ist die Kontrolle des neuen Verfahrens im Vergleich mit dem alten Verfahren.

Charakteristik

"Doppeltes Leben" - Altes und neues System parallel betrieben. Höchste Sicherheit, aber hoher Aufwand.

6.2 Warum Paralleleinführung?

Grund	Erklärung
Höchste Sicherheit	Bei Problemen kann sofort zum alten System zurückgekehrt werden
Risikominimierung	Kontinuierlicher Vergleich zwischen alter und neuer Lösung
Schrittweise Migration	Benutzer können sich schrittweise an neue Lösung gewöhnen
Validierung	Ergebnisse beider Systeme können verglichen werden
Training	Benutzer können mit neuem System üben, während altes System noch läuft

6.3 Beispiel: Betriebsdatenerfassung

Ein Unternehmen führt neue Software für die Betriebsdatenerfassung ein.

Aspekt	Altes System	Neues System
Zeitraum	Laufende Datenerfassung	Parallel laufende Datenerfassung
Vergleich	Täglicher Vergleich der Daten	Validierung der Ergebnisse
Zeitrahmen	Bis Validierung abgeschlossen (z.B. 4-6 Wochen)
Abschaltung	Nach erfolgreicher Validierung

6.4 Vor- und Nachteile

Vorteile	Nachteile
Höchste Sicherheit	Risikominimierung durch parallelen Betrieb
Einfacher Rollback	Sofortige Rückkehr zum alten System möglich
Validierung möglich	Kontinuierlicher Vergleich der Ergebnisse
Schrittweise Migration	Benutzer können sich gewöhnen
	Ressourcen-Beanspruchung
	Daten-Konsistenz

Hinweis: Wesentlicher Mehraufwand für die Benutzer

Die Paralleleinführung führt zu einem wesentlichen Mehraufwand für die Benutzer, da Daten oft doppelt erfasst werden müssen. Dies muss bei der Planung berücksichtigt werden (z.B. temporäres Personal, Überstunden, Akzeptanz-Maßnahmen).

6.5 Best Practices für Paralleleinführung

Best Practice	Beschreibung
Klaren Zeitrahmen definieren	Parallellauf zeitlich begrenzen (z.B. 4-8 Wochen)
Vergleichs-Prozesse	Systematische Vergleichs- und Validierungsprozesse
Automatisierung	Automatische Datenübertragung wenn möglich
Benutzer-Unterstützung	Unterstützung der Benutzer durch zusätzliches Personal
Klarer Abbruchplan	Kriterien für Ende des Parallelbetriebs
Daten-Migration	Sauberer Übergang der Daten am Ende der Paralleleinführung
Ressourcen-Management	Ausreichende Ressourcen für beide Systeme sicherstellen
Kommunikation	Klare Kommunikation an Benutzer über Zeitrahmen und Ziele

7. Sandbox-Verfahren

7.1 Definition

Mit dem Begriff Sandbox wird eine Technik bezeichnet, Software innerhalb einer speziellen - d.h. von den übrigen Systemressourcen isolierten - Laufzeitumgebung auszuführen.

Charakteristik

"Isoliertes Testen" - Software in isolierter Umgebung ausprobieren, ohne andere Systeme zu beeinträchtigen.

7.2 Technische Umsetzung

Technologie	Beschreibung	Beispiel
Virtuelle Maschinen (VM)	Vollständige virtuelle Maschine isoliert	VMware, VirtualBox, Hyper-V
Container	Leichtgewichtige Isolation auf Betriebssystem-Ebene	Docker, Kubernetes
Cloud-Sandboxes	Isolierte Cloud-Umgebungen	AWS EC2, Azure VM, GCE
Application Sandboxes	Isolierte Ausführung von Anwendungen	Chrome Sandbox, Java Sandbox

7.3 Verwendung von Sandbox-Verfahren

Anwendungsszenario	Beschreibung
Pilotierung	Sandbox als Testumgebung vor Produktivstart
Testen neuer Software	Ausprobieren von neuer Software ohne Risiko
Sicherheits-Testing	Testen von Software auf Sicherheitslücken
Entwicklung	Isolierte Entwicklungsumgebungen
Training	Schulungen in isolierten Umgebungen
Demonstration	Demos ohne Beeinträchtigung von Produktivsystemen

7.4 Mögliche Probleme bei Sandbox-Verfahren

Problem	Erklärung	Lösung
Leistungsfähigkeit / Performance	Sandboxes können langsamer sein als Produktivsystem	Leistungsstarke Hardware, Optimierung
Ressourcen-Verbrauch	Sandboxes verbrauchen Ressourcen (CPU, RAM, Speicher)	Ressourcen-Management, Bereinigung
Daten-Konsistenz	Unterschiede zwischen Sandbox und Produktivsystem	Daten-Replikation, Aktualisierung
Komplexität	Management von mehreren Umgebungen	Automatisierung, Cloud-Management
Kosten	Zusätzliche Kosten für Sandbox-Umgebungen	Effiziente Nutzung, Cloud-Optimierung

7.5 Verbindung mit Pilotierung

Die Sandbox-Technik wird oft in Verbindung mit einer Pilotierung eingesetzt:

graph TD
    A[Sandbox-Phase] --> B[Test- und Validierungsphase]
    B --> C[Pilot-Phase]
    C --> D[Produktiv-Rollout]

    style A fill:#e3f2fd
    style B fill:#fff9c4
    style C fill:#ffecb3
    style D fill:#c8e6c9

Beispiel: Ein Unternehmen testet eine neue CRM-Lösung zuerst in einer Sandbox-Cloud-Umgebung (Test), dann in einer Pilot-Abteilung (Pilot), dann im Rollout auf alle Abteilungen (Produktiv).

8. Entscheidung für die richtige Strategie

8.1 Kriterien für die Auswahl

Kriterium	Fragen zur Evaluation
Komplexität des Systems	Wie komplex ist das System? Wie viele Abhängigkeiten gibt es?
Anzahl der Benutzer	Wie viele Benutzer sind betroffen?
Kritikalität	Wie kritisch ist das System für den Geschäftsbetrieb?
Gesetzliche Vorgaben	Gibt es gesetzliche oder regulatorische Vorgaben?
Risikotoleranz	Wie viel Risiko kann das Unternehmen eingehen?
Zeitrahmen	Wie schnell muss das System eingeführt werden?
Ressourcen-Verfügbarkeit	Welche Ressourcen sind für den Rollout verfügbar?
Budget	Wie hoch ist das Budget für den Rollout?
Benutzer-Akzeptanz	Wie hoch ist die Akzeptanz der Benutzer?
Technische Voraussetzungen	Welche technischen Voraussetzungen gibt es?
Parallelbetriebs-Möglichkeit	Können altes und neues System parallel betrieben werden?
Erfahrungen des Unternehmens	Hat das Unternehmen Erfahrungen mit ähnlichen Projekten?

8.2 Entscheidungsmatrix

Projekttyp	Empfohlene Strategie	Begründung
Kritische Systeme mit hohem Risiko	Sukzessiv oder Paralleleinführung	Risikominimierung ist priorisiert
Gesetzlich vorgeschriebene Systeme	Big Bang zum Stichtag	Keine Wahl durch Gesetz
Große Unternehmens-Software (ERP, CRM)	Pilotierung oder Sukzessiv	Lernerfahrung und Ressourcen-Management
Innovative, komplexe Systeme	Pilotierung	Testen und Lernen vor Rollout
Einfache Systeme mit wenigen Benutzern	Big Bang	Geringes Risiko, einfacher Rollout
Migrationsprojekte mit Risiko	Sandbox + Paralleleinführung	Isolierung und Risikominimierung
Systeme mit hoher Benutzer-Resistenz	Sukzessiv	Schrittweise Einführung erhöht Akzeptanz
Zeitkritische Projekte	Big Bang oder Pilotierung	Schneller Rollout notwendig

8.3 Entscheidungsprozess

flowchart TD
    A[Start Entscheidung] --> B{Gesetzliche Vorgabe?}
    B -->|Ja| C[Big Bang<br/>zum Stichtag]
    B -->|Nein| D{System-Kritikalität?}
    D -->|Sehr hoch| E{Parallelbetrieb möglich?}
    D -->|Mittel/Hoch| F{Komplexität?}
    D -->|Niedrig| G{Benutzeranzahl?}

    E -->|Ja| H[Paralleleinführung]
    E -->|Nein| I[Sandbox + Sukzessiv]

    F -->|Hoch| J[Pilotierung]
    F -->|Mittel| K[Sukzessiv]

    G -->|Groß| K
    G -->|Klein| C

    C --> L[Ende]
    H --> L
    I --> L
    J --> L
    K --> L

    style C fill:#ffcdd2
    style H fill:#c8e6c9
    style I fill:#fff9c4
    style J fill:#e3f2fd
    style K fill:#ffecb3

9. Rollout-Planung

9.1 Rollout-Plan: Checkliste

□ Strategie-Auswahl und Begründung
□ Detaillierter Rollout-Plan erstellt
□ Rollout-Team benannt und eingewiesen
□ Ressourcen gebunden und geplant
□ Test-Umgebungen eingerichtet
□ Test- und Rollout-Daten vorbereitet
□ Schulungen geplant und durchgeführt
□ Kommunikation an alle Beteiligten
□ Go-Live-Team definiert und eingewiesen
□ Hypercare-Team aufgestellt
□ Notfallplan erstellt
□ Rollback-Plan definiert und getestet
□ Monitoring und Alerting eingerichtet
□ SLA und Support-Verträge finalisiert
□ Dokumentation erstellt und verteilt
□ Genehmigungen und Freigaben eingeholt

9.2 Rollout-Plan: Vorlage

Phase	Aktivität	Verantwortlicher	Start	Ende	Status
Vorbereitung	Strategie-Auswahl	Projektleiter	01.01.	15.01.	✅
Vorbereitung	Rollout-Plan erstellen	Rolloutmanager	15.01.	31.01.	✅
Vorbereitung	Team benennen und einweisen	Projektleiter	01.02.	15.02.	✅
Vorbereitung	Schulungen durchführen	Trainer	01.02.	28.02.	✅
Test	Pilot-Phase	Pilot-Team	01.03.	31.03.	✅
Test	Erfahrungen sammeln	Alle	01.04.	15.04.	✅
Anpassung	Verbesserungen implementieren	Entwickler	15.04.	30.04.	✅
Rollout 1	Rollout Phase 1 (Standort München)	Rollout-Team	01.05.	07.05.	🔄
Hypercare 1	Hypercare Phase 1	Hypercare-Team	01.05.	15.05.	⏳
Rollout 2	Rollout Phase 2 (Standort Berlin)	Rollout-Team	15.05.	21.05.	⏳
Hypercare 2	Hypercare Phase 2	Hypercare-Team	15.05.	31.05.	⏳
Rollout 3	Rollout Phase 3 (Standort Hamburg)	Rollout-Team	01.06.	07.06.	⏳
Hypercare 3	Hypercare Phase 3	Hypercare-Team	01.06.	15.06.	⏳
Abschluss	Projektabschluss	Projektleiter	15.06.	30.06.	⏳

10. Zusammenfassung

10.1 Kernpunkte des Kapitels

1. Strategie-Auswahl entscheidend - Die Rollout-Strategie kann über Erfolg oder Misserfolg entscheiden
2. Fünf Haupt-Strategien - Big Bang, Pilotierung, Sukzessiv, Parallel, Sandbox
3. Kriterien-basierte Entscheidung - Entscheidung basierend auf Komplexität, Risiko, Ressourcen
4. Jede Strategie hat Vor- und Nachteile - Keine "beste" Strategie, sondern passende Strategie
5. Planung ist Schlüssel - Sorgfältige Rollout-Planung ist entscheidend
6. Flexibilität - Strategie kann im Projektverlauf angepasst werden

10.2 Strategie-Empfehlung

Entscheidungs-Heuristik

• Schnell + Einfach + Geringes Risiko → Big Bang
• Komplex + Großes Projekt → Pilotierung
• Ressourcen-schonend + Geringes Risiko → Sukzessiv
• Höchste Sicherheit + Kritisch → Paralleleinführung
• Testen + Isoliert + Innovativ → Sandbox

11. Schlüsselbegriffe

Begriff	Definition
Rollout	Systematische Einführung einer neuen oder geänderten IT-Lösung im Unternehmen
Big Bang (Stichtagseinführung)	Gleichzeitige Einführung für alle Benutzer zu einem festen Zeitpunkt
Pilotierung	Testlauf in einer Region, Abteilung oder einem Funktionsbereich
Sukzessive Einführung	Schrittweise, zeitlich gestaffelte Einführung
Vertikaler Rollout	Regional gestaffelte Einführung: ein Benutzer/Benutzergruppe alle Funktionen
Horizontaler Rollout (funktional)	Funktional gestaffelte Einführung: ein Funktionsbereich bei allen Benutzern
Paralleleinführung	Paralleler Betrieb von altem und neuem System
Sandbox	Isolierte Laufzeitumgebung zum Testen von Software
Go-Live	Produktivstart eines neuen Systems oder einer neuen Version
Hypercare	Phase erhöhter Aufmerksamkeit und Support-Intensität direkt nach dem Go-Live
Rollback	Rückkehr zum vorherigen System nach einem fehlerhaften Go-Live
Pilot-Phase	Testphase zur Sammlung von Erfahrungen vor dem Haupt-Rollout

12. Verständnisfragen

Frage 1: Strategie-Auswahl

Ein Krankenhaus plant die Einführung einer neuen Software für das Patientenmanagement (Electronic Health Record - EHR). Das System ist komplex, kritisch für den Geschäftsbetrieb und wird von 500 Mitarbeitern genutzt. Es gibt keine gesetzlichen Vorgaben für einen bestimmten Zeitpunkt. Das Management möchte das Risiko minimieren.

a) Welche Strategie(n) kommen infrage? b) Welche Strategie würden Sie empfehlen und warum? c) Wie würde der Rollout-Plan grob aussehen?

Lösung: a) Infrage kommende Strategien: - Sukzessive Einführung (Ressourcen-schonend, geringes Risiko) - Pilotierung (Lernerfahrung, Risikominimierung) - Paralleleinführung (Höchste Sicherheit, wenn paralleler Betrieb möglich) - Sandbox + Pilotierung (Isolierung + Lernerfahrung)

b) Empfehlung: Pilotierung + Sukzessive Einführung

Begründung: - Pilotierung ermöglicht Lernerfahrungen und Risikominimierung in einem kontrollierten Bereich - Sukzessive Einführung schont Ressourcen und minimiert Risiko, indem Benutzer schrittweise wechseln - Kombination ist ideal für komplexe, kritische Systeme mit vielen Benutzern - Paralleleinführung würde zu hohem Aufwand führen (doppelte Dateneingabe in Klinikumfeld kritisch) - Big Bang ist zu risikoreich für ein kritisches Kliniksystem

c) Grober Rollout-Plan: 1. Sandbox-Phase: System in isolierter Umgebung testen (4 Wochen) 2. Pilot-Phase: Pilot in einer Klinik-Abteilung (z.B. Radiologie, 50 Mitarbeiter) (4 Wochen) 3. Erfahrungen sammeln & anpassen: Learnings dokumentieren, Verbesserungen umsetzen (2 Wochen) 4. Sukzessiver Rollout: Schrittweise Einführung in weiteren Abteilungen (z.B. 2-3 Abteilungen pro Woche) (8-12 Wochen) 5. Hypercare: Intensive Nachbetreuung jeder Phase (jeweils 2 Wochen pro Phase) 6. Projektabschluss: Vollständige Einführung abgeschlossen, Übergabe an Betrieb

Frage 2: Big Bang vs. Sukzessiv

Ein mittelständisches Unternehmen (100 Mitarbeiter) führt ein neues Projektmanagement-Tool ein. Die Projektleitung diskutiert, ob ein Big Bang oder eine sukzessive Einführung besser wäre.

a) Nennen Sie 3 Argumente für Big Bang und 3 Argumente für sukzessive Einführung. b) Welche Strategie würden Sie für dieses Szenario empfehlen und warum?

Lösung: a) Argumente:

Für Big Bang: 1. Klarer Schnitt: Keine Mischung alter und neuer Prozesse, klarer Bruch 2. Schnell: Alle Mitarbeiter arbeiten ab Tag 1 mit dem neuen System, keine langwierige Übergangsphase 3. Kosteneffizient: Nur ein System muss betrieben werden, keine parallelen Kosten

Für sukzessive Einführung: 1. Ressourcen-schonend: Keine Überlastung an einem einzigen Zeitpunkt, Support verteilt über Zeit 2. Geringeres Risiko: Probleme wirken sich nicht auf alle Mitarbeiter aus, Fehler können isoliert werden 3. Lernerfahrung: Erfahrungen aus früheren Phasen nutzen, System verbessern

b) Empfehlung: Sukzessive Einführung

Begründung: - Ein mittelständisches Unternehmen (100 Mitarbeiter) ist nicht so groß, dass ein Big Bang zwingend notwendig ist - Projektmanagement-Tool ist wichtig, aber meist nicht "geschäftskritisch" im Sinne von Stillstand bei Ausfällen - Sukzessive Einführung ermöglicht Lernerfahrungen und Verbesserungen im Verlauf - Support und Training können besser auf die Mitarbeiter verteilt werden - Weniger Stress und Überlastung für Support-Teams und Projektleitung - Wenn das Unternehmen bereits Erfahrung mit Change hat, kann auch Big Bang in Betracht gezogen werden

Wenn das Projektmanagement-Tool jedoch einfach ist, die Mitarbeiter hohes Change-Management-Potenzial haben und schnelle Ergebnisse gefordert sind, könnte auch ein Big Bang mit guter Vorbereitung funktionieren.

Frage 3: Paralleleinführung

Ein Unternehmen plant die Einführung eines neuen Buchhaltungssystems und diskutiert eine Paralleleinführung. Der CFO ist skeptisch wegen der hohen Kosten.

a) Erklären Sie dem CFO die Vor- und Nachteile der Paralleleinführung. b) Welche Maßnahmen könnten die Kosten und den Aufwand reduzieren? c) Unter welchen Bedingungen wäre eine Paralleleinführung gerechtfertigt?

Lösung: a) Vor- und Nachteile für den CFO:

Vorteile: 1. Höchste Sicherheit: Bei Problemen kann sofort zum alten System zurückgekehrt werden (Risk Mitigation) 2. Validierung: Kontinuierlicher Vergleich der Ergebnisse zwischen altem und neuem System (Quality Assurance) 3. Schrittweise Migration: Buchhaltungsteam kann sich schrittweise an neue Lösung gewöhnen (Change Management) 4. Minimierung von Ausfallrisiko: Kein Ausfall der Buchhaltung bei Problemen mit neuem System (Business Continuity)

Nachteile: 1. Hohe Kosten: Doppelte System- und Wartungskosten (Software-Lizenzen, Hardware, Wartung) 2. Doppelter Aufwand: Buchhaltungsteam muss Daten in beiden Systemen erfassen (Zeit- und Ressourcenaufwand) 3. Hohe Benutzerbelastung: Mitarbeiter müssen doppelt arbeiten, was zu Frustration führen kann 4. Komplexität: Management von zwei Systemen erfordert zusätzliche Koordination und Überwachung

b) Maßnahmen zur Kosten- und Aufwandsreduzierung:

Kostenreduzierung: - Zeitlich begrenzter Parallelbetrieb: Paralleleinführung auf 4-6 Wochen begrenzen, nicht unbefristet laufen lassen - Automatisierung: Automatische Datenübertragung zwischen Systemen, wo möglich (z.B. Schnittstelle für Stammdaten) - Cloud-Lösungen: Nutzung von Cloud-basierten Lösungen für das neue System (keine Hardware-Investition) - Staffelungs-Lizenzen: Lizenzierung nur für die Dauer der Paralleleinführung

Aufwandsreduzierung: - Zusätzliches Personal: Temporäre Unterstützung der Buchhaltung durch Hilfskräfte oder Service-Center - Schnittstellen: Entwicklung von Schnittstellen zur Daten-Synchronisierung - Schulung: Intensive Schulung vor Paralleleinführung, um Fehlerquote zu minimieren - Priorisierung: Nur kritische Prozesse parallel führen, weniger kritische Prozesse direkt im neuen System

c) Bedingungen, unter denen Paralleleinführung gerechtfertigt ist:

1. Hoch-kritisches System: Buchhaltung ist geschäftskritisch, Ausfälle hätten schwerwiegende finanzielle Konsequenzen
2. Hohe Compliance-Anforderungen: Fehlende Fehler könnten zu Compliance-Verletzungen führen (Steuern, Audit)
3. Komplexes System: Hohes Risiko von Fehlerquellen und Schnittstellenproblemen
4. Keine Testumgebung: Keine Möglichkeit zum umfassenden Testen vor Produktivstart
5. Erfahrungs-ARMES Team: Team hat keine Erfahrung mit ähnlichen Systemen, Lernerfahrung wichtig
6. Budget verfügbar: Unternehmen hat Budget für den zusätzlichen Aufwand
7. Zeitrahmen erlaubt: Projektdauer erlaubt zusätzlichen Zeitbedarf

Wenn diese Bedingungen zutreffen, ist der zusätzliche Aufwand der Paralleleinführung durch das reduzierte Risiko gerechtfertigt.

---

Nächstes Kapitel: 5. Hypercare & Nachbetreuung