Build-to-Run: Warum Betriebsfähigkeit nicht erst kurz vor dem Go-live betrachtet werden darf.

Ein Programm liefert nicht mit dem Go-live, sondern mit dem stabilen Betrieb. Wer Betriebsfähigkeit erst in den letzten Wochen betrachtet, verlagert die eigentliche Komplexität in eine Phase, in der kaum noch Steuerungsspielraum bleibt.

Beobachtung

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

Bemerkenswert ist die Asymmetrie: Für den Build existieren Governance, Pläne und Reporting. Für den Übergang in den Run existiert oft nur ein Termin. Die Komplexität verschwindet dadurch nicht — sie verschiebt sich in eine Phase mit weniger Zeit, weniger Aufmerksamkeit und weniger Steuerungsmitteln.

Einordnung

Dass große IT-Programme ihre Ziele häufig verfehlen, ist mehrfach dokumentiert. Die Boston Consulting Group berichtet, dass ein erheblicher Anteil großer Technologieprogramme die gesteckten Ziele nicht erreicht, und nennt fehlende durchgängige Planung und ein fehlendes aktives Programmmanagement als wiederkehrende Faktoren.¹ Die gemeinsame Untersuchung von McKinsey und der University of Oxford zu großen IT-Projekten zeigt im Durchschnitt deutliche Budgetüberschreitungen und einen erheblich geringeren Wertbeitrag als geplant.² Beide Quellen betrachten Programme insgesamt, nicht speziell die Betriebsübergabe. Die Verbindung zum Run ist eine eigene Einordnung: Wenn Wertbeitrag erst im Betrieb realisiert wird, ist eine unbetrachtete Betriebsfähigkeit ein plausibler Kanal, über den geplanter Wert verloren geht.

Dass Betrieb kein Anhängsel der Lieferung ist, ist im Service-Management-Standard fest verankert. ITIL 4 und ISO/IEC 20000-1 behandeln Betreibbarkeit, Support und Wiederherstellbarkeit als eigene Anforderungen an ein Service-Management-System, nicht als Abschlussdokument.³ Die Site-Reliability-Engineering-Literatur von Google macht Betreibbarkeit — Monitoring, Alerting, Fehlerbudgets, getestete Wiederherstellung — zu einer Entwurfseigenschaft, die in die Lösung eingebaut wird, nicht nachträglich ergänzt.⁴ Und die „Accelerate"-Forschung von Forsgren, Humble und Kim zeigt datenbasiert, dass leistungsstarke Organisationen Betriebs- und Lieferfähigkeit zusammen denken: schnelle, verlässliche Deployments und schnelle Wiederherstellung gehen mit besserer Gesamtleistung einher.⁵

Der Begriff: Build-to-Run

Build-to-Run bezeichnet die durchgängige Betrachtung der Betriebsfähigkeit über die gesamte Delivery hinweg — von der ersten Architektur- und Governance-Entscheidung bis in den stabilen Regelbetrieb. Der Kern ist keine zusätzliche Phase, sondern eine mitlaufende Steuerungsperspektive mit drei Prinzipien:

1. Run-Anforderungen früh sichtbar machen. Support-Modell, Betriebsverantwortlichkeiten, Datenpflege, Monitoring und Berechtigungskonzept werden nicht erst zum Cutover definiert, sondern als Anforderungen parallel zur Build-Phase geführt.
2. Betriebsfähigkeit als Steuerungsgröße. Der Reifegrad Richtung Betrieb wird sichtbar berichtet — nicht nur der Fortschritt Richtung Go-live. So entsteht Steuerungsspielraum, solange er noch besteht.
3. Übergabe als Prozess, nicht als Termin. Wissenstransfer, Betriebsdokumentation und Rollenklärung werden schrittweise aufgebaut, statt in eine kurze Hypercare-Phase komprimiert zu werden.

Vier Bereiche der Betriebsfähigkeit

