Was vorher fertig sein muss
Ein dokumentierter Prozess oder Wertstrom mit Schritten, Übergabepunkten und Durchsatz pro Schritt liegt vor.
Eine Value-Stream-Map mit Bearbeitungs- und Wartezeiten pro Schritt ist verfügbar oder wird im Rahmen der TOC-Anwendung erstellt.
Was vor Start vorliegen muss
Whiteboard mit Prozess-Übersicht; Daten zu Durchsatz, WIP, Wartezeiten pro Schritt; Plakat mit TOC-Five-Focusing-Steps; Marker; Vorlage für Engpass-Maßnahmen.
Ein TOC-Coach oder Lean-Erfahrener; 4-8 Personen mit Prozess- und Datenkenntnis (Ops, Engineering, Management); ein Scribe; bei abteilungsübergreifenden Engpässen Vertretung aller betroffenen Bereiche.
Prozess-Map mit Durchsatzdaten pro Schritt (letzte 4-12 Wochen); bekannte Beschwerden über Wartezeiten oder Stau; aktuelle Verbesserungsinitiativen; Zielgröße (Durchsatz, Lead Time, Variabilität).
Initial-Workshop 3-4 h, dann iterative Reviews alle 2-4 Wochen
Prozess-Map sichtbar mit Durchsatz pro Schritt. Five-Focusing-Steps als Wandplakat: 1) Engpass identifizieren, 2) Engpass ausnutzen, 3) Rest dem Engpass unterordnen, 4) Engpass elevieren, 5) Wenn Engpass gebrochen, zurück zu Schritt 1. Daten-Snapshot mit Zeitstempel.
Die eine Frage, die diese Methode beantwortet
Welcher Schritt im Prozess begrenzt aktuell den Gesamtdurchsatz, wie wird dieser Engpass maximal ausgenutzt, und welche Eskalationsstufe (ausnutzen, unterordnen, elevieren) ist als nächstes dran?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Engpass identifizieren | 45-60 min | Pro Prozess-Schritt Durchsatz, WIP und Wartezeit sichtbar machen. Engpass ist der Schritt mit höchstem WIP davor und Durchsatz unterhalb der Nachfrage. Konsens auf den einen Engpass. | Häufiger Fehler: politischer Engpass (der Schritt mit den lautesten Beschwerden) statt datenmäßiger. Daten gewinnen, nicht Wahrnehmung. Bei mehreren Kandidaten: Little's Law als Test. |
2Phase 2: Engpass ausnutzen | 45-60 min | Wie wird der Engpass-Schritt maximal genutzt: keine Unterbrechung durch Defekte, kein Leerlauf, keine doppelte Bearbeitung. Konkrete Maßnahmen für die nächsten 2 Wochen. | Ausnutzen bedeutet nicht überlasten. Engpass darf nicht durch fehlende Inputs warten, aber auch nicht durch Schlechtteile blockiert sein. Qualitätskontrolle vor dem Engpass, nicht danach. |
3Phase 3: Rest dem Engpass unterordnen | 30-45 min | Alle Nicht-Engpass-Schritte werden auf Engpass-Takt eingestellt. Vorgelagerte Schritte liefern nur so viel, wie Engpass aufnimmt. Nachgelagerte Schritte sind schneller als Engpass und warten gelegentlich. | Lokale Optimierung der Nicht-Engpässe schadet. Engineering schneller machen, wenn Code-Review der Engpass ist, baut WIP auf, nicht Durchsatz. Unterordnung ist häufig der schwierigste Schritt. |
4Phase 4: Engpass elevieren | 30-45 min | Wenn nach Phase 2 und 3 Engpass weiterhin limitiert: Kapazität erhöhen (Investition, Personal, Tool). Maßnahmen mit Kosten und erwartetem Nutzen, Entscheidung über Investition. | Elevieren ist die teuerste Stufe und sollte zuletzt kommen. Häufig zeigt sich nach Phase 2 und 3, dass der Engpass anderswo wandert, bevor Investition nötig wird. |
5Phase 5: Review und Wandern | 30 min, dann alle 2-4 Wochen | Nach 2-4 Wochen: ist der Engpass noch derselbe oder gewandert? Wenn gewandert, neuen Engpass identifizieren, Schritte 2-4 erneut. Wenn nicht gewandert, prüfen warum. | Engpass wandert oft schneller als erwartet. Wer denselben Engpass über 3 Monate kennt, hat entweder Phase 4 nicht durchgeführt oder einen organisatorischen Engpass (Politik, Vertrag), nicht einen operativen. |
Was am Ende rauskommt
Dokumentation mit aktuellem Engpass, Datenbeleg, Maßnahmen pro Five-Focusing-Step mit Owner und Datum, Status der Umsetzung und Review-Ergebnissen. Zeitverlauf des Engpasses über mehrere Iterationen (Wanderkarte).
Pro Iteration Eintrag mit Datum, identifiziertem Engpass, Daten-Snapshot und durchgeführten Maßnahmen. Historie nicht überschreiben, Wanderkarte zeigt strukturelle Muster.
Kompakte Arbeitsvorlage für Theory of Constraints mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Theory of Constraints 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
- Constraint Map:
- Improvement Plan:
- Flow Metrics:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## TOC — Engineering-Tribe Aurora, Iteration 3, 15.06.2026
**Daten (Sprint 11-12)**: Stories durchschnittlich 14 Tage Lead Time, davon 8 Tage in „Ready for Review“ wartend.
### Engpass: Code Review
- WIP in Review: durchschnittlich 9, max 14.
- Throughput Review: 4 Stories/Woche, Throughput Engineering: 7 Stories/Woche.
- Datenbeleg: Linear-Cycle-Time-Report, Snapshot vom 14.06.
### Maßnahmen
- **Ausnutzen**: Reviewer-Slot 14-16 Uhr täglich blockiert, keine Meetings. Pre-Review-Checkliste in PR-Template, reduziert Rückläufer. Owner @ben, ab 17.06.
- **Unterordnen**: WIP-Limit „in Progress“ auf 5 Stories pro Engineer reduziert, neue Stories warten in Ready. Pull statt Push. Owner @sabine, ab 17.06.
- **Elevieren**: Senior-Engineer als zweite Reviewer-Rolle pilotieren, falls nach 2 Wochen WIP über 7 bleibt. Entscheidung am 01.07. mit Datencheck.
### Vorgängerengpass
Iteration 2 (Mai): Engpass war QA. Nach Test-Automatisierung wanderte Engpass zu Review (erwartet, aber schneller als geplant).Symptome erkennen, gegensteuern
Team einigt sich auf den Schritt mit den lautesten Beschwerden, Daten widersprechen.
Engpass-Identifikation strikt auf Daten basieren: WIP, Throughput, Wartezeit. Wenn keine Daten verfügbar, vor Workshop messen. Beschwerden als Hinweis, nicht als Beweis.
Team optimiert Schritte, die ohnehin schneller als der Engpass sind, baut WIP davor auf, Lead Time steigt.
Klare Regel: Nur Engpass-Schritt wird optimiert. Andere Schritte werden unterordnet, also bewusst langsamer gemacht oder mit WIP-Limit versehen. Lokale Effizienz-Metriken pausieren.
Nach Maßnahmen ist neuer Engpass an unerwarteter Stelle, Team reagiert nicht und behandelt alten Engpass weiter.
Review-Cadence einhalten (2-4 Wochen). Daten neu erheben, Engpass neu identifizieren. Wenn Wanderung erkannt, alte Maßnahmen einfrieren, neuer Engpass wird Fokus.
Team erhöht Kapazität, bevor Phase 2 und 3 ausgeschöpft sind. Investition ist teuer, Wirkung gering.
Reihenfolge der Five-Focusing-Steps einhalten. Vor Elevation prüfen: ist Engpass wirklich voll ausgelastet, ist Unterordnung erfolgt. Wenn nicht, zurück zu Phase 2.
Engpass ist nicht ein Prozess-Schritt, sondern eine Politik oder Vertragsklausel (z. B. Freigabe vom CFO bei jedem Deploy).
Engpass-Definition erweitern auf Policy-Constraints. TOC Thinking Process oder Evaporating Cloud als Anschlussmethode für Policy-Engpässe.
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.