8. Service Level Management

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:

Warum Service Level Management wichtig ist

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

Beispiele:

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:

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:

Ein SLA allein verbessert noch keinen Service.

Ziele von Service Level Management

Service Level Management soll:

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:

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:

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:

Ein OLA unterstützt also die Einhaltung des SLA.

Underpinning Contract

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

Beispiele:

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:

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:

Beispiel:

Verfügbarkeit kann unterschiedlich gemessen werden:

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:

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

Geeignete Kennzahlen

Geeignete Kennzahlen sind:

Beispiele:

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:

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:

Ein Wartungsfenster muss zur Nutzung des Services passen.

Ein technisch bequemes Wartungsfenster kann fachlich ungeeignet sein.

Service Level und Benutzerkommunikation

Benutzer sollten wissen:

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:

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:

Ein guter Report beantwortet:

SLA-Abweichungen

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

Zu prüfen ist:

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:

Diese Hinweise sollten in Continual Improvement einfließen.

Service Level und Kosten

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

Beispiele:

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:

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:

Service Level Management muss prüfen:

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

Service Level und Monitoring

Monitoring liefert Daten für Service Level Management.

Beispiele:

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:

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

Service Level und Incident Management

Incident Management liefert Daten über Servicequalität.

Beispiele:

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:

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:

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

Review

Im Monatsbericht wird sichtbar:

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

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

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:

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

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

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

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:

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:

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:

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:

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:

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:

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

Beispiel Geltungsbereich

Service

VPN-Zugang für berechtigte Mitarbeitende.

Eingeschlossen

Nicht eingeschlossen

Diese Abgrenzung macht Erwartungen klarer.

Servicezeit

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

Beispiele:

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

Supportzeit

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

Beispiele:

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:

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:

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:

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

Wiederherstellungszeit

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

Das kann bedeuten:

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:

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

Dringlichkeit

Dringlichkeit beschreibt, wie schnell gehandelt werden muss.

Kriterien:

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:

Beispiel:

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

Ausnahmen

SLAs sollten Ausnahmen definieren.

Beispiele:

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:

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:

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:

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:

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:

Underpinning Contracts müssen zu den internen SLAs passen.

Warum Underpinning Contracts wichtig sind

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

Beispiele:

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:

SLA, OLA und Underpinning Contract abstimmen

Zu prüfen ist:

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:

Folge:

Das SLA wird regelmäßig verfehlt.

Verbesserung:

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:

Mehrere Lieferanten

Ein Service kann von mehreren Lieferanten abhängen.

Beispiel:

Dann muss klar sein:

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:

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:

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

SLA und Monitoring

SLA-Ziele müssen messbar sein.

Monitoring liefert Daten für:

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:

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:

Service Reviews verbinden Messung mit Entscheidung.

SLA-Änderungen

SLAs sollten angepasst werden, wenn sich Rahmenbedingungen ändern.

Auslöser:

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:

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:

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:

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:

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

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:

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

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

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

8.3 Kennzahlen, Messmethoden und Reporting

Kurz erklärt

Kennzahlen, Messmethoden und Reporting machen Servicequalität sichtbar.

Entscheidend ist nicht, möglichst viele Zahlen zu sammeln.

Entscheidend ist, die richtigen Fragen zu beantworten:

Gute Messung unterstützt Entscheidungen. Schlechte Messung erzeugt falsche Sicherheit.

Warum Kennzahlen wichtig sind

Ohne Messung bleibt Servicequalität oft subjektiv.

Typische Aussagen ohne klare Daten:

Kennzahlen helfen, solche Aussagen zu prüfen.

Sie zeigen:

Kennzahlen sind kein Selbstzweck

Eine Kennzahl ist nur sinnvoll, wenn sie genutzt wird.

Ungeeignet:

Wir messen alles, weil es technisch möglich ist.

Besser:

Wir messen das, was für Servicequalität, Steuerung, Risiko und Verbesserung wichtig ist.

Zu viele Kennzahlen führen zu unübersichtlichen Reports.

Zu wenige Kennzahlen können wichtige Probleme verdecken.

Die richtige Auswahl hängt vom Service, den Zielen und den Entscheidungen ab, die unterstützt werden sollen.

Gute Kennzahlen

Gute Kennzahlen sind:

Eine Kennzahl sollte immer eine Frage beantworten.

Beispiel:

Nicht nur:

Wie viele Tickets wurden geschlossen?

Sondern:

Werden Benutzer schneller wieder arbeitsfähig und verbessert sich die Servicequalität?

Kennzahl und Ziel unterscheiden

Eine Kennzahl ist ein Messwert.

Ein Ziel beschreibt, welcher Wert erreicht werden soll.

Begriff Bedeutung Beispiel
Kennzahl gemessener Wert Verfügbarkeit des Service
Zielwert gewünschter oder vereinbarter Wert mindestens 99,5 Prozent während Servicezeit
Messmethode Art der Ermittlung synthetischer Login-Test alle 5 Minuten
Report Darstellung und Bewertung Monatsbericht Servicequalität
Maßnahme Reaktion auf Ergebnis Problem Record für wiederholte Ausfälle

Ohne Zielwert ist eine Kennzahl schwer zu bewerten.

Ohne Messmethode ist ein Ziel schwer überprüfbar.

Messmethode

Die Messmethode beschreibt, wie eine Kennzahl ermittelt wird.

Zu klären ist:

Eine unklare Messmethode führt zu Diskussionen über Zahlen statt zu Verbesserungen.

Beispiel: Verfügbarkeit messen

Unklar:

Der Service war zu 99,9 Prozent verfügbar.

Klärende Fragen:

Erst mit diesen Angaben ist die Zahl aussagekräftig.

Technische Messung und Benutzerperspektive

Technische Messungen sind wichtig, aber nicht ausreichend.

Beispiele:

Technische Sicht Benutzerperspektive
Server antwortet auf Ping Benutzer kann Anwendung nutzen
HTTP-Status ist 200 Anmeldung funktioniert wirklich
Datenbank läuft Anwendung verarbeitet Daten korrekt
CPU-Auslastung ist normal Oberfläche reagiert schnell genug
Service Desk Ticket ist geschlossen Benutzer ist tatsächlich arbeitsfähig

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

Servicebezogene Kennzahlen

Service Level Management sollte möglichst servicebezogen messen.

Beispiele:

Servicebezogene Kennzahlen sind hilfreicher als reine Technikzahlen ohne Kontext.

Verfügbarkeit

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

Zu definieren ist:

Beispiel:

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

Diese Definition ist aussagekräftiger als nur:

Server ist erreichbar.

Berechnung von Verfügbarkeit

Eine einfache Formel:

Verfügbarkeit = verfügbare Zeit / vereinbarte Servicezeit × 100

Beispiel:

vereinbarte Servicezeit im Monat: 10.000 Minuten
Ausfallzeit: 50 Minuten

Verfügbarkeit = 9.950 / 10.000 × 100
Verfügbarkeit = 99,5 Prozent

Wichtig:

Die Berechnung muss definieren, welche Ausfallzeit zählt und welche nicht.

Geplante Wartung

Geplante Wartung sollte getrennt betrachtet werden.

Zu klären ist:

Geplante Wartung ist nicht automatisch unproblematisch.

Auch geplante Arbeiten können die Benutzererfahrung verschlechtern, wenn sie schlecht kommuniziert oder schlecht geplant sind.

Teilausfälle

Nicht jeder Ausfall betrifft den gesamten Service.

Beispiele:

Für Teilausfälle muss festgelegt werden, wie sie bewertet werden.

Sonst wird Servicequalität zu positiv oder zu negativ dargestellt.

Reaktionszeit

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

Zu klären ist:

Eine automatische Antwort sollte nicht als echte Reaktion gewertet werden, wenn keine Bearbeitung beginnt.

Wiederherstellungszeit

Wiederherstellungszeit beschreibt, wann ein Service wieder nutzbar ist.

Das kann bedeuten:

Wichtig ist, den Begriff vorher zu definieren.

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

Lösungszeit

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

Sie unterscheidet sich von Wiederherstellungszeit.

Beispiel:

Ein Incident wird durch Workaround schnell behoben.

Das zugrunde liegende Problem wird erst später durch einen Change dauerhaft gelöst.

Dann sind Wiederherstellung und endgültige Lösung unterschiedliche Zeitpunkte.

MTTA, MTTR und ähnliche Kennzahlen

Häufig genutzte Kennzahlen:

Kennzahl Bedeutung
MTTA durchschnittliche Zeit bis zur Annahme oder Reaktion
MTTR durchschnittliche Zeit bis Wiederherstellung oder Lösung
MTBF durchschnittliche Zeit zwischen Ausfällen
MTRS durchschnittliche Zeit bis Service-Wiederherstellung
FCR First Contact Resolution, Lösung beim ersten Kontakt

Wichtig:

Abkürzungen müssen in der Organisation einheitlich definiert werden.

MTTR kann je nach Organisation „Mean Time to Repair“, „Mean Time to Restore“ oder anders verstanden werden.

Incident-Kennzahlen

Mögliche Incident-Kennzahlen:

Wichtig ist die Kombination.

Eine einzelne Incident-Kennzahl erklärt selten die ganze Situation.

Problem-Kennzahlen

Mögliche Problem-Kennzahlen:

Problem-Kennzahlen helfen, strukturelle Ursachen sichtbar zu machen.

Sie sollten nicht dazu führen, Problems vorschnell zu schließen.

Change-Kennzahlen

Mögliche Change-Kennzahlen:

Change-Kennzahlen helfen, Stabilität und Veränderungsfähigkeit zu bewerten.

Request-Kennzahlen

Mögliche Request-Kennzahlen:

Diese Kennzahlen helfen, Serviceportale, Formulare und Automatisierung zu verbessern.

Knowledge-Kennzahlen

Mögliche Knowledge-Kennzahlen:

Knowledge-Kennzahlen zeigen, ob Wissen im Alltag hilft oder nur abgelegt wird.

Benutzerzufriedenheit

Benutzerzufriedenheit ergänzt technische Kennzahlen.

Mögliche Methoden:

Wichtig:

Zufriedenheit ist subjektiv, aber trotzdem wertvoll.

Sie zeigt, ob gemessene Servicequalität auch so erlebt wird.

Experience Level

Neben klassischen Service Levels kann auch die Benutzererfahrung betrachtet werden.

Beispiele:

Technische Ziele allein zeigen nicht immer die tatsächliche Nutzungserfahrung.

Reporting

Reporting stellt Kennzahlen und Bewertungen verständlich dar.

Ein Report sollte nicht nur Zahlen zeigen.

Er sollte erklären:

Ein guter Report führt zu Handlung, nicht nur zu Ablage.

Zielgruppen für Reporting

Verschiedene Zielgruppen benötigen unterschiedliche Reports.

Zielgruppe benötigt typischerweise
Management Risiken, Trends, Zielerreichung, Entscheidungen
Service Owner Servicequalität, Abweichungen, Maßnahmen
Service Desk Tickettrends, Knowledge-Lücken, Eskalationen
Fachteam technische Ursachen, Changes, Problems
Security Team Schwachstellen, kritische CIs, Vorfälle
Benutzer Status, einfache Verfügbarkeit, bekannte Störungen

Nicht jeder Report muss alle Details enthalten.

Management-Reporting

Management benötigt meist verdichtete Informationen.

Geeignete Inhalte:

Management-Reports sollten nicht mit technischen Details überladen werden.

Sie müssen entscheidungsfähig machen.

Operatives Reporting

Operative Teams benötigen mehr Detail.

Geeignete Inhalte:

Operatives Reporting hilft bei Analyse und Verbesserung der täglichen Arbeit.

Benutzerorientiertes Reporting

Benutzer benötigen klare und einfache Informationen.

Beispiele:

Benutzer brauchen keine internen Detailberichte.

Sie brauchen verständliche Orientierung.

Dashboards

Dashboards zeigen aktuelle oder regelmäßige Informationen auf einen Blick.

Mögliche Inhalte:

Ein Dashboard muss gepflegt und richtig interpretiert werden.

Ein grünes Dashboard bedeutet nicht automatisch, dass Benutzer zufrieden sind.

Ampelstatus

Viele Reports nutzen Ampelfarben.

Beispiel:

Status Bedeutung
grün Ziel erreicht
gelb Risiko oder leichte Abweichung
rot Ziel verfehlt oder kritisches Risiko

Wichtig:

Ampeln brauchen klare Regeln.

Ungeeignet:

Gelb nach Bauchgefühl.

Besser:

Gelb, wenn Zielwert um bis zu 10 Prozent verfehlt wird oder ein Risiko für den nächsten Zeitraum besteht.

Ein einzelner Monatswert reicht oft nicht aus.

Wichtiger sind Trends.

Beispiele:

Durchschnittswerte vorsichtig nutzen

Durchschnittswerte können täuschen.

Beispiel:

Die durchschnittliche Lösungszeit beträgt 4 Stunden.

Mögliche Realität:

Deshalb sollten Durchschnittswerte ergänzt werden durch:

Median und Perzentile

Der Median zeigt den mittleren Wert einer Verteilung.

Perzentile zeigen, wie viele Fälle unter einem bestimmten Wert liegen.

Beispiel:

Das ist oft aussagekräftiger als nur ein Durchschnittswert.

Kontext zu Kennzahlen

Kennzahlen brauchen Kontext.

Beispiel:

Ticketvolumen steigt.

Mögliche Ursachen:

Ohne Kontext kann eine Kennzahl falsch interpretiert werden.

Datenqualität im Reporting

Reports sind nur so gut wie ihre Daten.

Typische Datenprobleme:

Datenqualität muss regelmäßig geprüft werden.

Messung kann Verhalten beeinflussen

Kennzahlen beeinflussen, wie Menschen arbeiten.

Beispiele:

Kennzahlen müssen so gewählt werden, dass sie gutes Verhalten fördern.

Falsche Anreize vermeiden

Besser ist eine Kombination von Kennzahlen.

Beispiele:

Kombination besser als
Lösungszeit und Wiedereröffnungsquote nur schnelle Lösung
Ticketanzahl und Benutzerzufriedenheit nur Produktivität
SLA-Erfüllung und Major-Incident-Analyse nur grüne Ampel
Change-Erfolg und Incidents nach Changes nur Anzahl Changes
Knowledge-Nutzung und Artikelbewertung nur Anzahl Artikel

