8.1 Service Level Management – Ziele, Begriffe und Grundlagen

Kurz erklärt

Service Level Management sorgt dafür, dass Erwartungen an IT-Services klar beschrieben, messbar gemacht, vereinbart, überwacht und regelmäßig überprüft werden.

Ziel ist nicht, möglichst viele Kennzahlen zu sammeln.

Ziel ist, gemeinsam zu verstehen:

was ein Service leisten soll,

welche Qualität erwartet wird,

welche Ziele vereinbart sind,

ob diese Ziele erreicht werden,

und wo Verbesserungen notwendig sind.

Warum Service Level Management wichtig ist

Ohne klare Service Levels entstehen häufig Missverständnisse.

Beispiele:

Benutzer erwarten sofortige Reaktion, IT arbeitet aber nach Prioritäten.
Fachbereiche erwarten hohe Verfügbarkeit, aber technische Abhängigkeiten sind nicht bekannt.
Supportzeiten sind unklar.
Wiederherstellungszeiten sind nicht vereinbart.
Servicequalität wird nur gefühlt bewertet.
Reports zeigen Zahlen, aber keine Aussage zum tatsächlichen Nutzen.
IT und Fachbereich sprechen über unterschiedliche Erwartungen.

Service Level Management macht Erwartungen sichtbar und steuerbar.

Was ist ein Service Level?

Ein Service Level beschreibt ein vereinbartes oder erwartetes Qualitätsniveau eines Service.

Beispiele:

Verfügbarkeit,
Reaktionszeit,
Wiederherstellungszeit,
Supportzeit,
Bearbeitungszeit,
Antwortzeit einer Anwendung,
Erfolgsquote eines Prozesses,
Erreichbarkeit des Service Desk,
Backup- und Restore-Ziele,
Benutzerzufriedenheit,
Stabilität nach Changes.

Ein Service Level sollte verständlich, messbar und für den Service relevant sein.

Service Level Management ist mehr als SLA-Verwaltung

Ein häufiger Irrtum:

Service Level Management bedeutet nur, SLAs zu schreiben.

Das ist zu kurz gedacht.

Service Level Management umfasst auch:

Erwartungen verstehen,
Anforderungen erfassen,
Servicequalität definieren,
messbare Ziele vereinbaren,
passende Kennzahlen auswählen,
Ergebnisse überwachen,
Berichte erstellen,
Service Reviews durchführen,
Abweichungen analysieren,
Verbesserungen anstoßen,
und Kommunikation zwischen IT und Fachbereich verbessern.

Ein SLA allein verbessert noch keinen Service.

Ziele von Service Level Management

Service Level Management soll:

Erwartungen zwischen IT und Kunden klären,
Servicequalität transparent machen,
realistische Ziele vereinbaren,
Serviceleistung messbar machen,
Risiken sichtbar machen,
Berichte verständlich gestalten,
Verbesserungen priorisieren,
Kundenzufriedenheit unterstützen,
geschäftliche Anforderungen berücksichtigen,
und IT-Leistung mit Servicewert verbinden.

Wichtig ist, nicht nur technische Messwerte zu betrachten.

Entscheidend ist, ob der Service den benötigten Nutzen liefert.

Kunde, Benutzer und Service Provider unterscheiden

Rolle	Bedeutung	Beispiel
Kunde	entscheidet oder verantwortet den Bedarf an einem Service	Fachbereichsleitung
Benutzer	nutzt den Service im Alltag	Mitarbeitende im Mitarbeiterportal
Service Provider	stellt den Service bereit oder betreibt ihn	interne IT oder externer Anbieter
Service Owner	verantwortet den Service innerhalb der Organisation	Owner für VPN-Service
Stakeholder	ist vom Service betroffen oder beteiligt	Datenschutz, Security, Management

Kunden und Benutzer haben nicht immer dieselbe Perspektive.

Ein Kunde achtet oft auf Nutzen, Kosten und Risiko.

