Die operative Übergabe ist der Moment, in dem eine vor Ort entwickelte Lösung nicht mehr allein auf dem intuitiven Wissen des „Forward Deployed Engineer“ (FDE) beruht, sondern vom Kundenteam gezielt und eigenständig betrieben werden kann. Operative Übergabe bedeutet, dass der Kunde das System im Tagesgeschäft betreiben, bei Störungen Fehler beheben und sichere Änderungen vornehmen kann – ganz ohne Ihre direkte Anwesenheit.
Stellen Sie sich folgendes Szenario vor: Sie haben für HarborView Insurance einen internen, KI-gestützten Dienst zur Triage von Schadensfällen entwickelt. Das System läuft auf Kubernetes mit einer PostgreSQL-Datenbank, einem Redis-Cache und Modellaufrufen hinter einem internen Gateway. Die Pilotphase verlief erfolgreich, die Geschäftsführung möchte das System in die Produktion überführen, und Sie sollen den Standort in drei Wochen verlassen.
In dieser letzten Phase stellt sich nicht die Frage, ob das System heute funktioniert. Entscheidend ist vielmehr, ob HarborView den Betrieb auch bei einem Zwischenfall an einem Dienstagabend aufrechterhalten kann und ob Änderungen im nächsten Quartal möglich sind, ohne versehentlich Sicherheitslücken oder Zuverlässigkeitsprobleme zu verursachen.
Übergaben scheitern meist daran, dass der Begriff „fertig“ unterschiedlich interpretiert wird. Für Sie mag „fertig“ bedeuten, dass das Backlog abgearbeitet ist und die Dashboards „grün“ anzeigen. Der Kunde hingegen versteht darunter vielleicht, dass er Deployments ohne Ihre Unterstützung durchführen kann und das Sicherheitsteam die Zugriffs- und Protokollierungskonzepte freigegeben hat.
Definieren Sie „fertig“ als eine Reihe von Erfolgskriterien, die Aspekte wie Zuverlässigkeit, Sicherheit und die Übernahme der Verantwortung für die Bereitstellung (Delivery Ownership) abdecken. Es geht nicht darum, eine Fehlerfreiheit von 100 % zu garantieren. Vielmehr sollen Sie sicherstellen, dass der Kunde im Falle eines Zwischenfalls in der Lage ist, diesen zu erkennen, zu diagnostizieren und zu beheben – ohne auf Ihr persönliches Hintergrundwissen angewiesen zu sein.
Lernen Sie eine einfache Methode kennen, um zu bewerten, ob die Übergabe tatsächlich abgeschlossen ist.
Das entscheidende Prinzip lautet: Jedes Erfolgskriterium benötigt einen Verantwortlichen und einen Nachweis. Ein Nachweis ist etwas Konkretes, auf das man verweisen kann – etwa ein Link zu einem Runbook, eine abgeschlossene Zugriffsanfrage, ein Eintrag im Bereitschaftsplan oder eine erfolgreiche Bereitstellung (Deployment), die vom Kundenteam unter Ihrer Beobachtung durchgeführt wird.
Nachweise schlagen Versprechen Wenn sich eine Übergabeanforderung nicht in einer kurzen Überprüfung verifizieren lässt, handelt es sich noch nicht um eine echte Anforderung.
Bei einer mangelhaften Übergabe führt der erste Ausfall zu einem weiteren Problem. Während der Ausfall technischer Natur ist, entsteht als zweites Problem eine Unklarheit über die Zuständigkeiten; dies verlängert die Ausfallzeit und löst eine Spirale gegenseitiger Schuldzuweisungen aus.
Stellen Sie sich vor, HarborView meldet einen Alarm: Die p95-Latenz hat sich verdoppelt, und Anfragen laufen in Timeouts. Der Bereitschaftstechniker öffnet das Dashboard und sieht zehn Alarme gleichzeitig aufleuchten. Er weiß nicht, welcher Alarm relevant ist, hat keine Berechtigung für einen Neustart des Kubernetes-Deployments in der Produktion und findet kein Runbook, das beschreibt, wie der Normalbetrieb des Model-Gateways aussehen sollte.
Er kontaktiert Sie, Sie nennen drei Fakten aus der Entwicklungsphase, und das System läuft wieder. Zwei Wochen später tritt das Problem erneut auf – doch diesmal sitzen Sie im Flugzeug, und der Ausfall dauert drei Stunden länger. Die Ursache mag zwar ein „Cache Stampede“ oder ein falsch dimensionierter Datenbank-Verbindungspool sein, doch die lange Dauer ist auf fehlende operative Grundlagen zurückzuführen, nicht auf den Fehler an sich.
Hier zeigt sich, wie fehlende Elemente bei der Übergabe zu langwierigen Vorfällen und unklaren Verantwortlichkeiten führen können.