Gute Kennzahlensets betrachten Qualität, Wirkung und Stabilität gemeinsam.

Reporting-Frequenz

Die Frequenz hängt vom Zweck ab.

Report mögliche Frequenz
Live-Dashboard für Betrieb laufend
Major-Incident-Status während Ereignis regelmäßig
Service-Level-Report monatlich
Service Review monatlich oder quartalsweise
Lieferantenreport monatlich oder quartalsweise
Managementreport monatlich oder quartalsweise
Datenqualitätsreport regelmäßig nach Bedarf

Zu häufige Reports ohne Handlung erzeugen Aufwand.

Zu seltene Reports erkennen Probleme zu spät.

Reporting und Service Review

Reports sollten Service Reviews vorbereiten.

Ein Service Review nutzt Reports, um zu besprechen:

Reporting liefert Daten.

Service Review macht daraus Bewertung und Handlung.

SLA-Abweichungen berichten

Bei SLA-Abweichungen sollte ein Report enthalten:

Nur „SLA nicht erreicht“ reicht nicht aus.

Beispiel: SLA-Abweichung

Ziel

P1-Incidents innerhalb von 4 Stunden wiederherstellen.

Ergebnis

Ziel wurde in einem Fall verfehlt.

Ursache

Datenbankproblem wurde zu spät an das zuständige Team eskaliert.

Auswirkung

Mitarbeiterportal war für mehrere Standorte nicht nutzbar.

Maßnahme

OLA-Eskalation wird angepasst.

Service Desk erhält neuen Knowledge-Artikel.

Monitoringalarm wird geändert.

Serviceverbesserung aus Kennzahlen ableiten

Kennzahlen sollen Verbesserungen auslösen.

Beispiele:

Die wichtigste Frage lautet:

Welche konkrete Handlung folgt aus dem Report?

Kennzahlen für Continual Improvement

Continual Improvement nutzt Kennzahlen zur Priorisierung.

Hilfreich sind:

Nicht jede schlechte Kennzahl ist sofort höchste Priorität.

Die Bedeutung hängt von Servicekritikalität und Auswirkung ab.

Praxisbeispiel: Grüne SLA, unzufriedene Benutzer

Situation

SLA-Verfügbarkeit wurde erreicht.

Trotzdem sind Benutzer unzufrieden.

Analyse

Erkenntnis

Verfügbarkeit allein misst nicht die Benutzererfahrung.

Verbesserung

Performance-Ziel und Benutzerfeedback werden ergänzt.

Praxisbeispiel: Ticketzahlen steigen

Situation

Ticketanzahl im Service Desk steigt stark.

Mögliche Ursachen

Vorgehen

Tickets nach Service, Kategorie, Priorität und Ursache auswerten.

Nicht vorschnell annehmen, dass der Service Desk schlechter arbeitet.

Praxisbeispiel: Lieferant erfüllt Ziel nicht

Situation

SLA-Abweichungen entstehen durch langsame Lieferantenreaktion.

Reporting zeigt

Verbesserung

Supplier Review durchführen.

Underpinning Contract prüfen.

Internes SLA realistisch bewerten.

Praxisbeispiel: Knowledge-Lücke

Situation

Viele Benutzer suchen im Portal nach „neues Handy MFA“.

Es gibt keinen passenden Treffer.

Folge

Viele Tickets entstehen.

Verbesserung

Benutzerartikel „MFA auf neuem Smartphone einrichten“ erstellen.

Suchbegriffe ergänzen.

Ticketformular verlinken.

Messung

Suchtreffer, Artikelbewertung und Ticketvolumen nach Verbesserung prüfen.

Typische Fehler

Fehler 1

Es werden zu viele Kennzahlen ohne klare Entscheidung gemessen.

Fehler 2

Kennzahlen sind technisch korrekt, aber für den Service nicht relevant.

Fehler 3

Messmethoden sind nicht definiert.

Fehler 4

Reports enthalten Zahlen ohne Bewertung.

Fehler 5

Durchschnittswerte verdecken kritische Einzelfälle.

Fehler 6

Benutzerzufriedenheit wird ignoriert.

Fehler 7

Datenqualität in Tickets und CMDB ist schlecht.

Fehler 8

Automatische Antworten werden als echte Reaktion gezählt.

Fehler 9

SLA-Abweichungen werden nur gemeldet, aber nicht analysiert.

Fehler 10

Kennzahlen erzeugen falsche Anreize.

Fehler 11

Reports sind nicht auf Zielgruppen angepasst.

Fehler 12

Aus Reports entstehen keine Verbesserungsmaßnahmen.

Checkliste Kennzahl auswählen

Checkliste Messmethode

Checkliste Reporting

Checkliste SLA-Abweichung analysieren

Checkliste Datenqualität für Reports

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker liefern viele Daten, die für Service Level Management wichtig sind.

Im Arbeitsalltag bedeutet das:

Gute Messung hilft, technische Arbeit sichtbar und steuerbar zu machen.

Zusammenfassung

Serviceziele verstehen
↓
passende Kennzahlen auswählen
↓
Messmethode eindeutig definieren
↓
Datenquellen und Datenqualität sichern
↓
technische und Benutzerperspektive kombinieren
↓
Ergebnisse verständlich berichten
↓
Abweichungen analysieren
↓
Trends erkennen
↓
Verbesserungsmaßnahmen ableiten
↓
Wirkung erneut messen

Merksätze

Eine Kennzahl ist nur sinnvoll, wenn daraus eine Entscheidung oder Verbesserung entstehen kann.

Messmethode und Datenquelle müssen klar sein.

Technische Verfügbarkeit ist nicht automatisch gute Servicequalität.

Durchschnittswerte können kritische Probleme verdecken.

Reports brauchen Kontext, Bewertung und Maßnahmen.

Kennzahlen können Verhalten beeinflussen und falsche Anreize erzeugen.

Reporting ist die Grundlage für Service Reviews und Continual Improvement.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

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

8.4 Service Reviews und Continual Improvement

Kurz erklärt

Service Reviews bewerten regelmäßig, wie gut ein IT-Service seine vereinbarten Ziele erfüllt und ob er den erwarteten Nutzen liefert.

Dabei werden nicht nur SLA-Werte betrachtet.

Auch Incidents, Problems, Changes, Benutzerfeedback, Risiken, Lieferantenleistungen und Verbesserungspotenziale gehören dazu.

Continual Improvement sorgt anschließend dafür, dass aus Erkenntnissen konkrete und überprüfbare Verbesserungen entstehen.

Warum Service Reviews wichtig sind

Ein Report allein verbessert keinen Service.

Kennzahlen zeigen beispielsweise:

Ein Service Review bewertet zusätzlich:

Ein Service Review verbindet Daten mit Bewertung, Verantwortung und Handlung.

Was ist ein Service Review?

Ein Service Review ist eine regelmäßige strukturierte Betrachtung eines Service.

Dabei wird gemeinsam geprüft:

Service Reviews können je nach Kritikalität und Organisation:

stattfinden.

Ziele eines Service Reviews

Ein Service Review soll:

