12. Service Level Management

12.1 Ziele und Grundlagen des Service Level Management

Kurz erklärt

Service Level Management stellt sicher, dass IT-Services mit den vereinbarten Anforderungen der Kunden und des Unternehmens übereinstimmen.

Dazu werden Serviceziele definiert, überwacht und regelmäßig überprüft.

Ziel ist es, realistische Erwartungen zu vereinbaren, die Servicequalität messbar zu machen und die kontinuierliche Verbesserung der Services zu unterstützen.

Was ist Service Level Management?

Service Level Management ist eine ITIL Practice zur Vereinbarung, Überwachung und Verbesserung der Qualität von IT-Services.

Dabei geht es nicht nur darum,

möglichst kurze Reaktionszeiten einzuhalten.

Viel wichtiger ist,

dass Serviceanbieter und Kunden ein gemeinsames Verständnis darüber entwickeln,

welche Leistungen erbracht werden und welche Erwartungen realistisch sind.

Warum Service Level Management wichtig ist

Ohne klare Vereinbarungen entstehen häufig Missverständnisse.

Typische Fragen:

Service Level Management beantwortet diese Fragen.

Ziele des Service Level Management

Die wichtigsten Ziele sind:

Servicequalität

Servicequalität beschreibt,

wie gut ein Service die Anforderungen der Benutzer erfüllt.

Dabei spielen verschiedene Faktoren eine Rolle.

Beispiele:

Servicequalität umfasst also deutlich mehr als reine Technik.

Was ist ein Service Level?

Ein Service Level beschreibt das vereinbarte Qualitätsniveau eines Services.

Beispiele:

Service Levels werden gemeinsam vereinbart,

nicht einseitig festgelegt.

Service Level Agreement (SLA)

Ein Service Level Agreement (SLA) dokumentiert die vereinbarten Serviceziele.

Ein SLA beschreibt beispielsweise:

Ein SLA ist keine technische Anleitung,

sondern eine Vereinbarung zwischen Serviceanbieter und Kunde.

Bestandteile eines SLA

Ein typisches SLA enthält:

Je nach Organisation können weitere Inhalte ergänzt werden.

Servicezeiten

Nicht jeder Service muss rund um die Uhr verfügbar sein.

Beispiele:

Service Servicezeit
Büroarbeitsplätze Mo–Fr 08:00–18:00 Uhr
Produktionssystem 24 × 7
Intranet Mo–So 06:00–22:00 Uhr
Testsystem nach Bedarf

Die Servicezeit beeinflusst die Bewertung der Servicequalität.

Verfügbarkeit

Verfügbarkeit beschreibt,

wie lange ein Service innerhalb der vereinbarten Servicezeit nutzbar ist.

Beispiele:

Eine höhere Verfügbarkeit erfordert in der Regel mehr technische und organisatorische Maßnahmen.

Erwartungen abstimmen

Ein häufiges Ziel des Service Level Managements besteht darin,

realistische Erwartungen zu schaffen.

Beispiel:

Ein Fachbereich wünscht:

100 % Verfügbarkeit.

Die IT erläutert,

dass Wartungsfenster, Hardwarefehler oder externe Einflüsse dies praktisch unmöglich machen.

Gemeinsam wird ein realistisches Serviceziel vereinbart.

Messbarkeit

Serviceziele sollten eindeutig messbar sein.

Geeignete Formulierungen:

Ungeeignet sind Formulierungen wie:

Kundenzufriedenheit

Ein Service kann alle technischen Kennzahlen erfüllen

und trotzdem als unzureichend wahrgenommen werden.

Deshalb berücksichtigt Service Level Management auch:

Regelmäßige Reviews

Service Levels werden regelmäßig überprüft.

Dabei wird unter anderem betrachtet:

Service Level Management ist deshalb ein kontinuierlicher Prozess.

Praxisbeispiel

Ein Unternehmen betreibt einen VPN-Service.

Vereinbart wurde:

Monitoring misst die Verfügbarkeit,

Incident Management liefert die Wiederherstellungszeiten

und Service Level Management bewertet,

ob die vereinbarten Ziele eingehalten wurden.

Typische Fehler

Fehler 1

Serviceziele sind nicht messbar.

Fehler 2

Unrealistische Erwartungen.

