Blog / Wissen

Engpässe finden, Engpässe lösen – Theory of Constraints im IT-Support

20. März 2026 · 8 min read

Engpässe finden, Engpässe lösen – Theory of Constraints im IT-Support

1984 veröffentlichte der israelische Physiker Eliyahu Goldratt einen Roman über eine Fabrik. "The Goal" erzählt die Geschichte von Alex Rogo, einem Werksleiter, dessen Fabrik trotz hoher Maschinenauslastung Liefertermine nicht einhalten kann. Die Lösung, die Rogo findet, ist so kontraintuitiv wie wirkungsvoll: Er macht eine Maschine absichtlich langsamer – und die gesamte Fabrik wird schneller.

Das Prinzip dahinter heißt Theory of Constraints (TOC). Es gilt für Fabriken, für Softwareprojekte, für Krankenhäuser – und für IT-Service-Desks.

Das Kernprinzip: Es gibt immer genau einen Engpass

Jedes System, das einen Output erzeugt, hat mindestens einen Engpass – eine Stelle, die den Gesamtdurchsatz begrenzt. In einer Fabrik ist es die langsamste Maschine. In einem Service Desk ist es das Team (oder die Eskalationsstufe), bei dem sich die Tickets stauen.

Die entscheidende Einsicht: Der Durchsatz des Gesamtsystems wird vom Engpass bestimmt. Nicht vom schnellsten Team, nicht vom Durchschnitt, sondern von der engsten Stelle. Alles, was Sie vor dem Engpass schneller machen, produziert nur einen größeren Stau vor dem Engpass. Alles, was Sie nach dem Engpass schneller machen, läuft leer.

In einem typischen L1/L2/L3-Setup: Wenn L2 der Engpass ist, dann hilft es nichts, L1 schneller zu machen. Die Tickets kommen nur schneller bei L2 an – und stauen sich dort. Und es hilft auch nicht, L3 aufzustocken – denn L3 bekommt seine Tickets von L2, und L2 liefert nicht schneller, egal wie viel Kapazität hinter ihm wartet.

Die fünf Schritte

Goldratts Methode folgt einem klaren Ablauf. Fünf Schritte, in dieser Reihenfolge.

Schritt 1: Identify – Den Engpass identifizieren

Wo staut es sich? In einem Service Desk erkennt man den Engpass an drei Signalen:

  • Wachsende Queue: Die Anzahl offener Tickets in diesem Team steigt über Wochen.
  • Hohe Verweildauer: Tickets verbringen überdurchschnittlich lange in diesem Team – nicht weil die Bearbeitung komplex ist, sondern weil sie auf Bearbeitung warten.
  • Inflow > Outflow: Mehr Tickets kommen herein als herausgehen. In der Sprache von Little's Law: λ-in > λ-out, und damit wächst L ohne Grenze.

Achtung: Der Engpass ist nicht immer dort, wo die Beschwerden am lautesten sind. Manchmal ist es ein ruhiges Team im Hintergrund – ein Infrastruktur-Team, ein Sicherheitsteam – das langsam, aber stetig den Gesamtfluss bremst.

Schritt 2: Exploit – Den Engpass maximal ausnutzen

Bevor Sie Kapazität aufbauen, stellen Sie sicher, dass der Engpass seine vorhandene Kapazität voll nutzt. In einer Fabrik heißt das: Die Engpass-Maschine darf nie stillstehen – keine Pausen, kein Warten auf Material, keine unnötigen Umrüstungen.

Im Service Desk:

  • Keine Tickets im Engpass-Team, die dort nicht hingehören (falsch geroutet, bereits gelöst, Duplikate).
  • Keine unnötigen Abstimmungsschleifen, die Bearbeitungszeit kosten.
  • Alle Informationen, die das Engpass-Team braucht, liegen vor, bevor das Ticket zugewiesen wird (keine Rückfragen an L1, die Wartezeit erzeugen).
  • Unterbrechungen minimieren – jeder Kontextwechsel kostet den Engpass überproportional.

Das klingt trivial, ist es aber in der Praxis selten. In vielen Organisationen verbringt der Engpass 20–30% seiner Kapazität mit Tickets, die eigentlich woanders hingehören, oder mit Warten auf Informationen, die bei der Eskalation hätten mitgeliefert werden können.

Schritt 3: Subordinate – Alles dem Engpass unterordnen

Jetzt wird es kontraintuitiv. "Subordinate" bedeutet: Alle anderen Teams richten ihren Rhythmus am Engpass aus. Nicht schneller, nicht langsamer – genau im Takt des Engpasses.

