Was vorher fertig sein muss
Grundverständnis von TOC, insbesondere Engpass-Logik und Five-Focusing-Steps, ist beim Team vorhanden oder wird im Einführungs-Briefing vermittelt.
Eine Liste konkreter Undesirable Effects (UDEs) mit Belegen liegt vor (typisch 5-15 Items), die einer gemeinsamen Ursachenstruktur folgen können.
Was vor Start vorliegen muss
Großes Whiteboard oder digitales Diagramm-Tool mit Symbolik (Boxen für Aussagen, Pfeile für Kausalität, Ellipsen für AND-Verknüpfungen); Vorlagen für CRT, Evaporating Cloud, FRT, Transition Tree; UDE-Liste; Categories-of-Legitimate-Reservation-Checkliste.
Ein TOC-Coach mit Erfahrung im Thinking Process; 4-8 Personen mit Domänenkenntnis; ein Scribe für Annahmen und Vorbehalte; Sponsor mit Mandat zur Umsetzung.
UDE-Liste mit Beleg pro Item; bekannte Ursachenhypothesen; Stakeholder-Übersicht; vorherige Verbesserungsversuche und deren Ergebnisse; Categories-of-Legitimate-Reservation als Plakat.
Workshop-Serie 2-5 Tage, danach iterative Verfeinerung über Wochen
Werkzeuge des Thinking Process als Phasen sichtbar: 1) Current Reality Tree, 2) Evaporating Cloud, 3) Future Reality Tree, 4) Prerequisite Tree, 5) Transition Tree. Symbolik als Plakat. Categories of Legitimate Reservation (Clarity, Existence, Causality, Cause Insufficiency, Additional Cause, Predicted Effect, Tautology) bereit, um Bäume zu prüfen.
Die eine Frage, die diese Methode beantwortet
Welche Kernkonflikte und Root Causes erzeugen die beobachteten UDEs, welche Veränderungen lösen sie auf, und welche Vorbedingungen sowie Übergänge sind nötig, um die Veränderungen umzusetzen?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Current Reality Tree | 1-2 Tage | UDEs am unteren Rand. Pro UDE Kausalketten nach oben aufbauen, bis Root Causes erreicht. Mehrere UDEs zusammenführen, gemeinsame Root Causes identifizieren. Categories of Legitimate Reservation pro Verknüpfung prüfen. | CRT wird groß und unübersichtlich. Pflicht: Verknüpfungen logisch prüfen, nicht intuitiv akzeptieren. Wenn Reservation greift, Verknüpfung umformulieren oder Zwischenelement einfügen. |
2Phase 2: Evaporating Cloud | 0.5-1 Tag | Kernkonflikt aus CRT als Cloud darstellen: Common Objective, beide notwendige Bedingungen, beide Forderungen, Konflikt. Annahmen hinter jeder Verbindung explizit machen. Mindestens eine Annahme falsifizieren, um Konflikt aufzulösen. | Evaporating Cloud verlangt mindestens fünf Annahmen pro Verbindung. Wer mit drei Annahmen aufhört, hat zu früh aufgegeben. Annahmen-Falsifikation ist der Hebel. |
3Phase 3: Future Reality Tree | 1 Tag | Injection (die Veränderung aus Cloud) am unteren Rand. Logische Konsequenzen aufbauen, bis Desired Effects (DEs) erreicht. Negative Branches identifizieren (unbeabsichtigte negative Effekte) und mit zusätzlichen Injections trimmen. | FRT ohne Negative Branches ist gefährlich. Pro Injection mindestens 2-3 mögliche negative Effekte explizit prüfen. Trimming durch ergänzende Maßnahmen, nicht durch Ignorieren. |
4Phase 4: Prerequisite Tree | 0.5 Tag | Pro Injection: welche Vorbedingungen müssen erfüllt sein, bevor Umsetzung möglich ist. Hindernisse identifizieren, Intermediate Objectives ableiten. Logische Reihenfolge. | Prerequisite Tree zeigt Umsetzungs-Realismus. Wenn Vorbedingungen unrealistisch, Injection neu denken oder Stakeholder-Buy-in vorab klären. |
5Phase 5: Transition Tree | 0.5-1 Tag | Detailierte Umsetzungs-Schritte: Need, Action, Effect pro Schritt. Owner und Datum. Übergang in laufende Steuerung. | Transition Tree wird oft weggelassen, Methode landet bei FRT. Ohne TT bleibt Veränderung Konzept ohne Umsetzungspfad. |
Was am Ende rauskommt
Current Reality Tree mit UDEs, Verknüpfungen und Root Causes; Evaporating Cloud mit Annahmen; Future Reality Tree mit Injections, Desired Effects und Negative Branches; Prerequisite Tree mit IOs; Transition Tree mit Umsetzungs-Schritten; pro Tree CLR-Review-Vermerk.
Pro Projekt eigene Sammlung mit Datum, Sponsor und Coach. Bäume versioniert. Bei Iteration nach Umsetzung neue Version mit Diff. Annahmen-Logik unbedingt erhalten, da Falsifikation später wiederholbar.
Kompakte Arbeitsvorlage für Theory of Constraints Thinking Process mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Theory of Constraints Thinking Process Canvas
## Kontext
Wofür wird die Methode eingesetzt?
## Kernfrage
Welche Frage soll am Ende beantwortet sein?
## Input
Welche Daten, Beobachtungen oder Materialien liegen vor?
## Arbeitsfläche
- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:
## Ergebnisartefakte
- Current Reality Logic:
- Conflict Cloud:
- Future Reality Tree:
- Implementation Obstacles:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## TOC Thinking Process — Engineering-Tribe Aurora, 22.05.2026
**Coach**: @marlene. **Sponsor**: VP Engineering.
### UDEs (Auszug von 11)
- UDE-1: Releases dauern durchschnittlich 18 Tage statt geplante 7.
- UDE-3: Engineers berichten 40% Zeit in Wartezuständen.
- UDE-7: Bugfix-Reaktionszeit für P1 über 24 h.
### CRT (Auszug)
Root Cause: Geteilte Branches mit langlebigen Feature-Flags, gemeinsame Datenbank-Schemata zwischen Tribes. Verknüpft mit UDE-1, 3, 7 über Konfliktlinien.
### Evaporating Cloud
- Common Objective: Hoher Durchsatz mit hoher Qualität.
- Need A: Frühe Integration → Forderung: gemeinsame Main-Branch.
- Need B: Stabile Releases → Forderung: lange Feature-Branches.
- Konflikt zwischen Forderungen.
- Falsifizierte Annahme: „Stabilität verlangt lange Branches“ stimmt nicht, wenn Trunk-Based Development mit Feature-Flags und CI-Tests vorhanden.
### Injection
Trunk-Based Development einführen, kurze Branches, automatische Tests blockieren Merge bei Failures.
### FRT (Auszug)
Injection → kürzere Cycle Time → schnellere Releases (DE für UDE-1). Negative Branch: Test-Flakiness könnte Trunk lahmlegen. Trimming: Test-Stabilisierung als ergänzende Injection.
### Prerequisite Tree
Vorbedingungen: CI-Pipeline-Reliability über 95%, Feature-Flag-System, Engineering-Schulung. IOs: Pipeline-Health-Audit, Flag-Service-Migration, Workshop-Reihe.
### Transition Tree (Auszug)
1. CI-Pipeline-Audit (Owner @ben, bis 30.05).
2. Pipeline-Stabilisierung (Owner @ben, bis 30.06).
3. Feature-Flag-Service-Migration (Owner @anna, bis 31.07).
4. Schulungs-Workshop (Owner @sabine, 15.08).
5. Pilot mit zwei Teams (ab 22.08).
6. Rollout (ab 30.09).Symptome erkennen, gegensteuern
Bäume werden intuitiv akzeptiert, logische Lücken bleiben unentdeckt.
Pro Verknüpfung Categories of Legitimate Reservation prüfen. Mindestens Clarity, Existence, Causality strikt. Wenn Reservation greift, Verknüpfung anpassen.
Annahmen werden auf drei begrenzt, erste plausible Falsifikation wird gewählt, Konflikt scheinbar gelöst.
Pro Verbindung mindestens fünf Annahmen. Falsifikation muss begründbar und im konkreten Kontext belegbar sein, nicht theoretisch.
Future Reality Tree zeigt nur positive Effekte, Risiken bleiben unbenannt.
Pflicht: pro Injection 2-3 Negative Branches benennen und mit ergänzenden Injections trimmen. Wer keine Negative Branches findet, prüft nicht ehrlich.
Methode endet beim FRT, Umsetzungs-Plan fehlt, Veränderung scheitert.
Phasen 4-5 sind nicht Optional. Umsetzung verlangt explizite Vorbedingungen und Schrittfolge. Sonst bleibt Veränderung Konzept.
CRT füllt drei Wände, niemand kann ihn mehr nutzen, Methode kollabiert unter Eigengewicht.
Pro Tree maximal 30-40 Knoten anstreben. Bei mehr UDEs in Cluster aufteilen, jeweils eigener CRT. Coach hält Disziplin.
Bäume werden vom selben Team erarbeitet und akzeptiert, blinde Flecken bleiben.
Externe oder mindestens cross-funktionale Person als CLR-Reviewer. Bei strategischen Veränderungen Coach mit Methodendistanz beauftragen.
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.