Ein Benutzer achtet stärker auf Alltagstauglichkeit, Geschwindigkeit und Verständlichkeit.

Service Level Agreement

Ein Service Level Agreement (SLA) ist eine Vereinbarung über Serviceziele zwischen Service Provider und Kunde.

Ein SLA kann enthalten:

Servicebeschreibung,
Geltungsbereich,
Supportzeiten,
Verfügbarkeitsziele,
Reaktionszeiten,
Wiederherstellungsziele,
Prioritäten,
Messmethoden,
Berichtspflichten,
Verantwortlichkeiten,
Einschränkungen,
Ausnahmen,
Eskalationswege,
Review-Termine.

Ein SLA sollte verständlich und realistisch sein.

Ein SLA, das niemand liest oder versteht, hilft im Betrieb wenig.

Service Level Requirement

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

Beispiele:

Der Service muss montags bis freitags von 08:00 bis 18:00 Uhr verfügbar sein.
Kritische Incidents müssen innerhalb von 30 Minuten bearbeitet werden.
Die Anwendung soll für normale Benutzeraktionen unter drei Sekunden reagieren.
Passwort-Requests sollen automatisiert bearbeitet werden.
Fachbereich benötigt monatlichen Servicebericht.

SLRs helfen, Erwartungen zu erfassen, bevor sie als Serviceziele vereinbart werden.

Service Level Target

Ein Service Level Target ist ein konkretes Ziel innerhalb eines Service Levels.

Beispiele:

Bereich	mögliches Ziel
Verfügbarkeit	Service ist während vereinbarter Servicezeit zu 99,5 Prozent verfügbar
Reaktion	P1-Incidents werden innerhalb von 15 Minuten bearbeitet
Wiederherstellung	P1-Incidents werden innerhalb von 4 Stunden gelöst oder umgangen
Bearbeitung	Standardsoftware wird innerhalb von 2 Arbeitstagen bereitgestellt
Performance	Startseite lädt im Normalbetrieb unter 3 Sekunden
Kommunikation	Statusupdates bei Major Incidents alle 30 Minuten

Ein Ziel muss messbar und fachlich sinnvoll sein.

Operational Level Agreement

Ein Operational Level Agreement (OLA) beschreibt interne Vereinbarungen zwischen unterstützenden Teams.

Beispiel:

Das SLA verspricht dem Fachbereich eine Wiederherstellung innerhalb von 4 Stunden.

Dafür braucht die IT interne Beiträge:

Service Desk reagiert innerhalb von 15 Minuten.
Netzwerkteam übernimmt Eskalationen innerhalb von 30 Minuten.
Datenbankteam prüft kritische Datenbankalarme innerhalb von 30 Minuten.
Plattformteam stellt Wiederherstellungsschritte bereit.

Ein OLA unterstützt also die Einhaltung des SLA.

Underpinning Contract

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

Beispiele:

Provider für Internetanbindung,
Cloud-Anbieter,
Hardwarewartung,
Software-Support,
Rechenzentrumsdienstleister,
Telefonieanbieter.

Wenn ein SLA von externen Leistungen abhängt, müssen Lieferantenverträge dazu passen.

Beispiel:

Ein interner Service kann keine Wiederherstellung innerhalb von 2 Stunden garantieren, wenn der externe Lieferant nur Reaktion am nächsten Arbeitstag zusagt.

SLA, OLA und Lieferantenvertrag im Zusammenhang

Kundenanforderung
    ↓
Service Level Requirement
    ↓
Service Level Agreement
    ↓
interne Operational Level Agreements
    ↓
externe Underpinning Contracts
    ↓
technische Umsetzung, Monitoring und Reporting

Die Ziele müssen zusammenpassen.

Sonst werden Versprechen gemacht, die technisch oder organisatorisch nicht erfüllbar sind.

Servicebeschreibung als Grundlage

Vor Service Levels muss klar sein, welcher Service gemeint ist.

Eine Servicebeschreibung kann enthalten:

Name des Service,
Zweck,
Zielgruppe,
Leistungsumfang,
wichtige Funktionen,
Supportzeiten,
Kontaktweg,
Voraussetzungen,
Einschränkungen,
Service Owner,
beteiligte Supportgruppen,
Abhängigkeiten,
Sicherheitsanforderungen,
und relevante Dokumentation.

Ohne klare Servicebeschreibung ist ein SLA schwer verständlich.

Beispiel: Servicebeschreibung VPN-Zugang

Feld	Beispiel
Service	VPN-Zugang
Zweck	sicherer Zugriff auf interne Ressourcen von außerhalb
Benutzer	berechtigte Mitarbeitende
Supportzeit	Montag bis Freitag, 08:00 bis 18:00 Uhr
Abhängigkeiten	VPN-Gateway, MFA, Identity Provider, Internet
Service Owner	IT-Infrastruktur
Einschränkung	private Geräte nur nach Freigabe
Knowledge	Benutzeranleitung VPN, Known Error VPN-Client

Solche Informationen helfen, Erwartungen und Ziele sauber zu formulieren.

Messbarkeit

Ein Service Level sollte messbar sein.

Ungeeignet:

Der Service soll schnell sein.

Besser:

Die Startseite soll während normaler Last innerhalb von drei Sekunden laden.

Ungeeignet:

Der Support soll zeitnah reagieren.

Besser:

Kritische Incidents werden innerhalb von 15 Minuten aufgenommen und priorisiert.

Messbarkeit verhindert Diskussionen über unklare Begriffe.

Messmethode festlegen

Zu jedem Ziel sollte klar sein:

Was wird gemessen?
Wo wird gemessen?
Wann wird gemessen?
Wie oft wird gemessen?
Welche Datenquelle gilt?
Welche Ausnahmen gibt es?
Wer prüft die Daten?
Wie wird berichtet?

Beispiel:

Verfügbarkeit kann unterschiedlich gemessen werden:

aus Sicht des Servers,
aus Sicht der Anwendung,
aus Sicht eines Standortes,
aus Sicht externer Benutzer,
während Servicezeiten,
rund um die Uhr,
mit oder ohne geplante Wartung.

Ohne Messmethode ist eine Kennzahl schwer vergleichbar.

Technische Kennzahl und Benutzererfahrung unterscheiden

Ein Service kann technisch verfügbar sein und trotzdem schlecht nutzbar sein.

Beispiele:

Anwendung ist erreichbar, aber extrem langsam.
Login funktioniert, aber wichtige Funktion erzeugt Fehler.
Server läuft, aber Benutzer können wegen MFA-Problem nicht arbeiten.
Service Desk ist erreichbar, aber Benutzer erhalten keine hilfreiche Antwort.
Verfügbarkeit ist hoch, aber häufige kurze Störungen stören den Arbeitsablauf.

Service Level Management sollte deshalb technische Messwerte und Benutzererfahrung zusammen betrachten.

Geeignete Kennzahlen

Geeignete Kennzahlen sind:

relevant,
verständlich,
messbar,
beeinflussbar,
mit Servicezielen verbunden,
und nicht nur intern technisch interessant.

Beispiele:

Serviceverfügbarkeit,
Anzahl kritischer Incidents,
durchschnittliche Wiederherstellungszeit,
Einhaltung von Reaktionszeiten,
Benutzerzufriedenheit,
Ticketvolumen je Service,
Wiedereröffnungsquote,
Anzahl Incidents nach Changes,
Erfüllung von Request-Zielen,
häufige Serviceunterbrechungen.

Eine Kennzahl sollte eine Entscheidung oder Verbesserung unterstützen.

Problematische Kennzahlen

Kennzahlen können falsche Anreize erzeugen.

