Beschreibung / strategischer Inhalt
—
Objektiver Nachweis / Datenstand
Modellannahme – zu validieren: Migrationsplan ERP-2026, Stakeholder-Interviews, vendor-Proposal SAP/Implementierungspartner, Erfahrungswerte aus 3 vergleichbaren Migrationen im Branchenumfeld.
Risiko-Kategorie
Technisch
Geplante Entscheidung / Vorhaben
Migration des legacy ERP-Systems auf SAP S/4HANA innerhalb von 18 Monaten. Budget: 4,2 Mio. €. Ziel: Prozessharmonisierung über 6 Standorte, Echtzeit-Reporting und IFRS-Konformität. Go-Live: Q1/2027.
Scheitern-Annahme: 'Das Vorhaben ist gescheitert. Warum?'
Es ist 12 Monate nach dem geplanten Go-Live. Die Migration ist gescheitert. Das alte System ist abgeschaltet, das neue nicht funktionsfähig. Die Produktion an 4 von 6 Standorten steht still.
Evidenzqualität
C – Modellannahme / zu validieren
Ursachen für das Scheitern (Prospective Hindsight)
1) Datenmigration: Altdaten waren inkonsistent und unvollständig – 40 % der Materialstämme hatten doppelte oder fehlerhafte Einträge, die erst beim Go-Live sichtbar wurden. 2) Change-Management: Die Anwender an 4 Standorten wurden nicht rechtzeitig geschult, die neuen Prozesse wurden als 'von der Zentrale aufgezwungen' abgelehnt und umgangen. 3) Customizing-Lock-in: 1200 Z-Prozesse aus dem Altsystem wurden 1:1 migriert statt zu harmonisieren – das neue System replizierte die Fehler des alten. 4) Big-Bang-Go-Live: Alle 6 Standorte gleichzeitig statt phasenweise – ein Standortfehler zog alle mit sich.
Eintrittswahrscheinlichkeit
hoch (50–75 %)
Auswirkung bei Eintritt
existenzbedrohend
Frühwarnsignale: Woran wäre das Scheitern früh erkennbar?
1) Datenqualitäts-Index der Stämme < 85 % nach 6 Monaten Migration (Schwellwert). 2) Schulungsteilnahme < 60 % der Anwender 3 Monate vor Go-Live. 3) Anzahl offener Z-Prozesse > 800 nach Customizing-Review. 4) Testdurchlaufquote < 80 % der kritischen Geschäftsprozesse 4 Monate vor Go-Live.
Präventivmaßnahmen: Was jetzt tun, um das Scheitern zu verhindern?
1) Datenqualitäts-Audit vor Migrationsstart: 100 % der Stämme validieren, Bereinigungs-Team einsetzen. Owner: Datensteward, Termin: M-3. Messgröße: Datenqualitäts-Index ≥ 95 %. 2) Phasenweise Migration: Erst Standort 1, dann 2+3, dann 4+5+6. Owner: Projekt-PM, Termin: Go-Live-Planung. Messgröße: 14 Tage stabiler Betrieb je Standort. 3) Anwender-Schulung: 90 % Teilnahme, Key-User je Abteilung, kontinuierliche Begleitung. Owner: Change-Manager, Termin: ab M-6. Messgröße: Teilnahmequote ≥ 90 %. 4) Customizing-Harmonisierung: Z-Prozesse auf 200 reduzieren, Standardprozesse nutzen. Owner: Prozessverantwortlicher, Termin: M-9. Messgröße: Z-Prozesse ≤ 200.
Trigger / Eskalationsbedingung: Wann eingreifen?
Go-Live stoppen, wenn Datenqualitäts-Index < 90 % oder Testdurchlaufquote < 85 %. Eskalation an Geschäftsführung bei Schwellwert-Unterschreitung.
Erkannter strategischer Misfit / blinder Fleck
Blinder Fleck: 'Wir haben das schon mal gemacht' – aber jede Migration ist anders. Der Implementierungspartner verzeichnete 3 erfolgreiche Migrationen, aber in anderen Branchen mit anderen Datenstrukturen. Groupthink: Das Projektteam hat keine kritischen Stimmen zugelassen, weil alle 'motiviert' sein sollten.
Tempovorteil durch Früherkennung ggü. Wettbewerb
Vor dem Wettbewerb (Initiative)
Strategische Führungskonsequenz
Pre-Mortem vor jeder Groß-Migration verpflichtend. Datenqualität vor Systemmigration prüfen, nicht danach. Phasenweise Migration statt Big-Bang. Change-Management als gleichgewichtigen Workstream neben IT aufsetzen. Trigger-Stop-Bedingungen vor Go-Live verbindlich.