SLA-Verletzung: Ursache finden statt Symptome behandeln

Die SLA-Verletzungsrate ist in drei Monaten von 8 auf 15 Prozent gestiegen. Der Standard-Report sagt: "2nd Level ist zu langsam." Die Reaktion: Druck auf das 2nd-Level-Team, Überstunden, ein Eskalations-Meeting. Drei Wochen später: Die Rate ist bei 14 Prozent. Fast unverändert. Denn die Ursache war nie das 2nd Level.

SLA-Verletzungen sind Symptome. Wer nur das Symptom behandelt — "Team X muss schneller werden" — ändert nichts am zugrundeliegenden Problem. Und das zugrundeliegende Problem ist fast nie "zu langsam", sondern "falsch geroutet", "zu spät zugewiesen" oder "am falschen Team gelandet".

Warum Standard-Reports die falsche Ursache zeigen

Die meisten ITSM-Dashboards messen SLA-Verletzungen pro Team und pro Priorität. Das Ergebnis: Eine Tabelle, die zeigt, welches Team wie viele SLAs gerissen hat. Die logische Schlussfolgerung: Das Team mit den meisten Verletzungen ist das Problem.

Aber diese Schlussfolgerung ist oft falsch — aus drei Gründen.

Erstens: SLA-Uhren laufen teamübergreifend. Wenn ein Ticket zuerst zwei Tage beim falschen Team liegt, bevor es korrekt zugewiesen wird, hat das bearbeitende Team nur noch einen Bruchteil der SLA-Zeit übrig. Es reißt das SLA — aber die Ursache liegt beim Routing, nicht bei der Bearbeitungsgeschwindigkeit.

Zweitens: Volumenverschiebungen bleiben unsichtbar. Wenn das Ticket-Volumen in einer Kategorie um 30 Prozent steigt, aber die Teamgröße gleich bleibt, steigen die SLA-Verletzungen — nicht weil das Team langsamer geworden ist, sondern weil es mehr Arbeit hat. Der SLA-Report zeigt die Verletzung, aber nicht die Volumenveränderung.

Drittens: Aggregation verschleiert die Verteilung. "15 Prozent SLA-Verletzungsrate" kann bedeuten: Alle Kategorien haben 15 Prozent. Oder: Eine Kategorie hat 40 Prozent, alle anderen 5 Prozent. Die Handlung wäre eine völlig andere — aber der aggregierte Report zeigt nur die eine Zahl.

Die fünf häufigsten wahren Ursachen

Hinter steigenden SLA-Verletzungen stecken meistens fünf Muster, die sich in den Ticket-Daten identifizieren lassen.

1. Routing-Fehler — Tickets landen im falschen Team

Das häufigste Muster. Tickets werden bei der Erstellung oder ersten Zuweisung einem Team zugeordnet, das nicht zuständig ist. Das Team prüft, leitet weiter, das nächste Team prüft — und die SLA-Uhr läuft. In der Analyse zeigt sich das an Tickets, die vor der eigentlichen Bearbeitung ein oder zwei Zuweisungswechsel haben.

In einem typischen Fall landen 30 Prozent der Tickets einer bestimmten Kategorie beim falschen Team und werden erst nach durchschnittlich zwei Tagen korrekt zugewiesen. Diese zwei Tage sind der SLA-Killer — nicht die Bearbeitungszeit des richtigen Teams.

2. Kategorien mit verstecktem Komplexitätsanstieg

Manche Ticket-Kategorien verändern sich schleichend. Was früher Standard-Incidents waren, wird durch System-Updates, neue Anwendungen oder veränderte Anforderungen komplexer. Die SLA-Ziele bleiben aber gleich. Das Ergebnis: Steigende Verletzungsraten bei Kategorien, die früher unproblematisch waren.

3. Wartezeiten durch fehlende Zuarbeit

Tickets warten auf Rückmeldungen — von anderen Teams, vom Nutzer oder von externen Dienstleistern. Diese Wartezeit ist oft nicht als "On Hold" markiert und zählt voll in die SLA-Berechnung. Das bearbeitende Team kann nichts tun, aber die SLA-Uhr läuft.

4. Wochentags- und Schichteffekte

SLA-Verletzungen konzentrieren sich häufig auf bestimmte Wochentage oder Uhrzeiten. Tickets, die Freitagnachmittag eingehen, haben über das Wochenende keine Bearbeitung — aber die SLA-Uhr läuft (je nach Konfiguration). Ein überproportionaler Anteil der Verletzungen entsteht nicht durch langsame Bearbeitung, sondern durch ungünstiges Timing.

5. Kaskadeneffekte aus vorgelagerten Engpässen

Wenn ein Team staut, kommen nachgelagerte Teams ihre Zulieferungen später — und reißen ihrerseits SLAs. Der SLA-Report zeigt zwei oder drei Teams mit Verletzungen, obwohl die Ursache bei einem einzigen Engpass liegt.