Das Review sollte nicht nur rückwärts schauen.

Es sollte auch kommende Risiken und Veränderungen betrachten.

Service Review ist keine reine Zahlenbesprechung

Ein häufiger Fehler:

Im Service Review werden nur Diagramme und SLA-Werte vorgelesen.

Das reicht nicht aus.

Ein gutes Service Review beantwortet:

Merke

Reporting liefert Informationen.

Das Service Review bewertet diese Informationen und löst Entscheidungen aus.

Teilnehmer eines Service Reviews

Mögliche Teilnehmer:

Nicht jedes Review benötigt alle Rollen.

Die Teilnehmer sollten zum Service und zu den aktuellen Themen passen.

Rolle des Service Owners

Der Service Owner trägt eine zentrale Verantwortung.

Typische Aufgaben:

Der Service Owner muss nicht jede technische Einzelheit kennen.

Er muss aber verstehen, welche Auswirkungen technische Themen auf den Service haben.

Rolle des Service Level Managers

Der Service Level Manager unterstützt durch:

Die Rolle kann je nach Organisation anders benannt oder verteilt sein.

Rolle des Service Desk

Der Service Desk liefert wichtige Praxiserkenntnisse.

Beispiele:

Der Service Desk kennt oft die tatsächliche Benutzerwahrnehmung besser als rein technische Reports.

Rolle der technischen Teams

Technische Teams liefern Informationen zu:

Technische Informationen sollten so erklärt werden, dass ihre Servicewirkung verständlich ist.

Rolle des Fachbereichs oder Kunden

Fachbereiche und Kunden liefern die Geschäftsperspektive.

Wichtige Fragen:

Servicequalität darf nicht nur aus IT-Sicht bewertet werden.

Vorbereitung eines Service Reviews

Vor dem Review sollten relevante Informationen gesammelt werden.

Mögliche Inhalte:

Die Vorbereitung sollte sich auf wichtige Themen konzentrieren.

Ein unübersichtlicher Datenberg erschwert Entscheidungen.

Mögliche Agenda

Eine kompakte Agenda kann so aussehen:

  1. Servicezustand und wichtige Entwicklungen
  2. Zielerreichung und SLA-Abweichungen
  3. Benutzer- und Kundenfeedback
  4. wichtige Incidents und Major Incidents
  5. offene Problems und Known Errors
  6. Changes und Releases
  7. Lieferantenleistung
  8. Risiken und kommende Anforderungen
  9. Verbesserungsmaßnahmen
  10. Entscheidungen, Owner und Termine

Die Agenda sollte an den Service angepasst werden.

Servicezustand bewerten

Zu Beginn sollte ein Gesamtbild entstehen.

Mögliche Fragen:

Ein Gesamtbild hilft, einzelne Kennzahlen richtig einzuordnen.

SLA-Erfüllung bewerten

Zu prüfen ist:

Eine Zielverfehlung muss nicht automatisch bedeuten, dass das Ziel falsch ist.

Aber sie muss verstanden werden.

Erreichte Ziele kritisch betrachten

Auch grüne Kennzahlen sollten hinterfragt werden.

Beispiele:

Ein grünes Dashboard ist kein Beweis für einen guten Service.

Benutzerfeedback einbeziehen

Benutzerfeedback kann stammen aus:

Zu prüfen ist:

Qualitatives Feedback ergänzt Kennzahlen.

Incidents betrachten

Im Service Review sollten nicht alle Incidents einzeln besprochen werden.

Wichtig sind:

Ziel ist, Muster und Verbesserungsmöglichkeiten zu erkennen.

Major Incidents betrachten

Bei Major Incidents sollte geprüft werden:

Ein Major-Incident-Review kann Teil eines Service Reviews sein oder separat stattfinden.

Problems und Known Errors betrachten

Wichtige Fragen:

Häufig genutzte Workarounds sind ein Warnsignal.

Changes betrachten

Zu prüfen ist:

Changes beeinflussen Servicequalität direkt.

Releases betrachten

Bei Releases sind wichtig:

Ein technisch erfolgreiches Deployment kann aus Benutzersicht trotzdem unzureichend sein.

Lieferantenleistung betrachten

Bei externen Abhängigkeiten sollte geprüft werden:

Lieferantenprobleme dürfen nicht einfach als unveränderlich hingenommen werden.

Risiken betrachten

Mögliche Servicerisiken:

Risiken sollten mit Auswirkung, Wahrscheinlichkeit, Owner und Maßnahme dokumentiert werden.

Kommende Anforderungen betrachten

Ein Service Review sollte auch nach vorne schauen.

Beispiele:

So können notwendige Changes und Kapazitäten frühzeitig geplant werden.

Continual Improvement

Continual Improvement bedeutet, Services, Practices, Prozesse, Werkzeuge und Arbeitsweisen fortlaufend zu verbessern.

Verbesserungen können klein oder groß sein.

Beispiele:

Nicht jede Verbesserung benötigt ein großes Projekt.

Continual Improvement ist keine einmalige Maßnahme

Ein häufiger Irrtum:

Nach einem Verbesserungsprojekt ist der Service dauerhaft optimiert.

Services verändern sich ständig.

Gründe:

Deshalb ist Continual Improvement ein fortlaufender Kreislauf.

Verbesserungskreislauf

Ein möglicher Ablauf:

aktuelle Situation verstehen
        ↓
Zielzustand festlegen
        ↓
Verbesserungspotenzial erkennen
        ↓
Maßnahme priorisieren
        ↓
Umsetzung planen
        ↓
Verbesserung durchführen
        ↓
Wirkung messen
        ↓
Ergebnis bewerten
        ↓
nächste Verbesserung auswählen

Wichtig ist, nach der Umsetzung zu prüfen, ob die gewünschte Wirkung tatsächlich erreicht wurde.

Improvement Register

Ein Improvement Register sammelt Verbesserungsideen und Maßnahmen.

Mögliche Felder:

Das Improvement Register kann in einem ITSM-System, Projekttool, Wiki oder einer strukturierten Liste geführt werden.

Warum ein Improvement Register wichtig ist

Ohne zentrale Nachverfolgung entstehen typische Probleme:

Das Register schafft Transparenz und Verantwortung.

Verbesserungsideen erfassen

Verbesserungsideen können entstehen aus:

Jede Idee sollte kurz beschreiben:

Verbesserungen priorisieren

Nicht alle Verbesserungen können gleichzeitig umgesetzt werden.

Mögliche Kriterien:

Eine einfache Maßnahme mit hohem Nutzen kann vor einem großen Projekt sinnvoll sein.

Nutzen und Aufwand vergleichen

Eine einfache Bewertung kann helfen:

Nutzen Aufwand mögliche Priorität
hoch niedrig sehr hoch
hoch hoch strategisch bewerten
niedrig niedrig bei Gelegenheit
niedrig hoch meist geringe Priorität

Diese Matrix ist nur ein Beispiel.

Sicherheits- oder Compliance-Themen können unabhängig vom Aufwand hohe Priorität besitzen.

Erfolgskriterien für Verbesserungen

Vor Umsetzung sollte klar sein, woran Erfolg erkannt wird.

Beispiele:

Verbesserung Erfolgskriterium
Knowledge-Artikel verbessern weniger Tickets und bessere Bewertungen
Monitoring erweitern Fehler wird vor Benutzerbeschwerden erkannt
OLA anpassen Eskalationszeit sinkt
Self-Service einführen Standardrequests werden schneller erfüllt
Zertifikatsmonitoring einführen keine ungeplanten Ausfälle durch Ablauf
Change-Checkliste ergänzen weniger Incidents nach Changes

Ohne Erfolgskriterien bleibt unklar, ob die Verbesserung wirksam war.

Kleine Verbesserungen

Kleine Verbesserungen können schnell Wirkung zeigen.

Beispiele:

Solche Verbesserungen sollten nicht unnötig durch große Prozesse verzögert werden.

Größere Verbesserungen

Größere Maßnahmen können sein:

Solche Maßnahmen benötigen oft:

Verbesserung und Change Enablement

Viele Verbesserungen werden durch Changes umgesetzt.

Beispiele:

Continual Improvement erkennt und priorisiert den Verbesserungsbedarf.

Change Enablement sorgt für kontrollierte Umsetzung.

Verbesserung und Problem Management

Problem Management liefert Ursachen und dauerhafte Lösungsvorschläge.

Beispiele:

Diese Erkenntnisse können als Improvement erfasst und priorisiert werden.

Verbesserung und Knowledge Management

Knowledge Management kann verbessert werden durch:

Wissen ist häufig eine schnelle und kostengünstige Verbesserungsmöglichkeit.

Verbesserung und Service Configuration Management

Configuration-Daten können verbessert werden durch:

Gute Configuration-Daten verbessern Incident, Problem, Change und Security Management.

Verbesserung und Supplier Management

Lieferantenverbesserungen können sein:

Lieferantenleistung ist Teil der gesamten Servicequalität.

Verbesserungen verfolgen

Jede wichtige Maßnahme sollte mindestens besitzen:

Ungeeignet:

Monitoring verbessern.

Besser:

Bis zum 30.09.2026 Zertifikatsmonitoring für alle produktiven Webservices einführen. Erfolg: Warnung mindestens 30 Tage vor Ablauf, Owner je Zertifikat dokumentiert.

Status von Verbesserungen

Mögliche Status:

Ein klarer Status erleichtert Nachverfolgung.

Blockierte Verbesserungen

Verbesserungen können blockiert sein durch:

Blockierungen sollten sichtbar sein.

Zu dokumentieren ist:

Wirkung messen

Nach Umsetzung muss geprüft werden:

Eine umgesetzte Maßnahme ist nicht automatisch eine erfolgreiche Verbesserung.

Verbesserung schließen

Eine Verbesserung sollte erst geschlossen werden, wenn:

Wenn die Wirkung noch nicht messbar ist, kann der Status „Wirkung wird geprüft“ sinnvoll sein.

Service Review dokumentieren

Ein Service Review sollte dokumentieren:

Die Dokumentation sollte kompakt und handlungsorientiert sein.

Entscheidungen dokumentieren

Wichtige Entscheidungen können sein:

Zu jeder Entscheidung sollte nachvollziehbar sein:

Maßnahmenprotokoll

Ein einfaches Maßnahmenprotokoll:

Maßnahme Owner Termin Status Erfolgskriterium
VPN-Known-Error aktualisieren Netzwerkteam 15.08.2026 offen Service Desk findet Artikel
Zertifikatsmonitoring einführen Plattformteam 30.09.2026 geplant Warnung 30 Tage vor Ablauf
OLA-Eskalation anpassen Service Level Manager 31.08.2026 in Arbeit kürzere P1-Eskalationszeit

Ein Maßnahmenprotokoll verhindert, dass Entscheidungen nach dem Review verloren gehen.

Folgereview

Im nächsten Service Review sollte geprüft werden:

Ohne Folgereview verlieren Maßnahmen schnell an Verbindlichkeit.

Praxisbeispiel: Wiederkehrende VPN-Incidents

Beobachtung

VPN-Incidents steigen über drei Monate.

Service Review

Verbesserung

Erfolgskriterium

VPN-Incidents sinken innerhalb von vier Wochen deutlich.

Praxisbeispiel: SLA erfüllt, Benutzer unzufrieden

Beobachtung

Verfügbarkeitsziel wurde erreicht.

Benutzer melden trotzdem schlechte Performance.

Service Review

Verbesserung

Praxisbeispiel: Lieferantenproblem

Beobachtung

Mehrere SLA-Abweichungen entstehen durch langsame Herstellerreaktion.

Service Review

Verbesserung

Praxisbeispiel: Major Incident

Review-Erkenntnisse

Verbesserungen

Praxisbeispiel: Self-Service verbessern

Beobachtung

Viele Tickets entstehen zur MFA-Einrichtung.

Analyse

Verbesserungen

Erfolgskriterium

Weniger MFA-Standardtickets und bessere Artikelbewertung.

Typische Fehler

Fehler 1

Service Reviews bestehen nur aus dem Vorlesen von Kennzahlen.

Fehler 2

Es nehmen zu viele Personen ohne klare Rolle teil.

Fehler 3

Benutzer- und Fachbereichsfeedback fehlt.

Fehler 4

Grüne Kennzahlen werden nicht kritisch hinterfragt.

Fehler 5

SLA-Abweichungen werden erklärt, aber keine Maßnahmen beschlossen.

Fehler 6

Maßnahmen besitzen keinen Owner.

Fehler 7

Verbesserungen besitzen kein Erfolgskriterium.

Fehler 8

Lessons Learned werden nicht verfolgt.

Fehler 9

Lieferantenleistung wird getrennt vom Service betrachtet.

Fehler 10

Reviews schauen nur zurück und nicht auf kommende Risiken.

Fehler 11

Umgesetzte Maßnahmen werden nicht auf Wirkung geprüft.

Fehler 12

Verbesserungsideen gehen außerhalb eines Registers verloren.

Checkliste Service Review vorbereiten

Checkliste Service Review durchführen

Checkliste Improvement Register

Checkliste Wirkung prüfen

Checkliste Maßnahmenverfolgung

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker liefern wichtige technische Erkenntnisse für Service Reviews und Continual Improvement.

Im Arbeitsalltag bedeutet das:

Technische Verbesserung ist besonders wertvoll, wenn sie messbar zu stabileren Services und besserer Benutzerunterstützung führt.

Zusammenfassung

Serviceleistung und Benutzerfeedback sammeln
↓
Service Review vorbereiten
↓
Ziele, Abweichungen und Risiken bewerten
↓
Incidents, Problems, Changes und Lieferanten betrachten
↓
Verbesserungen identifizieren
↓
Nutzen, Risiko und Aufwand bewerten
↓
Maßnahmen priorisieren
↓
Owner, Termin und Erfolgskriterien festlegen
↓
Verbesserung kontrolliert umsetzen
↓
Wirkung messen
↓
Ergebnis im nächsten Service Review prüfen

Merksätze

Ein Service Review macht aus Reporting konkrete Entscheidungen.

Grüne Kennzahlen bedeuten nicht automatisch gute Servicequalität.

Benutzerfeedback gehört genauso zum Review wie technische Messwerte.

