Ein Programm hat sein Ziel erst erreicht, wenn der Betrieb stabil läuft. Der Go-live allein reicht dafür nicht. Wer die Betriebsfähigkeit erst in den letzten Wochen betrachtet, verschiebt die eigentliche Komplexität in eine Phase, in der kaum noch Spielraum für Steuerung bleibt.
Kernaussagen
  • Der Wert einer Transformation entsteht im verlässlichen Regelbetrieb nach dem Go-live. Trotzdem wird die Betriebsfähigkeit oft erst zum Abschluss behandelt.
  • Entscheidungen, die den Betrieb betreffen, fallen bereits in der Build-Phase, ob bewusst oder unbewusst. Dazu gehören Verantwortlichkeiten, Support-Modell, Datenpflege, Monitoring und Berechtigungen. Werden sie nicht bewusst gesteuert, entsteht später Nacharbeit unter Termindruck.
  • Build-to-Run betrachtet die Betriebsfähigkeit über die gesamte Delivery hinweg. Anforderungen an den Betrieb werden früh sichtbar gemacht und als Steuerungsgröße mitgeführt, statt erst beim Cutover geprüft zu werden.

Beobachtung

In komplexen IT- und SAP-Programmen wiederholt sich ein Muster. Die Delivery ist auf den Go-live ausgerichtet, und Meilensteine, Tests, Migration und Abnahme laufen alle auf diesen einen Termin zu. Der Betrieb danach mit Support, Datenpflege, Monitoring, Change-Prozess und Wissenstransfer wird als Hypercare oder Übergabe ans Ende gestellt. In der Praxis zeigt sich dann, dass viele Entscheidungen für den Betrieb längst gefallen sind. Sie wurden implizit getroffen, nämlich in der Art, wie Berechtigungen vergeben, Schnittstellen gebaut oder Daten strukturiert wurden. Diese Beobachtung stammt aus eigener Projektpraxis und erhebt keinen Anspruch auf statistische Allgemeingültigkeit.

Dabei besteht ein deutliches Ungleichgewicht. Für den Build gibt es Governance, Pläne und Reporting. Für den Übergang in den Betrieb gibt es oft nur einen Termin. Die Komplexität verschwindet dadurch nicht. Sie verschiebt sich in eine Phase, in der weniger Zeit, weniger Aufmerksamkeit und weniger Steuerungsmittel zur Verfügung stehen.

Einordnung

Dass große IT-Programme ihre Ziele häufig verfehlen, ist mehrfach dokumentiert. Die Boston Consulting Group berichtet, dass ein erheblicher Teil großer Technologieprogramme die gesetzten Ziele nicht erreicht. Als wiederkehrende Faktoren nennt sie eine fehlende durchgängige Planung und ein fehlendes aktives Programmmanagement.1 Die gemeinsame Untersuchung von McKinsey und der University of Oxford zeigt für große IT-Projekte im Durchschnitt deutliche Budgetüberschreitungen und einen erheblich geringeren Wertbeitrag als geplant.2 Beide Quellen betrachten Programme insgesamt und nicht speziell die Übergabe in den Betrieb. Die Verbindung zum Betrieb ist eine eigene Einordnung. Wenn der Wert erst im Betrieb entsteht, ist eine vernachlässigte Betriebsfähigkeit ein plausibler Weg, auf dem geplanter Wert verloren geht.

Im Service Management ist fest verankert, dass der Betrieb kein Anhängsel der Lieferung ist. ITIL 4 und ISO/IEC 20000-1 behandeln Betreibbarkeit, Support und Wiederherstellbarkeit als eigene Anforderungen an ein Service-Management-System.3 Die Literatur zum Site Reliability Engineering von Google beschreibt Betreibbarkeit als Eigenschaft des Entwurfs. Monitoring, Alerting, Fehlerbudgets und getestete Wiederherstellung werden in die Lösung eingebaut und nicht nachträglich ergänzt.4 Die Accelerate-Forschung von Forsgren, Humble und Kim zeigt auf Datenbasis, dass schnelle und verlässliche Deployments und eine schnelle Wiederherstellung mit besserer Gesamtleistung einhergehen.5

Der Begriff: Build-to-Run

Build-to-Run bezeichnet die durchgängige Betrachtung der Betriebsfähigkeit während der gesamten Delivery, von der ersten Entscheidung über Architektur und Governance bis in den stabilen Regelbetrieb. Gemeint ist keine zusätzliche Phase. Gemeint ist eine Perspektive, die die Steuerung von Anfang an begleitet und drei Prinzipien folgt.

  • Anforderungen an den Betrieb früh sichtbar machen: Support-Modell, Betriebsverantwortung, Datenpflege, Monitoring und Berechtigungskonzept werden nicht erst zum Cutover festgelegt. Sie werden als Anforderungen parallel zur Build-Phase geführt.
  • Betriebsfähigkeit als Steuerungsgröße: Berichtet wird auch, wie weit die Lösung für den Betrieb bereit ist, und nicht nur der Fortschritt in Richtung Go-live. So bleibt Spielraum für Steuerung, solange er noch besteht.
  • Übergabe als Prozess: Wissenstransfer, Betriebsdokumentation und die Klärung der Rollen werden schrittweise aufgebaut. Sie werden nicht in eine kurze Hypercare-Phase gedrängt.

