Technik bereit, Betrieb nicht: Welche Evidenz eine Go-live-Entscheidung tragen sollte

Die gefährliche Lücke zwischen System und Betrieb

Kurz vor einem Go-live verdichtet sich ein langes Programm auf eine scheinbar binäre Frage: starten oder verschieben. Technologie berichtet abgeschlossene Tests, der Anbieter meldet Bereitschaft, während Betrieb, Finance, Security oder Fachbereiche offene Punkte sehen. Diese Unterschiede sind nicht automatisch Widerstand. Sie können zeigen, dass jede Funktion einen anderen Teil der Wahrheit misst.

Microsofts Go-live-Leitfaden verbindet technische Freigabe mit Business-Abnahme, Migration, Abhängigkeiten, Change Management, operativem Support, Cutover-Rollen und Verifikation. Die zugrunde liegende Managementfrage ist breiter: Ein System kann bereit sein, während seine Betriebsumgebung es nicht ist. Ein technischer Status sollte deshalb nie allein die Go-live-Entscheidung tragen.

Sechs Evidenzfelder für die Managemententscheidung

Erstens muss der geschäftliche Mindestumfang eindeutig sein. Welche End-to-End-Prozesse müssen am ersten Tag funktionieren? Welche manuellen Workarounds sind vertretbar, für wie lange und mit welchem Eigentümer? Ein hoher Prozentwert abgeschlossener Anforderungen hilft wenig, wenn der fehlende Teil einen kritischen Prozess blockiert.

Zweitens braucht es Testevidenz, nicht nur Teststatus. Entscheidend sind Abdeckung, Repräsentativität, offene Defekte, Retests und die Qualität der Abnahme. Ein geschlossenes Ticket beweist nicht, dass die Ursache behoben oder der End-to-End-Prozess stabil ist.

Drittens muss die Datenmigration fachlich und technisch tragfähig sein. Reconciliation, Vollständigkeit, Datenqualität, Berechtigungen und die Behandlung von Restbeständen gehören in dieselbe Entscheidung. Testmigrationen müssen unter realistischen Zeit- und Volumenbedingungen zeigen, dass Cutover und Rückfalloption funktionieren.

Viertens ist der Betrieb selbst zu prüfen: geschulte Rollen, Supportmodell, Monitoring, Incident- und Problemprozesse, Business Continuity, Kapazität und klare Eskalation. Eine unterschriebene Readiness-Checkliste ist nur dann Evidenz, wenn Kriterien, Nachweise und Verantwortliche nachvollziehbar sind.

Fünftens brauchen Kontrollen, Security und Compliance einen expliziten Platz. Offene Kontrolllücken sind nicht durch allgemeine Risikobereitschaft erledigt. Das Management muss wissen, welche Exposition entsteht, wer sie akzeptieren darf und welche kompensierenden Massnahmen tatsächlich einsatzbereit sind.

Sechstens muss der Cutover als integrierte Operation geprüft werden. Sequenz, Entscheidungsfenster, Kommunikationswege, Abbruchkriterien und Rückfallpunkt müssen über Business, Technologie, Anbieter und Betrieb hinweg konsistent sein. Ein Plan ohne Entscheidungsrechte ist eine Ablaufbeschreibung, keine Steuerung.

Go, conditional go, delay oder reset

Die Entscheidung muss mehr als zwei Zustände kennen. Ein Go ist vertretbar, wenn kritische Outcomes, Kontrollen und Wiederanlaufbedingungen belegt sind. Ein Conditional Go kann sinnvoll sein, wenn verbleibende Lücken begrenzt, beobachtbar und mit klaren Eigentümern sowie kurzen Fristen versehen sind. Eine Verschiebung ist richtig, wenn Evidenz bis zu einem definierten Datum realistisch geschlossen werden kann. Ein Reset wird nötig, wenn die Lücken nicht nur terminlich, sondern strukturell sind — etwa bei unklarer Verantwortung, instabilem Design oder nicht beherrschbarer Migration.

Diese Optionen sollten vor dem finalen Meeting definiert werden. Sonst werden Kriterien unter Zeitdruck umgedeutet, damit die bereits kommunizierte Zielsetzung bestehen bleibt. Vorab vereinbarte Schwellenwerte schützen nicht vor jeder Überraschung, aber sie schützen die Entscheidung vor spontanem Optimismus.

Wie ein unabhängiger Review den Konflikt klärt

Wenn Business und Technologie verschiedene Readiness-Bilder liefern, braucht es keine Abstimmung auf die angenehmste Farbe. Es braucht ein gemeinsames Entscheidungsmodell: Welche Claims sind kritisch, welche Evidenz stützt sie, wo widersprechen sich Quellen und welche Abhängigkeit verändert die Konsequenz? Ein unabhängiger Review verbindet diese Fragmente, ohne selbst Implementierer oder formaler Freigabegeber zu werden.

Das Ergebnis sollte kurz genug für das Entscheidungsgremium und präzise genug für Verantwortlichkeit sein: Empfehlung, Bedingungen, offene Evidenz, unmittelbare Prioritäten und benannte Eigentümer. So wird aus einer emotionalen Termindebatte eine vertretbare Wahl zwischen Continue, Reset und Stop — beziehungsweise Go, Delay und grundlegender Neuaufstellung.

Fragen für das Go-live-Gremium

Das Gremium sollte vor der Sitzung wissen, welche Kriterien nicht verhandelbar sind, welche Restlücken bewusst akzeptiert werden können und wer dafür die formale Entscheidungsbefugnis besitzt. Für jedes kritische Feld braucht es einen Evidenzverweis, nicht eine neue Präsentation. Wo Nachweise fehlen, muss die Lücke als Lücke sichtbar bleiben. Eine Annahme wird nicht belastbarer, weil mehrere Folien sie wiederholen oder sprachlich vorsichtiger formulieren.

Ebenso wichtig ist die erste Phase nach dem Start. Welche Signale zeigen früh, dass Betrieb, Kontrollen oder Kundenwirkung von der Erwartung abweichen? Wer darf den Betrieb begrenzen, einen Rückfall auslösen oder zusätzliche Ressourcen binden? Die Go-live-Entscheidung endet nicht mit dem technischen Schalter. Sie umfasst die Fähigkeit, den neuen Zustand zu beobachten und rechtzeitig zu handeln.