Durchlaufzeit im ITSM: Warum schnellere Teams das Problem nicht lösen

Durchlaufzeit ist nicht Bearbeitungszeit

Ein typisches Ticket: Ein Endanwender meldet eine VPN-Störung. Der 1st Level Support klassifiziert, prüft Standardlösungen, eskaliert. Reine Bearbeitungszeit: 45 Minuten. Das Ticket wird drei Tage später geschlossen. Gesamtdurchlaufzeit: 72 Stunden.

Wo sind die restlichen 71 Stunden geblieben?

Das Ticket lag 14 Stunden in der Queue des 1st Level. Nach der Eskalation wartete es 22 Stunden auf Zuweisung im 2nd Level. Der 2nd Level stellte eine Rückfrage an den Netzwerk-Betrieb. Antwortzeit: 18 Stunden. Dann nochmal 12 Stunden in der Queue des Netzwerk-Teams. Dazwischen: Schichtwechsel, Wochenenden, andere Prioritäten.

Jeder Bearbeitungsschritt dauerte Minuten. Die Wartezeit dazwischen dauerte Tage. Das Verhältnis: 1 % Arbeit, 99 % Warten.

Der Endanwender sieht nur die 72 Stunden. Der IT-Leiter sieht nur die Bearbeitungszeit pro Team. Beide ziehen die falsche Schlussfolgerung. Der eine denkt: „Die IT ist langsam." Der andere denkt: „Meine Teams müssen schneller werden." Keiner sieht die Wartezeit.

Das Ticket ist ein typischer Fall. Keine Ausnahme. In den meisten IT-Organisationen liegt das Verhältnis von Bearbeitungszeit zu Gesamtdurchlaufzeit zwischen 5 und 20 %. Die restlichen 80 bis 95 % sind Wartezeit. Das Ticket liegt irgendwo. Niemand arbeitet daran.

Drei Wartezeit-Treiber, die kein Dashboard misst

Wartezeit entsteht nicht zufällig. Drei Treiber tauchen in den Daten immer wieder auf. Jeder einzelne ist für sich unsichtbar. Zusammen erklären sie den Großteil der Durchlaufzeit.

Queue-Wartezeit. Ein Ticket wird erstellt. Es landet in der Warteschlange des zuständigen Teams. Dort liegt es, bis ein Mitarbeiter es aufgreift. In einer typischen ITSM-Umgebung vergehen zwischen Ticket-Erstellung und erster Bearbeitung im Median 4 bis 8 Stunden. Bei Spezialisten-Teams, die nur tagsüber besetzt sind, auch 16 bis 24 Stunden.

Diese Wartezeit ist unsichtbar. Das Dashboard zeigt: Ticket ist zugewiesen. Der IT-Leiter denkt: wird bearbeitet. In Wahrheit liegt es in der Queue. Der Status „zugewiesen" bedeutet nicht „in Arbeit". Er bedeutet: „Irgendwann dran."

Übergabe-Wartezeit. Das Ticket wechselt das Team. Der 1st Level eskaliert an den 2nd Level. Der 2nd Level hat eine eigene Queue. Das Ticket wartet erneut. In gemessenen Daten: Jede Übergabe addiert im Median 6 bis 12 Stunden Wartezeit. Ein Ticket mit drei Zuweisungen sammelt allein durch Übergaben 18 bis 36 Stunden.

Nicht weil Teams langsam arbeiten. Weil jedes Team seinen eigenen Rückstau hat. Der 2nd Level hat 40 offene Tickets. Das neu eskalierte Ticket reiht sich ein. Egal wie schnell der 1st Level eskaliert hat. Egal wie dringend der Endanwender wartet. Das Ticket steht in der Schlange.

Rückfrage-Wartezeit. Das bearbeitende Team braucht Informationen. Vom Endanwender, von einem anderen Team, von einem externen Dienstleister. Das Ticket wartet auf Antwort. Median-Wartezeit bei internen Rückfragen: 8 bis 14 Stunden. Bei Rückfragen an Endanwender: 24 bis 48 Stunden. Während dieser Zeit zählt das Ticket als „in Bearbeitung". Tatsächlich passiert nichts.

Ein Beispiel aus der Praxis: Ein Server-Team stellt montags 15 Rückfragen an den Fachbereich. Bis Mittwoch kommen 8 Antworten zurück. Die restlichen 7 Tickets stehen bis Freitag still. Fünf Tage Wartezeit. Für eine fehlende Information.

Kein Standard-Dashboard trennt diese drei Wartezeit-Typen. Die meisten ITSM-Reports zeigen: durchschnittliche Bearbeitungszeit pro Team. Das ist die Kennzahl, die am wenigsten über die Durchlaufzeit aussagt.

„Schneller arbeiten" drückt den falschen Hebel

Der IT-Leiter sieht hohe Durchlaufzeiten. Die Teams bekommen den Auftrag: schneller bearbeiten. Das klingt logisch. Die Rechnung zeigt das Gegenteil.

Bearbeitungszeit pro Ticket: 45 Minuten. Wartezeit pro Ticket: 71 Stunden. Ein Team, das seine Bearbeitungszeit um 50 % senkt, spart 22 Minuten. Eine Reduzierung der Wartezeit um 20 % spart 14 Stunden. Das ist Faktor 38.

