Was vorher fertig sein muss
Eine chronologische Aufzeichnung des Problems mit Zeitstempeln, Symptomen und ergriffenen Maßnahmen liegt vor.
Bei der Entscheidungsanalyse (KT-DA) liegen Entscheidungskriterien mit Gewichtung vor oder werden im Workshop erarbeitet.
Was vor Start vorliegen muss
Vorlage mit vier KT-Prozessen (Situation Appraisal, Problem Analysis, Decision Analysis, Potential Problem Analysis); Tabellen für Ist/Ist-nicht-Vergleiche und Entscheidungskriterien; Zugriff auf Logs, Metriken, Dokumentation.
Ein Facilitator mit KT-Erfahrung, der durch die vier Prozesse führt; zwei bis acht Teilnehmer mit Domain- und Datenkenntnis; ein Scribe, der Hypothesen und Tests protokolliert.
Problemstellung, Zeitraum, beobachtete Symptome; bekannte Workarounds; verfügbare Daten und deren Quellen; Eskalationsstand und Stakeholder.
2-8 h
Vorlage geteilt verfügbar machen. Mit Situation Appraisal beginnen und entscheiden, welcher KT-Prozess primär angewandt wird (PA, DA, PPA). Telefone aus, parallele Threads pausieren.
Die eine Frage, die diese Methode beantwortet
Welche Ursache, Entscheidung oder Risikomaßnahme lässt sich durch disziplinierte Trennung von Fakten, Hypothesen und Entscheidungskriterien rational ableiten?
Marker: Sektion
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Sektion 1: Situation Appraisal | 20-30 min | Probleme, Entscheidungen und potenzielle Probleme listen. Pro Eintrag Dringlichkeit, Auswirkung und Wachstumsrate bewerten. Top-Themen für die folgenden KT-Prozesse priorisieren. | Wenn die Liste über 10 Einträge umfasst, in zwei Sessions splitten. KT lebt von Fokus, nicht von Volumen. |
2Sektion 2: Problem Analysis (Ist/Ist-nicht) | 45-90 min | Pro Problem Vier-Felder-Spezifikation: Was ist betroffen, was ist nicht betroffen, wo, wann, wie viel. Aus Unterschieden mögliche Ursachen ableiten und gegen jede Spezifikation testen. | Die Spalte „Ist-nicht“ ist der diagnostische Hebel. Wenn sie leer bleibt, fehlt Datenkenntnis und die PA wird Spekulation. |
3Sektion 3: Decision Analysis | 30-60 min | Entscheidungsaussage formulieren. Must-Kriterien (KO) und Want-Kriterien (gewichtet) auflisten. Optionen gegen Musts filtern, gegen Wants bewerten. Risiken pro Top-Option diskutieren. | Mehr als sieben Wants verdünnen die Bewertung. Wichtigste drei bis fünf reichen. Gewichtung 1-10, nicht binär. |
4Sektion 4: Potential Problem Analysis | 30-60 min | Pro gewählter Option mögliche Probleme listen, Wahrscheinlichkeit und Auswirkung bewerten. Pro Top-Risiko Präventiv- und Kontingenzmaßnahmen festlegen, Trigger und Owner benennen. | Trigger müssen messbar sein. „Wenn es Probleme gibt“ ist kein Trigger, „wenn Error Rate über 2% in 5 min“ ist einer. |
5Sektion 5: Followups | 15-20 min | Pro Ergebnis Owner, Datum und Review-Termin. Offene Tests aus PA als Spike-Aufgaben anlegen. Entscheidung und Begründung im Decision Log archivieren. | Spikes mit Datum, sonst geht die diagnostische Lücke verloren und KT war nur Theaterdokumentation. |
Was am Ende rauskommt
Strukturiertes Dokument mit vier Sektionen (Situation, PA mit Ist/Ist-nicht-Tabelle, DA mit Must/Want-Matrix, PPA mit Risikoliste), zusammen mit Entscheidungsbegründung, Followups und Decision Log mit Datum und Decider.
Pro Vorfall oder Entscheidung eigener Eintrag mit Datum und Decider im Header. Spätere Erkenntnisse als Update-Sektion am Ende, nicht überschreiben. Bei revidierter Entscheidung Status auf `revised` setzen.
Kompakte Arbeitsvorlage für Kepner-Tregoe mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Kepner-Tregoe Arbeitsvorlage
## Ziel
Strukturiert Situation, Problem, Entscheidung und Risikoanalyse in getrennte Denkprozesse.
## 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
- Problem Analysis:
- Decision Analysis:
- Risk Plan:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## KT-Analyse — Performance-Regression in Order-API (12.05.2026)
**Situation Appraisal**: Drei Themen identifiziert. Priorität 1: P95-Latenz ist seit 10.05. von 240 ms auf 1.8 s gestiegen.
**Problem Analysis**:
| | Ist | Ist-nicht |
|---|---|---|
| Was | Order-Endpoint /v2/orders | Read-Endpoints, Auth-Endpoint |
| Wo | EU-West Cluster | US-East Cluster |
| Wann | seit 10.05. 09:00 UTC | vor 10.05. |
| Wie viel | P95 1.8 s, P50 stabil bei 80 ms | — |
**Hypothese**: Änderung im EU-West-Cluster am 09.-10.05. relevant. Deploy-Log zeigt DB-Pool-Konfig-Änderung. Test bestätigt: Pool-Reduktion von 40 auf 20 verursacht Wartezeiten unter Last.
**Decision Analysis**: Pool zurück auf 40 (Must: keine API-Downtime; Want: Speicher unter 4 GB, Recovery in 5 min). Gewählt. Score 8.4/10.
**PPA**: Risiko OOM bei Pool 40 plus Spike. Trigger: Memory über 3.5 GB für 10 min. Kontingenz: Pool 30. Owner: @lisa, Monitoring-Alert bis 15.05.Symptome erkennen, gegensteuern
Teilnehmer füllen nur die Ist-Spalte, Hypothesen bleiben breit.
Facilitator stellt für jede Zeile beide Fragen explizit. Wer „Ist-nicht“ nicht beantworten kann, dokumentiert das als offene Wissenslücke und plant einen Spike.
Liste enthält 12 Wants, davon mehrere de facto K.-o.-Kriterien.
Musts strikt als binär (ja/nein) trennen. Wer ein „muss aber wirklich“ als Want führt, lügt sich an. Maximal drei bis fünf Wants.
Hypothesen werden diskutiert, aber nicht gegen vorhandene Logs oder Metriken getestet.
Pro Hypothese einen konkreten Datenpunkt verlangen. Wenn nicht verfügbar, als Spike notieren, nicht als Tatsache.
Entscheidung getroffen, aber keine Risiken oder Trigger benannt.
Sektion 4 als Pflichtschritt. Mindestens drei Risiken pro Top-Option mit messbarem Trigger.
DA endet mit Score-Liste, aber niemand trifft die Entscheidung.
KT-DA nur ansetzen, wenn Entscheider zugesagt hat. Ersatz mit Autorität vorab benennen.
Situation Appraisal listet 15 Themen, alle werden angepackt, keines abgeschlossen.
Top 3 priorisieren, Rest in zweite Session. KT erfordert Tiefe pro Thema, nicht Breite.
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.