Fehler 3

Kennzahlen werden nicht überwacht.

Fehler 4

SLA wird nie überprüft.

Fehler 5

Benutzeranforderungen werden nicht berücksichtigt.

Fehler 6

Nur technische Kennzahlen werden betrachtet.

Fehler 7

Verantwortlichkeiten sind unklar.

Fehler 8

Es gibt keine regelmäßigen Service Reviews.

Checkliste Service Level Management

Bedeutung für Fachinformatiker für Systemintegration

Auch wenn Service Level Agreements häufig vom Service Management erstellt werden,

arbeiten Fachinformatiker täglich an deren Einhaltung.

Typische Aufgaben:

Damit leisten sie einen wichtigen Beitrag zur Erfüllung der vereinbarten Serviceziele.

Zusammenfassung

Service definieren

↓

Erwartungen abstimmen

↓

Serviceziele vereinbaren

↓

SLA dokumentieren

↓

Serviceleistung messen

↓

Ergebnisse bewerten

↓

Services kontinuierlich verbessern

Merksätze

Service Level Management schafft gemeinsame Erwartungen.

Ein SLA beschreibt vereinbarte Leistungen – keine technischen Lösungen.

Servicequalität muss messbar sein.

Monitoring liefert die Daten, Service Level Management bewertet sie.

Regelmäßige Reviews sind Grundlage für kontinuierliche Verbesserungen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Ziele und Vorgehensweisen orientieren sich an der ITIL Practice „Service Level Management“. Die konkrete Ausgestaltung von Service Levels und Service Level Agreements hängt von den Anforderungen der jeweiligen Organisation und ihrer Kunden ab.

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

12.2 Service Level Agreements (SLA), Operational Level Agreements (OLA) und Underpinning Agreements (UC)

Kurz erklärt

Damit ein IT-Service zuverlässig erbracht werden kann, reichen Service Level Agreements (SLAs) allein nicht aus.

Zusätzlich werden interne Vereinbarungen zwischen IT-Teams sowie Verträge mit externen Dienstleistern benötigt.

ITIL unterscheidet hierfür drei Ebenen:

Gemeinsam sorgen sie dafür, dass vereinbarte Serviceziele tatsächlich eingehalten werden können.

Warum mehrere Vereinbarungen notwendig sind

Ein Kunde vereinbart beispielsweise:

Der VPN-Service soll innerhalb von vier Stunden wiederhergestellt werden.

Damit dieses Ziel erreicht werden kann,

müssen häufig mehrere interne und externe Stellen zusammenarbeiten.

Beispiele:

Deshalb existieren unterschiedliche Vereinbarungen.

Service Level Agreement (SLA)

Ein SLA ist eine Vereinbarung zwischen dem Serviceanbieter und dem Kunden.

Es beschreibt,

welche Leistungen erbracht werden.

Typische Inhalte:

Das SLA beschreibt die Erwartungen des Kunden.

Operational Level Agreement (OLA)

Ein OLA ist eine interne Vereinbarung innerhalb der Organisation.

Beispiele:

Ein OLA legt fest,

welche Leistungen ein internes Team für andere Teams erbringt.

Der Kunde sieht diese Vereinbarung normalerweise nicht.

Underpinning Agreement (UC)

Ein Underpinning Agreement (UC) ist eine Vereinbarung mit einem externen Dienstleister oder Lieferanten.

Beispiele:

Diese Vereinbarungen unterstützen die Einhaltung des SLA.

Die drei Ebenen

Kunde
   │
   ▼
SLA
   │
   ▼
Interne Teams
   │
   ▼
OLA
   │
   ▼
Externe Lieferanten
   │
   ▼
UC

Alle drei Ebenen müssen zusammenpassen.

Zusammenhang zwischen SLA, OLA und UC

Beispiel:

Das SLA fordert:

Wiederherstellung innerhalb von vier Stunden.

Damit dies möglich ist,

vereinbart das Netzwerk-Team intern:

Analyse innerhalb von einer Stunde.

Der Hardwarelieferant garantiert:

Ersatzhardware innerhalb von zwei Stunden.

Nur wenn alle Vereinbarungen zusammenpassen,

kann das SLA eingehalten werden.

Vergleich

