ITSM-Kennzahlen richtig lesen: Was unter der Oberfläche liegt
92 Prozent SLA-Erfüllung. 12 Stunden durchschnittliche Durchlaufzeit. 4.000 gelöste Tickets im Monat. Alles im grünen Bereich. Oder? Unter der Oberfläche dieser Kennzahlen verbergen sich Muster, die den Unterschied zwischen guter und mittelmäßiger IT-Performance ausmachen.
Durchschnitte verbergen die größten Hebel
Ein SLA-Wert von 92 Prozent entsteht aus einer Verteilung. Wenn 30 Kategorien bei 97 Prozent liegen und 3 Kategorien bei 65 Prozent, zeigt der Gesamtwert 92 Prozent. Alle 33 Kategorien sehen im Report identisch aus: "SLA erfüllt" oder "SLA nicht erfüllt." Die drei Kategorien bei 65 Prozent verschwinden in der Masse.
Aber genau dort liegt der Hebel. Von 97 auf 99 Prozent zu optimieren kostet Aufwand, bringt aber marginal wenig. Von 65 auf 85 Prozent zu kommen ist ein struktureller Sprung. Und oft einfacher, weil die Ursache spezifisch ist: ein Routing-Fehler, ein Kapazitätsengpass, ein Kategorien-Mix. Wer nur die Oberfläche liest, optimiert an der falschen Stelle.
Das gleiche Muster bei der Durchlaufzeit: 12 Stunden Durchschnitt. Aber die Verteilung zeigt zwei Cluster: 60 Prozent der Tickets bei 2 Stunden, 40 Prozent bei 27 Stunden. Der Durchschnitt liegt bei 12 – und sagt nichts über die Realität. Ein Team mit "12 Stunden durchschnittlicher Bearbeitungszeit" hat entweder ein sehr gleichmäßiges Problem (alle Tickets bei 12 Stunden) oder ein hochgradig ungleichmäßiges (schnelle Routine + langsame Sonderfälle). Die Maßnahme ist in beiden Fällen eine andere.
Vier KPI-Fallen im ITSM-Reporting
Falle 1: SLA als Zielwert statt Diagnosewerkzeug
SLA-Erfüllung misst, ob ein Ticket innerhalb der vereinbarten Frist gelöst wurde. Sie misst nicht, warum ein Ticket zu spät kam. War es ein Kapazitätsproblem? Ein Routing-Fehler? Eine Abhängigkeit von einem anderen Team? Die SLA-Kennzahl sagt: "Zu spät." Sie sagt nicht: "Weil Team B drei Tage auf Zulieferung von Team A gewartet hat."
IT-Leiter, die SLA als Zielwert verwenden, optimieren auf die Frist: "Wir müssen schneller werden." IT-Leiter, die SLA als Diagnosewerkzeug verwenden, fragen: "Warum sind genau diese Tickets zu spät?" Die Antwort führt zum Hebel – der oft nicht beim betroffenen Team liegt.
Falle 2: Durchlaufzeit ohne Wartezeit-Zerlegung
Die Durchlaufzeit eines Tickets besteht aus Bearbeitungszeit und Wartezeit. Ein Ticket mit 48 Stunden Durchlaufzeit kann 2 Stunden aktive Bearbeitungszeit haben und 46 Stunden Wartezeit. Wer die Durchlaufzeit als Ganzes betrachtet, interpretiert: "Die Bearbeitung dauert zu lang." Tatsächlich dauert die Bearbeitung 2 Stunden – das Ticket lag 46 Stunden in der Queue.
Die Konsequenz: "Bearbeitung beschleunigen" bringt wenig. "Queue-Tiefe reduzieren" bringt viel. Aber Standard-Reports zeigen die Zerlegung nicht. Sie zeigen eine Zahl – und die Interpretation bleibt dem Leser überlassen.
Falle 3: Volumen als Proxy für Relevanz
4.000 Tickets pro Monat, davon 1.200 Password Reset. Password Reset dominiert jede Volumen-Statistik. Aber es bindet nur 100 Stunden – 2,5 Prozent der Gesamtkapazität. Gleichzeitig gibt es 200 Tickets "Berechtigungsanträge" mit 15 Stunden Median – das sind 3.000 Stunden, 75 Prozent der Kapazität.
Wer Prioritäten nach Volumen setzt, investiert in die lauteste Kategorie statt in die teuerste. Die Stunden-Sicht – Tickets × Bearbeitungszeit – zeigt eine grundlegend andere Rangfolge.
Falle 4: Trends ohne Kontext
"Durchlaufzeit gestiegen um 15 Prozent." Alarm? Nicht unbedingt. Wenn gleichzeitig das Ticket-Volumen um 30 Prozent gestiegen ist, arbeitet das Team sogar effizienter – es bearbeitet mehr Tickets mit nur leicht höherer Durchlaufzeit. Ohne den Kontext (Volumen, Kategorien-Mix, saisonale Effekte) ist ein Trend-Wert keine Diagnose.
Umgekehrt: "Durchlaufzeit stabil" klingt beruhigend. Aber wenn der Backlog wächst, bedeutet stabile Durchlaufzeit nur, dass die abgeschlossenen Tickets weiterhin schnell sind – während immer mehr Tickets noch gar nicht angefasst wurden. Die Durchlaufzeit der abgeschlossenen Tickets verdeckt den wachsenden Berg unbearbeiteter Tickets.
Was unter der Oberfläche tatsächlich sichtbar wird
Wer über die Standard-KPIs hinaus analysiert, findet drei Arten von Mustern:
Cluster statt Durchschnitte
Jede Kennzahl hat eine Verteilung. Die Verteilung zeigt: Ist das Muster homogen – alle Tickets ähnlich? Oder existieren Cluster – zwei oder mehr Gruppen mit unterschiedlichem Verhalten?
In einer typischen IT-Organisation zeigen 60–70 Prozent der Kategorien ein homogenes Muster. Bei 30–40 Prozent existieren Cluster. Und dort liegen die Hebel.
Warum? Weil ein homogenes Muster eine gleichmäßige Maßnahme braucht: schneller bearbeiten, mehr Kapazität, bessere Tools. Ein Cluster-Muster braucht eine gezielte Maßnahme: Warum sind die 20 Prozent langsamen Tickets langsam? Was unterscheidet sie von den schnellen? Oft ist die Antwort ein Attribut: Standort, Kategorie, Vorgänger-Team. Und die Maßnahme adressiert nur dieses Attribut – nicht die gesamte Kategorie.
Ein Beispiel: "Arbeitsplatz-Service" hat eine Median-Durchlaufzeit von 8 Stunden. Aber die Verteilung zeigt zwei Cluster: Hardware-bezogene Tickets bei 3 Stunden, Software-bezogene bei 18 Stunden. Der Hebel liegt im Software-Cluster – und die Lösung ist eine andere als "das Team schneller machen."
Abhängigkeiten statt Einzelwerte
Korreliert die Durchlaufzeit einer Kategorie mit dem Zufluss einer anderen? Steigt der Backlog von Team B, wenn Team A staut? Diese Abhängigkeiten tauchen in keinem Standard-Report auf. Aber sie erklären, warum eine Kennzahl sich verschlechtert – obwohl das betroffene Team alles richtig macht.
Ein typisches Muster: Das Application-Management-Team zeigt steigende Durchlaufzeiten. Der Standard-Report sagt: "AppMgmt muss schneller werden." Die Korrelationsanalyse zeigt: Der Anstieg bei AppMgmt folgt dem Anstieg bei SAP Basis mit zwei Wochen Verzögerung. AppMgmt wartet auf Zulieferung – nicht auf bessere Leistung. Die richtige Maßnahme adressiert SAP Basis, nicht AppMgmt. Mehr dazu unter Cross-Team-Abhängigkeiten.
Varianz statt Mittelwert
Der Mittelwert sagt: "Im Schnitt 12 Stunden." Die Varianz sagt: "Aber 20 Prozent der Tickets brauchen 48 Stunden."
Ein Team mit hohem Durchschnitt und niedriger Varianz hat ein gleichmäßiges Kapazitätsproblem. Alle Tickets sind ähnlich langsam. Die Maßnahme: mehr Kapazität oder schnellere Bearbeitung – gleichmäßig.
Ein Team mit niedrigem Durchschnitt und hoher Varianz hat ein Ausreißer-Problem. Die meisten Tickets sind schnell. Einige wenige dauern extrem lang. Die Maßnahme: Diese Ausreißer identifizieren – was haben sie gemeinsam? Oft ist es eine bestimmte Kategorie, ein bestimmter Standort oder ein bestimmtes Vorgänger-Team. Die gezielte Maßnahme für die Ausreißer wirkt stärker als eine allgemeine Beschleunigung.
Drei Schritte von der Oberfläche zum Hebel
Schritt 1: Verteilungen statt Durchschnitte betrachten. Für die fünf wichtigsten Kategorien: Wie sieht die Verteilung der Durchlaufzeiten aus? Gibt es Cluster? Gibt es Ausreißer? Wo liegt der Median vs. der Durchschnitt? Ein großer Abstand zwischen Median und Durchschnitt zeigt: Ausreißer verzerren das Bild.
Schritt 2: Stunden-Impact berechnen. Für jede Kategorie: Tickets × Median-Bearbeitungszeit = gebundene Stunden. Sortierung nach Stunden statt nach Volumen. Die Top-3 nach Stunden sind die Kandidaten für die nächste Maßnahme – ob Automatisierung, Routing-Änderung oder Kapazitätsanpassung.
Schritt 3: Zusammenhänge prüfen. Welche Kategorien korrelieren? Wo gibt es zeitversetzte Muster? Wenn Kategorie A bei Team X steigt und zwei Wochen später Kategorie B bei Team Y steigt, liegt ein systemischer Zusammenhang vor. Isolierte Maßnahmen bei Team Y lösen das Problem nicht.
Wie Process Radar unter die Oberfläche schaut
Process Radar berechnet für jede Kennzahl automatisch die Verteilung, erkennt Cluster und Ausreißer und zeigt den Stunden-Impact statt des Volumens. Abhängigkeiten zwischen Teams werden als zeitversetzte Korrelationen dargestellt. Statt eines einzigen Durchschnittswerts sieht der IT-Leiter: Wo genau liegt das Problem? Wie groß ist es? Und was ist der wahrscheinlichste Hebel? Die drei größten Abweichungen von der erwarteten Performance erscheinen im Briefing – priorisiert nach Impact, nicht nach Alarm.
Laden Sie Ihre Ticket-Daten hoch. Die erste Analyse ist kostenlos.