ITIL beschreibt den Rahmen. Aber wie sieht konkrete Prozessverbesserung in der Praxis aus? Ein anonymisiertes Beispiel zeigt, wie eine mittelständische IT-Organisation mit datengetriebener Analyse ihre Incident-Bearbeitungszeit strukturell verbessert hat – ohne zusätzliches Personal, ohne neues Tooling.
Ausgangslage: Dashboard grün, Kunden unzufrieden
Eine mittelständische IT-Organisation (ca. 2.000 Mitarbeiter, 20-köpfiges IT-Team) bearbeitet rund 3.000 Tickets pro Monat. Die SLA-Quote liegt bei 91%. Die Durchlaufzeit im Durchschnitt bei 16 Stunden. Auf dem Papier sieht alles akzeptabel aus.
Aber die interne Zufriedenheit mit dem IT-Service sinkt. Die Geschäftsführung fragt: “Warum beschweren sich die Abteilungen, wenn unsere Zahlen stimmen?”
Schritt 1: Die Verteilung hinter dem Durchschnitt
Der IT-Leiter exportiert Ticket-Daten und Ticket-Historie aus dem ITSM-Tool und analysiert sie mit Process Radar. Die erste Erkenntnis: Der Durchschnitt von 16 Stunden verbirgt eine bimodale Verteilung.
Rund 70% der Tickets werden in unter 6 Stunden gelöst – für diese Tickets funktioniert der Prozess. Aber 15% der Tickets brauchen mehr als 40 Stunden. Diese Tickets ziehen den Durchschnitt hoch und verursachen den Großteil der Unzufriedenheit.
Schritt 2: Muster in den langsamen Tickets
Process Radar zeigt: Die langsamen Tickets sind nicht zufällig verteilt. Sie konzentrieren sich auf zwei Muster:
Muster A: Routing-Schleife
Tickets einer bestimmten Kategorie pendeln zwischen zwei Teams. Die Kategorie betrifft Themen, die an der Grenze zwischen Netzwerk und Applikation liegen. Kein Team fühlt sich zuständig.
Muster B: Wartezeit-Dominanz
Eine andere Kategorie hat hohe Durchlaufzeiten, weil Tickets im Median 20 Stunden in einer Queue liegen, bevor jemand sie anfasst. Die eigentliche Bearbeitung dauert 3 Stunden.
Schritt 3: ITIL-konforme Maßnahmen ableiten
Im ITIL-Framework entspricht das dem Continual Service Improvement (CSI) Prozess: Messen → Analysieren → Verbessern → Kontrollieren. Der Unterschied: Die Analyse liefert konkrete, faktenbasierte Maßnahmen statt allgemeiner Empfehlungen.
Für die Routing-Schleife
Neue Zuweisungsregel: Tickets der betroffenen Kategorie gehen direkt an das Netzwerk-Team mit einem vordefinierten Informationsset. Der Applikations-Aspekt wird als Folgemaßnahme koordiniert, nicht als Ping-Pong.
Für die Wartezeit-Dominanz
Queue-Priorisierung nach Kategorie und Ticket-Alter. Tickets der betroffenen Kategorie erhalten höhere Priorität in der Queue-Sortierung.
Schritt 4: Wirkung kontrollieren
Vier Wochen nach Umsetzung der Maßnahmen zeigt die erneute Analyse: Die Routing-Schleife in Kategorie A ist deutlich rückläufig. Die Wartezeit in Kategorie B hat sich spürbar reduziert. Die Gesamtdurchlaufzeit ist gesunken – nicht weil alle Tickets schneller werden, sondern weil die Ausreißer weniger werden.
Was dieses Beispiel zeigt
Die ITIL-Prinzipien waren vorhanden. Das ITSM-Tool war konfiguriert. Die Daten wurden gesammelt. Was fehlte, war die Analyse: Der Blick auf die Zusammenhänge, die Muster, die konkreten Hebel. Die Daten waren da – sie wurden nur nicht ausgewertet.
Datengetriebene Prozessanalyse ist kein Widerspruch zu ITIL – sie ist die konsequente Umsetzung des CSI-Gedankens. Statt auf Bauchgefühl oder allgemeine Best Practices zu setzen, wird mit echten Daten gearbeitet: Was passiert wirklich? Wo ist der größte Hebel? Hat die Maßnahme gewirkt?
ITIL-konforme Prozessverbesserung – datengetrieben
Process Radar liefert die Analyse. Sie liefern die Maßnahmen. Ergebnisse in Minuten, nicht in Wochen.
Kostenlos starten