Bildquelle: Pexels / https://www.pexels.com/photo/7688336/
Nach dem Go-live beginnt das eigentliche Betriebsrisiko
Ein IT-Projekt wirkt oft fertig, sobald der neue Service live ist. Der Auftrag ist abgeschlossen, das Projektteam zieht weiter und im Kalender steht ein Erfolgstermin. Für den Betrieb beginnt genau dann die riskanteste Phase. Nutzer melden echte Fälle, Schnittstellen reagieren anders als im Test, Berechtigungen fehlen und der Service Desk muss erklären, was bis gestern noch niemand im Alltag gesehen hat.
Der Go-live ist deshalb kein Zielstrich, sondern ein Übergang. Wer diesen Übergang zu knapp plant, verschiebt die Arbeit nur vom Projekt in den Betrieb. Aus offenen Fragen werden Tickets, aus fehlenden Rollen werden Eskalationen und aus kleinen Lücken werden Vertrauensprobleme. Gute Betriebsübergabe sorgt nicht für mehr Bürokratie. Sie verhindert, dass ein neuer Service in den ersten Wochen unter Alltagssituationen zerreibt.
Ein Live-System ist noch kein betriebsfähiger Service
Ein Projekt misst Erfolg häufig an Lieferung. Der Service ist erreichbar, die wichtigsten Funktionen laufen und die Abnahme ist unterschrieben. Der Betrieb misst Erfolg anders. Er fragt, wer nachts reagiert, wie Nutzer Hilfe bekommen, welche Fehlermeldungen kritisch sind, welche Änderungen erlaubt bleiben und wann ein Problem an das Projekt zurückgeht. Diese Fragen sind nicht kleiner als die technische Lieferung. Sie entscheiden, ob die Lösung verlässlich wird.
Atlassian ordnet Change Management im IT Service Management als strukturierte Steuerung von Änderungen ein. Der Kern ist nicht die Verhinderung von Veränderung, sondern die Kontrolle von Risiko und Wirkung. Für die Betriebsübergabe heißt das. Der neue Service braucht einen nachvollziehbaren Übergang von Projektwissen zu Betriebswissen. Sonst weiß das Projekt viel, aber der Betrieb trägt die Verantwortung ohne denselben Kontext.
Der Service Desk braucht Antworten vor den ersten Tickets
Der Service Desk ist oft die erste Stelle, an der ein holpriger Go-live sichtbar wird. Nutzer fragen nicht nach Architekturentscheidungen. Sie fragen, warum eine Anmeldung nicht klappt, welche Daten fehlen, warum ein Prozess anders aussieht oder ob eine Störung schon bekannt ist. Wenn der Service Desk darauf nur mit Rückfragen an das Projektteam reagieren kann, verlängert sich jeder Fall.
Vor dem Go-live sollten deshalb mindestens vier Dinge vorliegen. Erstens eine kurze Beschreibung des neuen Service in Alltagssprache. Zweitens die häufigsten Nutzerfragen mit klaren Antworten. Drittens ein Eskalationsweg mit Namen, Rollen und Zeiten. Viertens bekannte Einschränkungen, die nicht als Überraschung im Ticket landen dürfen. Das ist keine große Wissensdatenbank. Es ist die Startausrüstung für die ersten echten Fälle.
Rollen müssen nach dem Projekt weiterleben
In Projekten gibt es meist klare Ansprechpartner. Im Betrieb verschwimmen diese Rollen schnell. Produktverantwortung, technischer Betrieb, Service Owner, Security, Einkauf, Fachbereich und Lieferant sehen jeweils nur einen Teil. Der neue Service braucht aber eine Stelle, die fachliche Wirkung, technische Stabilität und Nutzererfahrung zusammenhält. Ohne diese Stelle entsteht ein Vakuum.
ITIL 4 betont den Wert von Practices und kontinuierlicher Verbesserung. Für Generalisten ist daran wichtig. Ein Service wird nicht nur durch Prozesse gesteuert, sondern durch gelebte Verantwortlichkeit. Wer bewertet Rückmeldungen nach dem Start. Wer priorisiert Nacharbeiten. Wer entscheidet, ob ein Workaround tragfähig ist. Wer sagt, dass ein Problem nicht mehr Projektarbeit, sondern dauerhaftes Betriebsrisiko ist. Diese Fragen müssen vor dem Übergang geklärt sein.
Die ersten Wochen brauchen eine andere Steuerung
Ein neuer Service sollte in den ersten Wochen nicht sofort wie ein alter Standardservice behandelt werden. Die Lage ist instabiler. Nutzer lernen neue Abläufe, Monitoringwerte haben noch wenig Vergleich, Supportartikel müssen nachgeschärft werden und kleine Fehlannahmen zeigen sich erst unter Last. Genau deshalb hilft eine kurze Hypercare-Phase. Sie bündelt Rückmeldungen, schnelle Korrekturen und klare Entscheidungen.
Hypercare ist kein Freibrief für Dauerimprovisation. Sie braucht einen Anfang, ein Ende und messbare Kriterien. Welche Ticketmuster werden täglich geprüft. Welche Fehler gehen zurück ins Projekt. Welche Nacharbeiten sind nur Komfort, welche sind betriebsnotwendig. Welche Entscheidung führt zum Stopp weiterer Ausrollung. Ohne solche Kriterien wird Hypercare zur weichen Übergangszone, in der niemand mehr sauber trennt, was geliefert, offen oder akzeptiert ist.
Messpunkte schützen vor Bauchgefühl
Nach einem Go-live entstehen schnell unterschiedliche Wahrheiten. Das Projekt sieht erledigte Arbeit. Der Betrieb sieht Störungen. Nutzer sehen Wartezeit. Das Management sieht einen Terminplan. Messpunkte helfen, diese Perspektiven zusammenzubringen. Dazu gehören Ticketvolumen, Wiederholungsfälle, Lösungszeit, Eskalationen, bekannte Fehler, Verfügbarkeit, Nutzerfeedback und offene Risiken.
Wichtig ist, diese Zahlen nicht als Schuldfrage zu nutzen. Sie sollen zeigen, ob der Service im Alltag stabiler wird. Steigen Rückfragen trotz Schulung, fehlt vielleicht eine bessere Erklärung. Häufen sich Berechtigungsfälle, ist der Rollenprozess nicht sauber genug. Bleiben dieselben technischen Fehler offen, braucht das Thema eine Priorität im Backlog. Messpunkte übersetzen Bauchgefühl in Entscheidungen.
Der Rückweg gehört zur Übergabe
Ein belastbarer Übergang enthält auch die Frage, was passiert, wenn der Start nicht trägt. Das muss nicht immer ein technischer Rollback sein. Manchmal reicht ein begrenzter Nutzerkreis, eine zusätzliche Freigabe, eine temporäre Umleitung im Support oder eine klare Pause für weitere Standorte. Entscheidend ist, dass diese Optionen vorher benannt sind. In der Störung ist es zu spät, Zuständigkeit und Grenzen neu zu verhandeln.
Die britische Service-Standard-Dokumentation betont für öffentliche digitale Services unter anderem, dass Dienste nutzerorientiert, betreibbar und kontinuierlich verbessert werden müssen. Übertragen auf IT-Management heißt das. Ein Service ist nicht fertig, weil er veröffentlicht wurde. Er ist erst dann belastbar, wenn echte Nutzung, Support, Betrieb und Verbesserung zusammen funktionieren.
Praktische Übergabeprüfung vor dem Livegang
Vor dem Go-live hilft eine kurze, harte Prüfung. Kann der Service Desk den Service in zwei Sätzen erklären. Gibt es eine aktuelle Kontakt- und Eskalationsliste. Sind die wichtigsten Fehlerszenarien beschrieben. Ist klar, wer bekannte Einschränkungen gegenüber Nutzern erklärt. Sind Monitoring, Logs und Alarme den richtigen Rollen zugeordnet. Gibt es eine Entscheidung, wann der Ausrollplan gestoppt wird. Ist festgelegt, wann Projekt und Betrieb gemeinsam auf die ersten Messwerte schauen.
Wenn eine dieser Fragen offen bleibt, ist der Service nicht automatisch unreif. Aber das Risiko muss sichtbar sein. Dann kann bewusst entschieden werden, ob der Go-live trotzdem vertretbar ist, welche Zusatzsicherung nötig wird und welcher Punkt nach dem Start sofort geschlossen werden muss. Genau diese Transparenz unterscheidet kontrollierte Betriebsübergabe von Hoffnung.
Fazit
Der gefährliche Moment eines IT-Projekts liegt oft nicht vor dem Go-live, sondern direkt danach. Dort zeigt sich, ob aus Lieferung ein verlässlicher Service wird. Betriebsübergabe ist deshalb keine Formalie am Ende. Sie ist der Moment, in dem Verantwortung, Wissen, Messung und Handlungsfähigkeit zusammenfinden müssen. Wer das ernst nimmt, schützt nicht nur den Betrieb. Er schützt auch den Projekterfolg vor einem schlechten ersten Alltag.
