Blog / Wissen

Little's Law im Service Desk – Warum Ihre Queue nicht lügt

20. März 2026 · 8 min read

Little's Law im Service Desk – Warum Ihre Queue nicht lügt

Es gibt wenige mathematische Zusammenhänge, die so einfach und gleichzeitig so mächtig sind wie Little's Law. Eine einzige Formel, drei Variablen, keine komplizierten Annahmen – und trotzdem beschreibt sie das Verhalten jeder Queue, in der Tickets, Aufträge oder Anfragen verarbeitet werden. Auch Ihrer.

Die Formel

1961 bewies der MIT-Mathematiker John D.C. Little einen Zusammenhang, der heute zu den Grundlagen der Warteschlangentheorie gehört:

L = λ × W

Die drei Variablen:

  • L – die durchschnittliche Anzahl von Items im System (z.B. offene Tickets in der Queue eines Teams)
  • λ (Lambda) – der Durchsatz, also die Rate, mit der Items das System verlassen (z.B. abgeschlossene Tickets pro Stunde)
  • W – die durchschnittliche Verweildauer eines Items im System (z.B. die mittlere Zeit von Ticket-Erstellung bis Abschluss)

Das Bemerkenswerte: Diese Beziehung gilt für jedes stationäre System. Egal ob eine Queue oder zehn, ob FIFO oder nach Prioritäten sortiert, ob ein Agent oder fünfzig. Die einzige Voraussetzung ist, dass das System im Gleichgewicht arbeitet – also langfristig ungefähr so viele Items hineinkommen wie hinausgehen.

Was heißt das konkret im Service Desk?

Nehmen wir ein 2nd-Level-Team. Im Tagesdurchschnitt befinden sich 15 Tickets gleichzeitig in Bearbeitung (L = 15). Das Team schließt im Schnitt 3 Tickets pro Stunde ab (λ = 3).

Little's Law sagt:

W = Lλ = 153 = 5 Stunden

Ein Ticket verbringt also im Durchschnitt 5 Stunden in diesem Team – von der Zuweisung bis zum Abschluss oder zur Weiterleitung.

Das ist kein Schätzwert, keine Stichprobe, keine Vermutung. Es ist eine mathematische Konsequenz aus zwei messbaren Größen.

Der Umkehrschluss: Warum wachsende Queues wehtun

Jetzt wird es interessant. Stellen wir die Formel um:

W = Lλ

Wenn die Queue-Tiefe L wächst und der Durchsatz λ konstant bleibt, dann steigt die Verweildauer W – zwingend.

Das klingt banal, hat aber Konsequenzen, die in der Praxis regelmäßig ignoriert werden. Wenn im obigen Beispiel die Queue von 15 auf 30 Tickets anwächst – vielleicht weil der Inflow gestiegen ist oder weil ein Agent ausfällt – dann verdoppelt sich die mittlere Verweildauer auf 10 Stunden. Nicht vielleicht. Zwingend.

Und umgekehrt: Wenn die Queue von 15 auf 10 sinkt (z.B. durch besseres Routing), sinkt die Verweildauer auf ca. 3,3 Stunden. Ohne dass jemand schneller arbeiten muss.

Die Instabilitätsbedingung

Little's Law setzt ein stabiles System voraus – ein System, in dem langfristig gleich viel hineinkommt wie hinausgeht. Was passiert, wenn das nicht der Fall ist?

Wenn die Eingangsrate (λ-in) dauerhaft größer ist als die Ausgangsrate (λ-out), dann wächst L unbegrenzt. Es gibt kein neues Gleichgewicht. Die Queue wird Woche für Woche größer, die Verweildauer steigt Woche für Woche.

Genau dieses Muster zeigt sich, wenn ein Team dauerhaft mehr Tickets bekommt, als es abarbeiten kann – ein Zustand, der in vielen IT-Organisationen nicht Ausnahme, sondern Normalzustand ist. In unserem Artikel über strukturelle Engpässe haben wir beschrieben, wie ein Inflow-Outflow-Verhältnis von 2:1 innerhalb eines Quartals einen nicht mehr aufholbaren Rückstau erzeugt. Little's Law liefert die mathematische Erklärung dafür.

Warum "mehr gleichzeitig bearbeiten" nicht hilft

Eine häufige Reaktion auf wachsende Queues: Mehr Tickets parallel bearbeiten. Jeder Agent nimmt statt 3 nun 5 Tickets gleichzeitig in Arbeit. Das fühlt sich produktiv an – schließlich arbeitet man ja an mehr Dingen gleichzeitig.

Little's Law zeigt, warum das kontraproduktiv ist.

Wenn jeder Agent mehr Tickets gleichzeitig bearbeitet, steigt L (die Anzahl der Items im System). Gleichzeitig sinkt typischerweise der effektive Durchsatz λ, weil Kontextwechsel, Rückfragen und Wartezeiten zunehmen. Das Ergebnis: W steigt – die Verweildauer pro Ticket wird länger.