Kennzahl	möglicher Fehlanreiz
viele geschlossene Tickets	schnelle Schließung statt guter Lösung
sehr kurze Bearbeitungszeit	komplexe Fälle werden oberflächlich behandelt
hohe SLA-Erfüllung	Ziele sind zu niedrig gesetzt
wenige Eskalationen	notwendige Eskalationen werden vermieden
hohe Verfügbarkeit	Benutzerprobleme werden übersehen
viele Knowledge-Artikel	Menge statt Qualität

Kennzahlen müssen deshalb immer mit Kontext bewertet werden.

Service Level und Priorität

Service Levels hängen oft mit Prioritäten zusammen.

Beispiel:

Priorität	typische Bedeutung
P1	kritischer Serviceausfall mit hoher Auswirkung
P2	wichtige Funktion stark eingeschränkt
P3	einzelner Benutzer oder begrenzte Auswirkung
P4	niedrige Auswirkung oder Standardanfrage

Wichtig:

Priorität sollte nicht nur aus Dringlichkeit entstehen.

Sie sollte Auswirkung und Dringlichkeit gemeinsam betrachten.

Ein einzelner Benutzer kann eine hohe Priorität haben, wenn eine geschäftskritische Rolle betroffen ist.

Reaktionszeit und Lösungszeit unterscheiden

Begriff	Bedeutung
Reaktionszeit	Zeit bis zur ersten qualifizierten Bearbeitung oder Rückmeldung
Lösungszeit	Zeit bis zur vollständigen Lösung oder vereinbarten Wiederherstellung
Wiederherstellungszeit	Zeit bis der Service wieder nutzbar ist, ggf. mit Workaround
Bearbeitungszeit	Zeit, in der aktiv am Vorgang gearbeitet wird
Wartezeit	Zeit, in der auf Benutzer, Lieferant oder Genehmigung gewartet wird

Diese Begriffe sollten nicht vermischt werden.

Ein Ticket kann schnell beantwortet, aber noch lange nicht gelöst sein.

Verfügbarkeit

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

Wichtige Fragen:

Welche Servicezeit gilt?
Welche Komponenten zählen?
Sind geplante Wartungen ausgeschlossen?
Wird aus Benutzer- oder Systemsicht gemessen?
Zählen kurze Unterbrechungen?
Wie wird Teilausfall bewertet?
Welche Standorte oder Benutzergruppen gelten?

Beispiel:

99,5 Prozent Verfügbarkeit während Servicezeit bedeutet etwas anderes als 99,5 Prozent rund um die Uhr.

Servicezeit und Supportzeit unterscheiden

Begriff	Bedeutung
Servicezeit	Zeitraum, in dem der Service vereinbarungsgemäß nutzbar sein soll
Supportzeit	Zeitraum, in dem Unterstützung verfügbar ist
Wartungsfenster	geplanter Zeitraum für Änderungen oder Wartung
Bereitschaft	Unterstützung außerhalb normaler Zeiten bei definierten Fällen

Ein Service kann rund um die Uhr verfügbar sein, aber nur zu bestimmten Zeiten vollen Support haben.

Diese Unterschiede müssen klar kommuniziert werden.

Wartungsfenster

Wartungsfenster sollten in Service Leveln berücksichtigt werden.

Zu klären ist:

Wann darf geplant gewartet werden?
Wird Wartung aus Verfügbarkeitsberechnung ausgeschlossen?
Wie früh wird angekündigt?
Wer muss informiert werden?
Welche Services sind betroffen?
Welche Ausnahmen gelten?
Gibt es kritische Geschäftszeiten?

Ein Wartungsfenster muss zur Nutzung des Services passen.

Ein technisch bequemes Wartungsfenster kann fachlich ungeeignet sein.

Service Level und Benutzerkommunikation

Benutzer sollten wissen:

wann Support erreichbar ist,
wie sie Störungen melden,
welche Reaktionszeiten gelten,
wann Statusupdates erfolgen,
welche Informationen im Ticket benötigt werden,
welche Einschränkungen bestehen,
wo Self-Service-Informationen stehen.

Unklare Kommunikation führt zu falschen Erwartungen.

Service Level Management unterstützt deshalb auch verständliche Kommunikation.