Ein Praxis-Szenario

Ein Unternehmen mit rund 200 IT-Tickets pro Woche beobachtet einen Anstieg der SLA-Verletzungsrate von 8 auf 15 Prozent innerhalb eines Quartals. Die Standardanalyse zeigt: Der 2nd Level Support hat die meisten Verletzungen. Reaktion: Wöchentliche Eskalationsmeetings, Priorisierung der ältesten Tickets.

Die tiefere Analyse mit Process Radar zeigt ein anderes Bild. Die Verletzungen konzentrieren sich nicht gleichmäßig auf den 2nd Level, sondern auf eine spezifische Konstellation: Tickets der Kategorie "SAP Berechtigungen", die zuerst dem Identity-Management-Team zugewiesen werden und dann ans SAP-Team weitergeleitet werden. Diese Weiterleitung dauert im Median 1.8 Tage — fast die gesamte SLA-Zeit.

Die Ursache: Eine Routing-Regel, die "SAP Berechtigungen" pauschal an Identity Management schickt, obwohl 60 Prozent dieser Tickets SAP-Basis-Expertise erfordern. Das Identity-Team erkennt das nach Prüfung und leitet weiter — aber die SLA-Uhr hat schon 1.8 Tage gezählt.

Process Radar identifiziert diese Konstellation — welches Team plus welche Kategorie die Verletzungen treibt — und zeigt sie als priorisiertes Handlungsfeld im Briefing. Nicht nur "wo" das Problem liegt, sondern "warum" es entsteht.

Die Lösung: Anpassung der Zuordnungsregel. "SAP Berechtigungen" mit bestimmten Schlüsselwörtern gehen direkt an das SAP-Team. Ergebnis nach vier Wochen: SLA-Verletzungsrate sinkt auf 9 Prozent. Ohne zusätzliches Personal. Ohne Überstunden.

Drei Schritte zur Ursachenanalyse

Schritt 1: SLA-Verletzungen nach Kategorie und Team aufschlüsseln. Nicht den Gesamtwert betrachten, sondern die Verteilung. In welchen Kategorien konzentrieren sich die Verletzungen? Welche Teams sind betroffen — und sind sie die Verursacher oder die Leidtragenden?

Schritt 2: Ticket-Pfade der verletzten Tickets analysieren. Lade deine Ticket-Daten als CSV in Process Radar hoch. Das Tool identifiziert automatisch, welche Konstellationen — Team, Kategorie, Routing-Muster — die SLA-Verletzungen treiben. Kostenlos starten, Ergebnis in Minuten.

Schritt 3: Ursache adressieren, nicht Symptom. Wenn das Problem ein Routing-Fehler ist: Zuordnungsregel anpassen. Wenn es ein Volumenanstieg ist: Kapazität prüfen. Wenn es ein Kaskadeneffekt ist: den Ursprungsengpass finden. Die richtige Maßnahme ergibt sich aus der richtigen Diagnose.

Fazit

Steigende SLA-Verletzungsraten sind ein Signal — aber die Ursache liegt selten dort, wo der Standard-Report sie zeigt. Wer die Ticket-Daten systematisch analysiert, findet die wahren Treiber: Routing-Fehler, Volumenverschiebungen, Kaskadeneffekte. Und die Lösung ist oft einfacher als gedacht.

Häufig gestellte Fragen

Warum steigen SLA-Verletzungen, obwohl das Team gleich groß ist? Die häufigsten Ursachen sind Volumenverschiebungen (mehr Tickets bei gleicher Kapazität), veränderte Ticket-Komplexität und Routing-Probleme. Wenn Tickets länger brauchen, um beim richtigen Team zu landen, bleibt dem bearbeitenden Team weniger SLA-Zeit — auch bei gleichbleibender Bearbeitungsgeschwindigkeit.

Wie findet man die wahre Ursache von SLA-Verletzungen? Drei Schritte: Erstens, Verletzungen nach Kategorie und Team aufschlüsseln statt nur den Gesamtwert zu betrachten. Zweitens, die Ticket-Pfade der verletzten Tickets analysieren — insbesondere Zuweisungswechsel vor der Bearbeitung. Drittens, prüfen ob die Verletzungen bei einem Team entstehen oder dort nur sichtbar werden, weil die Ursache früher im Prozess liegt.

Kann man SLA-Ursachen mit Ticket-Daten analysieren? Ja. Die Ticket-Historie enthält alle Zuweisungen, Statusänderungen und Zeitstempel, die für eine Ursachenanalyse nötig sind. Spezialisierte Tools wie Process Radar identifizieren die relevanten Muster automatisch aus einem CSV-Export — ohne API-Anbindung und ohne manuelle Datenaufbereitung.