Der Betrieb beginnt vor dem Go-live

Eine neue Anwendung besteht den Abnahmetest, die Daten wurden migriert und der Terminplan zeigt grün. Das Projekt erklärt den Go-live zum Erfolg. Am nächsten Morgen beginnt jedoch eine andere Art von Arbeit: Nutzer melden Störungen, Zertifikate laufen weiter, Schnittstellen liefern Fehler und jemand muss entscheiden, ob zurückgerollt oder im neuen System weitergearbeitet wird.

Ein Projekt kann fertig sein, obwohl der Betrieb noch nicht vorbereitet ist. Fachliche Abnahme beantwortet, ob die Lösung die vereinbarten Anforderungen erfüllt. Betriebsreife beantwortet, ob die Organisation sie unter normalen und gestörten Bedingungen verantworten, beobachten, unterstützen und verändern kann.

Der Betrieb beginnt deshalb nicht nach dem Go-live. Seine Voraussetzungen müssen vor der Produktivsetzung nachgewiesen oder als bewusstes Restrisiko entschieden werden.

Funktionsfähig ist nicht gleich betriebsfähig

Ein erfolgreicher Test zeigt nur das, was unter den getesteten Bedingungen geprüft wurde. Er sagt nicht automatisch, ob der Service im Alltag beherrschbar ist.

Betriebsfähigkeit umfasst mindestens:

• einen benannten Service Owner und operative Verantwortungen,
• einen erreichbaren Supportweg mit Prioritäten und Eskalation,
• Monitoring für technische und fachliche Fehlersignale,
• Sicherung, Wiederherstellung und einen Rückfallweg,
• dokumentierte Zugänge, Rollen und Notfallberechtigungen,
• bekannte Kapazitätsgrenzen und Betriebszeiten,
• Wartungs-, Patch- und Änderungsverfahren,
• aktuelle Betriebs- und Wiederanlaufdokumentation,
• geregelte Hersteller- und Dienstleisterkontakte,
• Lizenzen, Verträge und Abhängigkeiten für den laufenden Betrieb,
• akzeptierte bekannte Fehler und Restrisiken.

Die Liste ist kein Pflichtformular für jedes kleine Vorhaben. Sie beschreibt die Fragen, deren Relevanz vor dem Go-live entschieden werden muss.

Betriebsanforderungen gehören in das Projekt

Wenn der Betrieb erst kurz vor dem Go-live beteiligt wird, kann er nur noch Dokumente anfordern und Bedenken anmelden. Architektur, Verträge, Protokollierung und Supportmodell sind dann meist bereits festgelegt.

Die Betriebsanforderungen sollten deshalb während der Konzeption entstehen:

• Welche Servicezeiten und Wiederanlaufziele werden benötigt?
• Welche Mengen, Lastspitzen und Wachstumssignale sind zu erwarten?
• Welche Ereignisse müssen erkannt und an wen gemeldet werden?
• Welche Daten müssen gesichert, aufbewahrt oder gelöscht werden?
• Welche Änderungen darf das interne Team selbst durchführen?
• Welche Fähigkeiten und Werkzeuge benötigt der Support?
• Welche Nachweise muss ein Lieferant bereitstellen?
• Wie lässt sich die Lösung geordnet ablösen oder zurückrollen?

NIST SP 800-160 Vol. 1 Rev. 1 betrachtet Transition, Validierung, Betrieb und Wartung als zusammenhängende Prozesse im Systemlebenszyklus. Das ist für mittelständische Projekte ein hilfreicher Blick: Betrieb ist kein Empfänger am Ende einer Lieferkette, sondern ein Stakeholder mit eigenen Anforderungen.

Konstruiertes Beispiel: Abgenommen, aber nicht übernommen

Das folgende Beispiel ist konstruiert.

Eine neue Lageranwendung wird fachlich getestet und zum vereinbarten Termin produktiv gesetzt. Scanner erfassen Warenbewegungen, und die Schnittstelle überträgt Buchungen in das ERP. Das Projektteam löst sich anschließend auf.