Service Review

Ein Service Review ist eine regelmäßige Besprechung zur Servicequalität.

Mögliche Inhalte:

erreichte Service Levels,
wichtige Incidents,
Problems und Known Errors,
Changes und Releases,
Benutzerfeedback,
SLA-Abweichungen,
Trends,
Risiken,
offene Verbesserungen,
kommende Änderungen,
Entscheidungen oder Prioritäten.

Ein Service Review sollte nicht nur Zahlen vorlesen.

Es sollte helfen, Servicequalität zu verstehen und zu verbessern.

Reporting

Service Level Reporting stellt Informationen zur Serviceleistung bereit.

Gute Reports sind:

verständlich,
zielgruppengerecht,
servicebezogen,
nicht zu technisch,
mit Kontext versehen,
handlungsorientiert,
und regelmäßig.

Ein guter Report beantwortet:

Was wurde erreicht?
Was wurde nicht erreicht?
Warum ist das wichtig?
Welche Risiken bestehen?
Welche Maßnahmen laufen?
Welche Entscheidung wird benötigt?

SLA-Abweichungen

Eine SLA-Abweichung bedeutet, dass ein vereinbartes Ziel nicht erreicht wurde.

Zu prüfen ist:

Welches Ziel wurde verfehlt?
Wie groß war die Abweichung?
Welche Ursache liegt vor?
Welche Benutzer waren betroffen?
War ein Lieferant beteiligt?
Gab es einen Major Incident?
Gab es einen Change davor?
Ist ein Problem Record notwendig?
Welche Verbesserung wird geplant?

Eine SLA-Abweichung sollte nicht nur berichtet, sondern analysiert werden.

Service Level und Continual Improvement

Service Level Management liefert wichtige Hinweise für Verbesserungen.

Beispiele:

wiederholte SLA-Verfehlungen,
schlechte Benutzerzufriedenheit,
steigende Ticketzahlen,
viele Incidents nach Changes,
lange Wiederherstellungszeiten,
wiederkehrende Lieferantenprobleme,
fehlende Knowledge-Artikel,
unklare Servicebeschreibung.

Diese Hinweise sollten in Continual Improvement einfließen.

Service Level und Kosten

Höhere Service Levels verursachen oft höhere Kosten.

Beispiele:

24/7-Support,
Hochverfügbarkeit,
redundante Infrastruktur,
schnellere Lieferantenreaktion,
häufigere Backups,
kürzere Wiederherstellungszeiten,
größere Bereitschaftsteams.

Deshalb müssen Service Levels realistisch und wirtschaftlich sinnvoll sein.

Nicht jeder Service benötigt maximale Verfügbarkeit.

Service Level und Risiko

Service Levels sollten zum Risiko passen.

Fragen:

Was passiert bei Ausfall?
Welche Geschäftsprozesse sind betroffen?
Gibt es manuelle Ersatzverfahren?
Wie lange ist ein Ausfall tolerierbar?
Gibt es gesetzliche Anforderungen?
Gibt es Vertragsstrafen?
Gibt es Sicherheitsrisiken?
Welche Benutzergruppen sind betroffen?

Ein Service mit hohem Risiko benötigt strengere Ziele als ein unkritischer interner Testservice.

Service Level und Lieferanten

Viele Services hängen von Lieferanten ab.

Beispiele:

Internetprovider,
Cloud-Anbieter,
Softwarehersteller,
Hardwarewartung,
externer Support,
Rechenzentrum,
Telekommunikation.

Service Level Management muss prüfen:

Passen Lieferantenverträge zu internen SLAs?
Sind Reaktionszeiten kompatibel?
Sind Eskalationswege klar?
Gibt es Berichtspflichten?
Sind Wartungsfenster abgestimmt?
Gibt es Abhängigkeiten von externen Statusseiten?

Interne Zusagen dürfen externe Abhängigkeiten nicht ignorieren.

Service Level und Monitoring

Monitoring liefert Daten für Service Level Management.

