Inhaltsverzeichnis
Einleitung
Service Level Management ist eine häufig missverstandene Practice. Wer SLAs als Vertragsfußnote behandelt, verschenkt das stärkste Steuerungsinstrument im ITSM.
Problemstellung
SLA-Reports werden monatlich verschickt, aber nicht gelesen. Service Reviews kommen erstickt im Ampelbericht zur Welt. Niemand kennt die geschäftlichen Konsequenzen einer SLA-Verletzung.
Analyse
Drei strukturelle Mängel:
- SLAs sind nicht business-relevant. Verfügbarkeit ohne Wirkungslogik.
- Reviews sind Lieferantengespräche, keine Steuerungsformate.
- SLA-Verletzungen haben keine Konsequenzen. Möglich sind eine Anreizlogik, Service-Credits oder zielgerichtete Eskalationen.
Lösungsansatz
- Outcome-basierte SLAs. Was passiert, wenn der Service ausfällt und für wen?
- Service Reviews als Steuerungsformat mit Aktionen, Owner, Datum.
- Service Credits oder Eskalations-Hebel etablieren. Nicht als Strafe, sondern als Steuerung.
Praxisbeispiel
In einem öffentlichen Auftraggeber führten outcome-basierte SLAs (z.B. Anwender-Nutzung, nicht „technische Verfügbarkeit") dazu, dass der Provider die Architektur eigeninitiativ vereinfachte.
Handlungsempfehlungen
- Beginnen Sie mit 3–5 kritischen Services. Nicht mit dem ganzen Katalog.
- Verknüpfen Sie SLAs mit Geschäftsprozessen, nicht mit Komponenten.
- Etablieren Sie eine SLA-Governance und definieren Sie wer ändert was, wann?
Lessons Learned
- SLAs ohne Konsequenz sind Folklore.
- Reporting ist kein Service Level Management.


