8.2 SLA, SLR, OLA und Underpinning Contracts

Kurz erklärt

Service Level Management arbeitet mit mehreren Arten von Vereinbarungen und Anforderungen.

SLR beschreibt, welche Servicequalität benötigt wird.

SLA beschreibt, welche Servicequalität zwischen Kunde und Service Provider vereinbart ist.

OLA beschreibt interne Unterstützungsvereinbarungen zwischen Teams.

Underpinning Contracts beschreiben unterstützende Verträge mit externen Lieferanten.

Diese Ebenen müssen zusammenpassen, sonst werden Serviceziele vereinbart, die praktisch nicht erfüllbar sind.

Warum diese Begriffe wichtig sind

Ein IT-Service wird selten von nur einer Stelle erbracht.

Beispiel:

Der Service „Mitarbeiterportal“ kann abhängig sein von:

Anwendungsteam,
Datenbankteam,
Netzwerkteam,
Identity Management,
Service Desk,
Monitoring,
Cloud-Anbieter,
Softwarehersteller,
Internetprovider,
und externem Support.

Wenn ein SLA dem Fachbereich eine schnelle Wiederherstellung verspricht, müssen alle unterstützenden Teams und Lieferanten dazu beitragen können.

Deshalb reicht es nicht, nur ein SLA zu schreiben.

Die Vereinbarungen im Hintergrund müssen ebenfalls passen.

Grundmodell

Service Level Requirement
    ↓
beschreibt benötigte Servicequalität
    ↓
Service Level Agreement
    ↓
vereinbart Servicequalität mit dem Kunden
    ↓
Operational Level Agreements
    ↓
regeln interne Unterstützungsleistungen
    ↓
Underpinning Contracts
    ↓
sichern externe Lieferantenleistungen ab
    ↓
Monitoring, Reporting und Service Reviews
    ↓
prüfen, ob Ziele erreicht werden

Alle Ebenen müssen aufeinander abgestimmt sein.

Service Level Requirement

Ein Service Level Requirement (SLR) beschreibt eine Anforderung an die Servicequalität.

SLRs entstehen häufig aus:

fachlichen Anforderungen,
Benutzererwartungen,
gesetzlichen Vorgaben,
Sicherheitsanforderungen,
Geschäftsprozessen,
Risikobewertungen,
bisherigen Incidents,
Service Reviews,
Projekten,
neuen Services,
oder geänderten Arbeitsweisen.

Ein SLR ist noch nicht automatisch eine verbindliche Vereinbarung.

Es ist zunächst eine Anforderung, die geprüft, bewertet und verhandelt werden muss.

Beispiele für Service Level Requirements

Bereich	Beispiel für SLR
Verfügbarkeit	Mitarbeiterportal soll während Geschäftszeiten verfügbar sein
Support	Benutzer benötigen Support montags bis freitags von 08:00 bis 18:00 Uhr
Reaktion	kritische Störungen sollen sehr schnell aufgenommen werden
Wiederherstellung	zentrale Störungen sollen innerhalb weniger Stunden umgangen oder behoben werden
Performance	häufig genutzte Seiten sollen zügig laden
Requests	Standardsoftware soll innerhalb weniger Arbeitstage bereitgestellt werden
Kommunikation	bei größeren Störungen sollen regelmäßige Statusupdates erfolgen
Sicherheit	Sicherheitsvorfälle sollen sofort eskaliert werden

SLRs sollten so formuliert sein, dass sie später in messbare Ziele überführt werden können.

SLR prüfen

Nicht jede Anforderung kann unverändert übernommen werden.

Zu prüfen ist:

Ist die Anforderung fachlich notwendig?
Ist sie technisch erreichbar?
Ist sie wirtschaftlich sinnvoll?
Sind Ressourcen vorhanden?
Passen interne Teams dazu?
Passen Lieferantenverträge dazu?
Gibt es Abhängigkeiten?
Ist die Messung möglich?
Welche Risiken entstehen?
Welche Alternative gibt es?

Service Level Management hilft, Anforderungen realistisch zu machen.

Beispiel: unrealistisches SLR

Anforderung

Das System soll immer verfügbar sein.

Problem

„Immer“ ist unklar und praktisch kaum erreichbar.

Besser prüfen:

Welche Geschäftszeiten sind kritisch?
Welche Ausfallzeit ist tolerierbar?
Welche Funktionen sind besonders wichtig?
Welche Kosten wären für Hochverfügbarkeit notwendig?
Gibt es manuelle Ersatzverfahren?
Welche Lieferantenabhängigkeiten bestehen?