Jede wichtige Verbesserung braucht Owner, Termin und Erfolgskriterium.

Eine umgesetzte Maßnahme ist erst erfolgreich, wenn ihre Wirkung geprüft wurde.

Continual Improvement besteht aus vielen kleinen und großen Verbesserungen.

Reviews müssen auch kommende Risiken und Anforderungen betrachten.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

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

8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management

Kurz erklärt

Service Level Management kann Servicequalität nicht allein steuern.

Es benötigt Informationen aus Incident Management, Problem Management, Change Enablement, Service Configuration Management, Knowledge Management, Supplier Management sowie Measurement and Reporting.

Gleichzeitig liefert Service Level Management Ziele, Prioritäten und Anforderungen zurück, an denen diese Practices ihre Arbeit ausrichten können.

Erst durch dieses Zusammenspiel werden Servicequalität, Risiken und Verbesserungsbedarf aus Sicht der Benutzer und des Geschäfts sichtbar.

Warum das Zusammenspiel wichtig ist

Ein Service Level beschreibt, welche Qualität ein Service erreichen soll.

Ob diese Qualität tatsächlich erreicht wird, hängt jedoch von vielen Bereichen ab.

Beispiele:

Service Level Management verbindet diese Informationen mit den vereinbarten Servicezielen.

Grundidee des Zusammenspiels

Serviceziele und Erwartungen festlegen
        ↓
Service Level Management definiert messbare Ziele
        ↓
Incident Management liefert Störungs- und Wiederherstellungsdaten
        ↓
Problem Management untersucht wiederkehrende Ursachen
        ↓
Change Enablement setzt Verbesserungen kontrolliert um
        ↓
Service Configuration Management zeigt Abhängigkeiten
        ↓
Knowledge Management stellt nutzbares Wissen bereit
        ↓
Supplier Management bewertet externe Beiträge
        ↓
Measurement and Reporting zeigt Ergebnisse und Trends
        ↓
Service Review bewertet Abweichungen und Risiken
        ↓
Continual Improvement verfolgt Verbesserungen

Die Practices arbeiten nicht nacheinander in einer festen Reihenfolge.

Sie tauschen fortlaufend Informationen aus.

Service Level Management und Incident Management

Incident Management liefert wichtige Informationen darüber, wie stabil und zuverlässig ein Service im Alltag funktioniert.

Relevante Informationen:

Diese Daten helfen zu prüfen, ob vereinbarte Serviceziele erreicht werden.

Was Service Level Management an Incident Management liefert

Service Level Management unterstützt Incident Management durch:

Dadurch weiß Incident Management, welche Incidents besonders schnell und intensiv bearbeitet werden müssen.

Service Level und Incident-Priorität

Die Priorität eines Incidents sollte nicht allein von der Lautstärke eines Benutzers oder der technischen Komplexität abhängen.

Zu berücksichtigen sind:

Beispiel:

Ein technisch kleiner Fehler kann hohe Priorität besitzen, wenn ein geschäftskritischer Prozess vollständig blockiert wird.

Reaktionszeit im Incident Management

Service Level Management definiert möglicherweise ein Reaktionsziel.

Incident Management muss dafür nachvollziehbar erfassen:

Eine automatische Eingangsbestätigung sollte nicht mit einer qualifizierten Bearbeitung verwechselt werden.

Wiederherstellung und dauerhafte Lösung unterscheiden

Incident Management konzentriert sich auf die schnelle Wiederherstellung des Service.

Service Level Management kann deshalb ein Ziel für die Wiederherstellungszeit besitzen.

Beispiel:

Ein Workaround macht Benutzer nach zwei Stunden wieder arbeitsfähig.

Die dauerhafte Lösung erfolgt erst eine Woche später durch einen Change.

Dann gilt:

Diese Zeitpunkte sollten getrennt gemessen werden.

SLA-Verletzung durch Incident

Wenn ein Incident zu einer SLA-Verletzung führt, sollte geprüft werden:

Eine SLA-Verletzung ist häufig nicht nur ein technisches Ereignis.

Sie kann auch organisatorische Ursachen besitzen.

Beispiel: verspätete Eskalation

Situation

Ein geschäftskritischer Service fällt aus.

SLA-Ziel

Wiederherstellung innerhalb von vier Stunden.

Problem

Der Service Desk eskaliert erst nach zwei Stunden an das zuständige Fachteam.

Folge

Das Wiederherstellungsziel wird verfehlt.

Analyse

Verbesserungen

Service Level Management und Problem Management

Problem Management untersucht Ursachen wiederkehrender oder schwerwiegender Incidents.

Service Level Management hilft dabei, Problems zu priorisieren.

Relevante Kriterien:

Ein Problem kann hohe Priorität besitzen, auch wenn aktuell kein Incident offen ist.

Was Problem Management an Service Level Management liefert

Problem Management liefert:

Diese Informationen helfen, Servicequalität und zukünftige Risiken realistisch zu bewerten.

Häufige Workarounds als Service-Level-Risiko

Ein Workaround kann die Wiederherstellung beschleunigen.

Wenn er jedoch ständig genutzt wird, kann dies auf ein ungelöstes Problem hinweisen.

Zu prüfen ist:

Ein erreichtes SLA bedeutet nicht automatisch, dass der Service gesund ist.

Beispiel: Dienstneustart als Workaround

Situation

Ein Anwendungsdienst fällt regelmäßig aus.

Workaround

Der Service Desk veranlasst einen Neustart.

Kennzahl

Die Wiederherstellungszeit bleibt innerhalb des SLA.

Tatsächliches Problem

Verbesserung

Problem Record priorisieren und dauerhafte Lösung über Change Enablement umsetzen.

Problem-Priorisierung nach Servicewirkung

Problem Management sollte nicht nur technische Schwere betrachten.

Wichtige Fragen:

Service Level Management liefert dafür die geschäftliche und servicebezogene Perspektive.

Service Level Management und Change Enablement

Changes können Servicequalität verbessern oder verschlechtern.

Beispiele:

Service Level Management hilft zu bewerten, welche Serviceziele durch einen Change beeinflusst werden.

Was Service Level Management an Change Enablement liefert

Für die Change-Bewertung sind wichtig:

Dadurch kann ein Change nicht nur technisch, sondern auch servicebezogen bewertet werden.

Was Change Enablement an Service Level Management liefert

Change Enablement liefert:

Diese Informationen gehören in Service Reviews und Service-Level-Berichte.

Geplante Wartung und Service Levels

Geplante Wartung muss klar geregelt sein.

Zu prüfen ist:

Nicht jede angekündigte Unterbrechung darf automatisch aus der Messung ausgeschlossen werden.

Die Regeln müssen vorher vereinbart sein.

Change Freeze und kritische Geschäftszeiten

Service Level Management hilft zu erkennen, wann Changes besonders riskant sind.

Beispiele:

In solchen Zeiträumen kann ein Change Freeze oder eine besonders strenge Bewertung sinnvoll sein.

Emergency Changes können trotzdem notwendig sein.

Sie benötigen dann eine bewusste Risikoentscheidung.

Changes zur Verbesserung von Service Levels

Wenn Serviceziele regelmäßig verfehlt werden, können Changes notwendig sein.

Beispiele:

Service Level Management beschreibt den Verbesserungsbedarf.

Change Enablement steuert die kontrollierte Umsetzung.

Beispiel: Performance-Ziel wird verfehlt

Beobachtung

Das Mitarbeiterportal ist verfügbar, reagiert aber zu langsam.

Service Review

Das vereinbarte Performance-Ziel wird regelmäßig verfehlt.

Analyse

Changes

Erfolgskriterium

Die wichtigsten Benutzeraktionen liegen wieder innerhalb des vereinbarten Zielwerts.

Service Level Management und Service Configuration Management

Service Configuration Management zeigt, wie ein Service technisch und organisatorisch aufgebaut ist.

Wichtige Informationen:

Diese Informationen sind notwendig, um Service Levels realistisch festzulegen und Risiken zu verstehen.

Warum Serviceabhängigkeiten für SLAs wichtig sind

Ein Service kann nur so zuverlässig sein wie seine kritischen Abhängigkeiten.

Beispiel:

Das Mitarbeiterportal hängt ab von:

Ein hohes Verfügbarkeitsziel ist unrealistisch, wenn eine kritische Abhängigkeit deutlich schwächere Ziele oder keine Redundanz besitzt.

Configuration-Daten für SLA-Planung

Zu prüfen ist:

Diese Informationen helfen, Serviceziele realistisch zu gestalten.

Service Level Management verbessert Configuration Management

Service Reviews können Datenqualitätsprobleme sichtbar machen.

Beispiele:

Solche Erkenntnisse sollten in die Pflege der Configuration-Daten einfließen.

Beispiel: unbekannte Abhängigkeit

Situation

Ein interner Service verfehlt sein Verfügbarkeitsziel.

Analyse

Der Service hängt von einer externen API ab.

Diese Beziehung war in der CMDB nicht dokumentiert.

Folgen

Verbesserungen

Service Level Management und Knowledge Management

Knowledge Management beeinflusst Reaktions- und Wiederherstellungszeiten.

Gutes Wissen kann:

Knowledge Management trägt damit direkt zur Servicequalität bei.

Was Service Level Management an Knowledge Management liefert

Service Level Management zeigt, bei welchen Services und Themen Wissen besonders wichtig ist.

Beispiele:

Daraus können neue oder verbesserte Knowledge-Artikel entstehen.

Was Knowledge Management an Service Level Management liefert

Knowledge Management liefert:

Diese Informationen helfen zu verstehen, warum bestimmte Serviceziele erreicht oder verfehlt werden.

Beispiel: lange Wiederherstellungszeit

Beobachtung

DNS-Incidents werden regelmäßig zu spät gelöst.

Analyse

Verbesserungen

Erwartete Wirkung

Kürzere Erstdiagnose und schnellere Wiederherstellung.

Service Level Management und Supplier Management

Viele Services hängen von externen Lieferanten ab.

Beispiele:

Supplier Management sorgt dafür, dass Lieferantenleistungen die vereinbarten Serviceziele unterstützen.

Was Service Level Management an Supplier Management liefert

Supplier Management benötigt:

Daraus können geeignete Lieferantenverträge und Leistungsziele abgeleitet werden.

Was Supplier Management an Service Level Management liefert

Supplier Management liefert:

Diese Informationen gehören in Service Reviews.

Lieferantenvertrag und internes SLA abstimmen

Ein internes SLA darf nicht stärker sein als die tatsächlich verfügbare Unterstützung, sofern keine eigenen Schutzmaßnahmen bestehen.

Beispiel:

Internes Ziel

Wiederherstellung innerhalb von vier Stunden.

Lieferantenvertrag

Hersteller reagiert innerhalb eines Arbeitstages.

Mögliche Lösungen:

Service Level Management und Monitoring and Event Management

Monitoring liefert technische und servicebezogene Messdaten.

Beispiele:

Service Level Management definiert, welche Serviceeigenschaften gemessen werden müssen.

Monitoring aus Serviceperspektive

Unzureichend:

Webserver antwortet auf Ping.

Besser:

Ein Service kann technisch „grün“ erscheinen, obwohl Benutzer nicht arbeiten können.

Monitoring und Messmethode abstimmen

Zu klären ist:

Monitoring muss zu den vereinbarten Zielen passen.

Service Level Management und Measurement and Reporting

Measurement and Reporting bereitet Daten so auf, dass Servicequalität bewertet werden kann.

Service Level Management liefert dafür:

Measurement and Reporting liefert:

Reporting braucht Kontext aus anderen Practices

Eine Zahl allein erklärt nicht, warum ein Ziel verfehlt wurde.

Beispiel:

Verfügbarkeit beträgt 98,9 Prozent statt 99,5 Prozent.

Für eine sinnvolle Bewertung werden zusätzliche Informationen benötigt:

Reporting verbindet diese Informationen.

Service Level Management und Continual Improvement

Service Level Management erkennt Abweichungen und Verbesserungspotenziale.

Continual Improvement sorgt dafür, dass daraus konkrete Maßnahmen entstehen.

Mögliche Verbesserungen:

Verbesserungen aus Service Reviews

Ein möglicher Ablauf:

Serviceziel wird verfehlt
        ↓
Abweichung wird im Report sichtbar
        ↓
Service Review bewertet Ursache und Auswirkung
        ↓
Improvement wird erfasst
        ↓
Owner, Termin und Erfolgskriterium werden festgelegt
        ↓
Problem, Change, Knowledge oder Supplier Management wird eingebunden
        ↓
Maßnahme wird umgesetzt
        ↓
Wirkung wird gemessen
        ↓
Ergebnis wird im nächsten Service Review geprüft

So wird aus einer Kennzahl eine konkrete Verbesserung.

Service-Level-Ziele überprüfen

Nicht jede wiederholte Zielverfehlung bedeutet, dass das Ziel gesenkt werden sollte.

Zu prüfen ist:

Ziele sollten realistisch, aber nicht bequem sein.

Neue Service-Level-Ziele aus Verbesserungen

Neue Erkenntnisse können zusätzliche Ziele erforderlich machen.

Beispiele:

Service Levels sollten sich mit dem Service weiterentwickeln.

Rollen und Verantwortlichkeiten im Zusammenspiel

Rolle oder Practice Beitrag
Service Owner verantwortet Servicequalität und Prioritäten
Service Level Management definiert, misst und überprüft Serviceziele
Service Desk liefert Benutzerfeedback und Incident-Daten
Incident Management stellt Services wieder her
Problem Management untersucht Ursachen und Wiederholungen
Change Enablement setzt Änderungen kontrolliert um
Configuration Management liefert Services, CIs und Abhängigkeiten
Knowledge Management stellt Lösungen und Workarounds bereit
Supplier Management steuert externe Leistungen
Measurement and Reporting bereitet Daten und Trends auf
Continual Improvement verfolgt Verbesserungen

Die Verantwortlichkeiten müssen klar sein.

Servicequalität ist jedoch eine gemeinsame Aufgabe.

Informationsfluss zwischen den Practices

Service Level Management
    ↓ definiert Ziele
Incident Management
    ↓ liefert Störungsdaten
Problem Management
    ↓ liefert Ursachen und Known Errors
Change Enablement
    ↓ liefert Änderungen und Ergebnisse