Wenige Wochen später läuft ein Zertifikat der Schnittstelle ab. Das zentrale Monitoring prüft nur, ob der Server erreichbar ist; die stehen gebliebenen Buchungen erkennt es nicht. Der Service Desk kennt die Anwendung, aber nicht die Grenze zwischen internem Support und Herstellerleistung. Für den manuellen Notbetrieb existiert eine Präsentationsfolie, jedoch keine ausführbare Anleitung.

Der Fehler liegt nicht zwingend in der Software. Es fehlt ein Übergang, der Verantwortung, Beobachtung, Support, Wiederanlauf und Lieferantenweg als Teil der Lösung behandelt. Ein weiterer fachlicher Abnahmetest hätte diese Lücke nicht geschlossen.

Ein Go-live braucht zwei Blickrichtungen

Vor der Produktivsetzung sollten fachliche und betriebliche Abnahme unterscheidbar sein.

Die fachliche Abnahme prüft etwa:

• Unterstützt die Lösung den vorgesehenen Prozess?
• Sind Daten und Ergebnisse fachlich korrekt?
• Können die vorgesehenen Rollen ihre Aufgaben ausführen?
• Sind notwendige Ausnahmen und Kontrollen berücksichtigt?

Die betriebliche Abnahme prüft dagegen:

• Kann der Service überwacht, unterstützt und wiederhergestellt werden?
• Sind Zuständigkeiten und Entscheidungsrechte verfügbar?
• Sind Betriebsgrenzen und Abhängigkeiten bekannt?
• Können Changes, Patches und Herstellereskalationen kontrolliert durchgeführt werden?
• Ist der Betrieb mit Personal, Vertrag und Budget tatsächlich ausgestattet?

Eine Person kann in kleinen Organisationen mehrere Rollen wahrnehmen. Die beiden Perspektiven dürfen trotzdem nicht zu einem unklaren „alles getestet“ verschmelzen.

Abnahmekriterien müssen vor dem Test feststehen

FitSM ordnet dem Release and Deployment Management unter anderem Planung, Test, Abnahmekriterien, Rückfallvorbereitung und Erfolgsbewertung zu. Der entscheidende Punkt ist die Reihenfolge: Kriterien werden vor dem Deployment festgelegt, nicht nach einem erfolgreichen Termin rückwirkend passend formuliert.

Ein Nachweis sollte beobachtbar sein. „Monitoring vorhanden“ ist schwach. „Ein fehlgeschlagener Import erzeugt innerhalb des definierten Intervalls einen Alarm an die Betriebsrolle und ein Ticket mit Servicebezug“ ist prüfbar.

Weitere prüfbare Kriterien können sein:

• Ein Supportfall erreicht mit den vereinbarten Informationen die richtige Gruppe.
• Eine Wiederherstellung wurde in der vorgesehenen Umgebung erfolgreich durchgeführt.
• Eine fachliche Kontrollsumme erkennt fehlende oder doppelte Übertragungen.
• Der dokumentierte Notfallzugang funktioniert ohne das Projektkonto.
• Die Rufnummer und Vertragskennung des Herstellers sind für Berechtigte erreichbar.
• Der Rückfallweg besitzt eine klare Entscheidungsfrist und verantwortliche Rolle.

Dokumentenübergabe ist noch kein Wissenstransfer

Ein Ordner mit Architekturdiagrammen, Testprotokollen und Handbüchern kann vollständig wirken und im Störfall trotzdem unbrauchbar sein. Das Betriebsteam muss die entscheidenden Tätigkeiten ausführen können.

Ein belastbarer Wissenstransfer enthält deshalb praktische Nachweise:

• Support bearbeitet einen vorbereiteten Fehlerfall.
• Betrieb startet, stoppt und prüft die relevanten Komponenten.
• Ein Restore oder Rückfall wird mindestens repräsentativ geprobt.
• Eskalationskontakte und Berechtigungen werden tatsächlich verwendet.
• Bekannte Fehler und Übergangslösungen werden im Arbeitssystem auffindbar gemacht.
• Kritische Schritte funktionieren ohne die Person, die sie dokumentiert hat.

Der Beitrag „Technische Dokumentation muss im Ausfall helfen“ zeigt, wie sich Dokumentation an Entscheidungen und Tätigkeiten statt an Vollständigkeit ausrichten lässt.