Merkmal SLA OLA UC
Vertragspartner Kunde und Serviceanbieter interne Teams externer Dienstleister
Sichtbar für Kunden Ja Nein normalerweise nein
Ziel Servicequalität vereinbaren interne Zusammenarbeit regeln externe Leistungen absichern

Beispiel: E-Mail-Service

Ein Unternehmen betreibt einen E-Mail-Service.

Das SLA enthält:

Intern existieren OLAs:

Zusätzlich bestehen UCs mit:

Alle Beteiligten tragen gemeinsam zur Servicequalität bei.

Servicezeiten abstimmen

Ein häufiger Fehler:

SLA:

24 × 7

OLA:

Montag bis Freitag

Dadurch kann das SLA praktisch nicht eingehalten werden.

Interne und externe Vereinbarungen müssen deshalb zueinander passen.

Mehrere SLAs

Eine Organisation kann unterschiedliche SLAs besitzen.

Beispiele:

Nicht jeder Service benötigt dieselben Serviceziele.

Serviceklassen

Viele Organisationen definieren verschiedene Serviceklassen.

Beispiel:

Klasse Verfügbarkeit
Bronze 99 %
Silber 99,5 %
Gold 99,9 %
Platin 99,99 %

Je höher die Anforderungen,

desto größer sind meist Aufwand und Kosten.

Verantwortlichkeiten

Ein SLA beschreibt auch,

wer welche Aufgaben übernimmt.

Beispiele:

Serviceanbieter:

Kunde:

Klare Verantwortlichkeiten vermeiden Missverständnisse.

Messverfahren

Ein SLA sollte festlegen,

wie Kennzahlen gemessen werden.

Beispiele:

Nur eindeutig definierte Messverfahren ermöglichen objektive Bewertungen.

Ausnahmen

Nicht jede Unterbrechung zählt automatisch als SLA-Verletzung.

Typische Ausnahmen:

Diese Ausnahmen sollten im SLA eindeutig beschrieben werden.

Review von Vereinbarungen

SLAs, OLAs und UCs sollten regelmäßig überprüft werden.

Fragen dabei sind beispielsweise:

Dadurch bleiben Vereinbarungen aktuell.

Praxisbeispiel

Ein Unternehmen garantiert:

VPN-Service:

Intern besteht ein OLA:

Netzwerk-Team:

Mit dem Internetprovider besteht zusätzlich ein UC:

Alle Vereinbarungen unterstützen gemeinsam die Einhaltung des SLA.

Typische Fehler

Fehler 1

SLA und OLA widersprechen sich.

Fehler 2

Externe Lieferanten erfüllen die Anforderungen nicht.

Fehler 3

Servicezeiten sind unrealistisch.

Fehler 4

Kennzahlen sind nicht messbar.

Fehler 5

Verantwortlichkeiten fehlen.

Fehler 6

Vereinbarungen werden nie überprüft.

Fehler 7

SLA enthält technische Details statt Serviceziele.

Fehler 8

Unterschiedliche Teams kennen die Vereinbarungen nicht.

Checkliste SLA

Checkliste OLA und UC

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker erstellen SLAs meist nicht selbst,

arbeiten jedoch täglich daran,

dass deren Ziele erreicht werden.

Typische Aufgaben:

Dadurch tragen sie direkt zur Einhaltung der Servicequalität bei.

Zusammenfassung

Serviceziele vereinbaren

↓

SLA mit dem Kunden festlegen

↓

OLA zwischen internen Teams abstimmen

↓

UC mit externen Dienstleistern vereinbaren

↓

Servicequalität messen

↓

Regelmäßig überprüfen und verbessern

Merksätze

Das SLA beschreibt die Vereinbarung mit dem Kunden.

Das OLA regelt die Zusammenarbeit innerhalb der Organisation.

Das UC beschreibt Vereinbarungen mit externen Dienstleistern.

Alle drei Ebenen müssen zusammenpassen.

Ein SLA ist nur realistisch, wenn OLA und UC seine Einhaltung unterstützen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

ITIL unterscheidet zwischen Service Level Agreements (SLA), Operational Level Agreements (OLA) und Underpinning Agreements (UC). Gemeinsam stellen sie sicher, dass vereinbarte Serviceziele sowohl intern als auch mit externen Dienstleistern unterstützt werden. Die konkrete Ausgestaltung dieser Vereinbarungen richtet sich nach den Anforderungen der jeweiligen Organisation.

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