Daraus kann ein realistisches SLA-Ziel entstehen.

Service Level Agreement

Ein Service Level Agreement (SLA) ist eine Vereinbarung zwischen Service Provider und Kunde über die erwartete und vereinbarte Servicequalität.

Ein SLA beschreibt nicht nur technische Werte.

Es beschreibt, was der Service leisten soll und wie die Leistung bewertet wird.

Typische Inhalte:

Servicebeschreibung,
Geltungsbereich,
Zielgruppe,
Servicezeiten,
Supportzeiten,
Verfügbarkeitsziele,
Reaktionszeiten,
Wiederherstellungsziele,
Prioritätsdefinitionen,
Messmethoden,
Ausnahmen,
Wartungsfenster,
Rollen und Verantwortlichkeiten,
Eskalationswege,
Reporting,
Review-Termine.

Ein SLA sollte verständlich, realistisch und überprüfbar sein.

SLA ist eine Vereinbarung, kein Wunschzettel

Ein SLA darf keine Ziele enthalten, die nicht erbracht werden können.

Ungeeignet:

Fachbereich wünscht 24/7-Verfügbarkeit, obwohl kein 24/7-Betrieb, keine Bereitschaft und kein passender Lieferantenvertrag existieren.

Besser:

Verfügbarkeitsziel, Supportzeiten, Bereitschaft und Lieferantenleistungen werden gemeinsam geprüft und realistisch vereinbart.

Ein SLA muss zu Fähigkeiten, Budget, Risiko und Organisation passen.

Arten von SLAs

Mögliche SLA-Formen:

SLA-Art	Beschreibung	Beispiel
Servicebezogenes SLA	gilt für einen bestimmten Service	SLA für VPN-Zugang
Kundenbezogenes SLA	gilt für einen bestimmten Kunden oder Fachbereich	SLA für Personalabteilung
Mehrstufiges SLA	kombiniert allgemeine und spezifische Vereinbarungen	allgemeine IT-Supportregeln plus spezielle Ziele für kritischen Service
Interner Service Level	wird intern vereinbart und berichtet	interner Service Desk Support
Externer SLA-Bezug	hängt von Lieferantenvertrag ab	Cloud-Service mit Provider-SLA

Die passende Form hängt von Organisation und Servicekatalog ab.

SLA-Inhalte verständlich formulieren

Ein SLA sollte nicht nur juristisch oder technisch formuliert sein.

Ungeeignet:

HTTP-Endpunkt antwortet in 99,7 Prozent der Messintervalle mit Statuscode 200.

Besser ergänzt:

Der Service gilt als verfügbar, wenn Benutzer die Startseite öffnen und sich anmelden können. Technisches Monitoring prüft zusätzlich den HTTP-Status und die Login-Funktion.

Technische Definitionen sind wichtig.

Aber der Servicebezug muss verständlich bleiben.

Geltungsbereich

Der Geltungsbereich beschreibt, wofür das SLA gilt und wofür nicht.

Zu klären ist:

Welche Services sind eingeschlossen?
Welche Benutzergruppen sind eingeschlossen?
Welche Standorte sind eingeschlossen?
Welche Zeiten gelten?
Welche Funktionen gehören zum Service?
Welche Systeme sind ausgeschlossen?
Welche Voraussetzungen müssen Benutzer erfüllen?
Welche Abhängigkeiten bestehen?

Ein unklarer Geltungsbereich führt später zu Streit über Erwartungen.

Beispiel Geltungsbereich

Service

VPN-Zugang für berechtigte Mitarbeitende.

Eingeschlossen

VPN-Client,
VPN-Gateway,
Anmeldung über zentrale Identität,
MFA,
Zugriff auf freigegebene interne Ressourcen.

Nicht eingeschlossen

private Internetverbindung des Benutzers,
nicht freigegebene Privatgeräte,
externe Websites,
lokale Heimnetzwerkprobleme.

Diese Abgrenzung macht Erwartungen klarer.

Servicezeit

Die Servicezeit beschreibt, wann ein Service vereinbarungsgemäß nutzbar sein soll.

Beispiele:

Montag bis Freitag, 08:00 bis 18:00 Uhr,
Montag bis Samstag, 06:00 bis 22:00 Uhr,
24 Stunden täglich,
nur während Geschäftszeiten,
nur während Schulungszeiten,
nur innerhalb definierter Projektphasen.

