Über 1.000 Stunden pro Monat. Nicht Überstunden. Nicht Ausfälle. Reibung. Unsichtbar — bis man genau hinschaut.
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, werden weitergeleitet, zurückgeschoben, erneut zugewiesen. Der Endnutzer wartet. Die Teams fühlen sich nicht verantwortlich. Und kein Dashboard zeigt, dass hier ein systemisches Problem vorliegt.
Was ist Ticket-Ping-Pong?
Ein Ticket wird mehrfach zwischen Teams weitergeleitet, ohne dass die eigentliche Bearbeitung wesentlich vorankommt. Statt einer Zuweisung und einer Bearbeitung durchläuft das Ticket drei, vier oder mehr Stationen. Jede Weiterleitung kostet Zeit — nicht nur die reine Übergabe, sondern auch das erneute Einlesen, das Bewerten und das Entscheiden, ob man zuständig ist.
Die Durchlaufzeit steigt dabei auf ein Vielfaches: In Echtdaten dauern Ping-Pong-Tickets im Mittel 3.3× länger als direkt bearbeitete Tickets derselben Kategorie. Im Median ist der Unterschied noch drastischer — 75 Stunden statt 4. Die eigentliche Bearbeitungszeit bleibt oft gleich — die zusätzlichen Stunden sind reine Wartezeit zwischen den Zuweisungen.
Warum passiert das?
Drei Ursachen treten immer wieder auf:
Unklare Zuständigkeitsregeln. Das ist die häufigste Ursache. Für bestimmte Ticket-Kategorien gibt es keine eindeutige Regel, welches Team zuständig ist. Besonders bei Kategorien, die an der Grenze zwischen zwei Verantwortungsbereichen liegen — etwa Netzwerk-Incidents, die sowohl vom 1st Level Support als auch von Network Operations bearbeitet werden könnten.
Fehlende Informationen im Ticket. Das Ticket enthält nicht genug Details, damit das empfangende Team erkennen kann, ob es zuständig ist. Also wird es sicherheitshalber weitergeleitet — mit dem Ergebnis, dass das nächste Team vor demselben Problem steht.
Unterschiedliche Interpretationen von Kategorien. Team A versteht unter "Netzwerk" etwas anderes als Team B. Die Kategorisierung im Ticket-System ist zu grob oder mehrdeutig. Beide Teams halten sich für nicht zuständig — und beide haben aus ihrer Perspektive recht.
Warum zeigt kein Dashboard das Problem?
Dashboards messen pro Team: durchschnittliche Bearbeitungszeit, offene Tickets, SLA-Quote. Was sie nicht zeigen, sind die Übergänge zwischen Teams.
Team A sieht in seinem Dashboard: "Wir leiten 30% der Netzwerk-Tickets weiter — das ist normal." Team B sieht dasselbe. Niemand sieht, dass es dieselben Tickets sind, die 3× zwischen beiden Teams hin- und hergehen. Jedes Team sieht seine eigene Perspektive und hält sein Verhalten für korrekt.
Das Problem wird erst sichtbar, wenn man die Ticket-Pfade über alle Teams hinweg betrachtet — nicht die Einzelperspektive, sondern den Gesamtfluss.
Wie groß ist der Schaden?
In einer realen IT-Organisation mit über 15.000 Tickets sind die Zahlen ernüchternd: 21% aller Tickets durchlaufen drei oder mehr Zuweisungen — jedes fünfte Ticket. Die Median-Durchlaufzeit bei diesen Tickets liegt bei 75 Stunden — gegenüber 4 Stunden bei direkt bearbeiteten Tickets.
Allein in der größten Ticket-Kategorie summiert sich das auf über 1.000 Stunden pro Monat an vermeidbarer Reibung. Nicht weil jemand schlecht arbeitet — weil der Prozess es so erzwingt.
64% der Ping-Pong-Events konzentrieren sich auf Montag bis Mittwoch — die Tage mit dem höchsten Ticket-Volumen. Unter Druck werden Zuständigkeitsfragen schneller mit Weiterleitung statt mit Bearbeitung beantwortet.
Wie erkennt man Routing-Schleifen?
Drei Ansätze, die auch ohne spezialisierte Tools funktionieren:
1. Zuweisungshäufigkeit pro Ticket analysieren. Exportieren Sie die Ticket-Historie und zählen Sie die Zuweisungen pro Ticket. Tickets mit drei oder mehr Zuweisungen sind Kandidaten. Vergleichen Sie deren Durchlaufzeit mit der von Tickets, die direkt bearbeitet wurden.
2. Quell-Ziel-Matrix der Weiterleitungen erstellen. Welches Team leitet an welches Team weiter — und wie oft? Suchen Sie nach bidirektionalen Mustern: Wenn Team A regelmäßig an Team B weiterleitet und Team B regelmäßig an Team A zurück, haben Sie eine Routing-Schleife gefunden.
3. Durchlaufzeit mit vs. ohne Mehrfach-Routing vergleichen. Bilden Sie zwei Gruppen: Tickets mit einer Zuweisung und Tickets mit mehreren. Wenn die Durchlaufzeit-Differenz signifikant ist (in der Praxis oft Faktor 2–4), liegt ein strukturelles Routing-Problem vor.
Das Muster ist in den Daten — man muss nur an der richtigen Stelle suchen. Nicht in Team-Dashboards, die jedes Team isoliert zeigen, sondern in den Übergängen dazwischen. Dort, wo Tickets von einem Verantwortungsbereich zum nächsten wandern, entstehen die Reibungsverluste, die in keiner Quartalsübersicht auftauchen.
Solche Muster automatisch erkennen?
Process Radar analysiert Ihre ITSM-Daten und zeigt strukturelle Probleme — ohne manuelles Reporting.
Zugang anfragen