12.3 Kennzahlen, Berichte und Service Reviews

Kurz erklärt

Vereinbarte Serviceziele sind nur dann sinnvoll, wenn ihre Einhaltung regelmäßig gemessen und bewertet wird.

Service Level Management nutzt hierfür Kennzahlen (Metrics), Key Performance Indicators (KPIs), Berichte (Reports) und Service Reviews.

Ziel ist es, die tatsächliche Servicequalität objektiv zu bewerten, Verbesserungspotenziale zu erkennen und gemeinsam mit den Kunden geeignete Maßnahmen abzuleiten.

Warum Kennzahlen wichtig sind

Ein Service kann nur verbessert werden,

wenn seine Leistung messbar ist.

Ohne Kennzahlen bleiben viele Aussagen subjektiv.

Beispiele:

Nicht messbar:

Der Support arbeitet schnell.

Messbar:

95 % aller Incidents wurden innerhalb von 30 Minuten angenommen.

Nur messbare Informationen ermöglichen objektive Bewertungen.

Was sind Kennzahlen (Metrics)?

Kennzahlen sind messbare Werte,

die Informationen über einen Service liefern.

Beispiele:

Nicht jede Kennzahl eignet sich automatisch als KPI.

Key Performance Indicators (KPIs)

KPIs sind besonders wichtige Kennzahlen,

mit denen die Zielerreichung bewertet wird.

Beispiele:

KPIs konzentrieren sich auf die wichtigsten Erfolgsfaktoren.

Typische Service-Level-Kennzahlen

Kennzahl Aussage
Verfügbarkeit Wie lange war der Service nutzbar?
Reaktionszeit Wann begann die Bearbeitung?
Wiederherstellungszeit Wann war der Service wieder verfügbar?
SLA-Erfüllung Wurden die vereinbarten Ziele erreicht?
Erstlösungsquote Wie viele Anfragen wurden direkt gelöst?
Kundenzufriedenheit Wie bewerten Benutzer den Service?

Verfügbarkeit messen

Die Verfügbarkeit wird häufig in Prozent angegeben.

Beispiele:

Je höher die gewünschte Verfügbarkeit,

desto größer werden meist Aufwand und Kosten.

Reaktionszeit und Wiederherstellungszeit

Diese beiden Begriffe werden häufig verwechselt.

Reaktionszeit

Zeit zwischen Eingang einer Meldung und Beginn der Bearbeitung.

Wiederherstellungszeit

Zeit bis der Service wieder ordnungsgemäß funktioniert.

Ein Incident kann sehr schnell angenommen,

aber erst deutlich später vollständig behoben werden.

Erstlösungsquote (First Contact Resolution)

Die Erstlösungsquote beschreibt,

wie viele Anfragen bereits beim ersten Kontakt vollständig gelöst werden.

Eine hohe Erstlösungsquote bedeutet häufig:

Sie ist daher eine wichtige Kennzahl für Service Desks.

Kundenzufriedenheit

Technisch erfolgreiche Services führen nicht automatisch zu zufriedenen Benutzern.

Typische Bewertungsmöglichkeiten:

Subjektive Bewertungen ergänzen technische Kennzahlen.

Berichte (Reports)

Kennzahlen werden regelmäßig in Berichten zusammengefasst.

Typische Inhalte:

Berichte richten sich an unterschiedliche Zielgruppen.

Zielgruppen für Berichte

Je nach Rolle unterscheiden sich die Inhalte.

Beispiele:

Zielgruppe Typische Inhalte
Management KPIs, Trends, Risiken
Service Owner SLA-Erfüllung, Verbesserungen
Service Desk Incidents, Service Requests
Kunden Servicequalität, Verfügbarkeit
Administratoren technische Kennzahlen

Jede Zielgruppe benötigt andere Informationen.

Service Reviews

Ein Service Review ist ein regelmäßiges Treffen,

bei dem die Servicequalität bewertet wird.

Typische Fragen:

Service Reviews fördern die Zusammenarbeit zwischen IT und Kunden.

Typischer Ablauf eines Service Reviews

Kennzahlen sammeln
        │
        ▼