Servicezeit ist wichtig für Verfügbarkeitsmessung und Wartungsplanung.

Supportzeit

Die Supportzeit beschreibt, wann Unterstützung verfügbar ist.

Beispiele:

Service Desk erreichbar von 08:00 bis 17:00 Uhr,
Bereitschaft für P1-Incidents außerhalb der Geschäftszeit,
Lieferantensupport montags bis freitags,
erweiterter Support für kritische Zeiträume.

Ein Service kann auch außerhalb der Supportzeit verfügbar sein.

Aber bei Störungen gelten dann möglicherweise andere Reaktionszeiten.

Servicezeit und Supportzeit unterscheiden

Begriff	Bedeutung	Beispiel
Servicezeit	Service soll nutzbar sein	Mitarbeiterportal 24/7 erreichbar
Supportzeit	Hilfe ist verfügbar	Service Desk 08:00 bis 18:00 Uhr
Wartungsfenster	geplante Änderungen erlaubt	Sonntag 22:00 bis 23:00 Uhr
Bereitschaft	definierte Unterstützung außerhalb normaler Zeiten	P1-Rufbereitschaft nachts

Diese Begriffe dürfen nicht vermischt werden.

Wartungsfenster

Wartungsfenster regeln, wann geplante Arbeiten stattfinden dürfen.

Zu klären ist:

wann Wartung erlaubt ist,
wie früh sie angekündigt wird,
ob sie aus Verfügbarkeitsmessung ausgeschlossen wird,
welche Services betroffen sein dürfen,
wer informiert wird,
ob Fachbereiche zustimmen müssen,
welche Ausnahmen gelten.

Ein Wartungsfenster sollte zur Nutzung des Services passen.

Ein technisch bequemes Zeitfenster kann fachlich ungeeignet sein.

Verfügbarkeit im SLA

Verfügbarkeit beschreibt, ob ein Service im vereinbarten Zeitraum nutzbar ist.

Wichtig ist die genaue Definition.

Zu klären ist:

Wird während Servicezeit oder rund um die Uhr gemessen?
Zählen geplante Wartungen mit?
Wird aus Benutzerperspektive gemessen?
Welche Funktionen müssen verfügbar sein?
Wie werden Teilausfälle bewertet?
Welche Standorte zählen?
Welche Datenquelle wird verwendet?
Wie werden externe Abhängigkeiten behandelt?

Ohne klare Definition ist eine Verfügbarkeitszahl schwer interpretierbar.

Beispiel Verfügbarkeitsziel

Ungeeignet:

Service ist zu 99,9 Prozent verfügbar.

Besser:

Der Service gilt während der vereinbarten Servicezeit als verfügbar, wenn Benutzer die Startseite öffnen, sich anmelden und die Hauptfunktion nutzen können. Geplante Wartungsfenster werden separat ausgewiesen.

Diese Definition ist für Technik und Benutzer klarer.

Reaktionszeit

Reaktionszeit beschreibt die Zeit bis zur ersten qualifizierten Bearbeitung oder Rückmeldung.

Wichtig:

Eine automatische Eingangsbestätigung ist nicht automatisch eine qualifizierte Reaktion.

Beispiele:

P1-Incident wird innerhalb von 15 Minuten qualifiziert bearbeitet.
P2-Incident wird innerhalb von 60 Minuten geprüft.
Standardanfrage erhält innerhalb eines Arbeitstages eine Rückmeldung.

Reaktionszeit sollte mit Priorität und Supportzeit verknüpft sein.

Wiederherstellungszeit

Wiederherstellungszeit beschreibt, bis wann ein Service wieder nutzbar sein soll.

Das kann bedeuten:

vollständige Lösung,
temporäre Wiederherstellung,
nutzbarer Workaround,
Wiederherstellung einer Kernfunktion,
Rollback auf vorherigen Stand.

Wichtig ist, genau zu definieren, was als wiederhergestellt gilt.

Beispiel:

Ein Workaround kann den Benutzer wieder arbeitsfähig machen, obwohl die Ursache noch nicht dauerhaft behoben ist.

Lösungszeit

Lösungszeit beschreibt die Zeit bis zur endgültigen Lösung.

Sie ist nicht immer identisch mit Wiederherstellungszeit.

Beispiel:

Ein bekannter Fehler kann durch Workaround kurzfristig umgangen werden.

Die dauerhafte Lösung erfolgt erst durch einen späteren Change.

Dann ist der Service wiederhergestellt, aber das Problem noch nicht endgültig gelöst.

