IT-Leiter Prozessoptimierung: Was hinter guten Durchschnittswerten steckt

MTTR 4.2 Stunden. SLA-Quote 92 Prozent. Kundenzufriedenheit 3.8 von 5. 450 Tickets geschlossen. Der wöchentliche Report sieht solide aus. Der IT-Leiter nickt, schließt die Datei, wendet sich dem nächsten Thema zu.

Drei Monate später: Ein Team bricht zusammen. Backlog verdoppelt, Durchlaufzeiten explodieren, Beschwerden häufen sich. Und alle fragen: Warum hat das niemand kommen sehen?

Die Antwort: Weil der Report es aktiv verschleiert hat.

Das Durchschnittsproblem

Durchschnittswerte sind die gefährlichsten Kennzahlen im IT-Service-Management. Nicht weil sie falsch sind, sondern weil sie Probleme unsichtbar machen.

Eine MTTR von 4.2 Stunden kann bedeuten: Alle Teams arbeiten gleichmäßig bei 4 Stunden. Oder: Drei Teams arbeiten bei 2 Stunden und ein Team bei 11 Stunden. Der Durchschnitt ist identisch — die Realität könnte nicht unterschiedlicher sein.

Dasselbe gilt für die SLA-Quote. 92 Prozent insgesamt kann heißen: Alle Kategorien liegen bei 90 bis 94 Prozent. Oder: Acht Kategorien liegen bei 98 Prozent und zwei Kategorien bei 60 Prozent. Die zwei Problemkategorien verschwinden im Gesamtdurchschnitt — bis sie groß genug sind, um ihn zu kippen.

Das ist kein theoretisches Problem. In realen IT-Organisationen ist die Varianz zwischen Teams und Kategorien oft größer als die Durchschnittswerte vermuten lassen. Die besten Teams performen drei- bis fünffach besser als die schlechtesten — aber der Durchschnitt zeigt einen Wert irgendwo in der Mitte.

Was ein IT-Leiter wirklich wissen muss

Die Frage ist nicht "Wie stehen wir?" — die Frage ist "Wo muss ich handeln?" Und die Antwort darauf liefert kein Durchschnitt.

Ein IT-Leiter braucht drei Informationen pro Woche:

Was verschlechtert sich? Nicht wo die Zahlen absolut hoch sind, sondern wo sie steigen. Ein Team mit 6 Stunden MTTR und stabilem Trend braucht keine Aufmerksamkeit. Ein Team mit 3 Stunden MTTR und plus 40 Prozent Trend braucht sie dringend — obwohl die absolute Zahl besser aussieht.

Wo ist der größte Hebel? Nicht alle Probleme sind gleich groß. Ein Routing-Problem, das 400 Stunden pro Monat kostet und durch eine Konfigurationsänderung lösbar ist, hat einen besseren Return als ein Kapazitätsproblem, das 2.000 Stunden kostet aber eine Neüinstellung erfordert. Die Frage ist nicht nur "Was ist das größte Problem?" sondern "Was ist das größte lösbare Problem?"

Was ist systemisch? Einzelne Ausreißer sind normal. Wenn aber drei Teams gleichzeitig steigende Durchlaufzeiten zeigen und alle drei auf Zuarbeit desselben vierten Teams angewiesen sind, ist das Problem systemisch — und die Lösung liegt beim vierten Team, nicht bei den dreien.

Warum 50-Seiten-Reports keine Entscheidungen erzeugen

Viele IT-Organisationen produzieren detaillierte monatliche Reports: Ticket-Volumen pro Kategorie, Durchlaufzeiten pro Team, SLA-Quoten pro Priorität, Trendverläufe über sechs Monate. Alles korrekt. Alles vollständig. Und trotzdem ändert sich nichts.

Das Problem ist nicht der Inhalt — es ist das Format. Ein 50-Seiten-Report erzeugt keinen Handlungsdruck. Er erzeugt Leseaufwand. Der IT-Leiter muss sich durch Tabellen arbeiten, Muster erkennen, Zusammenhänge herstellen und Prioritäten ableiten. Das dauert 30 bis 60 Minuten — wenn es überhaupt passiert. In der Praxis wird der Report überflogen, die drei offensichtlichsten Zahlen gemerkt und der Rest vergessen.

Was stattdessen funktioniert: Drei priorisierte Handlungsfelder, jedes mit Impact-Größe, Trend und einer konkreten Leitfrage. Nicht "Durchlaufzeit SAP Basis: 8.4 Stunden" sondern "Kapazitätsengpass SAP Basis — 3.200 Stunden Impact, Trend plus 18 Prozent — liegt es an Volumen, Komplexität oder Routing?"

Diese Verdichtung ist der Unterschied zwischen Information und Entscheidungshilfe.

Ein Praxis-Szenario

Ein IT-Leiter mit fünf Teams und rund 500 Tickets pro Woche bekommt seinen wöchentlichen Report. Alles sieht stabil aus: MTTR liegt bei 4.5 Stunden, SLA-Quote bei 91 Prozent, Kundenzufriedenheit stabil. Keine roten Ampeln.

Process Radar zeigt ein anderes Bild. Hinter der stabilen Gesamt-MTTR verbergen sich zwei gegenläufige Trends: Drei Teams haben sich verbessert — von 5 auf 3 Stunden. Ein Team hat sich verschlechtert — von 6 auf 11 Stunden. Im Durchschnitt: 4.5 Stunden. Stabil. Aber das vierte Team steuert auf einen Zusammenbruch zu.