Berichte erstellen
        │
        ▼
Service Review durchführen
        │
        ▼
Abweichungen bewerten
        │
        ▼
Verbesserungen beschließen
        │
        ▼
Maßnahmen umsetzen

Service Reviews finden häufig monatlich oder quartalsweise statt.

Abweichungen analysieren

Nicht jede Zielabweichung bedeutet automatisch schlechte Servicequalität.

Beispiele:

Wichtig ist,

die Ursachen zu verstehen,

statt ausschließlich Kennzahlen zu betrachten.

Einzelne Messwerte liefern oft nur eine Momentaufnahme.

Trendanalysen zeigen Entwicklungen.

Beispiele:

Dadurch werden Verbesserungen sichtbar.

Visualisierung

Kennzahlen lassen sich unterschiedlich darstellen.

Beispiele:

Die Darstellung sollte übersichtlich und leicht verständlich sein.

Benchmarking

Organisationen vergleichen ihre Kennzahlen häufig:

Benchmarking hilft,

Verbesserungspotenziale zu erkennen.

Serviceverbesserungen ableiten

Service Reviews sollen konkrete Maßnahmen hervorbringen.

Beispiele:

Kennzahlen dienen also nicht nur der Kontrolle,

sondern vor allem der Verbesserung.

Praxisbeispiel

Ein Unternehmen bewertet seinen VPN-Service.

Ergebnisse:

Im Service Review wird beschlossen,

den Self-Service weiter auszubauen,

um die Anzahl einfacher Supportanfragen zusätzlich zu reduzieren.

Typische Fehler

Fehler 1

Zu viele Kennzahlen.

Fehler 2

KPIs sind nicht eindeutig definiert.

Fehler 3

Kennzahlen werden gemessen,

aber nicht ausgewertet.

Fehler 4

Berichte sind zu technisch.

Fehler 5

Service Reviews finden nicht regelmäßig statt.

Fehler 6

Nur negative Ergebnisse werden betrachtet.

Fehler 7

Kundenzufriedenheit wird nicht gemessen.

Fehler 8

Verbesserungsmaßnahmen werden nicht nachverfolgt.

Checkliste Kennzahlen

Checkliste Service Reviews

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker liefern viele der technischen Informationen,

auf denen Service Reviews basieren.

Typische Aufgaben:

Damit tragen sie direkt zur kontinuierlichen Verbesserung der IT-Services bei.

Zusammenfassung

Serviceleistung messen

↓

Kennzahlen berechnen

↓

Berichte erstellen

↓

Service Review durchführen

↓

Verbesserungen beschließen

↓

Maßnahmen umsetzen

Merksätze

Kennzahlen machen Servicequalität messbar.

KPIs konzentrieren sich auf die wichtigsten Ziele.

Service Reviews dienen der Verbesserung – nicht der Schuldzuweisung.

Gute Berichte unterstützen fundierte Entscheidungen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Kennzahlen, KPIs, Berichte und Service Reviews orientieren sich an den Empfehlungen der ITIL Practice „Service Level Management“. Welche Kennzahlen tatsächlich erhoben werden, richtet sich nach den vereinbarten Servicezielen und den Anforderungen der jeweiligen Organisation.

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

12.4 Kundenzufriedenheit und Continual Improvement

Kurz erklärt

Die Einhaltung von Service Level Agreements allein garantiert noch keinen guten IT-Service.

Service Level Management betrachtet deshalb neben technischen Kennzahlen auch die Zufriedenheit der Benutzer und Kunden.

Die gewonnenen Erkenntnisse fließen anschließend in das Continual Improvement ein, um Services langfristig weiterzuentwickeln.

Warum Kundenzufriedenheit wichtig ist

Ein Service kann alle vereinbarten Kennzahlen erfüllen,

und trotzdem als schlecht wahrgenommen werden.

Beispiel:

Ein Incident wird innerhalb der vereinbarten vier Stunden behoben.

Der Benutzer erhält jedoch während dieser Zeit keinerlei Rückmeldung.

Technisch wurde das SLA erfüllt.

Die wahrgenommene Servicequalität ist dennoch gering.

Servicequalität aus Sicht des Kunden

Kunden bewerten Services häufig nach anderen Kriterien als Administratoren.