Beispiele:

Verfügbarkeit,
Antwortzeiten,
Fehlerraten,
Kapazität,
Zertifikatsablauf,
Backupstatus,
Schnittstellenzustand,
Login-Erfolg,
Transaktionsprüfung.

Wichtig ist, dass Monitoring den Service aus relevanter Sicht misst.

Ein Server-Ping allein reicht oft nicht aus, um Servicequalität zu bewerten.

Service Level und Service Configuration Management

Service Configuration Management hilft zu verstehen:

welche CIs einen Service unterstützen,
welche Abhängigkeiten bestehen,
welche Owner beteiligt sind,
welche Lieferanten unterstützen,
welche Changes einen Service beeinflussen,
welche CIs kritisch sind.

Ohne Configuration-Daten sind Service Levels schwer realistisch zu bewerten.

Service Level und Incident Management

Incident Management liefert Daten über Servicequalität.

Beispiele:

Anzahl Incidents je Service,
Prioritäten,
Reaktionszeiten,
Wiederherstellungszeiten,
Wiedereröffnungen,
Major Incidents,
Benutzerfeedback,
Eskalationen.

Diese Daten helfen, SLA-Erfüllung und Verbesserungspotenzial zu bewerten.

Service Level und Problem Management

Problem Management unterstützt Service Level Management, wenn Ziele wiederholt verfehlt werden.

Beispiele:

Service fällt wiederholt aus,
gleiche Ursache erzeugt viele Incidents,
Workaround wird ständig genutzt,
Lieferant verursacht wiederkehrende Störungen,
Monitoring erkennt Probleme zu spät.

Dann reicht Reporting allein nicht aus.

Die Ursache muss untersucht und dauerhaft verbessert werden.

Service Level und Change Enablement

Changes können Service Levels beeinflussen.

Zu prüfen ist:

Wird ein kritischer Service geändert?
Gibt es Ausfallzeit?
Gibt es Wartungsfenster?
Werden Benutzer informiert?
Welche Service-Level-Ziele könnten betroffen sein?
Muss ein SLA wegen geplanter Wartung berücksichtigt werden?
Entstehen Risiken für Verfügbarkeit oder Performance?

Change Enablement und Service Level Management sollten deshalb zusammenarbeiten.

Praxisbeispiel: Mitarbeiterportal

Serviceziel

Das Mitarbeiterportal soll montags bis freitags von 08:00 bis 18:00 Uhr verfügbar sein.

Messung

Verfügbarkeit aus Anwendungssicht,
Login-Funktion,
zentrale Startseite,
geplante Wartungen getrennt ausgewiesen.

Review

Im Monatsbericht wird sichtbar:

Verfügbarkeit erreicht,
aber viele Benutzer melden langsame Antwortzeiten.

Erkenntnis

Technische Verfügbarkeit allein reicht nicht.

Performance und Benutzerfeedback müssen zusätzlich betrachtet werden.

Praxisbeispiel: Service Desk

Serviceziel

Kritische Incidents werden innerhalb von 15 Minuten aufgenommen und priorisiert.

Messung

Zeit von Ticketeingang bis qualifizierter Erstbearbeitung,
P1-Tickets,
Supportzeit,
Eskalationszeit.

Risiko

Wenn nur „erste Antwort“ gemessen wird, kann eine automatische Antwort die Kennzahl erfüllen, ohne echte Bearbeitung zu leisten.

Verbesserung

Gemessen wird qualifizierte Reaktion, nicht nur automatische Eingangsbestätigung.

Praxisbeispiel: Lieferantenabhängigkeit

Serviceziel

Interner Service soll innerhalb von 4 Stunden wiederhergestellt werden.

Problem

Ein externer Lieferant garantiert nur Reaktion innerhalb von 8 Stunden.

Folge

Das interne Ziel ist nicht realistisch, wenn der Lieferant kritisch beteiligt ist.

Verbesserung

