3.296 Stunden pro Woche. Nicht Überstunden — verlorene Produktivität, weil ein einziges Team strukturell mehr Tickets bekommt als es abarbeiten kann. 68 rein, 34 raus. Jede Woche. Der Rückstau ist kein Gefühl, er ist messbar.
In vielen IT-Organisationen gibt es Teams, die chronisch hinterherhinken. Die Tickets stapeln sich, die Durchlaufzeiten steigen, und die naheliegende Erklärung lautet: Das Team ist zu langsam. Aber was, wenn das Problem nicht Leistung ist, sondern Struktur?
Warum ist ein Team langsamer als alle anderen?
Nicht Faulheit, sondern Kapazität. Wenn der Zufluss den Abfluss übersteigt, wächst der Rückstau — unabhängig von der Leistung einzelner Mitarbeiter. In Echtdaten zeigt sich das Muster deutlich: Ein Team verarbeitet Tickets im Median 4× langsamer als vergleichbare Rollen. Nicht bei Einzelfällen, sondern über 803 Tickets hinweg.
Das Verhältnis ist einfach: 68 Tickets kommen pro Woche rein, 34 werden abgeschlossen. Die Differenz — 34 Tickets pro Woche — bleibt liegen. Nach einem Monat sind das über 130 zusätzliche offene Tickets. Nach einem Quartal ist der Rückstand so groß, dass keine Überstunden ihn abbauen können.
Was passiert, wenn der Engpass ignoriert wird?
Der Kaskadeneffekt. Ein Engpass bleibt selten isoliert. Nachgelagerte Teams, die auf Zuarbeit warten, können ihre eigenen Tickets nicht abschließen. In den Daten: Network Ops zeigt zusätzliche 2.847 Stunden Impact, Identity & Access Management weitere 1.204 Stunden. Aus einem Engpass werden drei.
Das Tückische: Die nachgelagerten Teams erscheinen in ihren eigenen Dashboards ebenfalls als "zu langsam". Ihr Leiter bekommt denselben Vorwurf wie das ursprüngliche Engpass-Team. Aber die Ursache liegt nicht bei ihnen — sie erben ein Problem, das sie nicht verursacht haben.
Wie erkennt man einen strukturellen Engpass?
Drei Indikatoren reichen:
Verweildauer vs. Peer-Rollen. Wenn ein Team signifikant langsamer ist als vergleichbare Rollen — nicht um 20%, sondern um das Mehrfache — liegt ein strukturelles Problem vor. Der Peer-Vergleich ist entscheidend: Nicht absolute Zahlen zählen, sondern die Abweichung vom Normalwert vergleichbarer Teams.
Zufluss-Abfluss-Ratio. Wenn dauerhaft mehr Tickets eingehen als abgeschlossen werden, ist die Ursache nicht Geschwindigkeit, sondern Volumen. Ein Verhältnis von 2:1 — wie in den Echtdaten: 68 rein, 34 raus — ist kein Leistungsproblem. Es ist ein Kapazitätsproblem.
Kaskadeneffekt auf nachgelagerte Teams. Wenn Teams, die auf Zuarbeit angewiesen sind, ebenfalls steigende Verweildauern zeigen, bestätigt das den Engpass. Der Effekt pflanzt sich fort wie eine Welle — und ist in den Daten sichtbar.
Was unterscheidet einen Kapazitätsengpass von einem Leistungsproblem?
Leistungsprobleme sind personenbezogen und schwanken. Ein Mitarbeiter hat eine schlechte Woche, ein anderer ist neu und braucht Einarbeitungszeit. Diese Schwankungen sind normal und gleichen sich über hunderte Tickets aus.
Kapazitätsengpässe sind strukturell und stabil. Sie zeigen sich nicht bei einzelnen Tickets, sondern als konsistentes Muster über Wochen und Monate. In den Daten: 803 Tickets mit derselben Abweichung. Das ist kein Zufall und keine schlechte Phase. Das ist Struktur.
Der Unterschied ist wichtig, weil er die Lösung bestimmt. Ein Leistungsproblem löst man mit Training oder Coaching. Einen Kapazitätsengpass löst man mit Routing, Volumensteuerung oder zusätzlicher Kapazität. Die falsche Diagnose führt zur falschen Maßnahme — und das Problem bleibt.
Was kann ein IT-Leiter tun?
Drei Hebel stehen zur Verfügung:
Routing anpassen. Kommen Tickets an dieses Team, die woanders bearbeitet werden könnten? In vielen Fällen landen Tickets bei einem Team, weil die Zuordnungsregeln zu pauschal sind — nicht weil dieses Team fachlich zuständig ist.
Kapazität erhöhen. Ist das Team für das aktuelle Volumen ausgelegt? Wenn sich das Ticket-Volumen in den letzten Monaten verändert hat, aber die Teamgröße nicht, ist ein Kapazitätsengpass die natürliche Folge.
Kategorien umverteilen. Können bestimmte Ticket-Typen anders geroutet werden? Oft reicht es, eine einzelne Kategorie auf ein anderes Team umzuleiten, um den Zufluss um 20–30% zu reduzieren.
Aber zuerst: Das Problem sichtbar machen. Denn ohne Daten bleibt es bei Vermutungen — und die häufigste Vermutung ("Das Team ist zu langsam") ist meistens falsch.
Kapazitätsengpässe sind keine Leistungsprobleme. Sie sind strukturell, messbar und lösbar — wenn man sie erkennt. Die Daten dafür existieren in jedem ITSM-System. Man muss nur die richtigen Fragen stellen: Nicht "Wer ist zu langsam?", sondern "Wo übersteigt der Zufluss den Abfluss?"
Solche Muster automatisch erkennen?
Process Radar analysiert Ihre ITSM-Daten und zeigt strukturelle Probleme — ohne manuelles Reporting.
Zugang anfragen