Typische Fragen sind:

Diese Aspekte ergänzen technische Kennzahlen.

Objektive und subjektive Bewertung

Servicequalität setzt sich aus beiden Bereichen zusammen.

Objektive Bewertung Subjektive Bewertung
Verfügbarkeit Freundlichkeit
Reaktionszeit Kommunikation
Wiederherstellungszeit Verständlichkeit
SLA-Erfüllung Gesamteindruck
Fehlerrate Zufriedenheit

Beide Sichtweisen sind wichtig.

Kundenzufriedenheit messen

Typische Verfahren:

Die Methode richtet sich nach Service und Organisation.

Customer Satisfaction Score (CSAT)

Der CSAT misst,

wie zufrieden Benutzer unmittelbar nach einer Serviceleistung sind.

Beispiel:

"Wie zufrieden waren Sie mit der Bearbeitung Ihres Incidents?"

Antwortmöglichkeiten:

Der CSAT eignet sich besonders für einzelne Supportfälle.

Net Promoter Score (NPS)

Der NPS bewertet,

wie wahrscheinlich Kunden den Service weiterempfehlen würden.

Typische Frage:

"Wie wahrscheinlich ist es, dass Sie unseren IT-Service weiterempfehlen?"

Bewertung:

0 bis 10 Punkte.

Der NPS betrachtet eher die langfristige Gesamtzufriedenheit.

Feedback ernst nehmen

Nicht jedes negative Feedback bedeutet,

dass Prozesse schlecht funktionieren.

Es kann beispielsweise aufzeigen:

Feedback liefert wichtige Hinweise für Verbesserungen.

Beschwerden analysieren

Beschwerden sollten systematisch ausgewertet werden.

Beispiele:

Dadurch lassen sich wiederkehrende Schwachstellen erkennen.

Verbesserungen priorisieren

Nicht jede Verbesserung besitzt dieselbe Bedeutung.

Typische Kriterien:

Priorisierung hilft,

Ressourcen gezielt einzusetzen.

Continual Improvement

Continual Improvement ist eine eigenständige ITIL Practice.

Ihr Ziel besteht darin,

Services, Prozesse und Arbeitsweisen kontinuierlich weiterzuentwickeln.

Service Level Management liefert dafür wichtige Informationen.

Zusammenspiel

Kennzahlen
      │
      ▼
Feedback
      │
      ▼
Service Review
      │
      ▼
Verbesserungen planen
      │
      ▼
Maßnahmen umsetzen
      │
      ▼
Erneut messen

Verbesserung ist ein fortlaufender Kreislauf.

Typische Verbesserungsmaßnahmen

Beispiele:

Auch kleine Änderungen können die Servicequalität deutlich erhöhen.

Kommunikation verbessern

Benutzer bewerten häufig nicht nur die Lösung,

sondern auch den Umgang während der Bearbeitung.

Wichtige Punkte:

Gute Kommunikation erhöht die Zufriedenheit oft stärker als technische Optimierungen.

Erfolge sichtbar machen

Verbesserungen sollten dokumentiert und kommuniziert werden.

Beispiele:

Dadurch wird der Nutzen des Continual Improvement sichtbar.

Langfristige Entwicklung beobachten

Einzelne Umfragen liefern nur Momentaufnahmen.

Erst langfristige Entwicklungen zeigen,

ob Verbesserungen tatsächlich wirken.

Beispiele:

Trendanalysen sind deshalb besonders wertvoll.

Praxisbeispiel

Eine Umfrage zeigt,

dass Benutzer zwar mit der technischen Lösung zufrieden sind,

aber häufig fehlende Statusinformationen bemängeln.

Daraufhin führt die IT automatische Statusmeldungen im Ticketsystem ein.

Bei der nächsten Befragung steigt die Kundenzufriedenheit deutlich,

obwohl sich die technischen Kennzahlen kaum verändert haben.

Typische Fehler

Fehler 1

Nur SLA-Kennzahlen werden betrachtet.

Fehler 2

Benutzerfeedback wird ignoriert.

Fehler 3

Umfragen finden nur selten statt.

Fehler 4

Verbesserungsmaßnahmen werden nicht umgesetzt.

Fehler 5

Kommunikation wird unterschätzt.

Fehler 6