Das ist kein ITSM-spezifisches Problem. In der Softwareentwicklung hat die Lean- und Kanban-Bewegung längst daraus die Konsequenz gezogen: WIP-Limits (Work in Progress Limits) begrenzen die Anzahl gleichzeitig bearbeiteter Aufgaben bewusst. Nicht aus Bequemlichkeit, sondern weil Little's Law zeigt, dass ein niedrigeres L bei gleichem λ automatisch zu einem niedrigeren W führt.

Ein Team, das sich diszipliniert auf wenige parallele Tickets beschränkt, liefert schneller – nicht weil die Agents schneller tippen, sondern weil die Systemdynamik für sie arbeitet.

Little's Law als Steuerungsinstrument

Wenn Sie Little's Law als Werkzeug nutzen, ergeben sich drei Stellhebel:

1. Queue-Tiefe senken (L reduzieren) Weniger parallele Arbeit, WIP-Limits, konsequentes Abschließen statt Multitasking. Bei gleichem Durchsatz sinkt die Verweildauer.

2. Durchsatz erhöhen (λ steigern) Schulung, bessere Tools, Automatisierung repetitiver Schritte. Bei gleicher Queue-Tiefe sinkt die Verweildauer.

3. Inflow kontrollieren Wenn der Inflow den Durchsatz übersteigt, hilft weder 1 noch 2 dauerhaft. Dann muss der Eingang gesteuert werden – durch besseres Routing, durch Umverteilung von Kategorien, durch kontrollierte Eskalation. Das ist kein Eingeständnis von Schwäche, sondern Systemsteuerung.

In der Theory of Constraints wird dieses Prinzip als "Subordination" bezeichnet: Der Eingang wird dem Engpass-Rhythmus untergeordnet, damit die Queue nicht unkontrolliert wächst.

Was Little's Law NICHT sagt

So mächtig die Formel ist – sie hat klare Grenzen.

Keine Aussage über Verteilung. Little's Law beschreibt Durchschnitte. Wenn W = 5 Stunden, heißt das nicht, dass jedes Ticket 5 Stunden braucht. Manche brauchen 20 Minuten, andere zwei Tage. Die Formel sagt nichts über die Streuung.

Keine Aussage über Einzeltickets. Sie können aus Little's Law nicht ableiten, wie lange ein bestimmtes Ticket dauern wird. Die Formel beschreibt das Systemverhalten, nicht das Verhalten einzelner Items.

Keine Kausalität. Little's Law sagt nicht, warum die Queue wächst. Es stellt nur fest, dass ein Zusammenhang zwischen Queue-Tiefe, Durchsatz und Verweildauer existiert. Die Ursachenanalyse – ist es der Inflow? Die Bearbeitungszeit? Falsche Priorisierung? – erfordert zusätzliche Daten.

Keine Aussage über Qualität. Ein Team kann seinen Durchsatz steigern, indem es Tickets schnell mit unzureichenden Lösungen schließt. Little's Law würde das als "Verbesserung" zeigen – λ steigt, W sinkt. Aber die Reopening-Rate steigt ebenfalls, und die geschlossenen Tickets kommen als neue Tickets zurück. Das System erscheint kurzfristig besser, ist aber langfristig instabiler.

Die Queue lügt nicht

Little's Law ist keine Theorie, die man "anwenden" kann oder nicht. Es ist eine Tatsache, die in jedem System gilt, in dem Items ankommen, verarbeitet und wieder verlassen werden. In jedem Service Desk, in jeder Eskalationsstufe, in jeder Support-Queue.

Die Queue-Tiefe, der Durchsatz und die Verweildauer hängen mathematisch zusammen. Wenn Sie zwei dieser Größen kennen, kennen Sie die dritte. Wenn eine wächst, verändert sich mindestens eine andere. Dagegen gibt es kein Management-Tool und keine Reorganisation – nur ein besseres Verständnis der Zusammenhänge.

Wer seine Queue versteht, versteht sein System. Und wer sein System versteht, trifft bessere Entscheidungen.

Zusammenfassung

Little's Law (L = λ × W) ist eine universelle Gesetzmäßigkeit für alle Systeme, in denen Items verarbeitet werden. Im Service Desk bedeutet es: Wachsende Queues erzwingen längere Wartezeiten, mehr parallele Arbeit verschlechtert die Durchlaufzeit, und ein dauerhafter Inflow-Überschuss führt zu unbegrenztem Rückstau. Die Formel beschreibt Durchschnitte, keine Einzelfälle – aber genau deshalb eignet sie sich als strategisches Steuerungsinstrument für Kapazitätsplanung und Inflow-Kontrolle.

Weiterführende Quellen

  • Little, J.D.C. (1961): "A Proof for the Queuing Formula: L = λW". Operations Research, 9(3), 383–387.
  • Little, J.D.C. & Graves, S.C. (2008): "Little's Law". In: Building Intuition, Springer.
  • Hopp, W.J. & Spearman, M.L. (2011): Factory Physics. 3. Aufl., Waveland Press.
  • Anderson, D.J. (2010): Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.

Solche Muster automatisch erkennen?

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

Zugang anfragen