SLA-Zahlen verdecken oft die echten Serviceprobleme

Ein Serviceversprechen klingt belastbar, sobald eine Zahl dahintersteht. 99,5 Prozent Verfügbarkeit, vier Stunden Reaktionszeit oder ein Werktag Bearbeitungsziel wirken nach Kontrolle. Für den IT-Betrieb wird es aber gefährlich, wenn die Zahl wichtiger wird als das Problem, das sie eigentlich sichtbar machen soll.

Ein Service Level Agreement, kurz SLA, beschreibt messbare Zusagen für einen IT-Service. Es kann Verfügbarkeit, Reaktionszeit, Wiederherstellungszeit, Supportzeiten oder Eskalationswege festlegen. Für ITSM-Generalisten ist der Zweck einfach: Nutzer, Fachbereiche und IT sollen dasselbe Verständnis davon haben, was ein Service leisten soll und was im Störungsfall passiert.

Die Zahl ist nur der Anfang der Vereinbarung

In der Praxis wird ein SLA oft auf eine Kennzahl reduziert. Dann steht im Bericht, dass ein Ziel erreicht oder verfehlt wurde. Das reicht für Steuerung aber nicht aus. Eine Kennzahl erklärt nicht automatisch, welcher Geschäftsprozess betroffen war, ob der Nutzer arbeiten konnte oder ob ein Lieferant nur formal pünktlich reagiert hat.

Atlassian beschreibt Service Level Management als laufenden Prozess, bei dem Erwartungen definiert, gemessen und verbessert werden. Genau dieser laufende Charakter geht verloren, wenn ein SLA nur als Vertragstabelle gelesen wird. Ein gutes Serviceversprechen verbindet Messung mit Alltagssprache: Was merken Nutzer? Wer handelt? Welche Unterbrechung ist wirklich kritisch? Welche Zusage passt zum Risiko des Services?

Reaktionszeit ersetzt keine Lösung

Ein klassisches Missverständnis entsteht bei Reaktionszeiten. Eine schnelle erste Antwort kann wichtig sein, besonders bei sichtbaren Ausfällen. Sie löst aber noch kein Ticket, stellt keinen Service wieder her und beseitigt keine Ursache. Wenn der Service Desk nur beweisen muss, dass er rechtzeitig geantwortet hat, kann ein SLA formal grün bleiben, während Nutzer weiter blockiert sind.

Darum sollten Reaktionszeit, Bearbeitungsfortschritt und Wiederherstellung getrennt betrachtet werden. Die erste Rückmeldung zeigt, dass ein Vorgang angekommen ist. Die Wiederherstellung zeigt, ob der Service wieder nutzbar ist. Der Fortschritt dazwischen zeigt, ob jemand Verantwortung übernimmt, kommuniziert und Abhängigkeiten steuert. Erst diese Kombination macht aus einer Zahl eine brauchbare Betriebssteuerung.

Servicequalität hängt an Abhängigkeiten

Kaum ein IT-Service hängt nur an einem Team. Anwendungen brauchen Infrastruktur, Identitäten, Netzwerk, Datenbanken, externe Plattformen, Supportprozesse und oft mehrere Lieferanten. Ein SLA gegenüber dem Fachbereich bleibt schwach, wenn die internen Unterstützungsleistungen nicht dazu passen. Dann verspricht die IT nach außen mehr, als sie innen zuverlässig steuern kann.

Hier werden Operational Level Agreements und Lieferantenvereinbarungen wichtig. Sie übersetzen das sichtbare Serviceversprechen in interne Zuständigkeiten. Wenn ein kritischer Service innerhalb von vier Stunden wieder laufen soll, müssen auch Diagnose, Freigabe, Infrastrukturreaktion, Herstellerkontakt und Kommunikation dazu passen. Sonst entsteht eine schöne Zielzahl ohne tragfähige Lieferkette.

Der Messpunkt entscheidet über Fairness

Ein SLA ist nur so klar wie sein Messpunkt. Beginnt die Uhr beim Eingang des Tickets, bei korrekter Kategorisierung, bei Geschäftszeitenbeginn oder erst nach vollständiger Nutzerangabe? Endet sie mit der ersten Antwort, mit einem Workaround, mit technischer Wiederherstellung oder mit bestätigter Nutzerfreigabe? Unterschiedliche Antworten verändern die Aussage der Kennzahl erheblich.

Diese Details wirken trocken, sind aber entscheidend für Vertrauen. Nutzer verlieren schnell den Glauben an Serviceberichte, wenn erlebte Wartezeit und gemeldete Zielerfüllung auseinanderfallen. Der IT-Betrieb sollte deshalb nicht nur messen, was technisch einfach erfassbar ist. Er sollte messen, was für die Serviceerfahrung und den Geschäftsprozess relevant ist.

Gute SLAs brauchen regelmäßige Pflege

Ein Serviceversprechen altert. Neue Fachbereichsprozesse, andere Arbeitszeiten, Cloud-Abhängigkeiten, mehr Automatisierung oder geänderte Sicherheitsvorgaben verschieben die Erwartungen. Ein SLA, das vor zwei Jahren sinnvoll war, kann heute entweder zu hart, zu weich oder am falschen Punkt präzise sein.

ITIL-nahe Service-Level-Praxis betont deshalb Überprüfung, Berichtswesen und Verbesserung. Für den Alltag heißt das: SLAs gehören in Gespräche mit Fachbereichen, Service Ownern und Betriebsteams. Nicht jede Abweichung ist ein Skandal. Aber jede wiederkehrende Abweichung ist ein Hinweis auf falsche Priorität, fehlende Kapazität, unklare Verantwortung oder ein Messmodell, das den Servicealltag nicht mehr abbildet.

Prüffragen für bessere Serviceversprechen

• Versteht der Fachbereich in Alltagssprache, was die SLA-Zahl tatsächlich bedeutet?
• Wird zwischen Reaktion, Fortschritt, Wiederherstellung und endgültiger Lösung unterschieden?
• Passen interne Teamzusagen und Lieferantenvereinbarungen zum sichtbaren Serviceversprechen?
• Ist klar, wann die Messung beginnt und wann sie endet?
• Zeigt der Bericht auch Nutzerwirkung, Wiederholungsfehler und Kommunikationsqualität?
• Gibt es einen festen Rhythmus, in dem SLAs anhand echter Fälle überprüft werden?

Ein SLA soll nicht beweisen, dass die IT eine Tabelle erfüllt. Es soll helfen, Servicequalität verlässlich zu machen. Dafür müssen Zahlen, Nutzerwirkung und Zuständigkeit zusammenpassen. Der beste Prüfstein ist nicht der grüne Monatsbericht, sondern die Frage, ob Fachbereich und IT nach einem Problem dasselbe Bild haben: Was war versprochen, was ist passiert, wer hat gehandelt und was muss sich ändern?

Quellen und Einordnung: Atlassian zu Service Level Management und Service Level Agreements, AXELOS/ITIL-Ressourcen zur Service-Level-Management-Praxis, CIO zur Einordnung von SLA-Grundlagen und Lieferantenbezug. Stand der Quellenprüfung: 26.06.2026.