Nur negatives Feedback wird ausgewertet.

Fehler 7

Verbesserungen werden nicht gemessen.

Fehler 8

Es gibt keine Verantwortlichen für Verbesserungsmaßnahmen.

Checkliste Kundenzufriedenheit

Checkliste Continual Improvement

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker tragen wesentlich zur Verbesserung der Servicequalität bei.

Typische Aufgaben:

Viele Verbesserungen entstehen direkt aus den Erfahrungen des täglichen IT-Betriebs.

Zusammenfassung

Serviceleistung messen

↓

Benutzerfeedback einholen

↓

Ergebnisse auswerten

↓

Verbesserungen planen

↓

Maßnahmen umsetzen

↓

Erfolg erneut messen

Merksätze

SLA-Erfüllung bedeutet nicht automatisch zufriedene Benutzer.

Kommunikation beeinflusst die wahrgenommene Servicequalität erheblich.

Feedback ist eine wichtige Grundlage für Verbesserungen.

Continual Improvement ist ein fortlaufender Prozess.

Jede Verbesserung sollte anschließend erneut bewertet werden.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Verfahren zur Messung der Kundenzufriedenheit und zur kontinuierlichen Verbesserung orientieren sich an den Empfehlungen der ITIL Practices „Service Level Management“ und „Continual Improvement“. Die Auswahl geeigneter Kennzahlen, Umfragen und Verbesserungsmaßnahmen richtet sich nach den Anforderungen der jeweiligen Organisation und ihrer Kunden.

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

12.5 Zusammenspiel mit Incident, Problem, Change und Monitoring

Kurz erklärt

Service Level Management arbeitet nicht isoliert.

Die Einhaltung vereinbarter Serviceziele ist nur möglich, wenn verschiedene ITIL Practices eng zusammenarbeiten.

Incident Management, Problem Management, Change Enablement, Monitoring and Event Management sowie Continual Improvement liefern die Informationen und Maßnahmen, die zur Erfüllung der Service Levels notwendig sind.

Service Level Management bewertet diese Ergebnisse und entwickelt die Services gemeinsam mit Kunden und Fachbereichen kontinuierlich weiter.

Warum das Zusammenspiel wichtig ist

Ein Service Level Agreement beschreibt,

welche Leistungen vereinbart wurden.

Es sorgt jedoch nicht selbst dafür,

dass diese Leistungen erbracht werden.

Dafür arbeiten mehrere ITIL Practices zusammen.

Zusammenspiel der Practices

Monitoring
      │
      ▼
Incident Management
      │
      ▼
Problem Management
      │
      ▼
Change Enablement
      │
      ▼
Service Level Management
      │
      ▼
Continual Improvement

Jede Practice erfüllt dabei eine eigene Aufgabe.

Service Level Management und Incident Management

Incident Management stellt den normalen Betrieb möglichst schnell wieder her.

Service Level Management bewertet anschließend,

ob dabei die vereinbarten Ziele eingehalten wurden.

Beispiele:

Incident Management arbeitet operativ.

Service Level Management bewertet die Ergebnisse.

Beispiel

SLA:

Ein Incident wird

nach 20 Minuten angenommen

und nach drei Stunden behoben.

Service Level Management bewertet:

SLA erfüllt.

Service Level Management und Problem Management

Wiederkehrende SLA-Verletzungen können auf tieferliegende Probleme hinweisen.

Beispiele:

Problem Management untersucht anschließend die eigentliche Ursache.

Service Level Management und Change Enablement

Viele Verbesserungen der Servicequalität erfolgen über Changes.

Beispiele:

Service Level Management zeigt,

welche Verbesserungen notwendig sind.

Change Enablement setzt sie kontrolliert um.

Monitoring and Event Management

Monitoring liefert die Messwerte,

auf denen viele SLA-Kennzahlen basieren.

Beispiele:

Ohne Monitoring wären objektive Bewertungen kaum möglich.

Beispiel

Monitoring misst:

SLA fordert:

99,90 %

Service Level Management bewertet:

SLA erfüllt.

Service Configuration Management

Service Configuration Management beschreibt,

welche Configuration Items zu einem Service gehören.

Dadurch lässt sich feststellen,

welche Ausfälle tatsächlich den vereinbarten Service beeinflussen.

