Ein SLA (Service Level Agreement) ist eine verbindliche Leistungsvereinbarung: Sie definiert, welche Serviceleistung in welcher Qualität und Zeit erbracht wird – messbar über Service Levels und KPIs.
Was bedeutet SLA (Service Level Agreement) / Service Level?
Ein SLA ist ein dokumentiertes Agreement zwischen Service-Provider und Service-Kunde. Es beschreibt u. a.:
- Serviceumfang (was genau geliefert wird – und was nicht)
- Service Levels (z. B. Verfügbarkeit, Reaktionszeit, Lösungszeit)
- Messung & Reporting (wie gemessen wird, welche KPI gelten, wie oft berichtet wird)
- Rollen & Eskalation (wer entscheidet, wenn es brennt)
- Servicezeiten (z. B. 8×5, 24×7) und Prioritätenlogik
Wichtig: Service Level ist das konkrete Leistungsniveau (z. B. „P1 innerhalb 30 Minuten reagieren“). SLA ist der Rahmenvertrag/das Agreement, das diese Service Levels festhält.
SLA im Unternehmensalltag
SLA-Themen tauchen überall dort auf, wo Leistung „als Service“ erbracht wird: IT-Services, interne Shared Services (HR, Finance), Kundenservice, externe Dienstleister, aber auch in Produktionsumfeldern (z. B. Instandhaltung/Facility).
In der Praxis scheitern SLAs selten an der Formulierung – sondern an drei Punkten:
- Unklare Prozessschnittstellen: Niemand weiss, wer in welchem Schritt wirklich dran ist. (→ Prozessmanagement)
- Falsche oder fehlende Kennzahlen: Es wird „gefühlt“ statt gemessen. (→ KPI, neu)
- SLA ohne Kundennutzen: Es wird „Zeit“ optimiert, aber nicht das, was den Kunden wirklich interessiert. (→ Kundennutzen, neu)
Warum SLA bei Leanovation eine Rolle spielt
Ein SLA ist nur so gut wie der Prozess, der es einlösen soll. Genau hier wird es für Leanovation spannend: Wir übersetzen Erwartungen in steuerbare Abläufe und schaffen Transparenz darüber, ob ein Service wirklich liefert – aus Sicht des Kunden und entlang der Wertschöpfung.
Und: SLAs werden gerade im KI-Kontext wieder relevanter. Sobald KI in Support, Wissensmanagement oder Automatisierung eingreift, müssen Unternehmen definieren:
- Was ist „gute“ Antwortqualität?
- Welche Reaktionszeiten sind realistisch – und für wen?
- Wo braucht es menschliche Kontrolle (und wann nicht)?
Wenn KI dabei helfen soll, Service Levels stabil zu erreichen (z. B. bessere Erstlösungsquote, schnellere Triage, weniger Suchzeit), arbeiten wir je nach Use Case mit unserem Netzwerkpartner Evoya AI (www.evoya.ai) zusammen – immer mit klaren Messpunkten und Governance, nicht als Tool-Spielwiese.
Unterscheidung SLA vs. OLA – ist „SLA extern, OLA intern“ korrekt?
Grundsätzlich: Ja – als Faustregel. In der IT-Service-Management-Logik (u. a. ITIL/ISO-20000-nahe Praxis) gilt typischerweise:
- SLA: Vereinbarung mit dem Kunden (extern oder intern als „Kunde“)
- OLA (Operational Level Agreement): Vereinbarung zwischen internen Teams, die gemeinsam das SLA ermöglichen (Schnittstellen/Beiträge, Zeiten, Responsibilities)
- UC (Underpinning Contract): Vereinbarung mit externen Lieferanten, die das SLA mittragen (z. B. Cloud-/Telekom-Provider)
Challenge aus der Praxis / aktueller Anwendung: ITIL 4 verwendet den Begriff „OLA“ weniger prominent bzw. lässt ihn in offiziellen Publikationen teils weg – nicht weil das Konzept falsch ist, sondern weil Organisationen in der Praxis sehr oft alles „SLA“ nennen (auch interne Zusagen). Das führt zu sprachlicher Unschärfe, aber nicht zu einem anderen Bedarf: Du brauchst weiterhin interne, messbare Zusagen an Schnittstellen – sonst ist das SLA nicht lieferbar.
Kurz gesagt:
- Als Konzept ist „OLA = interne Vereinbarung zur Erfüllung des SLA“ fachlich sauber.
- In der Praxis wird es oft anders benannt oder informeller gelebt („interne SLAs“), was zu Lücken in Verantwortung und Messung führt.
Verwandte Begriffe
- Prozessoptimierung
- Prozessmanagement
- KPI

