Kapazitätsengpass erkennen: Wenn Teams mehr bekommen als sie schaffen
68 Tickets pro Woche rein. 34 raus. Der Backlog wächst um 34 Tickets pro Woche. Das ist kein Leistungsproblem. Das ist Aufstau – und er entsteht, wenn Zufluss dauerhaft den Abfluss übersteigt. Kein Team der Welt kann diesen Aufstau durch härteres Arbeiten lösen.
Kapazitätsengpässe sehen aus wie Leistungsprobleme
Ein Team braucht 4,1-mal länger als vergleichbare Rollen. 803 betroffene Tickets. Im Standard-Report steht: "Team X hat erhöhte Durchlaufzeiten." Die naheliegende Interpretation: Das Team arbeitet zu langsam. Die naheliegende Reaktion: Druck, Eskalation, Überstunden.
Aber die Daten zeigen etwas anderes. Wenn der Zufluss doppelt so hoch ist wie der Abfluss, wächst der Aufstau unabhängig davon, wie schnell das Team arbeitet. Selbst wenn jeder Agent seine Bearbeitungszeit halbiert, reicht der Abfluss nicht aus, um den Zufluss zu bewältigen. Das Team wirkt langsam – ist aber strukturell überlastet.
Der Unterschied ist entscheidend für die Maßnahme. Ein Leistungsproblem löst man durch Schulung, Coaching oder Prozessverbesserung. Einen Aufstau löst man durch Zuflusssteuerung, Kapazitätserhöhung oder Kategorien-Umverteilung. Wer ein Kapazitätsproblem als Leistungsproblem behandelt, verschwendet Geld. Und demotiviert ein Team, das bereits am Limit arbeitet. Das Ergebnis: Die besten Leute gehen zuerst – und der Aufstau wird noch schlimmer.
Besonders tückisch: Die Rückmeldung des Teams klingt identisch. "Wir sind überlastet" kann beides bedeuten – zu langsame Bearbeitung oder zu hoher Zufluss. Nur die Daten zeigen den Unterschied. Bearbeitungszeit pro Ticket stabil, aber Queue wächst? Aufstau. Bearbeitungszeit steigt, Queue stabil? Komplexitätsproblem. Beides steigt? Kombination aus beidem – dann hilft es, die Zufluss-Seite zuerst zu adressieren, weil sie schneller wirkt.
Warum Durchschnittswerte den Aufstau verdecken
ITSM-Reports zeigen typischerweise die durchschnittliche Bearbeitungszeit pro Team. 12 Stunden Durchschnitt – klingt akzeptabel. Aber Durchschnitte verdecken den Aufstau auf drei Arten.
Erstens: Wartezeit verschwindet in der Gesamtzeit. Wenn ein Ticket 2 Stunden bearbeitet wird, aber 10 Stunden in der Queue wartet, zeigt die Gesamtdurchlaufzeit 12 Stunden. Der Report unterscheidet nicht zwischen Bearbeitung und Warten. Das Team sieht "12 Stunden" und denkt: "Das stimmt ungefähr." Der IT-Leiter sieht "12 Stunden" und denkt: "Das muss schneller gehen." Beide haben technisch recht. Aber die Lösung liegt bei der Queue, nicht bei der Bearbeitungsgeschwindigkeit.
Zweitens: Schnelle Tickets kompensieren langsame. Wenn 60 Prozent der Tickets in 2 Stunden erledigt sind und 40 Prozent 30 Stunden brauchen, zeigt der Durchschnitt 13 Stunden. Das klingt nach einem moderaten Problem. Tatsächlich hat das Team eine Zwei-Klassen-Bearbeitung: Standardfälle laufen durch, komplexe Fälle stauen. Die Ursache liegt oft in einer bestimmten Kategorie oder einem bestimmten Vorgänger-Team.
Drittens: Bestandsgröße fehlt. Standard-Reports zeigen Durchlaufzeit und Volumen. Was sie nicht zeigen: Wie viele Tickets liegen gerade im Backlog? Wie hat sich der Bestand in den letzten Wochen entwickelt? Ein wachsender Bestand bei gleichbleibender Bearbeitungszeit ist das Frühwarnsignal für Aufstau. Aber es steht in keinem Standard-Dashboard.
Was die Daten über Kapazitätsengpässe verraten
Drei Kennzahlen reichen, um einen Kapazitätsengpass von einem Leistungsproblem zu unterscheiden.
Zufluss-Abfluss-Verhältnis
Die wichtigste Kennzahl: Wie viele Tickets kommen pro Woche rein, wie viele werden abgeschlossen?
Ein Verhältnis über 1,15 bedeutet: Der Bestand wächst. Über 1,5: Der Aufstau beschleunigt sich. Bei 2:1 verdoppelt sich der Backlog innerhalb weniger Wochen.
Wichtig: Das Verhältnis muss über mehrere Wochen betrachtet werden. Eine einzelne Woche mit hohem Zufluss kann ein Ausreißer sein. Vier Wochen mit konstant erhöhtem Zufluss sind ein Muster. Die Trendrichtung zählt mehr als der Einzelwert.
In einem realen Fall: SAP Basis erhielt 68 Tickets pro Woche und schloss 34 ab. Verhältnis: 2:1. Der Backlog wuchs um 34 Tickets pro Woche. Kein Training, keine Prozessverbesserung und keine Überstunden hätten diesen Aufstau lösen können – der Zufluss war schlicht doppelt so hoch wie die Kapazität.
Median-Vergleich mit Peer-Rollen
Ein einzelnes Team isoliert betrachtet sagt wenig. Aber im Vergleich mit ähnlichen Rollen wird der Aufstau sichtbar. Wenn alle Second-Level-Teams eine Median-Bearbeitungszeit von 8 Stunden haben und ein Team bei 33 Stunden liegt, ist die Abweichung signifikant. Der Faktor 4,1 in unserem Beispiel bedeutet: Dieses Team braucht viermal so lang wie seine Peers.
Bestandsentwicklung über Zeit
Ein wöchentlicher Blick auf die Bestandsgröße zeigt, ob der Aufstau wächst, stabil ist oder schrumpft. Wachsender Bestand bei stabiler Bearbeitungszeit ist das sicherste Signal für einen Kapazitätsengpass. Schrumpfender Bestand bei steigender Bearbeitungszeit deutet auf ein Komplexitätsproblem: Die Tickets werden schwieriger, nicht mehr.
Drei Wochen wachsender Bestand können ein saisonaler Effekt sein. Sechs Wochen sind ein Muster. Zwölf Wochen sind ein strukturelles Problem. Die Zeitreihe zeigt auch, ob eine Maßnahme wirkt: Wenn nach einer Routing-Änderung der Bestand schrumpft, war die Maßnahme richtig. Wenn er weiter wächst, braucht es einen anderen Hebel.
Ein oft übersehenes Signal: Der Bestand ist stabil, aber die Zusammensetzung ändert sich. Alte Tickets bleiben liegen, neue werden bevorzugt bearbeitet. Das erzeugt einen "verdeckten Aufstau" – der Bestand sieht konstant aus, aber ein wachsender Anteil der Tickets ist alt. Dieser Effekt zeigt sich erst, wenn man die Altersstruktur des Backlogs betrachtet.
Vier Hebel gegen strukturellen Aufstau
Zufluss umleiten
Oft kommen Tickets an ein Team, die dort gar nicht hingehören. Wenn 25 Prozent der eingehenden Tickets besser bei einem anderen Team aufgehoben wären, reduziert eine Routing-Anpassung den Zufluss sofort. Im SAP-Basis-Beispiel wurden zwei Kategorien ans spezialisierte SAP-Development-Team umgeleitet. Das senkte den Zufluss um 25 Prozent – genug, um den Aufstau zu stoppen.
Kapazität gezielt aufstocken
Wenn der Zufluss berechtigt ist und nicht umgeleitet werden kann, braucht das Team mehr Kapazität. Aber: pauschal aufstocken ist teuer. Gezielt aufstocken heißt: In welcher Kategorie entsteht der Aufstau? Oft bindet eine einzelne Kategorie 60 Prozent der Bearbeitungszeit. Ein zusätzlicher Spezialist für diese Kategorie wirkt stärker als zwei Generalisten.
Kategorien umverteilen
Manchmal braucht ein Team keine zusätzlichen Köpfe, sondern eine andere Mischung. Wenn 40 Prozent der Tickets Spezialkompetenz erfordern und 60 Prozent Routine sind, kann die Routine verlagert werden. Das entlastet ohne Neueinstellung.
Ein Beispiel: Ein Netzwerk-Team bearbeitet sowohl komplexe Firewall-Änderungen als auch einfache WLAN-Zugänge. Die Firewall-Tickets brauchen 4 Stunden, die WLAN-Tickets 15 Minuten. Wenn die WLAN-Tickets an den Service Desk verlagert werden, gewinnt das Netzwerk-Team 30 Prozent seiner Kapazität zurück – für die Tickets, die tatsächlich Netzwerk-Expertise erfordern.
Kaskadeneffekte prüfen
Ein Kapazitätsengpass betrifft selten nur ein Team. Wenn SAP Basis staut, warten nachgelagerte Teams auf Zulieferung. Application Management und Change Management erben den Aufstau – nicht weil sie selbst überlastet sind, sondern weil sie auf Input warten. Wer den Engpass am Ursprung löst, befreit die gesamte Kette. In unserem Beispiel: 4.800 Stunden Gesamt-Impact über drei Teams – verursacht durch einen einzigen Engpass.
Wie Process Radar Kapazitätsengpässe identifiziert
Process Radar berechnet das Zufluss-Abfluss-Verhältnis pro Rolle automatisch aus den Ticket-Daten. Der Peer-Vergleich zeigt, welche Teams signifikant abweichen. Die Bestandsentwicklung wird als wöchentliche Zeitreihe dargestellt – inklusive der Frage, ob der Aufstau wächst oder schrumpft. Kaskaden auf nachgelagerte Teams werden automatisch erkannt und im Briefing als zusammenhängendes Handlungsfeld dargestellt: betroffene Tickets, Aufstau-Faktor, geschätzte Mehrkosten. Alles in unter 60 Sekunden nach dem CSV-Upload.
Der häufigste Aha-Moment: "Unser Team ist nicht langsam. Es bekommt zu viel." Diese Erkenntnis verändert das Gespräch – von Schuldzuweisung zu Strukturdiskussion. Und sie ist in 60 Sekunden belegt, nicht in 60 Seiten Report.
Testen Sie es mit Ihren eigenen Daten – die erste Analyse ist kostenlos.