Die unsichtbare Hälfte jedes Programms — und warum sie über Erfolg oder Scheitern entscheidet
Vor drei Monaten habe ich mit einem Programmdirektor bei einem Versicherer gesprochen. Sein Team hatte gerade ein großes SAP-Rollout abgeschlossen. Technisch perfekt. Im Zeitplan. Im Budget.
Das Management war zufrieden. Das Projektteam wurde gelobt. Die Consultants zogen ab.
Sechs Wochen später rief er mich wieder an.
„Das System läuft“, sagte er. „Aber die Leute nutzen es nicht. Die Produktivität ist eingebrochen. Die Fehlerquote ist explodiert. Und niemand weiß, wie wir das wieder hinbekommen.“
Ich habe ihm eine Frage gestellt: „Wie viel habt ihr für die Zeit nach dem Go-live eingeplant?“
Die Antwort: „Nach dem Go-live? Nichts. Das Projekt war fertig.“
Das ist kein Einzelfall. Es ist das Standardmuster.
In den meisten Unternehmen wird der Go-live als Ziellinie behandelt. Das System ist live, die Tests sind bestanden, die Freigabe ist erfolgt. Das Projekt ist abgeschlossen.
Aber das ist eine Illusion.
Der Go-live ist nicht das Ende eines Transformationsprogramms. Er ist die Halbzeit.
Was danach kommt — die Phase zwischen technischem Go-live und tatsächlicher Adoption — ist mindestens genauso aufwändig wie das, was davor war. Und es kostet genauso viel. Aber niemand budgetiert dafür. Niemand plant dafür. Niemand baut dafür Strukturen auf.
Die Folge: Programme, die technisch erfolgreich sind, scheitern operativ — weil niemand die zweite Hälfte ernst genommen hat.
Hier ist, was in den ersten 90 Tagen nach einem typischen Go-live passiert:
Phase 1: Die ersten zwei Wochen — Chaos Management
Das System ist live. Die Nutzer arbeiten damit zum ersten Mal produktiv. Und die Probleme beginnen. Nicht weil das System schlecht wäre — sondern weil echte Nutzung immer Dinge aufdeckt, die Tests nicht gefunden haben.
Prozesse, die in der Schulung logisch klangen, funktionieren in der Praxis nicht. Workflows, die im Test reibungslos liefen, kollidieren mit realen Abläufen. Edge Cases tauchen hundertfach auf.
In dieser Phase explodiert der Supportaufwand. Das Servicedesk ist überlastet. Die Fachabteilungen sind frustriert. Die Produktivität sinkt — manchmal um 30 bis 40 Prozent.
Was braucht man in dieser Phase? Ein Team, das sofort reagieren kann. Nicht das Projektteam — das ist längst aufgelöst. Nicht die Consultants — die sind weg. Sondern eine dedizierte Post-Go-live-Struktur, die für genau diese Phase aufgebaut wurde.
Richtwert: 10–15 % des ursprünglichen Projektbudgets — nur für die ersten zwei Wochen.
Phase 2: Wochen 3 bis 8 — Stabilisierung
Nach dem initialen Chaos beginnt die Stabilisierung. Die gröbsten Probleme sind gelöst. Die Nutzer haben die Grundfunktionen verstanden. Das System läuft.
Aber jetzt zeigt sich ein anderes Problem: Adoption. Die Leute nutzen das System — aber nicht so, wie es gedacht war. Sie bauen Workarounds. Sie nutzen Schatten-Tools parallel. Sie kehren zu alten Prozessen zurück, wo immer möglich. Das ist keine Böswilligkeit. Es ist Rationalität: Menschen optimieren ihren Workflow instinktiv auf das, was sie kennen.
Was braucht man in dieser Phase? Change-Begleitung in der Linie. Nicht Schulungen — die sind vorbei. Sondern konkrete Unterstützung am Arbeitsplatz. Guides, die zeigen, wie man die neue Logik in den eigenen Workflow integriert. Führungskräfte, die die Nutzung vorleben und einfordern.
Richtwert: 20–25 % des ursprünglichen Projektbudgets — verteilt über sechs Wochen.
Phase 3: Wochen 9 bis 12 — Optimierung
In dieser Phase beginnt die echte Arbeit: Die Prozesse, die im System abgebildet sind, müssen an die Realität angepasst werden. Nicht weil sie falsch konzipiert wären — sondern weil kein Prozess im ersten Anlauf perfekt ist. Die Praxis zeigt immer Optimierungspotenziale, die in der Planung nicht sichtbar waren.
Aber zu diesem Zeitpunkt ist das Projektteam längst aufgelöst. Die Verantwortung liegt bei der Linie — aber die Linie hat weder die Zeit noch die Kompetenz, das System anzupassen.
Was braucht man in dieser Phase? Eine Governance-Struktur, die Änderungen priorisieren und umsetzen kann. Nicht das alte Projektsteuergremium — das tagt nicht mehr. Sondern eine permanente Instanz, die zwischen Linie und IT vermittelt.
Richtwert: 15–20 % des ursprünglichen Projektbudgets — für Anpassungen und kontinuierliche Verbesserung.
Zusammengerechnet ergeben sich folgende Richtwerte für die ersten 90 Tage nach dem Go-live:
Gesamt: 45 bis 60 Prozent des ursprünglichen Projektbudgets — nur für die ersten 90 Tage nach dem Go-live.
Das ist konservativ gerechnet. Bei komplexen Programmen in regulierten Umfeldern habe ich Fälle erlebt, in denen die Post-Go-live-Phase genauso teuer war wie das gesamte Projekt davor.
Niemand budgetiert dafür — weil niemand es als Teil des Programms sieht.
Die Kosten wären halb so hoch, wenn Unternehmen die Post-Go-live-Phase richtig planen würden. Aber das passiert nicht — aus drei Gründen:
Erstens: Das Projekt ist offiziell fertig. Das Budget ist aufgebraucht. Die Verantwortung liegt jetzt bei der Linie — aber die Linie hat kein Budget für Post-Go-live-Support.
Zweitens: Die Strukturen sind aufgelöst. Das Projektteam ist weg. Die Consultants sind weg. Es gibt niemanden mehr, der schnell reagieren kann.
Drittens: Die Governance fehlt. Es gibt keine Instanz mehr, die Änderungen priorisieren und umsetzen kann. Jede Anpassung läuft durch normale IT-Prozesse — und das dauert Monate.
Die Folge: Man improvisiert. Man zieht Leute aus der Linie ab, die eigentlich produktiv arbeiten sollten. Man beauftragt teure Consultants auf Tagessatzbasis, die nicht mehr im Kontext sind. Man lässt Probleme liegen, bis sie eskalieren.
Die erfolgreichsten Programme, die ich gesteuert habe, haben die Post-Go-live-Phase von Anfang an eingeplant. Konkret:
Erstens: 50 Prozent des Projektbudgets für die Post-Go-live-Phase einplanen. Nicht als Puffer, sondern als fester Bestandteil des Programms.
Zweitens: Eine Post-Go-live-Struktur aufbauen, bevor der Go-live passiert. Ein Team, das für die ersten 90 Tage dediziert ist — mit klaren Rollen, Budget und Mandat.
Drittens: Eine Governance definieren, die nach dem Go-live weiterläuft. Nicht das Projektsteuergremium — sondern eine permanente Instanz, die Änderungen priorisiert und umsetzt.
Wenn diese drei Dinge stehen, sinken die Kosten — weil man nicht mehr improvisiert, sondern steuert.
Bei einem Rollout in einem mittelständischen Versicherer haben wir das konsequent umgesetzt. Wir haben 40 Prozent des Projektbudgets für die Post-Go-live-Phase reserviert und ein 10-köpfiges Post-Go-live-Team aufgebaut — besetzt mit Leuten aus der Linie, die das System kannten und operative Erfahrung hatten.
Wir haben eine Governance definiert, die täglich tagte — in den ersten zwei Wochen. Danach wöchentlich. Dann monatlich.
Das Ergebnis: Die Produktivität sank in den ersten Tagen um 15 Prozent — nicht um 40 Prozent. Nach vier Wochen war sie wieder auf dem alten Niveau. Nach drei Monaten lag sie 10 Prozent höher als vor dem Rollout.
Und die Kosten? Niedriger als geplant. Weil wir nicht improvisiert haben, sondern gesteuert.
Wenn Sie gerade ein Transformationsprogramm planen — oder eines steuern, das kurz vor dem Go-live steht — dann stellen Sie sich eine einfache Frage:
„Was passiert am Tag nach dem Go-live?“
Wenn die Antwort „das Projekt ist dann fertig“ lautet, dann ist Ihr Programm in Gefahr.
Der Go-live ist nicht die Ziellinie. Er ist die Halbzeit. Und die zweite Hälfte entscheidet, ob Ihr Programm wirklich erfolgreich ist — oder nur technisch abgeschlossen.
Über den Autor
Rainer V. Hiller ist Senior Program Manager mit 25 Jahren Erfahrung in der Steuerung komplexer Transformationsprogramme — spezialisiert auf regulierte Umfelder, Organisationsrückbau und Compliance-konforme Cloud-Transformation.
Er ist ab sofort verfügbar für Interim-Mandate.
Kontakt: rainer.hiller@dxb-41.consulting
