Was vorher fertig sein muss
Es liegt eine dynamische Situation mit Zeitdruck, unvollständiger Information und Handlungsbedarf vor, in der OODA gegenüber strukturierten Entscheidungsmethoden Vorteile hat.
Was vor Start vorliegen muss
Lagebild-Whiteboard mit vier Quadranten (Observe, Orient, Decide, Act); Datenquellen-Zugänge (Dashboards, Logs, Status-Channel); Timer für Loop-Begrenzung; geteiltes Dokument für Entscheidungslog; Kommunikationskanal mit allen Beteiligten.
Ein Lead, der den Loop führt und Entscheidungen trifft; ein Observer mit Datenzugang, der laufend Informationen einspielt; zwei bis vier weitere Mitwirkende, die Optionen und Risiken einbringen; ein Scribe, der jeden Loop dokumentiert.
Aktueller Status der Situation in zwei bis drei Sätzen; verfügbare Datenquellen; Entscheidungsbefugnisse des Leads; bekannte Constraints (Zeitfenster, Ressourcen, externe Abhängigkeiten); Eskalationspfad bei Schwellenüberschreitung.
5-30 min pro Loop, mehrere Loops in Folge
Vier Quadranten als sichtbarer Workspace. Erste Observation einspielen. Loop-Timer auf 5-10 min einstellen. Regel: nach jedem Act zurück zu Observe, nicht im Loop steckenbleiben. Entscheidungslog als laufendes Dokument mit Zeitstempel pro Loop.
Die eine Frage, die diese Methode beantwortet
Welche Beobachtung, Orientierung, Entscheidung und Handlung ist im aktuellen Loop dem Gegner, dem Markt oder der Situation einen Schritt voraus, und welcher Folge-Loop steht direkt danach an?
Marker: Minute
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
10-2 min Observe | 2 min | Aktuelle Lage erfassen: Daten, Signale, Akteursverhalten, eigene Position. Beobachtungen ohne Interpretation in den Observe-Quadranten. | Wenn Observe schon Schlüsse enthält („Konkurrent will übernehmen“), gehört das in Orient. Sauber trennen, sonst kontaminiert Bias die Daten. |
22-4 min Orient | 2 min | Interpretieren: was bedeuten die Beobachtungen vor dem Hintergrund von Erfahrung, Modellen und Hypothesen. Optionen sichtbar machen, mentale Modelle prüfen. | Orient ist die wichtigste Phase, häufig zu kurz behandelt. Mindestens zwei Lesarten der Lage explizit nebeneinander stellen, bevor entschieden wird. |
34-5 min Decide | 1 min | Eine Option auswählen. Lead entscheidet, andere bringen Risiken und Alternativen ein. Entscheidung mit Begründung im Log dokumentieren. | Wenn niemand entscheiden kann oder will, OODA stockt. Lead muss Entscheidung treffen, auch bei Unsicherheit. „Wir warten“ ist eine zulässige Entscheidung, muss aber explizit getroffen werden. |
45-10 min Act | 5 min | Entschiedene Handlung durchführen. Wirkung beobachtbar machen (Telemetrie, Statusmeldung, Kunden-Feedback). Vorbereitung für nächsten Loop. | Wenn Act länger als 5 min braucht, ist die Aktion zu groß für den Loop. Kleinere Aktion wählen oder Loop-Frequenz senken, nicht beides. |
510+ min Restart | kontinuierlich | Nach jedem Act sofort zurück zu Observe. Lage hat sich durch eigene Aktion und durch externe Bewegung verändert. Neuer Loop beginnt. | Wer nach Act lange analysiert, verliert Tempo-Vorteil. Loop-Disziplin ist Kern der Methode, nicht Geschwindigkeit pro se. |
Was am Ende rauskommt
Entscheidungslog mit Zeitstempel pro Loop, Beobachtungen, Orientierung, Entscheidung, Aktion und beobachteter Wirkung. Pro Situation eigenes Log mit Lead und Datum, archiviert für Lessons Learned.
Pro Situation neues Log, Loops chronologisch nummeriert. Bei Rückblick (After Action Review) wird das Log als Quelle genutzt. Korrekturen oder Klarstellungen als Edit am Ende anhängen, nicht überschreiben.
Kompakte Arbeitsvorlage für OODA Loop mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# OODA Loop Arbeitsvorlage
## Ziel
Iterativer Entscheidungszyklus aus Observe, Orient, Decide und Act für dynamische Situationen.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Situation Assessment:
- Decision Loop:
- Action Updates:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## OODA — Production-Incident DB-Failover, 14.05.2026 09:12-09:47
**Lead**: @sabine. **Scribe**: @tobias.
### Loop 1 (09:12-09:20)
- **Observe**: 500er-Rate Order-API auf 8%, DB-CPU 95%, Replica-Lag 4 min.
- **Orient**: Replica fällt zurück, Master-Last steigt. Zwei Lesarten: a) Batch-Job blockiert Master, b) Hardware-Issue Replica.
- **Decide**: Option a) priorisieren, da Batch-Job-Log auffällig. Batch-Job stoppen.
- **Act**: 09:18 Batch-Job gestoppt via kubectl.
### Loop 2 (09:20-09:30)
- **Observe**: 500er-Rate fällt auf 2%, DB-CPU auf 70%, Replica-Lag steigt weiter auf 6 min.
- **Orient**: Master-Druck weg, aber Replica-Problem unabhängig. Möglicherweise Hardware oder Netzwerk.
- **Decide**: Failover auf Standby-Replica einleiten, Original-Replica unter Beobachtung.
- **Act**: 09:28 Failover via Pgpool, Statusmeldung an Kunden.
### Loop 3 (09:30-09:47)
- **Observe**: 500er-Rate 0%, Replica-Lag 30 s und sinkend, neue Replica stabil.
- **Orient**: Stabilisierung erreicht, Original-Replica braucht Post-Incident-Untersuchung.
- **Decide**: Out of Incident, Postmortem-Setup.
- **Act**: 09:47 Incident closed, 5-Whys-Workshop für 15.05. terminiert.Symptome erkennen, gegensteuern
Beobachtungen enthalten Schlüsse („Angriff läuft“) statt Daten („Login-Versuche aus IP-Range X auf 500/min“).
Observe-Quadrant strikt auf Daten begrenzen. Interpretation gehört in Orient. Coach unterbricht, wenn Begriffe wie „klar“ oder „offensichtlich“ in Observe auftauchen.
Team springt direkt von Observe zu Decide, erste Lesart wird Entscheidung, Alternativen tauchen nicht auf.
Orient als Pflicht-Phase mit mindestens zwei Lesarten erzwingen. Frage: „Welche andere Erklärung passt zu denselben Daten?“ Bei nur einer Lesart Loop pausieren.
Team analysiert 20 min, bewegt sich nicht zu Decide oder Act. Situation entwickelt sich weiter ohne eigenes Zutun.
Timer hart durchsetzen. Lieber Entscheidung mit 60% Sicherheit als 100% Sicherheit zu spät. Wenn Lead nicht entscheidet, Eskalation an nächste Ebene.
Nächster Loop beginnt ohne Daten zur vorherigen Aktion, Wirkung wird vermutet statt beobachtet.
Vor Act festlegen, welche Metrik die Wirkung messbar macht. Telemetrie sichtbar im Observe-Quadranten halten. Bei fehlender Messbarkeit Aktion neu schneiden.
Decide erfordert Rückfragen nach oben, Loop pausiert mehrfach für Eskalation, Vorteil ist verspielt.
Vor OODA Entscheidungsbefugnis klären und schriftlich festhalten. Wenn Lead nicht entscheidungsbefugt ist, höhere Person als Lead einsetzen oder Eskalationspfad vorab pre-approved freigeben.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.