Konkret: Wenn L2 maximal 40 Tickets pro Tag abarbeiten kann, dann darf L1 nicht 60 Tickets pro Tag eskalieren. Auch wenn L1 das könnte. Auch wenn L1 dann "unterausgelastet" wäre.

Warum? Weil jedes Ticket, das über die Kapazität des Engpasses hinaus eskaliert wird, nur die Queue vor dem Engpass verlängert. Es erhöht die Verweildauer aller Tickets (Little's Law) und erzeugt Druck, der zu Fehlern, Shortcuts und schlechteren Lösungen führt.

Subordination heißt nicht, dass L1-Agents Däumchen drehen. Es heißt, dass sie die Zeit nutzen, die durch kontrollierte Eskalation entsteht: Bessere Erstlösung, bessere Dokumentation, bessere Kategorisierung. Alles, was den Engpass entlastet.

Schritt 4: Elevate – Kapazität am Engpass erhöhen

Erst wenn die Schritte 2 und 3 ausgeschöpft sind, kommt der Kapazitätsaufbau. "Elevate" bedeutet: Den Durchsatz des Engpasses erhöhen.

Das kann bedeuten:

  • Zusätzliches Personal im Engpass-Team.
  • Schulung, damit das Engpass-Team schneller arbeiten kann.
  • Automation von repetitiven Aufgaben im Engpass.
  • Umverteilung bestimmter Ticket-Kategorien auf andere Teams (Skill Sharing).

Wichtig: Kapazitätsaufbau am Engpass ist eine Investition. Kapazitätsaufbau an einer Stelle, die NICHT der Engpass ist, ist Verschwendung – das zusätzliche Personal produziert nur einen größeren Stau vor dem Engpass.

Schritt 5: Repeat – Zurück zum Anfang

Wenn der Engpass behoben ist, ist die Arbeit nicht fertig. Ein anderes Team wird zum neuen Engpass. Das ist unvermeidlich – in jedem System gibt es eine engste Stelle. Die Frage ist nur, welche.

In einem Service Desk wandern Engpässe typischerweise: Erst staut es sich bei L2, dann (nach Behebung) bei L3 oder bei einer spezialisierten Gruppe. Oder der Engpass verschiebt sich auf den Eingang – L1 kann die neuen Routing-Regeln nicht schnell genug umsetzen.

Das bedeutet: Engpass-Management ist kein Projekt mit Endtermin. Es ist ein kontinuierlicher Prozess.

Drum-Buffer-Rope: Die Produktionssteuerung

Goldratt entwickelte aus den fünf Schritten ein konkretes Steuerungsmodell: Drum-Buffer-Rope (DBR).

Drum (Trommel): Der Engpass gibt den Takt vor. In einem L1/L2/L3-System: Wenn L2 der Engpass ist, bestimmt L2 die Taktrate des gesamten Systems. Nicht L1 (der schnellste), nicht L3 (der letzte in der Kette) – sondern L2.

Buffer (Puffer): Vor dem Engpass wird ein kontrollierter Puffer gehalten – groß genug, damit der Engpass nie leer läuft (jede verlorene Stunde am Engpass ist für immer verloren), aber klein genug, damit die Wartezeiten nicht explodieren. In der Praxis: Eine Queue von 1–2 Tagen Arbeit vor dem Engpass-Team, nicht mehr.

Rope (Seil): Ein Signal vom Engpass zurück an den Eingang des Systems. Wenn der Buffer voll ist, wird der Eingang gedrosselt – L1 eskaliert weniger. Wenn der Buffer schrumpft, kann mehr eskaliert werden. Das "Seil" verbindet den Systemeingang mit dem Engpass und verhindert unkontrolliertes Überschwemmen.

Im ITSM-Kontext wird die Rope-Funktion selten explizit implementiert. Aber implizit existiert sie in jeder Organisation, die Eskalationsregeln hat: "Eskaliere nur, wenn Kriterien X, Y und Z erfüllt sind." Das Problem ist, dass diese Regeln oft statisch sind – sie reagieren nicht auf die aktuelle Auslastung des Engpasses. Ein dynamisches Rope würde die Eskalationsrate an die aktuelle Buffer-Tiefe koppeln. Das wäre echte Systemsteuerung.

Verbindung zu Little's Law und Kingman

Theory of Constraints ist kein isoliertes Framework. Die Konzepte verbinden sich direkt mit der Warteschlangentheorie:

Subordination = Inflow-Kontrolle. Wenn der Eingang dem Engpass-Rhythmus untergeordnet wird, dann gilt am Engpass: λ-in ≤ λ-out. Das System bleibt stabil (Little's Law).

Buffer = kontrollierte Queue-Tiefe. Der Buffer hält L am Engpass in einem definierten Bereich. Nicht zu groß (hohe Wartezeit), nicht zu klein (Engpass steht leer).

Auslastung am Engpass. Der Engpass sollte nahe seiner Kapazitätsgrenze arbeiten – aber nicht darüber. Die Kingman-Formel zeigt, dass auch der Engpass nicht über 85–90% getrieben werden sollte, weil sonst die Wartezeiten exponentiell steigen.

Häufige Fehler

L1 beschleunigen, ohne L2-Kapazität zu prüfen. Wer L1 effizienter macht, produziert mehr Eskalationen pro Zeiteinheit. Wenn L2 der Engpass ist, verschlimmert das die Situation. Das ist der häufigste Fehler in ITSM-Optimierungsprojekten – und ein direktes Ergebnis davon, Teams isoliert zu betrachten statt als System. In unserem Artikel über Kaskadeneffekte haben wir beschrieben, wie ein Engpass bei einem Team die gesamte Organisation ausbremsen kann.

Den Engpass nur mit Personal lösen. Mehr Personal erhöht die Kapazität, aber ändert nichts am Routing, an der Ticket-Qualität oder an den Eskalationsregeln. Wenn 25% der Tickets am Engpass falsch geroutet sind, löst zusätzliches Personal nur 75% des Problems. Exploit (Schritt 2) kommt vor Elevate (Schritt 4) – aus gutem Grund.

Den Engpass als "schlechtes Team" behandeln. Ein Team, das der Engpass ist, arbeitet oft härter als alle anderen. Es hat die vollste Queue, den größten Druck und die wenigste Verschnaufpause. Der Engpass ist kein Zeichen von Inkompetenz – er ist ein Zeichen dafür, dass der Bedarf die Kapazität übersteigt. Die richtige Reaktion ist Unterstützung, nicht Vorwurf.

Nach der Behebung aufhören. Der neue Engpass kommt. Immer. Wer nach der ersten Verbesserung aufhört zu messen, wird in drei Monaten ein neues Problem haben – an einer anderen Stelle.

Inflow/Outflow als Monitoring-Metrik

Für die tägliche Praxis braucht es kein aufwendiges Constraint-Tracking. Eine einzige Metrik reicht als Frühwarnsystem: das Inflow/Outflow-Verhältnis pro Team.

  • Ratio = 1,0: Steady State. So viel rein wie raus. Stabil.
  • Ratio 1,1–1,3: Leichtes Wachstum. Beobachten, aber kein Alarm.
  • Ratio > 1,3 über mehr als 2 Wochen: Struktureller Aufstau. Hier entsteht ein Engpass.
  • Ratio < 1,0: Queue schrumpft. Erholung – oder Unterauslastung.

Wenn ein Team dauerhaft über 1,3 liegt und ein nachgelagertes Team ebenfalls steigende Durchlaufzeiten zeigt, haben Sie eine Kaskade gefunden. Dann greifen die fünf Schritte: Identifizieren, Ausnutzen, Unterordnen, Erweitern, Wiederholen.

Fazit

Der Durchsatz eines IT-Service-Desks wird nicht vom schnellsten Team bestimmt, sondern vom langsamsten. Goldratts Theory of Constraints bietet ein systematisches Vorgehen: Engpass identifizieren, vorhandene Kapazität voll ausschöpfen, den Rest des Systems dem Engpass-Rhythmus unterordnen, erst dann Kapazität aufbauen – und dann den nächsten Engpass finden. Wer Kapazität an der falschen Stelle aufbaut, investiert ohne Wirkung. Wer den Engpass kennt, hat einen Hebel.

Weiterführende Quellen

  • Goldratt, E.M. (1984): The Goal. North River Press.
  • Goldratt, E.M. (1997): Critical Chain. North River Press.
  • Dettmer, H.W. (2007): The Logical Thinking Processes. ASQ Quality Press.
  • Hopp, W.J. & Spearman, M.L. (2011): Factory Physics. 3. Aufl., Waveland Press.

Solche Muster automatisch erkennen?

Process Radar analysiert Ihre ITSM-Daten und zeigt strukturelle Probleme — ohne manuelles Reporting.

Zugang anfragen