Vier Bereiche der Betriebsfähigkeit

  • Ownership: Für jeden produktiven Service ist klar, wer ihn fachlich und technisch verantwortet, wer über Changes entscheidet, wer Incidents und technische Schulden priorisiert und wer nach Projektende die Verantwortung übernimmt. Eine anonyme Übergabe „an den Betrieb" schafft keine Verantwortung.
  • Operability: Das System lässt sich im Produktivbetrieb verstehen und steuern. Dafür braucht es Monitoring, Logging, Alerting, definierte Service Levels, Health Checks, Informationen zu Kapazität und Performance sowie nachvollziehbare Deployment-Prozesse. Ein Betriebshandbuch allein reicht dafür nicht. Die Betreibbarkeit muss technisch in die Lösung eingebaut sein.
  • Supportability: Support-Teams können Incidents strukturiert bearbeiten. Voraussetzung sind ein Service- und Support-Modell, klare Support-Stufen, Ticket-Kategorien, bekannte Eskalationswege, Wissensartikel, reproduzierbare Fehlerbilder und eine definierte Zusammenarbeit zwischen Support, Entwicklung und Lieferanten.
  • Recoverability: Die Organisation kann nach Störungen in einen stabilen Zustand zurückkehren. Dazu gehören Backup und Restore, Rollback, Verfahren für Disaster Recovery, Restart-Pläne, getestete Notfallprozesse sowie technische und organisatorische Entscheidungsrechte. Ein ungetesteter Recovery-Plan ist eine Annahme und keine Absicherung.

Build-to-Run entlang des Projektlebenszyklus

  1. Initiierung: Der Service Owner wird benannt. Kritikalität und Betriebsmodell werden geklärt, und interne wie externe Verantwortlichkeiten werden festgelegt.
  2. Architektur und Planung: Nichtfunktionale Anforderungen werden definiert, Anforderungen an Monitoring und Security werden eingeplant, Support- und Betriebsprozesse werden entworfen, und realistische Service Levels werden abgeleitet.
  3. Umsetzung: Logging und Monitoring entstehen parallel zur Lösung. Die Betriebsdokumentation wächst laufend mit, automatisierte Deployments und Tests werden eingeführt, und das Wissen für den Support entsteht während der Umsetzung.
  4. Test: Getestet werden neben der Funktion auch das Verhalten unter Last, die Wiederherstellung und die Abläufe im Support. Incident- und Eskalationswege werden geprobt, Berechtigungen und Betriebszugriffe werden geprüft.
  5. Cutover und Go-live: Die Go/No-go-Kriterien werden um die Betriebsreife erweitert. Support-Besetzung und Eskalationswege werden aktiviert, Monitoring und Alerting werden auf die Produktion umgestellt, und die Fähigkeit zum Rollback wird nachgewiesen.
  6. Hypercare: Die Betreuung ist für eine begrenzte Zeit intensiver und hat klare Kriterien für ihr Ende. Kritische Incidents werden täglich bewertet, das Wissen geht in die reguläre Support-Organisation über, und die Übergabe erfolgt erst nach nachgewiesener Stabilisierung.

Hypercare ist keine Dauerlösung

Hypercare sichert die Anfangsphase eines neuen oder stark veränderten Systems sinnvoll ab. Es darf aber nicht dazu dienen, strukturelle Mängel dauerhaft mit Projektressourcen auszugleichen. Aus der Projektpraxis sind mehrere Warnsignale bekannt. Es gibt keine klaren Kriterien für das Ende, die Projektbesetzung bleibt dauerhaft erhöht, Support-Tickets gehen weiter direkt an die Entwicklung, der Service Owner hat keine tatsächliche Verantwortung, oder externe Spezialisten sind die einzige Wissensquelle. Ein erfolgreiches Hypercare endet, wenn festgelegte Kriterien für Stabilität und Übergabe erfüllt sind, und nicht an einem bestimmten Datum.

Anwendung in Projekten

  • Run-Backlog parallel zum Build: Ein sichtbarer und gepflegter Bestand an Themen für den Betrieb läuft über die gesamte Delivery mit. Dazu gehören Support, Monitoring, Berechtigungen, Datenpflege und Notfallprozesse. Er wird nicht erst am Ende als Restliste geführt.
  • Betriebsverantwortung früh benennen: Wer den Betrieb später trägt, wird früh eingebunden. So berücksichtigen Entscheidungen über Architektur und Prozesse die spätere Betreibbarkeit.
  • Kriterien für die Betriebsbereitschaft: Neben den Abnahmekriterien für die Funktion gibt es festgelegte Kriterien für die Betriebsfähigkeit. Das Monitoring ist vorhanden, die Support-Wege sind geklärt, die Datenpflege ist verantwortet, und die Rollen sind dokumentiert.
  • Übergabe in Etappen: Wissenstransfer und Betriebsdokumentation entstehen während der Umsetzung. Dadurch bedeutet der Go-live keinen plötzlichen Sprung bei Wissen und Verantwortung.

Grenzen

Build-to-Run ist ein Begriff aus der Praxis und eine Perspektive für die Steuerung, aber kein empirisch validiertes Modell. Die Struktur aus drei Prinzipien ist eine Verallgemeinerung aus Projekterfahrung. Die zitierten Studien belegen, wie häufig Programme ihre Ziele verfehlen. Sie belegen nicht, welcher Anteil davon auf mangelnde Vorbereitung des Betriebs zurückgeht. Nicht jedes Vorhaben braucht dieselbe Vorbereitung. Bei kleinen, gut betreuten Systemen kann eine kompakte Übergabe genügen. Der Wert des Konzepts liegt darin, über die Betriebsfähigkeit früh und bewusst zu entscheiden, statt sie nebenbei entstehen zu lassen.