# 8.1 Service Level Management – Ziele, Begriffe und Grundlagen

> **Kurz erklärt**
>
> Service Level Management sorgt dafür, dass Erwartungen an IT-Services klar beschrieben, messbar gemacht, vereinbart, überwacht und regelmäßig überprüft werden.
>
> Ziel ist nicht, möglichst viele Kennzahlen zu sammeln.
>
> Ziel ist, gemeinsam zu verstehen:
>
> - was ein Service leisten soll,
> - welche Qualität erwartet wird,
> - welche Ziele vereinbart sind,
> - ob diese Ziele erreicht werden,
> - und wo Verbesserungen notwendig sind.

---

**Warum Service Level Management wichtig ist**

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

Beispiele:

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

Service Level Management macht Erwartungen sichtbar und steuerbar.

---

**Was ist ein Service Level?**

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

Beispiele:

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

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

---

**Service Level Management ist mehr als SLA-Verwaltung**

Ein häufiger Irrtum:

> Service Level Management bedeutet nur, SLAs zu schreiben.

Das ist zu kurz gedacht.

Service Level Management umfasst auch:

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

Ein SLA allein verbessert noch keinen Service.

---

**Ziele von Service Level Management**

Service Level Management soll:

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

Wichtig ist, nicht nur technische Messwerte zu betrachten.

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

---

**Kunde, Benutzer und Service Provider unterscheiden**

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

Kunden und Benutzer haben nicht immer dieselbe Perspektive.

Ein Kunde achtet oft auf Nutzen, Kosten und Risiko.

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

---

**Service Level Agreement**

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

Ein SLA kann enthalten:

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

Ein SLA sollte verständlich und realistisch sein.

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

---

**Service Level Requirement**

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

Beispiele:

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

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

---

**Service Level Target**

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

Beispiele:

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

Ein Ziel muss messbar und fachlich sinnvoll sein.

---

**Operational Level Agreement**

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

Beispiel:

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

Dafür braucht die IT interne Beiträge:

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

Ein OLA unterstützt also die Einhaltung des SLA.

---

**Underpinning Contract**

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

Beispiele:

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

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

Beispiel:

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

---

**SLA, OLA und Lieferantenvertrag im Zusammenhang**

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

Die Ziele müssen zusammenpassen.

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

---

**Servicebeschreibung als Grundlage**

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

Eine Servicebeschreibung kann enthalten:

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

Ohne klare Servicebeschreibung ist ein SLA schwer verständlich.

---

**Beispiel: Servicebeschreibung VPN-Zugang**

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

Solche Informationen helfen, Erwartungen und Ziele sauber zu formulieren.

---

**Messbarkeit**

Ein Service Level sollte messbar sein.

Ungeeignet:

> Der Service soll schnell sein.

Besser:

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

Ungeeignet:

> Der Support soll zeitnah reagieren.

Besser:

> Kritische Incidents werden innerhalb von 15 Minuten aufgenommen und priorisiert.

Messbarkeit verhindert Diskussionen über unklare Begriffe.

---

**Messmethode festlegen**

Zu jedem Ziel sollte klar sein:

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

Beispiel:

Verfügbarkeit kann unterschiedlich gemessen werden:

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

Ohne Messmethode ist eine Kennzahl schwer vergleichbar.

---

**Technische Kennzahl und Benutzererfahrung unterscheiden**

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

Beispiele:

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

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

---

**Geeignete Kennzahlen**

Geeignete Kennzahlen sind:

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

Beispiele:

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

Eine Kennzahl sollte eine Entscheidung oder Verbesserung unterstützen.

---

**Problematische Kennzahlen**

Kennzahlen können falsche Anreize erzeugen.

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

Kennzahlen müssen deshalb immer mit Kontext bewertet werden.

---

**Service Level und Priorität**

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

Beispiel:

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

Wichtig:

Priorität sollte nicht nur aus Dringlichkeit entstehen.