Abweichungen benötigen einen Entscheider, nicht nur eine rote Ampel

Kaum ein Go-live erfüllt jeden wünschenswerten Punkt vollständig. Ein starres Gate kann dann zur formalen Übung werden: offene Punkte werden umbenannt, damit der Termin hält.

Besser ist eine sichtbare Abweichungsentscheidung. Für jeden fehlenden Nachweis werden festgehalten:

• konkrete Lücke und betroffener Service,
• mögliche Betriebs- und Geschäftsfolge,
• zeitweise Gegenmaßnahme,
• verantwortlicher Entscheider,
• Umsetzungsowner und verbindlicher Termin,
• Auslöser für Verschiebung oder Abbruch des Go-lives.

Ein fehlender Nice-to-have-Bericht ist anders zu behandeln als ein ungeprüfter Wiederherstellungsweg. Die Entscheidungstiefe folgt Wirkung und Reversibilität.

Die Betriebsreife-Karte

Eine kompakte Karte macht den Übergang entscheidungsfähig.

Prüffeld	Erwarteter Nachweis
Service und Owner	benannte Leistung, Nutzer und fachliche Verantwortung
Support	Eingang, Priorisierung, Zuständigkeit, Eskalation und Betriebszeit
Beobachtung	technische und fachliche Signale mit Reaktionsweg
Wiederanlauf	Sicherung, Restore, Notbetrieb, Rückfall und getestete Zeiten
Sicherheit	Rollen, privilegierte Zugänge, Protokollierung und offene Risiken
Kapazität	erwartete Last, Grenzen, Wachstumssignal und Reaktion
Änderungen	Wartungsfenster, Standardwege, Herstelleranteil und Freigaben
Dokumentation	ausführbare Betriebs-, Fehler- und Wiederanlaufanleitungen
Lieferanten	Vertrag, Supportkennung, Ansprechpartner und Leistungsgrenze
Übergabe	Übungen, bekannte Fehler, Schulung und bestätigte Übernahme
Abweichungen	Risiko, Gegenmaßnahme, Entscheider, Owner und Termin

Die Karte ergänzt Projekt- und Abnahmeplanung. Sie ersetzt weder technische Tests noch fachliche Verantwortung.

Eine Übergangsphase braucht ein Ende

Nach größeren Einführungen ist eine Phase erhöhter Betreuung sinnvoll. Häufig wird sie „Hypercare“ genannt. Ohne Austrittskriterien wird daraus jedoch ein dauerhaftes Schatten-Supportmodell, in dem Projektmitglieder alle Probleme informell auffangen.

Die Übergangsphase sollte festlegen:

• welche zusätzlichen Rollen und Zeiten gelten,
• welche Fehler direkt zum Projektteam gelangen,
• wie Erkenntnisse in den regulären Support überführt werden,
• welche Kennzahlen und offenen Fehler beobachtet werden,
• wann die normale Betriebsorganisation vollständig übernimmt.

Das Ende richtet sich nicht allein nach einem Kalenderdatum. Es kann an stabilen Betrieb, geschlossene kritische Fehler, abgeschlossenen Wissenstransfer und funktionierende Regelprozesse gebunden sein.

Kleine Änderungen brauchen ein kleines Gate

Ein internes Werkzeug mit wenigen Nutzern, geringem Datenrisiko und einfachem Rückfallweg benötigt keine mehrwöchige Betriebsabnahme. Eine kurze Checkliste, ein Owner, ein Supportweg und ein getesteter Rückfall können genügen.

Mehr Prüftiefe ist angemessen, wenn der Service geschäftskritisch, stark integriert, extern betrieben, schwer rückgängig zu machen oder sicherheitsrelevant ist. Das Gate wird nicht nach Projektbudget skaliert, sondern nach Betriebswirkung.

Der Go-live ist dann kein Sprung vom Projekt in die Unklarheit. Er ist eine bewusst vorbereitete Übergabe: Das Geschäft bestätigt den Nutzen, der Betrieb bestätigt seine Handlungsfähigkeit, und verbleibende Risiken besitzen einen benannten Entscheider.