Ich mache das jetzt seit über zehn Jahren. IT-Transformationen, international, meistens Automotive. Tokyo, São Paulo, München, Südafrika — ich habe Systeme ausgerollt, die in 30+ Märkten gleichzeitig funktionieren müssen. Manche Projekte hatten ein Budget, bei dem man nicht nachfragen wollte. Andere hatten ein Team von acht Leuten für fünfzehn Länder.
Was mich immer wieder überrascht: Die Projekte scheitern nicht an der Technik. Die Technik ist meistens in Ordnung. Es scheitert an fünf Dingen, die in jedem einzelnen Programm auftauchen. Ich habe sie mittlerweile so oft gesehen, dass ich sie vorhersagen kann, bevor das Projekt überhaupt richtig anfängt.
Testing wird immer als Erstes gestrichen
Ich weiß nicht, warum das so ist, aber es passiert jedes Mal. Der Zeitplan gerät unter Druck — Anforderungen dauern länger als geplant, weil der Fachbereich seine eigenen Prozesse nicht kennt. Das Design wird dreimal überarbeitet. Die Entwicklung liefert spät.
Und dann sitzt irgendwer in einem Steering und sagt: „Wir kürzen die Testing-Phase von zehn auf vier Wochen.“ Nicht weil jemand analysiert hat, dass vier Wochen reichen. Sondern weil der Go-Live-Termin feststeht und Testing die Phase ist, bei der niemand auf den Tisch haut.
Ich habe in einem Projekt erlebt, wie ein Konfigurationsfehler im Bestellprozess durch die verkürzte Testing-Phase gerutscht ist. Im Pilotmarkt hat ihn jemand zufällig gefunden, weil er manuell einen Sonderfall getestet hat. In Welle drei, als niemand mehr manuell getestet hat, hat er sich über acht Märkte verbreitet. Die Bereinigung hat drei Monate gedauert.
Vier Wochen gespart, drei Monate verloren.
Welle zwei ist nicht einfacher als der Pilot. Nie.
Das hört sich logisch an: Im Piloten lernt man, in Welle zwei wendet man das Gelernte an, ab Welle drei läuft alles von selbst. Auf Folien funktioniert das. In der Realität ist Welle zwei der Moment, in dem alles kippt.
Warum? Weil das Team gleichzeitig den Piloten stabilisiert und Welle zwei vorbereitet. Die erfahrensten Leute hängen in Eskalationen aus Welle eins fest. Und die Lessons-Learned aus dem Piloten — die existieren meistens als Dokument, das in einem SharePoint liegt und das keiner gelesen hat.
Ich habe ein Programm begleitet, in dem ein Fehler in der Fahrzeugkonfiguration im Pilotmarkt in zwei Tagen behoben wurde. Dasselbe Problem in Welle drei hat sich über acht Märkte gezogen, weil niemand die Testfälle angepasst hatte. Nicht aus Faulheit — aus Zeitmangel.
Wer glaubt, dass spätere Wellen einfacher werden, hat noch keinen Multi-Markt-Rollout gemacht.
150% Auslastung bedeutet 60% Output
Auf dem Papier: 10 Leute, 5 Systeme, 15 Märkte. Jeder macht zwei Märkte und ein System. Klingt machbar.
In der Realität hat jeder drei Meetings am Tag, zwei Eskalationen pro Woche, einen Kollegen, der seit drei Wochen krank ist und dessen Arbeit verteilt wurde, und ein System, das sich nicht so verhält wie die Dokumentation von 2022 es beschreibt.
Ich habe Teams gesehen, in denen innerhalb eines Quartals drei von zehn Leuten ausgefallen sind. Nicht weil die Arbeit zu schwer war. Weil sie zu viel war, zu lange, ohne Pause. Da geht niemand freiwillig — der Körper macht einfach nicht mehr mit.
Und die Leute, die noch da sind? Die überspringen Reviews. Die testen den Happy Path und hoffen, dass die Edge Cases nicht auftreten. Die dokumentieren nichts mehr, weil es schneller geht, es direkt zu machen, als es aufzuschreiben.
Wer mit 100% Auslastung plant, plant das Scheitern. Die reale Kapazität liegt bei 70% — der Rest geht für Meetings, Abstimmung und die Dinge drauf, die nicht im Projektplan stehen.
Der Pilot beweist gar nichts
Der gefährlichste Satz, den ich kenne: „Der Pilot war erfolgreich.“
Was heißt das konkret? Es heißt, dass das System in einem Markt funktioniert hat. Mit dem besten Team, der vollen Aufmerksamkeit des Managements und einem Markt, der meistens deswegen als Pilot ausgewählt wurde, weil er am wenigsten komplex ist.
Die Frage ist nicht, ob das System im Pilot funktioniert. Die Frage ist, ob es in Markt fünfzehn funktioniert — wenn die besten Leute längst im nächsten Projekt sind, der Support halbiert wurde und die lokalen Anwender zum ersten Mal mit dem System arbeiten. Auf Japanisch. Mit einer Dokumentation, die auf Englisch geschrieben wurde.
Ein Pilot ohne Probleme ist kein gutes Zeichen. Er bedeutet, dass nicht gründlich genug getestet wurde. Die Programme, die funktioniert haben, waren die, in denen der Pilot fünfzig Probleme aufgedeckt hat — und jedes einzelne davon vor Welle zwei gelöst und in die Testfälle übernommen wurde.
Go-Live wird geplant. Was danach kommt, nicht.
Jedes Programm hat einen Go-Live-Plan. Checklisten, Countdown-Meetings, War Rooms, Eskalationspfade. Das volle Programm.
Was passiert in Woche zwei nach dem Go-Live? Wer ist zuständig, wenn ein Anwender ein Problem meldet, das im Testing nicht aufgefallen ist? Wie schnell muss reagiert werden? Wer entscheidet über einen Rollback?
In einem japanischen Markt habe ich erlebt, wie der Go-Live technisch sauber durchlief. Alles grün. Champagner im War Room. Drei Monate später hat der Markt das alte System wieder eingeführt. Nicht weil die Technik versagt hat — sondern weil die Anwender in der Hypercare-Phase nicht ausreichend unterstützt wurden. Schulungen zu kurz, Dokumentation in der falschen Sprache, Support in der falschen Zeitzone.
Der Go-Live dauert einen Tag. Die Hypercare dauert Wochen. Die Gewichtung in den meisten Projektplänen spiegelt das nicht wider.
Was ich daraus gemacht habe
Irgendwann habe ich angefangen, diese Muster aufzuschreiben. Nicht als Theorie, sondern als Checkliste für mich selbst: Worauf muss ich achten, wenn ein neues Programm startet? Wo wird es wieder schiefgehen?
Daraus ist ein Werkzeug entstanden — unser Go-Live Risiko-Simulator. Man gibt die Parameter eines geplanten Rollouts ein — Märkte, Systeme, Timeline, Teamgröße, Testing-Ansatz — und bekommt eine Heatmap, die zeigt, wo die Risiken liegen werden. Basierend auf dem, was ich in über einem Jahrzehnt beobachtet habe.
Kostenlos. 30 Sekunden.
→ Zum Go-Live Risiko-Simulator
Und für alle, die sich fragen, welche Prozesse in ihrem Unternehmen durch KI automatisiert werden könnten: Unser KI-Automatisierungs-Scan analysiert Ihre Website und zeigt konkrete Potenziale.