Sie sollte Auswirkung und Dringlichkeit gemeinsam betrachten.

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

---

**Reaktionszeit und Lösungszeit unterscheiden**

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

Diese Begriffe sollten nicht vermischt werden.

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

---

**Verfügbarkeit**

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

Wichtige Fragen:

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

Beispiel:

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

---

**Servicezeit und Supportzeit unterscheiden**

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

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

Diese Unterschiede müssen klar kommuniziert werden.

---

**Wartungsfenster**

Wartungsfenster sollten in Service Leveln berücksichtigt werden.

Zu klären ist:

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

Ein Wartungsfenster muss zur Nutzung des Services passen.

Ein technisch bequemes Wartungsfenster kann fachlich ungeeignet sein.

---

**Service Level und Benutzerkommunikation**

Benutzer sollten wissen:

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

Unklare Kommunikation führt zu falschen Erwartungen.

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

---

**Service Review**

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

Mögliche Inhalte:

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

Ein Service Review sollte nicht nur Zahlen vorlesen.

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

---

**Reporting**

Service Level Reporting stellt Informationen zur Serviceleistung bereit.

Gute Reports sind:

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

Ein guter Report beantwortet:

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

---

**SLA-Abweichungen**

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

Zu prüfen ist:

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

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

---

**Service Level und Continual Improvement**

Service Level Management liefert wichtige Hinweise für Verbesserungen.

Beispiele:

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

Diese Hinweise sollten in Continual Improvement einfließen.

---

**Service Level und Kosten**

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

Beispiele:

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

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

Nicht jeder Service benötigt maximale Verfügbarkeit.

---

**Service Level und Risiko**

Service Levels sollten zum Risiko passen.

Fragen:

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

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

---

**Service Level und Lieferanten**

Viele Services hängen von Lieferanten ab.

Beispiele:

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

Service Level Management muss prüfen:

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

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

---

**Service Level und Monitoring**

Monitoring liefert Daten für Service Level Management.

Beispiele:

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

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

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

---

**Service Level und Service Configuration Management**

Service Configuration Management hilft zu verstehen:

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

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

---

**Service Level und Incident Management**

Incident Management liefert Daten über Servicequalität.

Beispiele:

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

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

---

**Service Level und Problem Management**

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

Beispiele:

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

Dann reicht Reporting allein nicht aus.

Die Ursache muss untersucht und dauerhaft verbessert werden.

---

**Service Level und Change Enablement**

Changes können Service Levels beeinflussen.

Zu prüfen ist:

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

Change Enablement und Service Level Management sollten deshalb zusammenarbeiten.

---

**Praxisbeispiel: Mitarbeiterportal**

**Serviceziel**

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

**Messung**

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

**Review**

Im Monatsbericht wird sichtbar:

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

**Erkenntnis**

Technische Verfügbarkeit allein reicht nicht.

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

---

**Praxisbeispiel: Service Desk**

**Serviceziel**

Kritische Incidents werden innerhalb von 15 Minuten aufgenommen und priorisiert.

**Messung**

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

**Risiko**

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

**Verbesserung**

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

---

**Praxisbeispiel: Lieferantenabhängigkeit**

**Serviceziel**

Interner Service soll innerhalb von 4 Stunden wiederhergestellt werden.

**Problem**

Ein externer Lieferant garantiert nur Reaktion innerhalb von 8 Stunden.

**Folge**

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

**Verbesserung**

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

---

**Typische Fehler**

**Fehler 1**

SLA wird geschrieben, aber nicht aktiv genutzt.

---

**Fehler 2**

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

---

**Fehler 3**

Kennzahlen messen Systeme, aber nicht Servicequalität.

---

**Fehler 4**

Messmethode ist unklar.

---

**Fehler 5**

Servicezeit, Supportzeit und Wartungsfenster werden vermischt.

---

**Fehler 6**

Interne SLAs ignorieren Lieferantenabhängigkeiten.