Im Briefing-View erscheinen drei priorisierte Situationen:

1. Kapazitätsengpass im SAP-Team — 3.200 Stunden Impact, Trend steigend. Leitfrage: Liegt es an gestiegenem Volumen oder an veränderter Ticket-Komplexität?

2. Routing-Anomalie bei Netzwerk-Incidents — Überdurchschnittliche Reassignment-Rate. Leitfrage: Sind die Eskalationskriterien für VPN-Tickets eindeutig?

3. Quick Win im 1st Level — Eine Kategorie mit hoher Bearbeitungszeit, die durch ein Template-Update um 30 Prozent reduziert werden könnte.

Der IT-Leiter braucht 60 Sekunden, um alle drei zu erfassen. Situation 1 delegiert er per Link an den SAP-Teamleiter. Situation 2 nimmt er in das nächste Teamleitemeeting. Situation 3 setzt er sofort um. Drei Entscheidungen in einer Minute — statt 30 Minuten Report-Interpretation mit unsicherem Ergebnis.

Fünf KPIs, die mehr zeigen als Durchschnitte

Statt MTTR und SLA-Quote allein zu betrachten, lohnen sich fünf ergänzende Perspektiven:

1. Varianz zwischen Teams. Wie groß ist die Spreizung der Bearbeitungszeiten? Wenn das langsamste Team dreimal langsamer ist als das schnellste, ist der Durchschnitt bedeutungslos.

2. Volumen-Kapazitäts-Verhältnis. Wie viele Tickets kommen pro Team rein, wie viele gehen raus? Ein Verhältnis über 1.3 zeigt strukturellen Aufstau — unabhängig von der Bearbeitungszeit.

3. Reassignment-Rate. Wie viele Tickets durchlaufen mehr als zwei Zuweisungen? Eine Rate über 15 Prozent deutet auf Routing-Probleme hin.

4. Kategorien-Konzentration bei SLA-Verletzungen. Verteilen sich die Verletzungen gleichmäßig oder konzentrieren sie sich auf wenige Kategorien? Konzentration deutet auf ein spezifisches Problem hin, gleichmäßige Verteilung auf ein systemisches.

5. Trend statt Absolutwert. Nicht die Zahl zählt, sondern die Veränderung. Ein Team mit 8 Stunden MTTR und sinkendem Trend ist in besserer Verfassung als eines mit 4 Stunden und steigendem Trend.

Drei Schritte für morgen

Schritt 1: Varianz sichtbar machen. Nimm deinen letzten Report und prüfe: Wie groß ist die Spreizung zwischen dem besten und dem schlechtesten Team? Wenn der Faktor größer als 2 ist, versteckt der Durchschnitt ein Problem.

Schritt 2: Automatisch priorisieren lassen. Lade deine Ticket-Daten als CSV in Process Radar hoch. Das Tool identifiziert automatisch die wichtigsten Handlungsfelder und präsentiert sie als priorisiertes Briefing — drei Situationen, jede mit Impact, Trend und Leitfrage. Kostenlos starten.

Schritt 3: Delegation per Link. Nutze die Möglichkeit, einzelne Handlungsfelder direkt per Link an Verantwortliche weiterzuleiten. Nicht "Prüf mal eure Zahlen", sondern "Hier ist ein spezifisches Problem mit konkreten Daten — was ist dein Plan?"

Fazit

Gute Durchschnittswerte sind kein Zeichen für eine gesunde IT-Organisation. Sie sind oft ein Zeichen dafür, dass Probleme in der Aggregation verschwinden. Wer als IT-Leiter wissen will, wo die echten Hebel liegen, braucht nicht mehr Daten — sondern die richtigen drei Fragen: Was verschlechtert sich? Wo ist der größte Hebel? Was ist systemisch?

Häufig gestellte Fragen

Welche KPIs sollte ein IT-Leiter wirklich messen? Neben den Standard-KPIs wie MTTR und SLA-Quote sind drei ergänzende Perspektiven besonders wertvoll: die Varianz zwischen Teams (nicht nur der Durchschnitt), das Volumen-Kapazitäts-Verhältnis pro Team (Inflow vs. Outflow) und die Trendentwicklung über Wochen. Diese Perspektiven zeigen strukturelle Probleme, die Durchschnittswerte verschleiern.

Was zeigen ITSM-Dashboards nicht? Standard-Dashboards zeigen Team-Metriken isoliert. Was sie nicht zeigen: die Zusammenhänge zwischen Teams (Kaskadeneffekte), die Verteilung hinter Durchschnittswerten (ein extremes Team vs. gleichmäßige Verteilung) und die Differenz zwischen Trend und Absolutwert. Ein Team kann absolut gut aussehen und sich trotzdem rapide verschlechtern.

Wie oft sollte man ITSM-Prozesse analysieren? Die Kernmetriken sollten wöchentlich geprüft werden — idealerweise als automatisiertes Briefing, nicht als manueller Report. Tiefere Analysen (Routing-Muster, Kaskadeneffekte, Kategorien-Trends) lohnen sich monatlich oder nach jedem signifikanten Organisationswechsel. Wichtig ist weniger die Frequenz als die Kontinuität: Einmalige Analysen zeigen Momentaufnahmen, regelmäßige Analysen zeigen Trends.