Configuration Management
    ↓ liefert Abhängigkeiten und Kritikalität
Knowledge Management
    ↓ liefert Workarounds und Nutzungswissen
Supplier Management
    ↓ liefert externe Leistungsdaten
Measurement and Reporting
    ↓ erstellt Berichte und Trends
Service Review
    ↓ beschließt Verbesserungen
Continual Improvement
    ↓ verfolgt Umsetzung und Wirkung

Dieser Informationsfluss muss nicht in einem einzigen Werkzeug stattfinden.

Wichtig sind verlässliche Verknüpfungen und Verantwortlichkeiten.

Praxisbeispiel: VPN-Service

Service Level Management

Definiert Verfügbarkeit, Supportzeit und Wiederherstellungsziel.

Incident Management

Liefert Daten zu VPN-Abbrüchen und Wiederherstellungszeiten.

Problem Management

Erkennt fehlerhafte Client-Version als gemeinsame Ursache.

Knowledge Management

Stellt Workaround und Prüfschritte bereit.

Change Enablement

Steuert Pilot und Rollout einer neuen Client-Version.

Service Configuration Management

Zeigt betroffene Clientversionen, Gateway und MFA-Abhängigkeit.

Supplier Management

Prüft Herstellerunterstützung.

Continual Improvement

Misst, ob die VPN-Incidents nach dem Rollout sinken.

Praxisbeispiel: Zertifikatsausfall

Incident

Anmeldung am Mitarbeiterportal fällt aus.

Problem

Zertifikat war abgelaufen.

Configuration Management

Zertifikat war nicht als CI mit Owner und Ablaufdatum erfasst.

Service Level Management

Verfügbarkeitsziel wurde verfehlt.

Change Enablement

Zertifikat wird erneuert und Monitoring eingeführt.

Knowledge Management

Runbook und Prüfschritte werden erstellt.

Continual Improvement

Alle produktiven Zertifikate werden erfasst und mindestens 30 Tage vor Ablauf überwacht.

Praxisbeispiel: Lieferantenabhängige Störung

Situation

Ein SaaS-Service ist nicht erreichbar.

Incident Management

Koordiniert Benutzerkommunikation und Eskalation.

Supplier Management

Eskaliert an den Anbieter.

Service Level Management

Prüft Auswirkung auf SLA und Benutzer.

Configuration Management

Zeigt betroffene Geschäftsprozesse und Schnittstellen.

Problem Management

Prüft wiederkehrende Providerstörungen.

Continual Improvement

Bewertet zusätzlichen Workaround, Redundanz oder Vertragsänderung.

Praxisbeispiel: Service verfügbar, aber langsam

Monitoring

Server und Anwendung erscheinen verfügbar.

Benutzerfeedback

Benutzer melden lange Ladezeiten.

Service Level Management

Erkennt, dass nur Verfügbarkeit, aber keine Benutzerperformance gemessen wird.

Configuration Management

Zeigt Datenbank und externe Schnittstelle als Abhängigkeiten.

Problem Management

Untersucht Performanceursache.

Change Enablement

Steuert Kapazitäts- und Konfigurationsänderung.

Measurement and Reporting

Ergänzt Antwortzeit und synthetische Benutzertransaktion.

Praxisbeispiel: viele Standardtickets

Beobachtung

Viele Tickets betreffen Passwort und MFA.

Service Level Management

Erkennt hohe Bearbeitungsmenge und schlechte Benutzererfahrung.

Knowledge Management

Überarbeitet Benutzerartikel und Suchbegriffe.

Service Request Management

Vereinfacht Formulare und Automatisierung.

Service Desk

Liefert häufige Fragen und Rückmeldungen.

Continual Improvement

Misst Ticketentwicklung, Self-Service-Nutzung und Artikelbewertung.

Typische Fehler im Zusammenspiel

Fehler 1

Service Levels werden festgelegt, ohne technische Abhängigkeiten zu prüfen.

Fehler 2

Incident-Daten werden gemessen, aber nicht servicebezogen ausgewertet.

Fehler 3

Wiederholte SLA-Verletzungen führen nicht zu Problem Management.

Fehler 4

Changes werden durchgeführt, ohne Service-Level-Auswirkungen zu prüfen.

Fehler 5

Geplante Wartung wird pauschal aus allen Messungen ausgeschlossen.

Fehler 6

CMDB-Daten sind veraltet und führen zu falscher Risikobewertung.

Fehler 7

Lieferantenverträge unterstützen interne Serviceziele nicht.

Fehler 8

Monitoring misst einzelne Server, aber keine nutzbare Servicefunktion.

Fehler 9

Workarounds halten SLA-Ziele formal ein, obwohl der Service dauerhaft instabil ist.

Fehler 10

Knowledge-Lücken verlängern Wiederherstellungszeiten.

Fehler 11

Reports zeigen Abweichungen, aber keine Verantwortlichen oder Maßnahmen.

Fehler 12

Verbesserungen werden umgesetzt, aber ihre Wirkung wird nicht gemessen.

Checkliste Zusammenspiel mit Incident Management

Checkliste Zusammenspiel mit Problem Management

Checkliste Zusammenspiel mit Change Enablement

Checkliste Zusammenspiel mit Service Configuration Management

Checkliste Zusammenspiel mit Knowledge Management

Checkliste Zusammenspiel mit Supplier Management

Checkliste Service Review über alle Practices

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker liefern wichtige technische Informationen für das Zusammenspiel der Practices.

Im Arbeitsalltag bedeutet das:

Technische Arbeit wird dadurch nicht nur als einzelne Tätigkeit betrachtet.

Sie wird mit Servicequalität, Benutzerwirkung und geschäftlichem Nutzen verbunden.

Zusammenfassung

Serviceziele und Erwartungen festlegen
↓
Incident Management liefert Störungs- und Wiederherstellungsdaten
↓
Problem Management untersucht wiederkehrende Ursachen
↓
Change Enablement setzt Verbesserungen kontrolliert um
↓
Service Configuration Management zeigt Abhängigkeiten und Risiken
↓
Knowledge Management beschleunigt Diagnose und Wiederherstellung
↓
Supplier Management steuert externe Beiträge
↓
Monitoring und Reporting messen Servicequalität
↓
Service Review bewertet Abweichungen und Risiken
↓
Continual Improvement verfolgt Maßnahmen und Wirkung

Merksätze

Service Level Management kann Servicequalität nicht allein erzeugen.

Incident Management zeigt, wie sich Störungen auf Serviceziele auswirken.

Problem Management verhindert, dass dieselben SLA-Verletzungen ständig wiederkehren.

Change Enablement setzt Serviceverbesserungen kontrolliert um.

Configuration Management zeigt, wovon ein Service tatsächlich abhängig ist.

Knowledge Management verkürzt Diagnose- und Wiederherstellungszeiten.

Interne Serviceziele müssen durch Teams und Lieferanten unterstützt werden.

Monitoring muss nutzbare Servicefunktionen und nicht nur einzelne Systeme messen.

Ein erreichtes SLA bedeutet nicht automatisch, dass ein Service dauerhaft gesund ist.

Verbesserungen sind erst abgeschlossen, wenn ihre Wirkung gemessen wurde.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

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