Außerdem unterstützt die CMDB:

Availability Management

Availability Management entwickelt Maßnahmen,

um die Verfügbarkeit eines Services zu erhöhen.

Beispiele:

Service Level Management bewertet anschließend,

ob die vereinbarten Verfügbarkeitsziele erreicht wurden.

Capacity and Performance Management

Kapazitätsengpässe können SLA-Verletzungen verursachen.

Capacity and Performance Management überwacht beispielsweise:

Service Level Management erkennt anhand der Kennzahlen,

wann zusätzliche Ressourcen notwendig werden.

Information Security Management

Auch Sicherheitsmaßnahmen beeinflussen Service Levels.

Beispiele:

Ein ausgewogenes Verhältnis zwischen Sicherheit und Benutzerfreundlichkeit ist wichtig.

Supplier Management

Externe Dienstleister beeinflussen häufig direkt die Servicequalität.

Beispiele:

Service Level Management überprüft,

ob externe Leistungen die vereinbarten Serviceziele unterstützen.

Continual Improvement

Service Reviews liefern Verbesserungspotenziale.

Diese fließen anschließend in Continual Improvement ein.

Beispiele:

Servicequalität wird dadurch kontinuierlich verbessert.

Informationsfluss

Monitoring
      │
      ▼
Kennzahlen
      │
      ▼
Service Review
      │
      ▼
Verbesserungsmaßnahmen
      │
      ▼
Change Enablement
      │
      ▼
Monitoring überprüft Ergebnis

Dadurch entsteht ein geschlossener Verbesserungszyklus.

Praxisbeispiel

Ein Unternehmen stellt fest,

dass die Wiederherstellungszeit des VPN-Services regelmäßig das SLA überschreitet.

Monitoring liefert die Messdaten.

Incident Management dokumentiert die Bearbeitungszeiten.

Problem Management erkennt,

dass ein einzelner VPN-Gateway überlastet ist.

Change Enablement führt einen zweiten Gateway ein.

Monitoring bestätigt anschließend,

dass die Wiederherstellungszeit deutlich sinkt.

Im nächsten Service Review wird festgestellt,

dass das SLA nun wieder zuverlässig eingehalten wird.

Typische Fehler

Fehler 1

Service Level Management betrachtet nur SLA-Kennzahlen.

Fehler 2

Monitoring liefert unvollständige Daten.

Fehler 3

Problem Management wird nicht einbezogen.

Fehler 4

Verbesserungen werden nicht umgesetzt.

Fehler 5

Changes berücksichtigen Serviceziele nicht.

Fehler 6

Supplier erfüllen vereinbarte Leistungen nicht.

Fehler 7

Service Reviews führen zu keinen Maßnahmen.

Fehler 8

Service Levels werden nach Änderungen nicht angepasst.

Fehler 9

Configuration-Daten sind veraltet.

Fehler 10

Kennzahlen werden gemessen,

aber nicht zur Verbesserung genutzt.

Checkliste Zusammenspiel

Checkliste Service Level Management

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker tragen täglich zur Einhaltung der Service Levels bei.

Typische Aufgaben:

Damit unterstützen sie direkt die vereinbarte Servicequalität.

Zusammenfassung

Monitoring liefert Kennzahlen

↓

Incident Management stellt Services wieder her

↓

Problem Management beseitigt Ursachen

↓

Change Enablement setzt Verbesserungen um

↓

Service Level Management bewertet die Ergebnisse

↓

Continual Improvement entwickelt den Service weiter

Merksätze

Service Level Management bewertet Leistungen – andere Practices erbringen sie.

Monitoring liefert die Messwerte für SLA-Bewertungen.

Problem Management reduziert zukünftige SLA-Verletzungen.

Service Reviews bilden die Grundlage für kontinuierliche Verbesserungen.

Gute Servicequalität entsteht nur durch das Zusammenspiel mehrerer ITIL Practices.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Zusammenhänge entsprechen den Empfehlungen der ITIL-Practices. Service Level Management bewertet die Einhaltung vereinbarter Serviceziele, während andere Practices die technischen und organisatorischen Voraussetzungen schaffen. Erst ihr Zusammenspiel ermöglicht eine dauerhaft hohe Servicequalität.

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