---

**Fehler 7**

Zu hohe Ziele werden vereinbart, obwohl Ressourcen fehlen.

---

**Fehler 8**

SLA-Abweichungen werden nur berichtet, aber nicht analysiert.

---

**Fehler 9**

Benutzerfeedback wird ignoriert.

---

**Fehler 10**

Service Reviews bestehen nur aus Zahlen ohne Maßnahmen.

---

**Fehler 11**

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

---

**Fehler 12**

Service Level Management wird als reine Kontrollfunktion verstanden.

---

**Checkliste Service Level definieren**

- [ ] Service eindeutig beschrieben
- [ ] Zielgruppe bekannt
- [ ] Kunde und Benutzer unterschieden
- [ ] Service Owner benannt
- [ ] Supportzeit festgelegt
- [ ] Servicezeit festgelegt
- [ ] wichtigste Funktionen beschrieben
- [ ] Abhängigkeiten bekannt
- [ ] Risiken bewertet
- [ ] relevante Ziele festgelegt
- [ ] Messmethode definiert
- [ ] Reporting und Review geplant

---

**Checkliste SLA-Inhalte**

- [ ] Servicebeschreibung
- [ ] Geltungsbereich
- [ ] Servicezeiten
- [ ] Supportzeiten
- [ ] Zielwerte
- [ ] Prioritätsdefinition
- [ ] Reaktionszeiten
- [ ] Wiederherstellungsziele
- [ ] Messmethoden
- [ ] Ausnahmen
- [ ] Wartungsfenster
- [ ] Rollen und Verantwortlichkeiten
- [ ] Eskalationswege
- [ ] Reporting
- [ ] Review-Termine

---

**Checkliste Messung**

- [ ] Kennzahl ist relevant
- [ ] Datenquelle ist klar
- [ ] Messzeitraum ist klar
- [ ] Servicezeit ist berücksichtigt
- [ ] geplante Wartung ist geregelt
- [ ] Benutzerperspektive ist berücksichtigt
- [ ] technische Messung ist nachvollziehbar
- [ ] Ausnahmen sind definiert
- [ ] Ergebnis ist verständlich berichtbar
- [ ] Kennzahl unterstützt Verbesserung

---

**Checkliste Service Review**

- [ ] vereinbarte Ziele geprüft
- [ ] SLA-Abweichungen analysiert
- [ ] Major Incidents betrachtet
- [ ] wiederkehrende Incidents betrachtet
- [ ] Problems und Known Errors geprüft
- [ ] Changes und Releases berücksichtigt
- [ ] Benutzerfeedback einbezogen
- [ ] Lieferantenleistung bewertet
- [ ] Risiken besprochen
- [ ] Verbesserungsmaßnahmen festgelegt
- [ ] Verantwortliche benannt
- [ ] nächster Review-Termin geplant

---

**Bedeutung für Fachinformatiker für Systemintegration**

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

Im Arbeitsalltag bedeutet das:

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

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

---

**Zusammenfassung**

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

---

**Merksätze**

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

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

> Technische Verfügbarkeit ist nicht automatisch gute Benutzererfahrung.

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

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

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

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

---

**Verwandte Seiten**

- 8.2 SLA, SLR, OLA und Underpinning Contracts
- 8.3 Kennzahlen, Messmethoden und Reporting
- 8.4 Service Reviews und Continual Improvement
- 8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management
- Incident Management
- Problem Management
- Change Enablement
- Service Configuration Management
- Knowledge Management
- Measurement and Reporting

---

**Quellen und Versionsstand**

**Offizielle Grundlagen**

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

**Einordnung**

Die dargestellten:

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

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

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

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

- Services,
- Kunden,
- Benutzergruppen,
- Risiken,
- Servicezeiten,
- Supportmodell,
- Lieferanten,
- Monitoring,
- Organisation,
- und verfügbare Fähigkeiten

angepasst werden.

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