22 Minuten gegen 14 Stunden. Der IT-Leiter investiert seine Aufmerksamkeit in den Faktor, der am wenigsten bewirkt. Nicht aus Inkompetenz. Weil die Bearbeitungszeit die einzige Kennzahl ist, die pro Team messbar ist. Wartezeit zwischen Teams misst niemand.

Das erzeugt einen Teufelskreis. Die Teams arbeiten schneller. Die Durchlaufzeit bleibt gleich. Der IT-Leiter erhöht den Druck. Die Teams arbeiten noch schneller. Die Durchlaufzeit bleibt gleich. Die Frustration steigt auf beiden Seiten.

Dabei liegt das Problem gar nicht bei den Teams. Es liegt in den Lücken zwischen den Teams. In den Queues, in den Übergaben, in den Rückfragen. Diese Lücken sind strukturell. Kein Team kann sie allein schließen, weil jedes Team nur seinen eigenen Abschnitt sieht.

Ein konkretes Beispiel: Eine IT-Organisation mit 12.000 Tickets pro Monat reduzierte die durchschnittliche Bearbeitungszeit um 30 %. Das Service-Desk-Team arbeitete messbar schneller. Die Durchlaufzeit sank um 3 %. Weil 97 % der Durchlaufzeit aus Wartezeit bestand, die niemand angefasst hatte. Die Teams waren nicht das Problem. Die Wartezeit zwischen den Teams war das Problem.

Der IT-Leiter hatte die falsche Frage gestellt. Nicht „Wie schnell arbeiten die Teams?" hätte er fragen müssen. Sondern: „Wie lange wartet das Ticket zwischen den Teams?"

Die Durchlaufzeit zerlegen – drei Fragen für IT-Leiter

Bevor ein IT-Leiter Maßnahmen ergreift, braucht er drei Antworten. Keine davon liefert das Standard-Dashboard.

Frage 1: Wie viel Prozent der Durchlaufzeit ist Wartezeit? Die meisten IT-Leiter schätzen 30 bis 40 %. Die typische Realität liegt bei 60 bis 80 %. Allein diese Zahl verändert die Diskussion. Wer weiß, dass nur 20 % der Durchlaufzeit aktive Bearbeitung sind, fragt nicht mehr nach schnelleren Teams. Sondern nach kürzeren Wartezeiten.

Die Berechnung ist einfach. Durchlaufzeit minus Bearbeitungszeit ergibt Wartezeit. Beide Werte stecken in der Ticket-Historie. Die meisten ITSM-Systeme protokollieren Statuswechsel mit Zeitstempel. Daraus lässt sich die aktive Bearbeitungszeit ableiten. Der Rest ist Warten.

Frage 2: Wo entsteht die meiste Wartezeit? Nicht pauschal. Zwischen welchen Teams. Die Übergabe vom Service Desk an den 2nd Level dauert anders als die vom 2nd Level an den Netzwerk-Betrieb. In den meisten Organisationen konzentriert sich 60 % der gesamten Wartezeit auf zwei bis drei Übergabe-Punkte. Das sind die Hebel.

Ein typisches Muster: Die Übergabe an das Netzwerk-Team dauert im Median 18 Stunden. Die Übergabe an das Desktop-Team dauert 4 Stunden. Beide Teams haben ähnliche Auslastung. Der Unterschied: Das Netzwerk-Team priorisiert eingehende Tickets anders. Wer diesen Übergabe-Punkt kennt, kann gezielt ansetzen.

Frage 3: Wie viele Zuweisungen durchläuft ein Ticket im Schnitt? Ein Ticket mit einer Zuweisung hat wenig Wartezeit. Zwei Zuweisungen verdoppeln die Wartezeit nicht, sie verdreifachen sie. Ab drei Zuweisungen explodiert die Durchlaufzeit. Der Median steigt auf das 5- bis 10-Fache eines direkt bearbeiteten Tickets.

Die Anzahl der Zuweisungen ist der stärkste Prädiktor für hohe Durchlaufzeit. Nicht die Kategorie. Nicht die Priorität. Die Zahl der Stationen, die das Ticket durchläuft.

Diese drei Fragen lassen sich aus jeder ITSM-Ticket-Historie beantworten. Ohne neue Tools, ohne Beratungsprojekt. Export, Pivot, Erkenntnis.

Wartezeit sichtbar machen

Process Radar zerlegt die Durchlaufzeit automatisch in Bearbeitungs- und Wartezeit. Pro Rolle, pro Kategorie, pro Ticket-Pfad. Die Analyse zeigt, wo Wartezeit entsteht, zwischen welchen Teams sie sich konzentriert und welche Kapazitätsengpässe die Queues füllen.

Statt pauschaler Durchlaufzeit-Reports sehen IT-Leiter: Übergabe A an B dauert im Median 18 Stunden. Übergabe B an C dauert 3 Stunden. Der Hebel liegt bei A an B. Wer Ticket-Routing-Pfade versteht, kann gezielt die Wartezeit an den Stellen reduzieren, die den größten Anteil an der Durchlaufzeit haben.

Laden Sie Ihre Ticket-Daten hoch – die erste Analyse zeigt, wo Ihre Wartezeit entsteht.

---

Dieses Thema vertiefen: Kapazitätsengpass erkennen: Wenn Teams mehr bekommen als sie schaffen