1. Ownership. Für jeden produktiven Service ist klar, wer fachlich und wer 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" ist kein Ownership.
2. Operability. Das System lässt sich im Produktivzustand verstehen und steuern: Monitoring, Logging, Alerting, definierte Service Levels, Health Checks, Kapazitäts- und Performance-Informationen sowie nachvollziehbare Deployment-Prozesse. Betreibbarkeit entsteht nicht aus einem Betriebshandbuch allein — sie muss technisch in die Lösung eingebaut sein.
3. Supportability. Support-Teams können Incidents strukturiert bearbeiten: Service- und Support-Modell, klare Tiers, Ticket-Kategorien, bekannte Eskalationswege, Wissensartikel, reproduzierbare Fehlerbilder und eine definierte Zusammenarbeit zwischen Support, Entwicklung und Lieferanten.
4. Recoverability. Die Organisation kann nach Störungen in einen stabilen Zustand zurückkehren: Backup und Restore, Rollback, Disaster-Recovery-Verfahren, Restart-Pläne, getestete Notfallprozesse sowie technische und organisatorische Entscheidungsrechte. Ein ungetesteter Recovery-Plan ist eine Annahme, keine Absicherung.

Build-to-Run entlang des Projektlebenszyklus

• Initiierung. Service Owner identifizieren, Kritikalität und Betriebsmodell klären, interne und externe Verantwortlichkeiten festlegen.
• Architektur & Planung. Nicht-funktionale Anforderungen definieren, Monitoring- und Security-Anforderungen einplanen, Support- und Betriebsprozesse entwerfen, realistische Service Levels ableiten.
• Umsetzung. Logging und Monitoring parallel zur Lösung entwickeln, Betriebsdokumentation laufend aufbauen, automatisierte Deployments und Tests etablieren, Support-Wissen mitentstehen lassen.
• Test. Nicht nur Funktion testen, sondern auch Last, Wiederherstellung und Support-Abläufe; Incident- und Eskalationswege proben; Berechtigungen und Betriebszugriffe verifizieren.
• Cutover & Go-live. Go/No-go-Kriterien um Betriebsreife erweitern, Support-Besetzung und Eskalationswege aktivieren, Monitoring und Alerting auf Produktion schalten, Rollback-Fähigkeit nachweisen.
• Hypercare. Erhöhte Betreuung mit klaren Ausstiegskriterien, tägliche Bewertung kritischer Incidents, Wissenstransfer in die Regel-Supportorganisation, Übergabe erst nach nachgewiesener Stabilisierung.

Hypercare ist keine Dauerlösung

Hypercare sichert sinnvoll die Anfangsphase eines neuen oder stark veränderten Systems. Es darf aber nicht dazu dienen, strukturelle Defizite dauerhaft mit Projektressourcen zu kompensieren. Warnsignale: keine klaren Ausstiegskriterien, dauerhaft erhöhte Projektbesetzung, Support-Tickets, die weiter direkt an die Entwicklung gehen, ein Service Owner ohne tatsächliche Verantwortung, externe Spezialisten als einzige Wissensquelle. Ein erfolgreiches Hypercare endet nicht an einem Kalenderdatum, sondern wenn definierte Stabilitäts- und Übergabekriterien erfüllt sind.

Anwendung in Projekten

• Run-Backlog parallel zum Build. Ein sichtbarer, gepflegter Bestand an betriebsrelevanten Themen (Support, Monitoring, Berechtigungen, Datenpflege, Notfallprozesse) läuft über die gesamte Delivery mit — nicht als Restliste am Ende.
• Betriebsverantwortung früh benennen. Wer den Betrieb später trägt, wird früh eingebunden, damit Architektur- und Prozessentscheidungen die spätere Betreibbarkeit berücksichtigen.
• Operational-Readiness-Kriterien. Neben Abnahmekriterien für die Funktion existieren definierte Kriterien für die Betriebsfähigkeit — Monitoring vorhanden, Support-Wege geklärt, Datenpflege verantwortet, Rollen dokumentiert.
• Übergabe in Etappen. Wissenstransfer und Betriebsdokumentation entstehen begleitend zur Umsetzung, sodass der Go-live kein Wissens- und Verantwortungssprung ist.

Grenzen

Build-to-Run ist ein Praxisbegriff und eine Steuerungsperspektive, kein empirisch validiertes Modell. Die dreiteilige Struktur ist eine Verallgemeinerung aus Projekterfahrung; die zitierten Studien belegen die Häufigkeit verfehlter Programmziele, nicht kausal den Anteil, der auf mangelnde Betriebsvorbereitung entfällt. Nicht jedes Vorhaben braucht denselben Umfang an Run-Vorbereitung — bei kleinen, gut betreuten Systemen kann eine kompakte Übergabe genügen. Der Wert des Konzepts liegt darin, Betriebsfähigkeit früh als bewusste Entscheidung zu behandeln, statt sie als implizites Nebenprodukt entstehen zu lassen.