Prioritäten im SLA

SLAs enthalten häufig Prioritätsklassen.

Eine Priorität sollte aus Auswirkung und Dringlichkeit entstehen.

Auswirkung	Dringlichkeit	mögliche Priorität
viele Benutzer betroffen	sofortige Arbeit blockiert	P1
wichtiger Fachbereich betroffen	kurzfristige Bearbeitung nötig	P2
einzelner Benutzer betroffen	Arbeit teilweise möglich	P3
geringe Auswirkung	kein Zeitdruck	P4

Die konkrete Matrix muss zur Organisation passen.

Wichtig ist, Priorität nicht nur nach Lautstärke oder subjektivem Druck zu vergeben.

Auswirkung

Auswirkung beschreibt, wie stark ein Incident, Request oder Problem den Service oder die Organisation betrifft.

Kriterien:

Anzahl betroffener Benutzer,
Kritikalität des Services,
betroffener Geschäftsprozess,
Standort,
Sicherheitsrisiko,
finanzielle Auswirkung,
gesetzliche oder vertragliche Folgen,
Reputationsrisiko,
verfügbare Alternativen.

Ein einzelner Benutzer kann hohe Auswirkung haben, wenn eine kritische Rolle betroffen ist.

Dringlichkeit

Dringlichkeit beschreibt, wie schnell gehandelt werden muss.

Kriterien:

Arbeitsfähigkeit,
Frist,
Sicherheitsbezug,
drohende Eskalation,
betroffene Geschäftszeit,
kommende Termine,
vorhandener Workaround,
zeitkritischer Prozess.

Hohe Dringlichkeit ohne hohe Auswirkung führt nicht automatisch zu höchster Priorität.

Beides muss gemeinsam bewertet werden.

Messmethoden im SLA

Ein SLA-Ziel braucht eine klare Messmethode.

Zu definieren ist:

Startzeitpunkt,
Endzeitpunkt,
Messzeitraum,
Datenquelle,
Berechnungslogik,
Ausnahmen,
Verantwortlicher für Messung,
Reporting-Form,
Prüfintervall.

Beispiel:

Bei Reaktionszeit muss klar sein, ob die Zeit ab Ticketeingang, ab Kategorisierung oder ab Supportzeitbeginn zählt.

Ausnahmen

SLAs sollten Ausnahmen definieren.

Beispiele:

geplante Wartungsfenster,
höhere Gewalt,
Ausfall externer Netze außerhalb der Verantwortung,
Benutzer reagiert nicht,
fehlende Genehmigung,
falsche oder unvollständige Anfrage,
Sicherheitsvorfall mit Sonderprozess,
Lieferantenverzug außerhalb vereinbarter Leistung,
Testsysteme ohne SLA.

Ausnahmen dürfen nicht genutzt werden, um Verantwortung zu vermeiden.

Sie müssen nachvollziehbar sein.

OLA

Ein Operational Level Agreement (OLA) ist eine interne Vereinbarung zwischen Teams oder Organisationseinheiten.

Ziel:

Interne Teams stellen gemeinsam sicher, dass ein SLA erfüllt werden kann.

Beispiele:

Service Desk nimmt P1-Incidents innerhalb von 15 Minuten auf.
Netzwerkteam übernimmt P1-Eskalationen innerhalb von 30 Minuten.
Datenbankteam prüft kritische Datenbankalarme innerhalb von 30 Minuten.
Plattformteam stellt Restore-Unterstützung innerhalb definierter Zeit bereit.
Fachteam aktualisiert Knowledge-Artikel nach Changes.

OLAs sind interne Zusagen, keine Kundenzusagen.

Warum OLAs wichtig sind

Ein SLA kann nur eingehalten werden, wenn interne Abläufe funktionieren.

Ohne OLA entstehen Probleme:

Service Desk wartet zu lange auf Fachteam,
Eskalationswege sind unklar,
Teams priorisieren unterschiedlich,
interne Wartezeiten werden nicht sichtbar,
SLA wird verfehlt, obwohl einzelne Teams „ihren Teil“ erledigt haben,
Verantwortung wird hin- und hergeschoben.

OLAs machen interne Beiträge transparent.

Beispiel OLA-Kette

SLA:

P1-Incident wird innerhalb von 4 Stunden wiederhergestellt.

Dafür notwendige OLA-Beiträge:

Team	interner Beitrag
Service Desk	Ticket aufnehmen, priorisieren, Kommunikation starten
Monitoring	Alarm korrekt auslösen
Plattformteam	Serverzustand prüfen
Datenbankteam	Datenbankverfügbarkeit prüfen
Netzwerkteam	Netz- und Firewallpfade prüfen
Service Owner	fachliche Auswirkung bewerten
Kommunikation	Statusupdates unterstützen

Nur zusammen kann das SLA erreicht werden.

OLA-Inhalte

Ein OLA kann enthalten:

beteiligte Teams,
unterstützte Services,
interne Reaktionszeiten,
Eskalationswege,
Übergabepunkte,
Verantwortlichkeiten,
Kommunikationsregeln,
benötigte Informationen,
Betriebszeiten,
Bereitschaftsregeln,
Dokumentationspflichten,
Knowledge-Pflege,
Review-Termine.

Ein OLA muss praktikabel sein.

Zu komplizierte interne Vereinbarungen werden im Alltag nicht genutzt.

OLA und Ticketübergabe

OLAs helfen besonders bei Übergaben.

Zu klären ist:

Wann darf eskaliert werden?
Welche Informationen muss das Ticket enthalten?
Wer übernimmt Verantwortung?
Wie schnell wird reagiert?
Wann geht das Ticket zurück?
Wie wird der Benutzer informiert?
Wer dokumentiert die Lösung?
Wann wird Problem Management informiert?

Klare Übergaben verhindern Verzögerungen und Doppelarbeit.

Underpinning Contract

Ein Underpinning Contract ist ein unterstützender Vertrag mit einem externen Lieferanten.

Er kann Leistungen regeln wie:

Supportzeiten,
Reaktionszeiten,
Wiederherstellungszeiten,
Verfügbarkeit,
Wartungsfenster,
Eskalationswege,
Berichtspflichten,
Sicherheitsanforderungen,
Datenschutz,
Vertraulichkeit,
Vertragsstrafen,
Kündigungsfristen.

Underpinning Contracts müssen zu den internen SLAs passen.

Warum Underpinning Contracts wichtig sind

Viele IT-Services hängen von externen Leistungen ab.

Beispiele:

Internetverbindung,
Cloud-Plattform,
Software-Support,
Hardwarewartung,
Rechenzentrum,
Telefonie,
SaaS-Anwendung,
Sicherheitsdienstleister,
Druckdienstleister.

Wenn ein externer Vertrag schwächer ist als das interne SLA, entsteht ein Risiko.

Die Organisation verspricht dann möglicherweise mehr, als sie liefern kann.

Beispiel Lieferantenabhängigkeit

Interner SLA-Wunsch:

Fachanwendung bei kritischer Störung innerhalb von 4 Stunden wiederherstellen.

Externer Softwarevertrag:

Hersteller reagiert innerhalb von 1 Arbeitstag.

Risiko:

Wenn die Ursache beim Hersteller liegt, kann das interne Ziel nicht sicher eingehalten werden.

Mögliche Maßnahmen:

Lieferantenvertrag verbessern,
internes Ziel anpassen,
Workaround definieren,
technische Redundanz schaffen,
eigenes Fachwissen aufbauen,
Risiko bewusst akzeptieren.

SLA, OLA und Underpinning Contract abstimmen

Zu prüfen ist:

Unterstützen OLAs das SLA?
Unterstützen Lieferantenverträge das SLA?
Sind Supportzeiten kompatibel?
Sind Eskalationswege klar?
Gibt es Lücken zwischen interner und externer Leistung?
Sind Messmethoden vergleichbar?
Sind Wartungsfenster abgestimmt?
Sind Sicherheitsanforderungen berücksichtigt?
Sind Berichtspflichten geregelt?

Eine SLA-Zusage darf nicht isoliert betrachtet werden.

Typische Lücke zwischen SLA und OLA

SLA:

P2-Incidents werden innerhalb von 8 Stunden gelöst.

Interne Realität:

Service Desk ist schnell,
Fachteam reagiert aber erst nach 2 Arbeitstagen,
keine interne Eskalationsregel,
kein definierter Owner.

Folge:

Das SLA wird regelmäßig verfehlt.

Verbesserung:

OLA mit Fachteam definieren,
Eskalationsweg festlegen,
Prioritäten abstimmen,
Knowledge-Artikel bereitstellen,
Monitoring verbessern.

Typische Lücke zwischen SLA und Lieferantenvertrag

SLA:

Service ist Montag bis Freitag von 08:00 bis 18:00 Uhr unterstützt.

Lieferantenvertrag:

Hersteller-Support nur von 09:00 bis 17:00 Uhr.

Folge:

Bei Störung um 17:30 Uhr kann interne IT das SLA möglicherweise nicht erfüllen.

Verbesserung:

Vertrag anpassen,
interne Kompetenz erweitern,
SLA-Ziel anpassen,
Einschränkung klar kommunizieren,
Notfallverfahren definieren.

Mehrere Lieferanten

Ein Service kann von mehreren Lieferanten abhängen.

Beispiel:

Cloud-Anbieter,
Softwarehersteller,
Internetprovider,
externer Identity-Dienst,
Hardwarewartung,
Sicherheitsdienstleister.

Dann muss klar sein:

welcher Lieferant wofür zuständig ist,
wer zuerst kontaktiert wird,
welche Eskalationswege gelten,
welche Vertragszeiten gelten,
welche Nachweise benötigt werden,
wer den Gesamtservice koordiniert.

Der Benutzer interessiert sich nicht für Lieferantengrenzen.

Für ihn zählt, ob der Service funktioniert.

SLA und Supplier Management

Supplier Management stellt sicher, dass Lieferantenleistungen die Serviceziele unterstützen.

Wichtige Fragen:

Welche Lieferanten sind kritisch?
Welche Services hängen von ihnen ab?
Passen Vertragsziele zu SLAs?
Werden Lieferantenleistungen gemessen?
Gibt es regelmäßige Reviews?
Gibt es Eskalationswege?
Gibt es Risiken durch einzelne Lieferanten?
Gibt es Alternativen oder Notfallpläne?

Service Level Management und Supplier Management müssen eng zusammenarbeiten.

SLA und Service Configuration Management

Service Configuration Management zeigt, welche CIs und Lieferanten einen Service unterstützen.

Das hilft bei SLA-Planung.

Beispiele:

Service hängt von Cloud-Datenbank ab,
Service nutzt externen Identity Provider,
Service nutzt bestimmten Internetprovider,
Service nutzt internes Datenbankteam,
Service nutzt Zertifikate mit Ablaufdatum,
Service nutzt Monitoring und Backup.

Ohne diese Abhängigkeiten können SLAs falsch bewertet werden.

SLA und Monitoring

SLA-Ziele müssen messbar sein.

Monitoring liefert Daten für:

Verfügbarkeit,
Antwortzeiten,
Fehlerraten,
Login-Funktion,
Schnittstellenstatus,
Backupstatus,
Kapazität,
Zertifikatsablauf,
Servicezustand.

Wichtig ist:

Monitoring muss die vereinbarte Servicequalität abbilden.

Ein Server-Ping reicht nicht aus, wenn Benutzer sich trotzdem nicht anmelden können.

SLA und Reporting

SLA-Reports sollten zeigen:

erreichte Ziele,
verfehlte Ziele,
Ursachen für Abweichungen,
betroffene Services,
betroffene Benutzer,
Trends,
Risiken,
Lieferantenbeiträge,
geplante Verbesserungen.

Ein guter Report erklärt nicht nur, ob ein Ziel rot oder grün ist.

Er erklärt, warum es relevant ist und was daraus folgt.

SLA und Service Review

Im Service Review werden SLA, OLA und Lieferantenleistung gemeinsam betrachtet.

Mögliche Fragen:

Wurden SLA-Ziele erreicht?
Welche OLAs haben gut funktioniert?
Wo gab es interne Verzögerungen?
Welche Lieferanten haben Ziele verfehlt?
Welche Incidents waren besonders relevant?
Welche Problems sind offen?
Welche Changes beeinflussen Ziele?
Müssen Zielwerte angepasst werden?
Müssen Verträge angepasst werden?
Welche Verbesserungen werden beschlossen?

Service Reviews verbinden Messung mit Entscheidung.

SLA-Änderungen

SLAs sollten angepasst werden, wenn sich Rahmenbedingungen ändern.

Auslöser:

neuer Service,
geänderter Geschäftsprozess,
neue Benutzergruppe,
geänderte Betriebszeiten,
neue Lieferanten,
Cloud-Migration,
höhere Kritikalität,
wiederholte SLA-Abweichungen,
neue gesetzliche Anforderungen,
geänderte Sicherheitslage,
geändertes Budget.

Ein SLA ist kein dauerhaft unveränderliches Dokument.

Es muss regelmäßig überprüft werden.

SLA-Verhandlung

Bei SLA-Verhandlungen sollten folgende Punkte offen besprochen werden:

gewünschte Servicequalität,
tatsächlicher Bedarf,
technische Machbarkeit,
Kosten,
Risiken,
Lieferantenabhängigkeiten,
Supportzeiten,
Wartungsfenster,
Messmethoden,
Ausnahmen,
Alternativen.

Wichtig:

Nicht jede hohe Anforderung ist automatisch sinnvoll.

Manchmal ist ein realistischer Service Level mit gutem Workaround besser als ein teures Maximalziel.

Service Level und Kosten

Höhere Service Levels können höhere Kosten verursachen.

Beispiele:

24/7-Bereitschaft,
redundante Systeme,
schnellerer Lieferantensupport,
Hochverfügbarkeitsarchitektur,
zusätzliche Monitoringprüfungen,
häufigere Backups,
kürzere Restore-Zeiten,
mehr Personal,
mehr Tests.

Service Level Management macht sichtbar, welche Qualität benötigt wird und was sie kostet.

Service Level und Risikoakzeptanz

Nicht alle Risiken lassen sich vollständig vermeiden.

Wenn ein niedrigeres Service Level vereinbart wird, sollte klar sein:

welches Risiko akzeptiert wird,
wer es akzeptiert,
welche Auswirkungen möglich sind,
welche Workarounds existieren,
wann neu bewertet wird,
welche Verbesserungen geplant sind.

Beispiel:

Ein nicht kritischer Testservice erhält kein 24/7-SLA.

Das ist akzeptabel, wenn die Auswirkung gering und bekannt ist.

Service Level und Kommunikation

SLA-Inhalte müssen für Benutzer und Stakeholder verständlich kommuniziert werden.

Benutzer sollten wissen:

wann der Service verfügbar sein soll,
wann Support erreichbar ist,
wie Störungen gemeldet werden,
welche Prioritäten gelten,
wann Statusupdates erfolgen,
welche Self-Service-Angebote existieren,
welche Einschränkungen bekannt sind.

Unklare Kommunikation erzeugt falsche Erwartungen.

Praxisbeispiel: VPN-Service

SLR

Benutzer im Homeoffice benötigen werktags zuverlässigen Zugriff auf interne Systeme.

SLA

VPN-Service soll Montag bis Freitag von 08:00 bis 18:00 Uhr verfügbar sein.

P1-Incidents werden innerhalb von 15 Minuten qualifiziert bearbeitet.

OLA

Netzwerkteam übernimmt P1-Eskalationen innerhalb von 30 Minuten.

Identity-Team unterstützt bei MFA-Störungen innerhalb definierter Zeit.

Underpinning Contract

Internetprovider und VPN-Hersteller bieten Support innerhalb vereinbarter Zeiten.

Prüfung

Wenn Hersteller-Support nur am nächsten Arbeitstag reagiert, muss das SLA entsprechend bewertet werden.

Praxisbeispiel: Mitarbeiterportal

SLR

Fachbereich benötigt das Portal während der Kernarbeitszeit.

SLA

Servicezeit Montag bis Freitag von 07:00 bis 19:00 Uhr.

Geplante Wartung nur außerhalb dieser Zeit.

OLA

Anwendungsteam und Datenbankteam stellen interne Unterstützung während Servicezeit sicher.

Underpinning Contract

Cloud-Datenbank besitzt Provider-Support für kritische Fälle.

Review

Nach mehreren Performancebeschwerden wird ein zusätzliches Performance-Ziel ergänzt.

Praxisbeispiel: Standardsoftware bereitstellen

SLR

Benutzer sollen freigegebene Standardsoftware schnell erhalten.

SLA

Standardsoftware wird innerhalb von 2 Arbeitstagen bereitgestellt.

OLA

Service Desk prüft Anfrage innerhalb eines Arbeitstages.

Endpoint-Team stellt Paketierung und Softwareverteilung bereit.

Underpinning Contract

Softwarelieferant stellt Lizenzportal und Support bereit.

Risiko

Wenn Lizenzfreigabe extern länger dauert, muss dies im SLA berücksichtigt werden.

Praxisbeispiel: Lieferant passt nicht zum SLA

Situation

Interner SLA verspricht Wiederherstellung innerhalb von 4 Stunden.

Problem

Der externe Wartungsvertrag garantiert Ersatzteilversand erst am nächsten Arbeitstag.

Folge

Das SLA ist bei Hardwaredefekt nicht erfüllbar.

Mögliche Maßnahmen

