Über 1.000 Stunden pro Monat. Nicht Überstunden. Nicht Ausfälle. Reibung. Unsichtbar, bis jemand nachrechnet.
In vielen IT-Organisationen gibt es Tickets, die niemand haben will. Nicht weil sie kompliziert sind, sondern weil unklar ist, wer zuständig ist. Diese Tickets wandern von Team zu Team. Sie werden weitergeleitet, zurückgeschoben, erneut zugewiesen. Der Endnutzer wartet. Die Teams fühlen sich nicht verantwortlich. Kein ITSM-Dashboard zeigt, dass hier ein systemisches Problem vorliegt.
Dieser Artikel zeigt, wie Sie die Kosten von Ticket-Routing-Schleifen berechnen. Nicht geschätzt, sondern gemessen.
Tickets kreisen – und niemand merkt es
Ein Ticket wird mehrfach zwischen Teams weitergeleitet. Statt einer Zuweisung und einer Lösung durchläuft es drei, vier oder mehr Stationen. Jede Weiterleitung erzeugt Reibung. Nicht nur die Übergabe selbst kostet Zeit. Das empfangende Team liest sich ein, bewertet und entscheidet: zuständig oder nicht?
Die Ticket-Durchlaufzeit steigt auf ein Vielfaches. In gemessenen Daten dauern Ping-Pong-Tickets im Mittel 3,3× länger als direkt bearbeitete Tickets derselben Kategorie. Im Median: 75 Stunden statt 4. Die eigentliche Bearbeitungszeit bleibt gleich. Die zusätzlichen Stunden sind reine Wartezeit zwischen den Zuweisungen.
Das Tückische: Die Bearbeitungszeit pro Team sieht normal aus. Erst der Blick auf den gesamten Ticket-Pfad zeigt die Reibung.
Drei Ursachen zeigen sich in den Routing-Daten
Routing-Schleifen im ITSM entstehen nicht zufällig. Drei Muster tauchen in den Daten immer wieder auf.
Unklare Zuständigkeitsregeln. Für bestimmte Ticket-Kategorien gibt es keine eindeutige Regel. Besonders bei Kategorien an der Grenze zweier Verantwortungsbereiche. Ein Beispiel: Netzwerk-Incidents, die sowohl der 1st Level Support als auch Network Operations bearbeiten könnte. Ohne klare Regel leiten beide weiter.
Fehlende Informationen im Ticket. Das Ticket enthält nicht genug Details für eine Zuständigkeitsentscheidung. Also leitet das Team sicherheitshalber weiter. Das nächste Team steht vor demselben Problem. Ein Kreislauf aus Informationsmangel.
Mehrdeutige Kategorisierung. Team A versteht unter „Netzwerk" etwas anderes als Team B. Die Kategorien im ITSM-System sind zu grob. Beide Teams halten sich für nicht zuständig. Beide haben aus ihrer Perspektive recht.
Wer die konkreten Ursachen tiefer verstehen will, findet dort eine detaillierte Analyse mit Gegenmaßnahmen.
Team-Dashboards zeigen die Symptome, nicht die Ursache
Standard-ITSM-Dashboards messen pro Team: durchschnittliche Bearbeitungszeit, offene Tickets, SLA-Quote. Was sie nicht messen: die Übergänge zwischen Teams.
Team A sieht: „Wir leiten 30 % der Netzwerk-Tickets weiter." Team B sieht dasselbe. Niemand sieht, dass es dieselben Tickets sind. Dass sie 3× zwischen beiden Teams pendeln. Jedes Team sieht seine Perspektive und hält sein Verhalten für korrekt.
Das Problem wird erst sichtbar, wenn jemand den Ticket-Pfad über alle Teams betrachtet. Nicht die Einzelperspektive, sondern den Gesamtfluss. Genau diese Lücke beschreibt auch der Artikel „Dein ITSM-Dashboard lügt" – Team-KPIs, die grün leuchten, während der Prozess dahinter brennt.
Über 1.000 Stunden Reibung im Monat
In einer realen IT-Organisation mit über 15.000 Tickets zeigen die Daten ein klares Bild.
Die Fakten:
- 21 % aller Tickets durchlaufen drei oder mehr Zuweisungen.
- Median-Durchlaufzeit bei Routing-Schleifen: 75 Stunden.
- Median-Durchlaufzeit bei direkter Bearbeitung: 4 Stunden.
- Faktor: 19×.
Die Rechnung: Allein in der größten Ticket-Kategorie summiert sich die Reibung auf über 1.000 Stunden pro Monat. Bei einem internen Stundensatz von 50 € sind das 50.000 € pro Monat. Für eine einzige Kategorie. Nicht weil jemand schlecht arbeitet. Weil der Prozess es erzwingt.
Das Timing: 64 % der Ping-Pong-Events konzentrieren sich auf Montag bis Mittwoch. Die Tage mit dem höchsten Ticket-Volumen. Unter Druck beantworten Teams Zuständigkeitsfragen mit Weiterleitung statt mit Bearbeitung.
Die resultierende Reibung ist kein individuelles Versagen. Sie ist ein Prozessdesign-Problem, das sich in Euro berechnen lässt.
So berechnen Sie den Routing-Impact in Ihrer Organisation
Drei Ansätze, die auch ohne spezialisierte Tools funktionieren.
Zuweisungshäufigkeit pro Ticket analysieren. Exportieren Sie die Ticket-Historie aus Ihrem ITSM-System. Zählen Sie die Zuweisungen pro Ticket. Tickets mit drei oder mehr Zuweisungen sind Kandidaten. Vergleichen Sie deren Durchlaufzeit mit der von direkt bearbeiteten Tickets.
Quell-Ziel-Matrix erstellen. Welches Team leitet an welches Team weiter? Wie oft? Suchen Sie nach bidirektionalen Mustern. Wenn Team A regelmäßig an Team B weiterleitet und Team B regelmäßig zurück: Routing-Schleife gefunden.
Durchlaufzeit-Delta berechnen. Bilden Sie zwei Gruppen: Tickets mit einer Zuweisung und Tickets mit mehreren. In der Praxis: Faktor 2 bis 4. Multiplizieren Sie das Delta mit der Ticket-Anzahl. Das ist die monatliche Reibung in Stunden.
Wer den Export abkürzen will: Der Use Case Routing-Probleme erkennen zeigt den Weg vom CSV-Export zur ersten Erkenntnis.
Eine Regel reicht, um die größte Schleife zu brechen
Die Reibung durch Routing-Schleifen ist messbar. Die drei Methoden aus dem vorherigen Abschnitt liefern die Datenbasis. Was danach kommt, ist eine Entscheidung: Welche Kategorie bereinigen Sie zuerst?
Typisches Muster: Die Routing-Schleife zwischen 1st Level Support und Network Operations verursacht den größten Impact. Der effektivste Hebel ist eine klare Erst-Zuweisungsregel für genau diese Kategorie. Nicht für alle gleichzeitig. Für die eine, die am meisten Reibung verursacht.
Die Daten zeigen, wo die Reibung entsteht. Nicht in Team-Dashboards, die jedes Team isoliert betrachten. Sondern in den Übergängen dazwischen – dort, wo Tickets den Verantwortungsbereich wechseln und Stunden zu Tagen werden.
Dieses Thema vertiefen: Ticket-Routing optimieren: Wie Umwege den IT-Support ausbremsen
Solche Muster automatisch erkennen?
Process Radar analysiert Ihre ITSM-Daten und zeigt strukturelle Probleme — ohne manuelles Reporting.
Zugang anfragen