Lieferantenvertrag prüfen,
interne SLA-Ziele anpassen,
technische Redundanz prüfen,
Workaround oder Notfallverfahren definieren.

Typische Fehler

Fehler 1

SLA wird geschrieben, aber nicht aktiv genutzt.

Fehler 2

Service Levels sind technisch korrekt, aber für Benutzer nicht verständlich.

Fehler 3

Kennzahlen messen Systeme, aber nicht Servicequalität.

Fehler 4

Messmethode ist unklar.

Fehler 5

Servicezeit, Supportzeit und Wartungsfenster werden vermischt.

Fehler 6

Interne SLAs ignorieren Lieferantenabhängigkeiten.

Fehler 7

Zu hohe Ziele werden vereinbart, obwohl Ressourcen fehlen.

Fehler 8

SLA-Abweichungen werden nur berichtet, aber nicht analysiert.

Fehler 9

Benutzerfeedback wird ignoriert.

Fehler 10

Service Reviews bestehen nur aus Zahlen ohne Maßnahmen.

Fehler 11

Prioritäten werden nur nach Lautstärke des Benutzers gesetzt.

Fehler 12

Service Level Management wird als reine Kontrollfunktion verstanden.

Checkliste Service Level definieren

Checkliste SLA-Inhalte

Checkliste Messung

Checkliste Service Review

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker unterstützen Service Level Management durch technische Daten und praktische Betriebserfahrung.

Im Arbeitsalltag bedeutet das:

Services und Abhängigkeiten verstehen,
Monitoringdaten richtig einordnen,
Incidents sauber dokumentieren,
Wiederherstellungszeiten nachvollziehbar erfassen,
Changes mit Servicewirkung bewerten,
technische Grenzen realistisch erklären,
Workarounds und Known Errors berücksichtigen,
und Verbesserungen aus wiederkehrenden Abweichungen ableiten.

Service Level Management hilft dabei, technische Arbeit mit Servicequalität und Benutzererwartung zu verbinden.

Zusammenfassung

Service verstehen
↓
Erwartungen und Anforderungen erfassen
↓
Service Level Requirements formulieren
↓
realistische Ziele vereinbaren
↓
Messmethoden festlegen
↓
SLA, OLA und Lieferantenabhängigkeiten abstimmen
↓
Serviceleistung überwachen
↓
verständlich berichten
↓
Service Reviews durchführen
↓
Abweichungen analysieren
↓
Verbesserungen anstoßen

Merksätze

Service Level Management klärt Erwartungen und macht Servicequalität steuerbar.

Ein SLA verbessert nichts, wenn es nicht verstanden, gemessen und genutzt wird.

Technische Verfügbarkeit ist nicht automatisch gute Benutzererfahrung.

Servicezeit, Supportzeit und Wartungsfenster müssen klar getrennt werden.

Interne Ziele müssen zu internen Fähigkeiten und Lieferantenverträgen passen.

Kennzahlen brauchen Kontext, sonst erzeugen sie falsche Schlüsse.

Service Reviews sollen Verbesserungen auslösen, nicht nur Zahlen präsentieren.

Verwandte Seiten

8.2 SLA, SLR, OLA und Underpinning Contracts
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
Incident Management
Problem Management
Change Enablement
Service Configuration Management
Knowledge Management
Measurement and Reporting

Quellen und Versionsstand

Offizielle Grundlagen

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

Einordnung

Die dargestellten:

SLA-Beispiele,
Begriffe,
Messfragen,
Review-Inhalte,
Checklisten,
Prioritätsbeispiele,
und Praxisbeispiele

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

SLA-Vorlage,
Kennzahlenliste,
Zielwerttabelle,
Prioritätsmatrix,
Review-Frequenz,
oder Reporting-Struktur

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

Services,
Kunden,
Benutzergruppen,
Risiken,
Servicezeiten,
Supportmodell,
Lieferanten,
Monitoring,
Organisation,
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:47:29 by Admin
Updated 2 August 2026 16:47:52 by Admin