besserer Wartungsvertrag,
Ersatzhardware vorhalten,
redundante Architektur,
SLA anpassen,
Risiko akzeptieren und dokumentieren.

Typische Fehler

Fehler 1

SLR wird ungeprüft direkt als SLA übernommen.

Fehler 2

SLA-Ziele sind nicht messbar.

Fehler 3

SLA, OLA und Lieferantenverträge passen nicht zusammen.

Fehler 4

Supportzeit und Servicezeit werden vermischt.

Fehler 5

Wartungsfenster sind nicht geregelt.

Fehler 6

Prioritäten sind unklar oder subjektiv.

Fehler 7

Messmethode wird nicht definiert.

Fehler 8

Ausnahmen werden nicht dokumentiert.

Fehler 9

Interne Teams kennen ihre OLA-Beiträge nicht.

Fehler 10

Lieferantenabhängigkeiten werden nicht berücksichtigt.

Fehler 11

SLA wird nicht regelmäßig überprüft.

Fehler 12

SLA wird als Kontrollinstrument genutzt, aber nicht als Grundlage für Verbesserung.

Checkliste SLR

Checkliste SLA

Checkliste OLA

Checkliste Underpinning Contract

Checkliste Abstimmung SLA, OLA und Lieferantenvertrag

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker müssen SLA, OLA und Lieferantenabhängigkeiten praktisch verstehen.

Im Arbeitsalltag bedeutet das:

technische Machbarkeit von Servicezielen einschätzen,
interne Reaktions- und Eskalationswege kennen,
Lieferantenabhängigkeiten erkennen,
Monitoring passend zu SLA-Zielen prüfen,
Incidents korrekt priorisieren,
Wiederherstellungszeiten nachvollziehbar dokumentieren,
Wartungsfenster beachten,
Changes mit Servicezielen abstimmen,
und unrealistische Zusagen früh sichtbar machen.

Service Level Management verbindet technische Realität mit vereinbarter Servicequalität.

Zusammenfassung

Service Level Requirement erfassen
↓
fachlichen Bedarf, Risiko und Machbarkeit prüfen
↓
realistische SLA-Ziele vereinbaren
↓
interne OLAs zur Unterstützung festlegen
↓
externe Underpinning Contracts abstimmen
↓
Messmethoden und Ausnahmen definieren
↓
Monitoring und Reporting einrichten
↓
Service Reviews durchführen
↓
Abweichungen analysieren
↓
SLA, OLA oder Lieferantenvertrag verbessern

Merksätze

Ein SLR beschreibt Bedarf, ein SLA beschreibt eine Vereinbarung.

Ein SLA ist nur erfüllbar, wenn OLAs und Lieferantenverträge dazu passen.

Servicezeit und Supportzeit sind nicht dasselbe.

Reaktionszeit ist nicht automatisch Lösungszeit.

Ein Ziel ohne Messmethode ist später kaum bewertbar.

Lieferantenabhängigkeiten müssen vor der SLA-Zusage geprüft werden.

Gute Service Level sind realistisch, messbar und verständlich.

Verwandte Seiten

8.1 Service Level Management – Ziele, Begriffe und Grundlagen
8.3 Kennzahlen, Messmethoden und Reporting
8.4 Service Reviews und Continual Improvement
8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management
Supplier Management
Incident Management
Change Enablement
Service Configuration Management
Measurement and Reporting

Quellen und Versionsstand

Offizielle Grundlagen

PeopleCert – ITIL Practice Guide: Service Level Management
PeopleCert – ITIL Practice Guide: Supplier Management
PeopleCert – ITIL Practice Guide: Measurement and Reporting
PeopleCert – ITIL Practice Guide: Incident Management
PeopleCert – ITIL Practice Guide: Change Enablement
ITIL Foundation – Version 5

Einordnung

Die dargestellten:

SLR-Beispiele,
SLA-Inhalte,
OLA-Strukturen,
Lieferantenvertragsbezüge,
Checklisten,
Prioritätsbeispiele,
und Praxisbeispiele

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

SLA-Vorlage,
SLR-Vorlage,
OLA-Struktur,
Prioritätsmatrix,
Messmethode,
Vertragsstruktur,
oder Review-Frequenz

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

Services,
Kunden,
Benutzergruppen,
Risiken,
Kosten,
Supportmodell,
Lieferanten,
Monitoring,
Organisationsstruktur,
und verfügbare Fähigkeiten

angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026

Revision #1
Created 2 August 2026 16:51:19 by Admin
Updated 2 August 2026 16:51:32 by Admin