Phase 08 / 08 TRANSFORM

Operate

Vom stabilen Betrieb zur lernenden, selbstfahrenden Organisation

Die Operate-Phase etabliert den dauerhaften, weitgehend autonomen Betrieb der agentischen Ziellandschaft: SRE-basierte Zuverlässigkeitssteuerung, agentische Incident-Behandlung, kontinuierliche KI-Governance und eine Verbesserungsschleife, die Betriebserkenntnisse in Strategie und Backlog zurückspeist — damit wird die Organisation im Wortsinn selbstfahrend.

Best-Practice-Anleitung als PDF laden

Einordnung der Phase im TRANSFORM-Vorgehensmodell

Operate

Vorgehensmodell

Ergebnis ist ein messbar zuverlässiger, komplianter und wirtschaftlicher Betrieb: eingehaltene SLOs, autonome Behebung von Standardstörungen, kontinuierliches Modell- und Kostenmanagement sowie ein etablierter Verbesserungszyklus zurück in die TRANSFORM-Phasen.

Service- & SLO-Design

Observability & AIOps

Autonomer Betrieb & Incident-Management

KI-Governance & Model Operations

Kontinuierliche Verbesserung & Wertnachweis

Service- & SLO-Design

Definition von Service Level Indicators und Objectives je Service und Agent; Vereinbarung von Error Budgets als Steuerungsinstrument zwischen Fachbereich, Betrieb und Delivery.

Observability & AIOps

Durchgängige Telemetrie (Metriken, Logs, Traces, Agenten-Entscheidungen); agentische Anomalieerkennung und Ursachenanalyse über die gesamte Landschaft.

Autonomer Betrieb & Incident-Management

Self-Healing für Standardstörungen durch Operations-Agenten; strukturiertes Incident-Management mit Human-Eskalation und blameless Post-Mortems nach SRE-Praxis.

KI-Governance & Model Operations

Laufende Überwachung von Modellverhalten, Drift und Guardrail-Einhaltung; Compliance-Nachweise nach EU AI Act und NIST AI RMF; kontrollierte Modell- und Prompt-Releases über die Eval-Suiten.

Kontinuierliche Verbesserung & Wertnachweis

FinOps-basierte Kostensteuerung, Messung des realisierten Wertbeitrags gegen die OKRs; Rückspeisung von Verbesserungsbedarfen in Strategy- und Plan-Phase.

Methodik-Mix

Selbstfahrender Betrieb mit Governance und kontinuierlicher Verbesserung

Methode	Einsatzzweck im TRANSFORM-Kontext	Referenz
Site Reliability Engineering (SRE)	SLIs, SLOs und Error Budgets als quantitative Zuverlässigkeitssteuerung; Automatisierung vor Personaleinsatz.	Beyer et al. (Google, 2016)
ITIL 4 — Service Value System	Rahmenwerk für Service-Management-Praktiken (Incident, Problem, Change) im Zusammenspiel mit agiler Lieferung.	PeopleCert/Axelos
AIOps	KI-gestützte Anomalieerkennung, Ereigniskorrelation und Ursachenanalyse im IT-Betrieb; wissenschaftlich fundierte Failure-Management-Methoden.	Notaro et al. (2021)
EU AI Act & NIST AI RMF	Regulatorischer und risikobasierter Rahmen für den Betrieb von KI-Systemen; Grundlage der Compliance-Nachweise.	EU 2024/1689; NIST
FinOps	Betriebsmodell für die wirtschaftliche Steuerung von Cloud- und KI-Ressourcen (inkl. Token-Ökonomie der Agenten).	FinOps Foundation
Kontinuierliche Verbesserung (PDCA/Kaizen)	Systematische Lernschleife aus Betriebsdaten zurück in Strategie, Backlog und Architektur; schließt den TRANSFORM-Zyklus.	Deming; ITIL CSI

Plattform-Unterstützung

ReqPOOL Suite: REAM (Enterprise-Architektur) · SLIP (Reverse Engineering — Whitebox)

REAM — Lifecycle- & Architekturmanagement

Lifecycle- und Architekturmanagement in einem Inventar: jede produktive Anwendung mit Verantwortlichkeiten, Technologie-Stack und Lebenszyklusstatus.

REAM — End-of-Support & technische Schulden

Automatische End-of-Support-Erkennung und Monitoring technischer Schulden; die Ergebnisse speisen die kontinuierliche Transformations-Roadmap.

REAM — Kreislauf zur Strategie

Neue Bedarfe aus dem Betrieb speisen den nächsten Ideation-Zyklus — der Lifecycle schließt sich zum kontinuierlichen Kreislauf.

SLIP — lebende Systemdokumentation

Quellenbelegte Dokumentation, Wissensgraph und KI-Assistent bleiben als Arbeitsmittel im Betrieb — das Systemwissen hängt nicht mehr an einzelnen Köpfen.

SLIP — Impact-Analysen im Betrieb

Vor jeder Änderung beantwortet der Assistent die Frage „Was geht kaputt, wenn ich das ändere?“ — auf Basis des tatsächlichen Codes statt veralteter Dokumente.

Best Practices der Plattformnutzung

Jede Änderung am Produktivsystem mit einer SLIP-Impact-Analyse vorbereiten; ungeklärte Abhängigkeiten blockieren den Change.
Die Systemdokumentation nach jedem Release aktualisieren — veraltete Doku ist ein Betriebsrisiko, keine Formalie.
End-of-Support- und Schulden-Signale aus REAM quartalsweise bewerten und als Bedarfe in den nächsten Ideation-Zyklus geben.
Error Budgets konsequent durchsetzen — bei Unterschreitung stoppt die Release-Pipeline automatisch, Ausnahmen entscheidet der Lenkungsausschuss.
Post-Mortems blameless führen und Maßnahmen als Backlog-Items in die Plan-Phase zurückspielen; Erkenntnisse ohne Umsetzung sind Verschwendung.
Den Wertnachweis quartalsweise gegen den Business Case der Strategy-Phase berichten — der Betrieb beweist die Transformation.

Artefakte & Ergebnisse

SLO-Katalog mit Error-Budget-Policy
Etablierter autonomer Betrieb mit Runbook-Bibliothek
KI-Governance-Nachweise (EU AI Act, NIST AI RMF)
Quartalsweiser Wert- und Kostenbericht (FinOps)
Kontinuierlicher Verbesserungs-Backlog in die Folgezyklen

Quality Gate — Operate

Der Übergang in die Folgephase erfolgt über ein formales Quality Gate (Go/No-Go). Die Gate-Kriterien werden im Gate-Review dokumentiert und vom Engagement Lead freigegeben.