SLA vs. OLA vs. UC – Unterschiede einfach erklärt – Wer Services professionell erbringt, kommt an Begriffen wie SLA, OLA und UC kaum vorbei – trotzdem herrscht hier in vielen Unternehmen Verwirrung. Die Begriffe klingen technisch und wirken ähnlich, aber sie erfüllen sehr unterschiedliche Rollen in Ihrem Service- und Provider-Management.
In diesem Artikel erhalten Sie eine praxisnahe, aber fachlich saubere Erklärung der Unterschiede, des Zusammenspiels und der typischen Stolperfallen. So können Sie Ihre eigenen Vereinbarungen gezielt verbessern und die Erwartungen Ihrer Kunden klar steuern.

1. Grundbegriffe: Was bedeuten SLA, OLA und UC?
1.1 Was ist ein SLA (Service Level Agreement)?
Ein Service Level Agreement (SLA) ist eine Vereinbarung zwischen Dienstleister und Kunde über die Qualität eines Services. Es beschreibt, welche Leistung ein Kunde erhält und unter welchen Bedingungen diese Leistung erbracht wird.
Typische Inhalte eines SLA sind zum Beispiel:
- Beschreibung des Services (Scope, Funktionen, Grenzen)
- Verfügbarkeitsziele (z. B. 99,9 % im Monat)
- Reaktions- und Lösungszeiten (Incident- und Request-Management)
- Supportzeiten (z. B. Mo–Fr, 08:00–18:00 Uhr)
- Reporting, Messverfahren und Kennzahlen (KPIs)
- Eskalationswege und Verantwortlichkeiten
- Vertragsstrafen, Gutschriften oder Boni bei Nichteinhaltung
Wichtig ist:
- Zielgruppe des SLA: Externer oder interner Kunde
- Perspektive: „Was darf der Kunde erwarten?“
- Sprache: Möglichst verständlich für Fachfremde, nicht nur für IT- oder Prozess-Experten
Ein gutes SLA schafft also Transparenz und Vertrauen, weil es Erwartungen klar macht und gleichzeitig messbare Ziele definiert.
1.2 Was ist ein OLA (Operational Level Agreement)?
Ein Operational Level Agreement (OLA) richtet sich nicht an den Kunden, sondern an interne Einheiten des Dienstleisters. Es legt fest, wie verschiedene interne Teams zusammenarbeiten, damit sie gemeinsam die im SLA versprochene Leistung liefern können.
Typische Beispiele:
- Vereinbarung zwischen Service Desk und Fachabteilung (z. B. Netzwerk-Team)
- Vereinbarung zwischen IT-Abteilung und Facility Management
- Vereinbarung zwischen Support-Team und Entwicklungsteam (Dev, DevOps)
Typische Inhalte eines OLA:
- Interne Rollen und Verantwortlichkeiten
- Interne Reaktions- und Bearbeitungszeiten
- Übergabepunkte (Handovers) zwischen Teams
- Kommunikationskanäle und Eskalationsregeln
- Technische oder prozessuale Schnittstellen
Merke:
- Zielgruppe des OLA: Interne Teams des Serviceanbieters
- Perspektive: „Was muss intern passieren, damit das SLA eingehalten wird?“
- Sprache: Deutlich technischer und prozessorientierter möglich als im SLA
Das OLA übersetzt also die „Außenwelt“-Versprechen des SLA in konkrete interne Verpflichtungen, damit nichts im Graubereich bleibt.
1.3 Was ist ein UC (Underpinning Contract)?
Ein Underpinning Contract (UC) ist ein Vertrag mit externen Lieferanten oder Subdienstleistern, der die Erbringung eines Teils des Services regelt. Er ist sozusagen das „Fundament“ der Leistung, die Sie im SLA versprechen.
Typische Beispiele:
- Wartungsvertrag mit einem Hardware-Hersteller
- Cloud-Vertrag mit einem Hyperscaler (IaaS, PaaS, SaaS)
- Internetzugang über einen Telekommunikationsanbieter
- Supportvertrag mit einem Spezialdienstleister (z. B. für Application Management)
Typische Inhalte eines UC:
- Genaue Leistungsbeschreibung des Lieferanten
- Liefer- oder Supportzeiten und Reaktionszeiten
- Verfügbarkeits- und Performance-Zusagen
- Haftung, Garantien, SLAs des Lieferanten
- Preise, Vertragslaufzeiten, Kündigungsfristen
Wesentliche Punkte:
- Zielgruppe des UC: Externer Lieferant / Subdienstleister
- Perspektive: „Welche Leistung bekomme ich als Provider von meinen Zulieferern?“
- Risiko: Wenn der UC schwächer ist als Ihr SLA, geraten Sie leicht in Erklärungsnot.
2. Warum Sie alle drei brauchen – Zusammenspiel von SLA, OLA und UC
SLA, OLA und UC sind keine Alternativen, sondern Bausteine derselben Kette. Sie greifen ineinander und sichern gemeinsam die Servicequalität ab.
Man kann sich das Zusammenspiel wie folgt vorstellen:
- SLA – definiert das externe Leistungsversprechen an den Kunden.
- OLA – regelt die interne Zusammenarbeit, damit das SLA erfüllt wird.
- UC – sichert die Leistungen Dritter ab, die für das SLA notwendig sind.
Oder anders formuliert:
Der Kunde schaut auf das SLA,
das Management schaut auf die OLAs,
und der Einkauf schaut auf die UCs.
Wenn Sie ein neues SLA gestalten, sollten Sie daher immer gleichzeitig prüfen:
- Welche internen Teams sind beteiligt?
→ Dafür definieren Sie passende OLAs. - Welche externen Lieferanten sind kritisch?
→ Dafür passen Sie Ihre UCs auf das SLA-Niveau an.
Nur wenn diese drei Ebenen abgestimmt sind, können Sie zuverlässig liefern und Ausfälle oder Eskalationen professionell handhaben.
3. Die wichtigsten Unterschiede auf einen Blick
3.1 Vergleich nach Zielgruppe und Zweck
- SLA (Service Level Agreement)
- Adressat: Kunde (intern oder extern)
- Zweck: Erwartungsmanagement, formale Servicezusage
- Fokus: Was bekommt der Kunde, zu welchen Bedingungen?
- OLA (Operational Level Agreement)
- Adressat: Interne Teams und Abteilungen
- Zweck: Interne Leistungszusagen zur Unterstützung des SLA
- Fokus: Wie arbeiten Teams zusammen, um das SLA zu halten?
- UC (Underpinning Contract)
- Adressat: Externe Lieferanten / Subdienstleister
- Zweck: Vertragliche Absicherung der Zulieferleistungen
- Fokus: Welche Leistung und Qualität liefert der Lieferant?
3.2 Typische Inhalte im Vergleich
SLA:
- Servicebeschreibung und Scope
- Verfügbarkeit, Reaktions- und Lösungszeiten
- Supportkanäle und -zeiten
- Service-Reporting und KPIs
- Sanktionen oder Gutschriften
OLA:
- Interne Rollen, Zuständigkeiten und Schnittstellen
- Detaillierte Prozessschritte und Übergabepunkte
- Interne Reaktions- und Bearbeitungsziele
- Eskalationsstufen und Kommunikationswege
UC:
- Lieferumfang und Serviceumfang des Lieferanten
- Leistungskennzahlen (z. B. Verfügbarkeit, Performance)
- Liefer- und Supportzeiten
- Haftung, Gewährleistung, Vertragsdauer, Preise
4. Praxisbeispiele: Wie SLA, OLA und UC zusammenwirken
4.1 Beispiel aus dem IT-Service: E-Mail-Service für ein Unternehmen
SLA mit dem Kunden:
- Verfügbarkeit des E-Mail-Systems: 99,9 % im Monat
- Reaktionszeit bei kritischen Störungen: 30 Minuten
- Lösungszeit bei kritischen Störungen: 4 Stunden
- Supportzeiten: 07:00–19:00 Uhr, Mo–Fr
OLAs intern:
- Service Desk ↔ Infrastruktur-Team:
- Service Desk nimmt Tickets an, priorisiert sie und leitet sie innerhalb von 10 Minuten an das Infrastruktur-Team weiter.
- Infrastruktur-Team beginnt innerhalb von 20 Minuten mit der Fehleranalyse bei Priorität „kritisch“.
- Infrastruktur-Team ↔ Netzwerk-Team:
- Wenn die Ursache im Netzwerk liegt, informiert das Infrastruktur-Team das Netzwerk-Team innerhalb von 15 Minuten.
- Netzwerk-Team startet innerhalb von 15 Minuten mit der Fehlerbehebung.
UC mit externem Cloud-Anbieter:
- Verfügbarkeit der Cloud-Plattform: 99,95 %
- Reaktionszeit des Anbieters bei kritischen Fällen: 15 Minuten
- 24/7-Support für kritische Incidents
Wenn nun eine kritische Störung eintritt, greifen alle drei Ebenen ineinander:
Der Kunde bezieht sich auf das SLA, die internen Teams orientieren sich an ihren OLAs, und der Provider stützt sich auf den UC mit dem Cloud-Anbieter.
4.2 Beispiel außerhalb der IT: Gebäudemanagement
SLA mit dem Auftraggeber (z. B. Eigentümer):
- Aufzüge müssen zu 99,7 % verfügbar sein.
- Störungen im Aufzug müssen binnen 30 Minuten bearbeitet und binnen 4 Stunden behoben werden.
OLAs intern (Facility Management):
- Leitstelle nimmt Meldungen rund um die Uhr an und informiert sofort den zuständigen Techniker.
- Techniker bestätigt den Einsatz innerhalb von 15 Minuten und meldet nach Behebung zurück.
UC mit Aufzughersteller/Wartungsfirma:
- Der Hersteller bietet 24/7-Notdienst.
- Reaktionszeit: 30 Minuten, Anfahrt und Beginn der Arbeit innerhalb von 60 Minuten.
Auch hier zeigt sich, wie SLA, OLA und UC eine Kette bilden, die den Service gegenüber dem Endkunden absichert.
5. Typische Fehler in der Praxis – und wie Sie sie vermeiden
In vielen Organisationen gibt es zwar irgendeine Art von SLA, aber die dahinterliegenden OLAs und UCs passen nicht dazu. Dadurch entstehen Konflikte, die sich mit wenig Aufwand verhindern lassen.
Häufige Fehler:
- „SLA aus dem Bauch heraus“ ohne Datenbasis
- Reaktions- und Lösungszeiten sind ambitioniert, aber niemand hat gemessen, ob sie realistisch sind.
- Keine oder zu vage OLAs
- Interne Teams kennen zwar grob ihre Aufgaben, aber niemand hat schriftlich festgehalten, wer wann was liefern muss.
- UC schwächer als das SLA
- Der Provider verspricht dem Kunden z. B. 99,9 % Verfügbarkeit, während der Lieferant nur 99,0 % zusichert.
- Zu technische SLAs
- Der Kunde versteht die Kennzahlen nicht, fühlt sich verunsichert und bewertet den Service eher nach Gefühl als nach Fakten.
- OLAs und UCs werden nicht regelmäßig überprüft
- Prozesse ändern sich, neue Services kommen hinzu, aber die Vereinbarungen bleiben veraltet.
So vermeiden Sie diese Fehler:
- Definieren Sie SLA-Ziele datenbasiert, also auf Grundlage historischer Performance.
- Leiten Sie OLAs systematisch aus dem SLA ab, statt sie isoliert zu formulieren.
- Prüfen Sie jeden UC darauf, ob er die Einhaltung des SLA wirklich ermöglicht.
- Halten Sie SLAs für den Kunden verständlich, aber führen Sie intern detaillierte technische Dokumentation.
- Planen Sie regelmäßige Reviews ein, z. B. jährlich oder bei größeren Serviceänderungen.
6. So gehen Sie bei der Einführung vor – Schritt für Schritt
Wenn Sie SLA, OLA und UC neu aufsetzen oder überarbeiten möchten, hilft ein strukturierter Ansatz. Die folgenden Schritte bieten sich an:
6.1 Anforderungen und Ist-Situation klären
- Welche Services sind geschäftskritisch?
- Welche Erwartungen haben Kunden heute, und wo bestehen aktuell Reibungspunkte?
- Welche Kennzahlen stehen bereits zur Verfügung (Verfügbarkeit, Bearbeitungszeiten, Ticketvolumen)?
6.2 SLA-Ziele definieren
- Legen Sie für die wichtigsten Services konkrete Ziele fest: Verfügbarkeit, Reaktionszeiten, Lösungszeiten.
- Achten Sie darauf, dass Ziele ambitioniert, aber erreichbar sind.
- Formulieren Sie die Inhalte so, dass Fachfremde sie verstehen.
6.3 OLAs ableiten
- Identifizieren Sie alle beteiligten Teams entlang der Prozesskette.
- Definieren Sie, wer in welchem Schritt welche Verantwortung trägt.
- Vereinbaren Sie interne Zeitziele, die zusammen das SLA ermöglichen.
Beispiel:
Wenn Sie eine Lösungszeit von 4 Stunden zusagen, sollten die internen Schritte (Diagnose, Eskalation, Bereitstellung von Ressourcen) jeweils deutlich kürzer ausfallen.
6.4 UCs überprüfen und anpassen
- Listen Sie alle externen Lieferanten auf, die für den Service relevant sind.
- Vergleichen Sie deren Zusagen mit Ihren geplanten SLAs.
- Passen Sie Verträge an, wo immer Ihnen das möglich ist, oder passen Sie notfalls Ihre SLA-Zusagen nach unten an, damit sie realistisch bleiben.
6.5 Governance, Monitoring und Reporting etablieren
- Definieren Sie, wie Sie SLA-, OLA- und UC-Ziele regelmäßig messen und berichten.
- Legen Sie Verantwortlichkeiten für das Monitoring fest.
- Richten Sie klare Eskalationswege ein, damit Abweichungen früh sichtbar werden und nicht erst beim Kunden eskalieren.
6.6 Kommunikation und Schulung
- Erklären Sie den Kunden, warum bestimmte Ziele gewählt wurden und welche Mehrwerte das für sie bringt.
- Schulen Sie interne Teams, damit sie ihre OLA-Verpflichtungen kennen und verstehen.
- Sensibilisieren Sie den Einkauf, damit neue UCs von Anfang an auf die bestehenden SLAs abgestimmt werden.
7. Fazit SLA vs. OLA vs. UC – Unterschiede einfach erklärt: Klarheit über SLA, OLA und UC zahlt sich aus
SLA, OLA und UC sind drei Perspektiven auf dasselbe Thema: verlässliche Servicequalität.
- Das SLA bildet die sichtbare Spitze des Eisbergs – es regelt, was der Kunde erwarten darf.
- Das OLA strukturiert die interne Zusammenarbeit, damit Teams koordiniert und zielgerichtet handeln.
- Der UC verankert die Beiträge externer Lieferanten vertraglich, sodass Sie Ihr Leistungsversprechen einlösen können.
Wenn diese drei Ebenen sauber aufeinander abgestimmt sind, erleben Kunden den Service als professionell, verlässlich und transparent. Gleichzeitig reduzieren Sie interne Konflikte, weil Rollen, Verantwortlichkeiten und Grenzen klar geregelt sind.
Nutzen Sie die Gelegenheit, Ihre bestehenden Vereinbarungen kritisch zu prüfen, und entwickeln Sie aus SLA, OLA und UC ein stimmiges Gesamtbild – Ihr Service- und Provider-Management wird spürbar davon profitieren.