Das Go-live

Was ist ein Go-live?

Der Duden führt Go-live als Stichwort und definiert es als den Start des Betriebs einer Software oder Website unter realen Bedingungen, den Beginn des Regel- und Produktivbetriebs (Duden). Der Begriff ist also im Deutschen lexikalisiert; als Übersetzung findet sich außerdem Liveschaltung, die Microsoft in seiner deutschen Dokumentation verwendet.

Microsoft beschreibt das Go-live im Implementierungsleitfaden als kritischen Meilenstein bei der Überführung einer Geschäftslösung in den Produktivbetrieb: den Moment, in dem geprüft und bestätigt wird, dass alles wie erwartet funktioniert – nicht jeder Baustein für sich, sondern das Ganze (Microsoft Learn).

Konkret ändert sich mit dem Go-live Folgendes:

• Das Altsystem wird schreibgeschützt oder abgeschaltet.
• Die migrierten Daten werden zu den führenden Daten.
• Die Geschäftsprozesse laufen im neuen System, ohne Doppelerfassung.
• Der Support wechselt vom Projektmodus in den Betriebsmodus.
• Die Anwender erleben die Lücke zwischen dem, was sie gelernt haben, und dem, was sie jetzt tun müssen.

Wer entscheidet über das Go-live, und nach welchen Kriterien?

Das Go-live markiert nicht den Abschluss des Projekts; es ist eine Risikoentscheidung. Sie fällt im Go-/No-go-Gremium und bindet die Fachbereiche genauso wie die IT-Abteilung.

Die Kriterien, die vor einem Gremium Bestand haben, sind wenige und überprüfbar:

1. Das UAT ist abgenommen, mit einer Liste der offenen Fehler und deren Kritikalität, verantwortet vom Fachbereich.
2. Die Datenmigration ist abgestimmt: Salden, Bestände oder Personaldaten des neuen Systems stimmen mit dem Altsystem überein, bis auf dokumentierte Abweichungen.
3. Der Rückfallplan ist geschrieben und geprobt, samt der Uhrzeit, ab der er nicht mehr durchführbar ist.
4. Das Hypercare-Team steht – mit benannten Personen, nicht nur mit Budget.
5. Die Anwender wissen, was am Montagmorgen zu tun ist: wen sie anrufen, wo sie Hilfe finden, welcher Ablauf sich geändert hat.

Für seine Finance-&-Operations-Einführungen formalisiert Microsoft diesen Meilenstein: Die Bereitschaftsprüfung ist spätestens vier Wochen vor dem Go-live anzufordern. Das ist eine brauchbare Größenordnung, um Entscheidungen festzuschreiben, statt sie unter Zeitdruck zu treffen.

Big Bang oder schrittweise Einführung?

Zwei Strategien stehen zur Wahl, und die Entscheidung wirkt stärker auf die Begleitung als auf die Technik.

Beim Big Bang geht der gesamte Umfang auf einmal live. Kemira hat so 400 Werke in 37 Ländern gleichzeitig gestartet, nach 15 Monaten Projektlaufzeit (SAP News Center). Vorteil: keine Übergangsschnittstellen zwischen alter und neuer Welt. Risiko: Alle lernen gleichzeitig, und der Support muss die gesamte Anfragespitze auf einmal auffangen.

Die schrittweise Einführung – nach Land, Gesellschaft oder Modul – verteilt das Risiko und erlaubt, aus der ersten Welle zu lernen. Sie erfordert allerdings temporäre Schnittstellen und doppelte Pflege – und bringt eine Projektmüdigkeit mit sich, die sich über Monate zieht.

Ausschlaggebend ist in der Regel die Aufnahmefähigkeit der Organisation; technische Gründe geben seltener den Ausschlag. Ein belastbares Change Management macht den Big Bang vertretbar; ohne es wird auch die schrittweise Einführung mühsam.

Was das Go-live für die Anwender bedeutet

Ein Projekt wird monatelang von einem Team vorbereitet, das die Lösung im Schlaf beherrscht. Am Tag des Go-live geht sie an Tausende Menschen, die sie zwei Stunden im Schulungsraum gesehen haben – sechs Wochen vorher.

Hier entsteht die teuerste Lücke der Einführung. Die Schulung kam zu früh, um erinnert zu werden, die Dokumentation liegt außerhalb des Bildschirms, und wer um 9:15 Uhr an einem Pflichtfeld hängen bleibt, öffnet kein PDF mit achtzig Seiten: Er fragt den Nachbarn oder arbeitet am System vorbei.

Eine Digital Adoption Platform setzt genau an diesem Moment an: Die Hilfe steckt in der Oberfläche, auf dem richtigen Bildschirm, in der Sekunde des Bedarfs. Sie macht zugleich die tatsächliche Nutzung messbar statt nur die Anmeldungen – und damit überhaupt beurteilbar, ob das Go-live gelungen ist.

Fünf Fehler, die aus einem Go-live eine Krise machen

1. Das Go-live am Datum statt an Kriterien entscheiden. Ein dem Vorstand genanntes Datum lässt sich kaum verschieben, selbst wenn alle Signale für eine Verschiebung sprechen.
2. Zu früh schulen. Eine Schulung sechs Wochen vor der Umstellung ist am Tag X weitgehend vergessen. Begleitung muss im Moment der Nutzung verfügbar sein.
3. Technische Tests mit dem UAT verwechseln. Ein spezifikationskonformes System kann in der täglichen Arbeit unbrauchbar sein.
4. Das Hypercare zu klein dimensionieren. Die Anfragespitze kommt in den ersten Tagen; ein auf den Regelbetrieb ausgelegter Support ist sofort überlastet.
5. Den Rückfallplan nur auf dem Papier haben. Ein ungeprobter Plan ist kein Plan. Und seine zeitliche Grenze muss vor der Umstellung bekannt sein, nicht während.

Fazit

Das Go-live bündelt die Aufmerksamkeit des gesamten Projekts auf wenige Stunden. Das ist berechtigt: Dort ist das Risiko am größten und der Rückweg am teuersten.

Ein technisch gelungenes Go-live kann dennoch fachlich scheitern, wenn die Anwender im neuen System nicht arbeiten können. Die Umstellung entscheidet sich in Stunden, die Akzeptanz in den Wochen danach.

Häufige Fragen