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: 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 8.2 SLA, SLR, OLA und Underpinning Contracts Kurz erklärt Service Level Management arbeitet mit mehreren Arten von Vereinbarungen und Anforderungen. SLR beschreibt, welche Servicequalität benötigt wird. SLA beschreibt, welche Servicequalität zwischen Kunde und Service Provider vereinbart ist. OLA beschreibt interne Unterstützungsvereinbarungen zwischen Teams. Underpinning Contracts beschreiben unterstützende Verträge mit externen Lieferanten. Diese Ebenen müssen zusammenpassen, sonst werden Serviceziele vereinbart, die praktisch nicht erfüllbar sind. Warum diese Begriffe wichtig sind Ein IT-Service wird selten von nur einer Stelle erbracht. Beispiel: Der Service „Mitarbeiterportal“ kann abhängig sein von: Anwendungsteam, Datenbankteam, Netzwerkteam, Identity Management, Service Desk, Monitoring, Cloud-Anbieter, Softwarehersteller, Internetprovider, und externem Support. Wenn ein SLA dem Fachbereich eine schnelle Wiederherstellung verspricht, müssen alle unterstützenden Teams und Lieferanten dazu beitragen können. Deshalb reicht es nicht, nur ein SLA zu schreiben. Die Vereinbarungen im Hintergrund müssen ebenfalls passen. Grundmodell Service Level Requirement ↓ beschreibt benötigte Servicequalität ↓ Service Level Agreement ↓ vereinbart Servicequalität mit dem Kunden ↓ Operational Level Agreements ↓ regeln interne Unterstützungsleistungen ↓ Underpinning Contracts ↓ sichern externe Lieferantenleistungen ab ↓ Monitoring, Reporting und Service Reviews ↓ prüfen, ob Ziele erreicht werden Alle Ebenen müssen aufeinander abgestimmt sein. Service Level Requirement Ein Service Level Requirement (SLR) beschreibt eine Anforderung an die Servicequalität. SLRs entstehen häufig aus: fachlichen Anforderungen, Benutzererwartungen, gesetzlichen Vorgaben, Sicherheitsanforderungen, Geschäftsprozessen, Risikobewertungen, bisherigen Incidents, Service Reviews, Projekten, neuen Services, oder geänderten Arbeitsweisen. Ein SLR ist noch nicht automatisch eine verbindliche Vereinbarung. Es ist zunächst eine Anforderung, die geprüft, bewertet und verhandelt werden muss. Beispiele für Service Level Requirements Bereich Beispiel für SLR Verfügbarkeit Mitarbeiterportal soll während Geschäftszeiten verfügbar sein Support Benutzer benötigen Support montags bis freitags von 08:00 bis 18:00 Uhr Reaktion kritische Störungen sollen sehr schnell aufgenommen werden Wiederherstellung zentrale Störungen sollen innerhalb weniger Stunden umgangen oder behoben werden Performance häufig genutzte Seiten sollen zügig laden Requests Standardsoftware soll innerhalb weniger Arbeitstage bereitgestellt werden Kommunikation bei größeren Störungen sollen regelmäßige Statusupdates erfolgen Sicherheit Sicherheitsvorfälle sollen sofort eskaliert werden SLRs sollten so formuliert sein, dass sie später in messbare Ziele überführt werden können. SLR prüfen Nicht jede Anforderung kann unverändert übernommen werden. Zu prüfen ist: Ist die Anforderung fachlich notwendig? Ist sie technisch erreichbar? Ist sie wirtschaftlich sinnvoll? Sind Ressourcen vorhanden? Passen interne Teams dazu? Passen Lieferantenverträge dazu? Gibt es Abhängigkeiten? Ist die Messung möglich? Welche Risiken entstehen? Welche Alternative gibt es? Service Level Management hilft, Anforderungen realistisch zu machen. Beispiel: unrealistisches SLR Anforderung Das System soll immer verfügbar sein. Problem „Immer“ ist unklar und praktisch kaum erreichbar. Besser prüfen: Welche Geschäftszeiten sind kritisch? Welche Ausfallzeit ist tolerierbar? Welche Funktionen sind besonders wichtig? Welche Kosten wären für Hochverfügbarkeit notwendig? Gibt es manuelle Ersatzverfahren? Welche Lieferantenabhängigkeiten bestehen? Daraus kann ein realistisches SLA-Ziel entstehen. Service Level Agreement Ein Service Level Agreement (SLA) ist eine Vereinbarung zwischen Service Provider und Kunde über die erwartete und vereinbarte Servicequalität. Ein SLA beschreibt nicht nur technische Werte. Es beschreibt, was der Service leisten soll und wie die Leistung bewertet wird. Typische Inhalte: Servicebeschreibung, Geltungsbereich, Zielgruppe, Servicezeiten, Supportzeiten, Verfügbarkeitsziele, Reaktionszeiten, Wiederherstellungsziele, Prioritätsdefinitionen, Messmethoden, Ausnahmen, Wartungsfenster, Rollen und Verantwortlichkeiten, Eskalationswege, Reporting, Review-Termine. Ein SLA sollte verständlich, realistisch und überprüfbar sein. SLA ist eine Vereinbarung, kein Wunschzettel Ein SLA darf keine Ziele enthalten, die nicht erbracht werden können. Ungeeignet: Fachbereich wünscht 24/7-Verfügbarkeit, obwohl kein 24/7-Betrieb, keine Bereitschaft und kein passender Lieferantenvertrag existieren. Besser: Verfügbarkeitsziel, Supportzeiten, Bereitschaft und Lieferantenleistungen werden gemeinsam geprüft und realistisch vereinbart. Ein SLA muss zu Fähigkeiten, Budget, Risiko und Organisation passen. Arten von SLAs Mögliche SLA-Formen: SLA-Art Beschreibung Beispiel Servicebezogenes SLA gilt für einen bestimmten Service SLA für VPN-Zugang Kundenbezogenes SLA gilt für einen bestimmten Kunden oder Fachbereich SLA für Personalabteilung Mehrstufiges SLA kombiniert allgemeine und spezifische Vereinbarungen allgemeine IT-Supportregeln plus spezielle Ziele für kritischen Service Interner Service Level wird intern vereinbart und berichtet interner Service Desk Support Externer SLA-Bezug hängt von Lieferantenvertrag ab Cloud-Service mit Provider-SLA Die passende Form hängt von Organisation und Servicekatalog ab. SLA-Inhalte verständlich formulieren Ein SLA sollte nicht nur juristisch oder technisch formuliert sein. Ungeeignet: HTTP-Endpunkt antwortet in 99,7 Prozent der Messintervalle mit Statuscode 200. Besser ergänzt: Der Service gilt als verfügbar, wenn Benutzer die Startseite öffnen und sich anmelden können. Technisches Monitoring prüft zusätzlich den HTTP-Status und die Login-Funktion. Technische Definitionen sind wichtig. Aber der Servicebezug muss verständlich bleiben. Geltungsbereich Der Geltungsbereich beschreibt, wofür das SLA gilt und wofür nicht. Zu klären ist: Welche Services sind eingeschlossen? Welche Benutzergruppen sind eingeschlossen? Welche Standorte sind eingeschlossen? Welche Zeiten gelten? Welche Funktionen gehören zum Service? Welche Systeme sind ausgeschlossen? Welche Voraussetzungen müssen Benutzer erfüllen? Welche Abhängigkeiten bestehen? Ein unklarer Geltungsbereich führt später zu Streit über Erwartungen. Beispiel Geltungsbereich Service VPN-Zugang für berechtigte Mitarbeitende. Eingeschlossen VPN-Client, VPN-Gateway, Anmeldung über zentrale Identität, MFA, Zugriff auf freigegebene interne Ressourcen. Nicht eingeschlossen private Internetverbindung des Benutzers, nicht freigegebene Privatgeräte, externe Websites, lokale Heimnetzwerkprobleme. Diese Abgrenzung macht Erwartungen klarer. Servicezeit Die Servicezeit beschreibt, wann ein Service vereinbarungsgemäß nutzbar sein soll. Beispiele: Montag bis Freitag, 08:00 bis 18:00 Uhr, Montag bis Samstag, 06:00 bis 22:00 Uhr, 24 Stunden täglich, nur während Geschäftszeiten, nur während Schulungszeiten, nur innerhalb definierter Projektphasen. Servicezeit ist wichtig für Verfügbarkeitsmessung und Wartungsplanung. Supportzeit Die Supportzeit beschreibt, wann Unterstützung verfügbar ist. Beispiele: Service Desk erreichbar von 08:00 bis 17:00 Uhr, Bereitschaft für P1-Incidents außerhalb der Geschäftszeit, Lieferantensupport montags bis freitags, erweiterter Support für kritische Zeiträume. Ein Service kann auch außerhalb der Supportzeit verfügbar sein. Aber bei Störungen gelten dann möglicherweise andere Reaktionszeiten. Servicezeit und Supportzeit unterscheiden Begriff Bedeutung Beispiel Servicezeit Service soll nutzbar sein Mitarbeiterportal 24/7 erreichbar Supportzeit Hilfe ist verfügbar Service Desk 08:00 bis 18:00 Uhr Wartungsfenster geplante Änderungen erlaubt Sonntag 22:00 bis 23:00 Uhr Bereitschaft definierte Unterstützung außerhalb normaler Zeiten P1-Rufbereitschaft nachts Diese Begriffe dürfen nicht vermischt werden. Wartungsfenster Wartungsfenster regeln, wann geplante Arbeiten stattfinden dürfen. Zu klären ist: wann Wartung erlaubt ist, wie früh sie angekündigt wird, ob sie aus Verfügbarkeitsmessung ausgeschlossen wird, welche Services betroffen sein dürfen, wer informiert wird, ob Fachbereiche zustimmen müssen, welche Ausnahmen gelten. Ein Wartungsfenster sollte zur Nutzung des Services passen. Ein technisch bequemes Zeitfenster kann fachlich ungeeignet sein. Verfügbarkeit im SLA Verfügbarkeit beschreibt, ob ein Service im vereinbarten Zeitraum nutzbar ist. Wichtig ist die genaue Definition. Zu klären ist: Wird während Servicezeit oder rund um die Uhr gemessen? Zählen geplante Wartungen mit? Wird aus Benutzerperspektive gemessen? Welche Funktionen müssen verfügbar sein? Wie werden Teilausfälle bewertet? Welche Standorte zählen? Welche Datenquelle wird verwendet? Wie werden externe Abhängigkeiten behandelt? Ohne klare Definition ist eine Verfügbarkeitszahl schwer interpretierbar. Beispiel Verfügbarkeitsziel Ungeeignet: Service ist zu 99,9 Prozent verfügbar. Besser: Der Service gilt während der vereinbarten Servicezeit als verfügbar, wenn Benutzer die Startseite öffnen, sich anmelden und die Hauptfunktion nutzen können. Geplante Wartungsfenster werden separat ausgewiesen. Diese Definition ist für Technik und Benutzer klarer. Reaktionszeit Reaktionszeit beschreibt die Zeit bis zur ersten qualifizierten Bearbeitung oder Rückmeldung. Wichtig: Eine automatische Eingangsbestätigung ist nicht automatisch eine qualifizierte Reaktion. Beispiele: P1-Incident wird innerhalb von 15 Minuten qualifiziert bearbeitet. P2-Incident wird innerhalb von 60 Minuten geprüft. Standardanfrage erhält innerhalb eines Arbeitstages eine Rückmeldung. Reaktionszeit sollte mit Priorität und Supportzeit verknüpft sein. Wiederherstellungszeit Wiederherstellungszeit beschreibt, bis wann ein Service wieder nutzbar sein soll. Das kann bedeuten: vollständige Lösung, temporäre Wiederherstellung, nutzbarer Workaround, Wiederherstellung einer Kernfunktion, Rollback auf vorherigen Stand. Wichtig ist, genau zu definieren, was als wiederhergestellt gilt. Beispiel: Ein Workaround kann den Benutzer wieder arbeitsfähig machen, obwohl die Ursache noch nicht dauerhaft behoben ist. Lösungszeit Lösungszeit beschreibt die Zeit bis zur endgültigen Lösung. Sie ist nicht immer identisch mit Wiederherstellungszeit. Beispiel: Ein bekannter Fehler kann durch Workaround kurzfristig umgangen werden. Die dauerhafte Lösung erfolgt erst durch einen späteren Change. Dann ist der Service wiederhergestellt, aber das Problem noch nicht endgültig gelöst. Prioritäten im SLA SLAs enthalten häufig Prioritätsklassen. Eine Priorität sollte aus Auswirkung und Dringlichkeit entstehen. Auswirkung Dringlichkeit mögliche Priorität viele Benutzer betroffen sofortige Arbeit blockiert P1 wichtiger Fachbereich betroffen kurzfristige Bearbeitung nötig P2 einzelner Benutzer betroffen Arbeit teilweise möglich P3 geringe Auswirkung kein Zeitdruck P4 Die konkrete Matrix muss zur Organisation passen. Wichtig ist, Priorität nicht nur nach Lautstärke oder subjektivem Druck zu vergeben. Auswirkung Auswirkung beschreibt, wie stark ein Incident, Request oder Problem den Service oder die Organisation betrifft. Kriterien: Anzahl betroffener Benutzer, Kritikalität des Services, betroffener Geschäftsprozess, Standort, Sicherheitsrisiko, finanzielle Auswirkung, gesetzliche oder vertragliche Folgen, Reputationsrisiko, verfügbare Alternativen. Ein einzelner Benutzer kann hohe Auswirkung haben, wenn eine kritische Rolle betroffen ist. Dringlichkeit Dringlichkeit beschreibt, wie schnell gehandelt werden muss. Kriterien: Arbeitsfähigkeit, Frist, Sicherheitsbezug, drohende Eskalation, betroffene Geschäftszeit, kommende Termine, vorhandener Workaround, zeitkritischer Prozess. Hohe Dringlichkeit ohne hohe Auswirkung führt nicht automatisch zu höchster Priorität. Beides muss gemeinsam bewertet werden. Messmethoden im SLA Ein SLA-Ziel braucht eine klare Messmethode. Zu definieren ist: Startzeitpunkt, Endzeitpunkt, Messzeitraum, Datenquelle, Berechnungslogik, Ausnahmen, Verantwortlicher für Messung, Reporting-Form, Prüfintervall. Beispiel: Bei Reaktionszeit muss klar sein, ob die Zeit ab Ticketeingang, ab Kategorisierung oder ab Supportzeitbeginn zählt. Ausnahmen SLAs sollten Ausnahmen definieren. Beispiele: geplante Wartungsfenster, höhere Gewalt, Ausfall externer Netze außerhalb der Verantwortung, Benutzer reagiert nicht, fehlende Genehmigung, falsche oder unvollständige Anfrage, Sicherheitsvorfall mit Sonderprozess, Lieferantenverzug außerhalb vereinbarter Leistung, Testsysteme ohne SLA. Ausnahmen dürfen nicht genutzt werden, um Verantwortung zu vermeiden. Sie müssen nachvollziehbar sein. OLA Ein Operational Level Agreement (OLA) ist eine interne Vereinbarung zwischen Teams oder Organisationseinheiten. Ziel: Interne Teams stellen gemeinsam sicher, dass ein SLA erfüllt werden kann. Beispiele: Service Desk nimmt P1-Incidents innerhalb von 15 Minuten auf. Netzwerkteam übernimmt P1-Eskalationen innerhalb von 30 Minuten. Datenbankteam prüft kritische Datenbankalarme innerhalb von 30 Minuten. Plattformteam stellt Restore-Unterstützung innerhalb definierter Zeit bereit. Fachteam aktualisiert Knowledge-Artikel nach Changes. OLAs sind interne Zusagen, keine Kundenzusagen. Warum OLAs wichtig sind Ein SLA kann nur eingehalten werden, wenn interne Abläufe funktionieren. Ohne OLA entstehen Probleme: Service Desk wartet zu lange auf Fachteam, Eskalationswege sind unklar, Teams priorisieren unterschiedlich, interne Wartezeiten werden nicht sichtbar, SLA wird verfehlt, obwohl einzelne Teams „ihren Teil“ erledigt haben, Verantwortung wird hin- und hergeschoben. OLAs machen interne Beiträge transparent. Beispiel OLA-Kette SLA: P1-Incident wird innerhalb von 4 Stunden wiederhergestellt. Dafür notwendige OLA-Beiträge: Team interner Beitrag Service Desk Ticket aufnehmen, priorisieren, Kommunikation starten Monitoring Alarm korrekt auslösen Plattformteam Serverzustand prüfen Datenbankteam Datenbankverfügbarkeit prüfen Netzwerkteam Netz- und Firewallpfade prüfen Service Owner fachliche Auswirkung bewerten Kommunikation Statusupdates unterstützen Nur zusammen kann das SLA erreicht werden. OLA-Inhalte Ein OLA kann enthalten: beteiligte Teams, unterstützte Services, interne Reaktionszeiten, Eskalationswege, Übergabepunkte, Verantwortlichkeiten, Kommunikationsregeln, benötigte Informationen, Betriebszeiten, Bereitschaftsregeln, Dokumentationspflichten, Knowledge-Pflege, Review-Termine. Ein OLA muss praktikabel sein. Zu komplizierte interne Vereinbarungen werden im Alltag nicht genutzt. OLA und Ticketübergabe OLAs helfen besonders bei Übergaben. Zu klären ist: Wann darf eskaliert werden? Welche Informationen muss das Ticket enthalten? Wer übernimmt Verantwortung? Wie schnell wird reagiert? Wann geht das Ticket zurück? Wie wird der Benutzer informiert? Wer dokumentiert die Lösung? Wann wird Problem Management informiert? Klare Übergaben verhindern Verzögerungen und Doppelarbeit. Underpinning Contract Ein Underpinning Contract ist ein unterstützender Vertrag mit einem externen Lieferanten. Er kann Leistungen regeln wie: Supportzeiten, Reaktionszeiten, Wiederherstellungszeiten, Verfügbarkeit, Wartungsfenster, Eskalationswege, Berichtspflichten, Sicherheitsanforderungen, Datenschutz, Vertraulichkeit, Vertragsstrafen, Kündigungsfristen. Underpinning Contracts müssen zu den internen SLAs passen. Warum Underpinning Contracts wichtig sind Viele IT-Services hängen von externen Leistungen ab. Beispiele: Internetverbindung, Cloud-Plattform, Software-Support, Hardwarewartung, Rechenzentrum, Telefonie, SaaS-Anwendung, Sicherheitsdienstleister, Druckdienstleister. Wenn ein externer Vertrag schwächer ist als das interne SLA, entsteht ein Risiko. Die Organisation verspricht dann möglicherweise mehr, als sie liefern kann. Beispiel Lieferantenabhängigkeit Interner SLA-Wunsch: Fachanwendung bei kritischer Störung innerhalb von 4 Stunden wiederherstellen. Externer Softwarevertrag: Hersteller reagiert innerhalb von 1 Arbeitstag. Risiko: Wenn die Ursache beim Hersteller liegt, kann das interne Ziel nicht sicher eingehalten werden. Mögliche Maßnahmen: Lieferantenvertrag verbessern, internes Ziel anpassen, Workaround definieren, technische Redundanz schaffen, eigenes Fachwissen aufbauen, Risiko bewusst akzeptieren. SLA, OLA und Underpinning Contract abstimmen Zu prüfen ist: Unterstützen OLAs das SLA? Unterstützen Lieferantenverträge das SLA? Sind Supportzeiten kompatibel? Sind Eskalationswege klar? Gibt es Lücken zwischen interner und externer Leistung? Sind Messmethoden vergleichbar? Sind Wartungsfenster abgestimmt? Sind Sicherheitsanforderungen berücksichtigt? Sind Berichtspflichten geregelt? Eine SLA-Zusage darf nicht isoliert betrachtet werden. Typische Lücke zwischen SLA und OLA SLA: P2-Incidents werden innerhalb von 8 Stunden gelöst. Interne Realität: Service Desk ist schnell, Fachteam reagiert aber erst nach 2 Arbeitstagen, keine interne Eskalationsregel, kein definierter Owner. Folge: Das SLA wird regelmäßig verfehlt. Verbesserung: OLA mit Fachteam definieren, Eskalationsweg festlegen, Prioritäten abstimmen, Knowledge-Artikel bereitstellen, Monitoring verbessern. Typische Lücke zwischen SLA und Lieferantenvertrag SLA: Service ist Montag bis Freitag von 08:00 bis 18:00 Uhr unterstützt. Lieferantenvertrag: Hersteller-Support nur von 09:00 bis 17:00 Uhr. Folge: Bei Störung um 17:30 Uhr kann interne IT das SLA möglicherweise nicht erfüllen. Verbesserung: Vertrag anpassen, interne Kompetenz erweitern, SLA-Ziel anpassen, Einschränkung klar kommunizieren, Notfallverfahren definieren. Mehrere Lieferanten Ein Service kann von mehreren Lieferanten abhängen. Beispiel: Cloud-Anbieter, Softwarehersteller, Internetprovider, externer Identity-Dienst, Hardwarewartung, Sicherheitsdienstleister. Dann muss klar sein: welcher Lieferant wofür zuständig ist, wer zuerst kontaktiert wird, welche Eskalationswege gelten, welche Vertragszeiten gelten, welche Nachweise benötigt werden, wer den Gesamtservice koordiniert. Der Benutzer interessiert sich nicht für Lieferantengrenzen. Für ihn zählt, ob der Service funktioniert. SLA und Supplier Management Supplier Management stellt sicher, dass Lieferantenleistungen die Serviceziele unterstützen. Wichtige Fragen: Welche Lieferanten sind kritisch? Welche Services hängen von ihnen ab? Passen Vertragsziele zu SLAs? Werden Lieferantenleistungen gemessen? Gibt es regelmäßige Reviews? Gibt es Eskalationswege? Gibt es Risiken durch einzelne Lieferanten? Gibt es Alternativen oder Notfallpläne? Service Level Management und Supplier Management müssen eng zusammenarbeiten. SLA und Service Configuration Management Service Configuration Management zeigt, welche CIs und Lieferanten einen Service unterstützen. Das hilft bei SLA-Planung. Beispiele: Service hängt von Cloud-Datenbank ab, Service nutzt externen Identity Provider, Service nutzt bestimmten Internetprovider, Service nutzt internes Datenbankteam, Service nutzt Zertifikate mit Ablaufdatum, Service nutzt Monitoring und Backup. Ohne diese Abhängigkeiten können SLAs falsch bewertet werden. SLA und Monitoring SLA-Ziele müssen messbar sein. Monitoring liefert Daten für: Verfügbarkeit, Antwortzeiten, Fehlerraten, Login-Funktion, Schnittstellenstatus, Backupstatus, Kapazität, Zertifikatsablauf, Servicezustand. Wichtig ist: Monitoring muss die vereinbarte Servicequalität abbilden. Ein Server-Ping reicht nicht aus, wenn Benutzer sich trotzdem nicht anmelden können. SLA und Reporting SLA-Reports sollten zeigen: erreichte Ziele, verfehlte Ziele, Ursachen für Abweichungen, betroffene Services, betroffene Benutzer, Trends, Risiken, Lieferantenbeiträge, geplante Verbesserungen. Ein guter Report erklärt nicht nur, ob ein Ziel rot oder grün ist. Er erklärt, warum es relevant ist und was daraus folgt. SLA und Service Review Im Service Review werden SLA, OLA und Lieferantenleistung gemeinsam betrachtet. Mögliche Fragen: Wurden SLA-Ziele erreicht? Welche OLAs haben gut funktioniert? Wo gab es interne Verzögerungen? Welche Lieferanten haben Ziele verfehlt? Welche Incidents waren besonders relevant? Welche Problems sind offen? Welche Changes beeinflussen Ziele? Müssen Zielwerte angepasst werden? Müssen Verträge angepasst werden? Welche Verbesserungen werden beschlossen? Service Reviews verbinden Messung mit Entscheidung. SLA-Änderungen SLAs sollten angepasst werden, wenn sich Rahmenbedingungen ändern. Auslöser: neuer Service, geänderter Geschäftsprozess, neue Benutzergruppe, geänderte Betriebszeiten, neue Lieferanten, Cloud-Migration, höhere Kritikalität, wiederholte SLA-Abweichungen, neue gesetzliche Anforderungen, geänderte Sicherheitslage, geändertes Budget. Ein SLA ist kein dauerhaft unveränderliches Dokument. Es muss regelmäßig überprüft werden. SLA-Verhandlung Bei SLA-Verhandlungen sollten folgende Punkte offen besprochen werden: gewünschte Servicequalität, tatsächlicher Bedarf, technische Machbarkeit, Kosten, Risiken, Lieferantenabhängigkeiten, Supportzeiten, Wartungsfenster, Messmethoden, Ausnahmen, Alternativen. Wichtig: Nicht jede hohe Anforderung ist automatisch sinnvoll. Manchmal ist ein realistischer Service Level mit gutem Workaround besser als ein teures Maximalziel. Service Level und Kosten Höhere Service Levels können höhere Kosten verursachen. Beispiele: 24/7-Bereitschaft, redundante Systeme, schnellerer Lieferantensupport, Hochverfügbarkeitsarchitektur, zusätzliche Monitoringprüfungen, häufigere Backups, kürzere Restore-Zeiten, mehr Personal, mehr Tests. Service Level Management macht sichtbar, welche Qualität benötigt wird und was sie kostet. Service Level und Risikoakzeptanz Nicht alle Risiken lassen sich vollständig vermeiden. Wenn ein niedrigeres Service Level vereinbart wird, sollte klar sein: welches Risiko akzeptiert wird, wer es akzeptiert, welche Auswirkungen möglich sind, welche Workarounds existieren, wann neu bewertet wird, welche Verbesserungen geplant sind. Beispiel: Ein nicht kritischer Testservice erhält kein 24/7-SLA. Das ist akzeptabel, wenn die Auswirkung gering und bekannt ist. Service Level und Kommunikation SLA-Inhalte müssen für Benutzer und Stakeholder verständlich kommuniziert werden. Benutzer sollten wissen: wann der Service verfügbar sein soll, wann Support erreichbar ist, wie Störungen gemeldet werden, welche Prioritäten gelten, wann Statusupdates erfolgen, welche Self-Service-Angebote existieren, welche Einschränkungen bekannt sind. Unklare Kommunikation erzeugt falsche Erwartungen. Praxisbeispiel: VPN-Service SLR Benutzer im Homeoffice benötigen werktags zuverlässigen Zugriff auf interne Systeme. SLA VPN-Service soll Montag bis Freitag von 08:00 bis 18:00 Uhr verfügbar sein. P1-Incidents werden innerhalb von 15 Minuten qualifiziert bearbeitet. OLA Netzwerkteam übernimmt P1-Eskalationen innerhalb von 30 Minuten. Identity-Team unterstützt bei MFA-Störungen innerhalb definierter Zeit. Underpinning Contract Internetprovider und VPN-Hersteller bieten Support innerhalb vereinbarter Zeiten. Prüfung Wenn Hersteller-Support nur am nächsten Arbeitstag reagiert, muss das SLA entsprechend bewertet werden. Praxisbeispiel: Mitarbeiterportal SLR Fachbereich benötigt das Portal während der Kernarbeitszeit. SLA Servicezeit Montag bis Freitag von 07:00 bis 19:00 Uhr. Geplante Wartung nur außerhalb dieser Zeit. OLA Anwendungsteam und Datenbankteam stellen interne Unterstützung während Servicezeit sicher. Underpinning Contract Cloud-Datenbank besitzt Provider-Support für kritische Fälle. Review Nach mehreren Performancebeschwerden wird ein zusätzliches Performance-Ziel ergänzt. Praxisbeispiel: Standardsoftware bereitstellen SLR Benutzer sollen freigegebene Standardsoftware schnell erhalten. SLA Standardsoftware wird innerhalb von 2 Arbeitstagen bereitgestellt. OLA Service Desk prüft Anfrage innerhalb eines Arbeitstages. Endpoint-Team stellt Paketierung und Softwareverteilung bereit. Underpinning Contract Softwarelieferant stellt Lizenzportal und Support bereit. Risiko Wenn Lizenzfreigabe extern länger dauert, muss dies im SLA berücksichtigt werden. Praxisbeispiel: Lieferant passt nicht zum SLA Situation Interner SLA verspricht Wiederherstellung innerhalb von 4 Stunden. Problem Der externe Wartungsvertrag garantiert Ersatzteilversand erst am nächsten Arbeitstag. Folge Das SLA ist bei Hardwaredefekt nicht erfüllbar. Mögliche Maßnahmen besserer Wartungsvertrag, Ersatzhardware vorhalten, redundante Architektur, SLA anpassen, Risiko akzeptieren und dokumentieren. Typische Fehler Fehler 1 SLR wird ungeprüft direkt als SLA übernommen. Fehler 2 SLA-Ziele sind nicht messbar. Fehler 3 SLA, OLA und Lieferantenverträge passen nicht zusammen. Fehler 4 Supportzeit und Servicezeit werden vermischt. Fehler 5 Wartungsfenster sind nicht geregelt. Fehler 6 Prioritäten sind unklar oder subjektiv. Fehler 7 Messmethode wird nicht definiert. Fehler 8 Ausnahmen werden nicht dokumentiert. Fehler 9 Interne Teams kennen ihre OLA-Beiträge nicht. Fehler 10 Lieferantenabhängigkeiten werden nicht berücksichtigt. Fehler 11 SLA wird nicht regelmäßig überprüft. Fehler 12 SLA wird als Kontrollinstrument genutzt, aber nicht als Grundlage für Verbesserung. Checkliste SLR fachlicher Bedarf beschrieben betroffener Service genannt Zielgruppe bekannt gewünschte Servicequalität beschrieben Kritikalität bewertet Risiko bei Nichterfüllung beschrieben technische Machbarkeit geprüft Kostenwirkung geprüft Lieferantenabhängigkeiten geprüft Messbarkeit geprüft Alternative oder Workaround geprüft Checkliste SLA Service eindeutig beschrieben Geltungsbereich definiert Kunde und Service Provider benannt Servicezeiten festgelegt Supportzeiten festgelegt Wartungsfenster geregelt Zielwerte definiert Prioritäten beschrieben Reaktionszeiten festgelegt Wiederherstellungsziele festgelegt Messmethoden beschrieben Ausnahmen dokumentiert Rollen und Verantwortlichkeiten klar Reporting geregelt Review-Termine festgelegt Checkliste OLA beteiligte interne Teams benannt unterstützte Services genannt interne Reaktionszeiten definiert Übergabepunkte beschrieben Eskalationswege festgelegt benötigte Ticketinformationen definiert Supportzeiten intern abgestimmt Bereitschaftsregeln geklärt Dokumentationspflichten beschrieben Knowledge-Pflege berücksichtigt Review vorgesehen Beitrag zum SLA nachvollziehbar Checkliste Underpinning Contract unterstützter Service bekannt Lieferant und Leistung beschrieben Supportzeiten geregelt Reaktionszeiten geregelt Wiederherstellungs- oder Ersatzzeiten geregelt Eskalationswege bekannt Berichtspflichten vereinbart Wartungsfenster abgestimmt Sicherheitsanforderungen geregelt Datenschutzanforderungen berücksichtigt Vertragsziele passen zum SLA Risiken bei Abweichung dokumentiert Checkliste Abstimmung SLA, OLA und Lieferantenvertrag SLA-Ziele sind durch interne Teams unterstützbar OLAs decken kritische interne Beiträge ab Lieferantenverträge unterstützen relevante Ziele Servicezeiten sind kompatibel Supportzeiten sind kompatibel Eskalationswege sind durchgängig Messmethoden widersprechen sich nicht Wartungsfenster sind abgestimmt Ausnahmen sind klar Risiken sind dokumentiert Reviews betrachten alle Ebenen gemeinsam Bedeutung für Fachinformatiker für Systemintegration Fachinformatiker müssen SLA, OLA und Lieferantenabhängigkeiten praktisch verstehen. Im Arbeitsalltag bedeutet das: technische Machbarkeit von Servicezielen einschätzen, interne Reaktions- und Eskalationswege kennen, Lieferantenabhängigkeiten erkennen, Monitoring passend zu SLA-Zielen prüfen, Incidents korrekt priorisieren, Wiederherstellungszeiten nachvollziehbar dokumentieren, Wartungsfenster beachten, Changes mit Servicezielen abstimmen, und unrealistische Zusagen früh sichtbar machen. Service Level Management verbindet technische Realität mit vereinbarter Servicequalität. Zusammenfassung Service Level Requirement erfassen ↓ fachlichen Bedarf, Risiko und Machbarkeit prüfen ↓ realistische SLA-Ziele vereinbaren ↓ interne OLAs zur Unterstützung festlegen ↓ externe Underpinning Contracts abstimmen ↓ Messmethoden und Ausnahmen definieren ↓ Monitoring und Reporting einrichten ↓ Service Reviews durchführen ↓ Abweichungen analysieren ↓ SLA, OLA oder Lieferantenvertrag verbessern Merksätze Ein SLR beschreibt Bedarf, ein SLA beschreibt eine Vereinbarung. Ein SLA ist nur erfüllbar, wenn OLAs und Lieferantenverträge dazu passen. Servicezeit und Supportzeit sind nicht dasselbe. Reaktionszeit ist nicht automatisch Lösungszeit. Ein Ziel ohne Messmethode ist später kaum bewertbar. Lieferantenabhängigkeiten müssen vor der SLA-Zusage geprüft werden. Gute Service Level sind realistisch, messbar und verständlich. Verwandte Seiten 8.1 Service Level Management – Ziele, Begriffe und Grundlagen 8.3 Kennzahlen, Messmethoden und Reporting 8.4 Service Reviews und Continual Improvement 8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management Supplier Management Incident Management Change Enablement Service Configuration Management Measurement and Reporting Quellen und Versionsstand Offizielle Grundlagen PeopleCert – ITIL Practice Guide: Service Level Management PeopleCert – ITIL Practice Guide: Supplier Management PeopleCert – ITIL Practice Guide: Measurement and Reporting PeopleCert – ITIL Practice Guide: Incident Management PeopleCert – ITIL Practice Guide: Change Enablement ITIL Foundation – Version 5 Einordnung Die dargestellten: SLR-Beispiele, SLA-Inhalte, OLA-Strukturen, Lieferantenvertragsbezüge, Checklisten, Prioritätsbeispiele, und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: SLA-Vorlage, SLR-Vorlage, OLA-Struktur, Prioritätsmatrix, Messmethode, Vertragsstruktur, oder Review-Frequenz für alle Organisationen vor. Die konkrete Umsetzung muss an: Services, Kunden, Benutzergruppen, Risiken, Kosten, Supportmodell, Lieferanten, Monitoring, Organisationsstruktur, und verfügbare Fähigkeiten angepasst werden. Behandelter Framework-Stand: ITIL Version 5 Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance Fachlicher Stand: August 2026 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: Wird der Service wie vereinbart erbracht? Wo gibt es Abweichungen? Welche Benutzer oder Geschäftsprozesse sind betroffen? Welche Ursachen sind erkennbar? Welche Verbesserungen sind notwendig? 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: „Der Service ist ständig langsam.“ „Der Support reagiert nie.“ „Das System fällt dauernd aus.“ „Die IT hält ihre Zusagen nicht ein.“ „Der Lieferant ist unzuverlässig.“ „Die Benutzer sind unzufrieden.“ Kennzahlen helfen, solche Aussagen zu prüfen. Sie zeigen: wie häufig etwas passiert, wie stark die Auswirkung ist, ob Ziele erreicht wurden, ob sich Trends verschlechtern, ob Verbesserungen wirken, und wo genauer analysiert werden muss. 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: verständlich, messbar, relevant, nachvollziehbar, regelmäßig verfügbar, vergleichbar, beeinflussbar, mit Servicezielen verbunden, und für Entscheidungen nutzbar. 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: Was genau wird gemessen? Wo wird gemessen? Wann wird gemessen? Wie häufig wird gemessen? Welche Datenquelle gilt? Welche Zeiträume zählen? Welche Ausnahmen gelten? Wer prüft die Daten? Wie wird das Ergebnis berechnet? Wie wird berichtet? 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: Wurde aus Sicht des Servers oder aus Sicht des Benutzers gemessen? Zählte nur die Startseite oder auch die Anmeldung? Wurden geplante Wartungsfenster ausgeschlossen? Wurde während Servicezeit oder rund um die Uhr gemessen? Zählten kurze Unterbrechungen? Waren alle Standorte betroffen oder nur einzelne? Welche Datenquelle wurde verwendet? 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: Verfügbarkeit je Service, Incidents je Service, Reaktionszeit je Priorität, Wiederherstellungszeit je Service, Benutzerzufriedenheit je Service, Anzahl Major Incidents je Service, Anzahl Changes je Service, Incidents nach Changes, wiederkehrende Incidents je Service, offene Problems je Service, SLA-Erfüllung je Service. 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: Servicezeit, Messpunkt, Messintervall, betroffene Funktionen, Ausnahmen, Wartungsfenster, Teilausfälle, Datenquelle. 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: Wird geplante Wartung aus der Verfügbarkeitsberechnung ausgeschlossen? War die Wartung angekündigt? Lag sie im vereinbarten Wartungsfenster? Wurde das Wartungsfenster überschritten? Waren Benutzer trotzdem betroffen? Gab es Incidents nach der Wartung? 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: Anmeldung funktioniert, aber Export nicht. Service funktioniert an Standort A, aber nicht an Standort B. interne Benutzer können arbeiten, externe Benutzer nicht. Anwendung läuft, aber Schnittstelle zum ERP ist gestört. nur bestimmte Benutzergruppe ist betroffen. 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: Wann startet die Messung? Wann endet die Messung? Zählt nur Supportzeit? Was gilt als qualifizierte Reaktion? Zählt eine automatische Eingangsbestätigung? Wird nach Priorität unterschieden? Werden Wartezeiten auf Benutzer getrennt? 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: vollständige technische Lösung, Wiederherstellung der Kernfunktion, funktionierender Workaround, Rollback, Ersatzverfahren, Teilwiederherstellung. 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: Anzahl Incidents je Service, Anzahl Incidents je Priorität, Major Incidents, Reaktionszeit, Wiederherstellungszeit, Wiedereröffnungen, Eskalationen, Incidents nach Changes, wiederkehrende Incidents, Incidents mit Known Error, Incidents mit Knowledge-Nutzung, Benutzerzufriedenheit nach Incident. Wichtig ist die Kombination. Eine einzelne Incident-Kennzahl erklärt selten die ganze Situation. Problem-Kennzahlen Mögliche Problem-Kennzahlen: offene Problems, Problems je Service, Problems mit Known Error, Problems mit Workaround, Zeit bis Ursachenanalyse, wiederkehrende Incidents je Problem, Problems mit dauerhafter Lösung, Problems ohne Owner, gealterte Problems, Problems mit hohem Risiko. 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: Anzahl Changes, erfolgreiche Changes, fehlgeschlagene Changes, Emergency Changes, Changes mit Rollback, Incidents nach Changes, Changes ohne betroffene CIs, Changes ohne Risikoanalyse, Changes ohne Knowledge-Prüfung, Durchlaufzeit von Changes, Changes außerhalb Wartungsfenster. Change-Kennzahlen helfen, Stabilität und Veränderungsfähigkeit zu bewerten. Request-Kennzahlen Mögliche Request-Kennzahlen: Anzahl Service Requests, Bearbeitungszeit je Request-Typ, Erfüllung vereinbarter Zielzeiten, Rückfragenquote, abgebrochene Requests, automatisierte Requests, Self-Service-Anteil, Genehmigungsdauer, häufige Standardrequests, falsch eingereichte Requests. Diese Kennzahlen helfen, Serviceportale, Formulare und Automatisierung zu verbessern. Knowledge-Kennzahlen Mögliche Knowledge-Kennzahlen: Artikelaufrufe, Nutzung im Incident, Suchanfragen ohne Treffer, Artikel ohne Owner, Artikel ohne Review-Datum, schlecht bewertete Artikel, häufig genutzte Workarounds, Knowledge-Artikel nach Major Incidents, Knowledge-Aktualisierung nach Changes, veraltete Artikel. Knowledge-Kennzahlen zeigen, ob Wissen im Alltag hilft oder nur abgelegt wird. Benutzerzufriedenheit Benutzerzufriedenheit ergänzt technische Kennzahlen. Mögliche Methoden: kurze Umfrage nach Ticketabschluss, regelmäßige Serviceumfrage, Feedback im Serviceportal, Bewertung von Knowledge-Artikeln, Interviews mit Fachbereichen, Service Reviews, Auswertung wiederkehrender Beschwerden. 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: Wie einfach ist ein Service zu nutzen? Wie verständlich ist der Self-Service? Wie hilfreich ist die Kommunikation? Wie schnell fühlen sich Benutzer unterstützt? Wie viele Schritte braucht ein Standardrequest? Wie störend sind kurze Ausfälle im Arbeitsfluss? 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: Was ist passiert? Was bedeutet es? Welche Ziele wurden erreicht? Welche Ziele wurden verfehlt? Was sind die Ursachen? Welche Risiken bestehen? Welche Maßnahmen laufen? Welche Entscheidungen werden benötigt? 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: wichtigste Serviceziele, rote und kritische Abweichungen, große Risiken, Major Incidents, Trends, Lieferantenprobleme, Kosten- oder Ressourcenbezug, Entscheidungen, geplante Verbesserungen. 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: genaue Incident-Daten, betroffene CIs, Fehlerkategorien, wiederkehrende Muster, technische Messpunkte, betroffene Versionen, Eskalationszeiten, Change-Auswirkungen, Problem Records, konkrete Maßnahmen. Operatives Reporting hilft bei Analyse und Verbesserung der täglichen Arbeit. Benutzerorientiertes Reporting Benutzer benötigen klare und einfache Informationen. Beispiele: aktueller Status eines Service, bekannte Störung, geplantes Wartungsfenster, erwartete nächste Aktualisierung, was Benutzer tun sollen, ob ein Ticket notwendig ist, ob ein Workaround verfügbar ist. Benutzer brauchen keine internen Detailberichte. Sie brauchen verständliche Orientierung. Dashboards Dashboards zeigen aktuelle oder regelmäßige Informationen auf einen Blick. Mögliche Inhalte: Serviceverfügbarkeit, offene Major Incidents, SLA-Erfüllung, Ticketvolumen, kritische Changes, offene Problems, ablaufende Zertifikate, Lieferantenstatus, Knowledge-Lücken, Benutzerzufriedenheit. 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. Trends statt Momentaufnahmen Ein einzelner Monatswert reicht oft nicht aus. Wichtiger sind Trends. Beispiele: Ticketvolumen steigt seit drei Monaten. Wiederherstellungszeit verbessert sich. Benutzerzufriedenheit sinkt trotz SLA-Erfüllung. Incidents nach Changes nehmen zu. Suchanfragen ohne Treffer steigen. Emergency Changes werden häufiger. Trends zeigen, ob sich Servicequalität verbessert oder verschlechtert. Durchschnittswerte vorsichtig nutzen Durchschnittswerte können täuschen. Beispiel: Die durchschnittliche Lösungszeit beträgt 4 Stunden. Mögliche Realität: viele kleine Tickets werden sehr schnell gelöst, wenige kritische Tickets dauern extrem lange, bestimmte Benutzergruppen sind stark betroffen, ein Service hat große Probleme, andere nicht. Deshalb sollten Durchschnittswerte ergänzt werden durch: Median, Verteilung, Priorität, Servicebezug, Ausreißer, Anzahl kritischer Fälle. Median und Perzentile Der Median zeigt den mittleren Wert einer Verteilung. Perzentile zeigen, wie viele Fälle unter einem bestimmten Wert liegen. Beispiel: 90 Prozent der P2-Incidents werden innerhalb von 8 Stunden wiederhergestellt. 50 Prozent werden innerhalb von 2 Stunden wiederhergestellt. 10 Prozent dauern deutlich länger. Das ist oft aussagekräftiger als nur ein Durchschnittswert. Kontext zu Kennzahlen Kennzahlen brauchen Kontext. Beispiel: Ticketvolumen steigt. Mögliche Ursachen: neuer Service eingeführt, Release mit Fehlern, bessere Meldewege, mehr Benutzer, bekannte Störung, schlechte Self-Service-Artikel, organisatorische Änderung, Sicherheitskampagne, saisonale Belastung. Ohne Kontext kann eine Kennzahl falsch interpretiert werden. Datenqualität im Reporting Reports sind nur so gut wie ihre Daten. Typische Datenprobleme: falsche Kategorien, fehlende Servicezuordnung, falsche Prioritäten, nicht gepflegte CIs, uneinheitliche Statuswerte, manuell geschönte Werte, fehlende Zeitstempel, automatische Antworten als Reaktion gezählt, Wartezeiten falsch behandelt. Datenqualität muss regelmäßig geprüft werden. Messung kann Verhalten beeinflussen Kennzahlen beeinflussen, wie Menschen arbeiten. Beispiele: Wird nur Ticketanzahl gemessen, werden Tickets schnell geschlossen. Wird nur Bearbeitungszeit gemessen, werden schwierige Fälle vermieden. Wird nur SLA-Erfüllung gemessen, werden Prioritäten möglicherweise angepasst. Wird nur Artikelanzahl gemessen, entstehen viele schlechte Knowledge-Artikel. 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: welche Ziele erreicht wurden, welche Abweichungen relevant sind, welche Ursachen erkennbar sind, welche Risiken bestehen, welche Maßnahmen laufen, welche Entscheidungen nötig sind, welche Verbesserungen priorisiert werden. Reporting liefert Daten. Service Review macht daraus Bewertung und Handlung. SLA-Abweichungen berichten Bei SLA-Abweichungen sollte ein Report enthalten: betroffenes Ziel, Zeitraum, Höhe der Abweichung, betroffener Service, betroffene Benutzer, Ursache oder vermutete Ursache, beteiligte CIs oder Lieferanten, Zusammenhang mit Changes oder Problems, aktuelle Maßnahmen, geplante Verbesserung, Verantwortlicher, Termin. 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: viele Incidents nach Changes → Change Review verbessern, viele Tickets zu MFA → Self-Service-Artikel verbessern, lange Eskalationszeiten → OLA prüfen, schlechte Benutzerbewertung → Kommunikation und Lösung prüfen, häufige Workarounds → Problem Management starten, veraltete Knowledge-Artikel → Review-Prozess verbessern, wiederholte Lieferantenverzögerung → Supplier Review durchführen. Die wichtigste Frage lautet: Welche konkrete Handlung folgt aus dem Report? Kennzahlen für Continual Improvement Continual Improvement nutzt Kennzahlen zur Priorisierung. Hilfreich sind: Trends, wiederholte Abweichungen, Auswirkung auf Benutzer, Risiko, Kosten, Häufigkeit, Verbesserungspotenzial, Aufwand, erwarteter Nutzen. 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 Anwendung ist verfügbar, aber häufig langsam, Suchfunktion reagiert schlecht, Tickets werden formal schnell beantwortet, dauerhafte Lösung fehlt. 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 neuer Service, schlechtes Release, fehlender Self-Service, bessere Meldewege, echter Qualitätsverlust, neue Benutzergruppe, Sicherheitskampagne. 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 betroffener Service, Lieferant, Reaktionszeiten, Vertragsziel, tatsächliche Bearbeitung, Auswirkung auf Benutzer. 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 Kennzahl beantwortet eine konkrete Frage Kennzahl ist für den Service relevant Zielgruppe kennt die Bedeutung Zielwert ist definiert Messmethode ist klar Datenquelle ist verfügbar Datenqualität ist ausreichend Kennzahl ist beeinflussbar Kennzahl erzeugt keine falschen Anreize Kennzahl unterstützt Entscheidung oder Verbesserung Checkliste Messmethode Startpunkt der Messung definiert Endpunkt der Messung definiert Messzeitraum definiert Servicezeit berücksichtigt Supportzeit berücksichtigt Wartungsfenster geregelt Ausnahmen definiert Datenquelle festgelegt Berechnung beschrieben Verantwortlicher für Prüfung festgelegt Ergebnis nachvollziehbar dokumentiert Checkliste Reporting Zielgruppe definiert Servicebezug vorhanden Zielwerte sichtbar Ist-Werte sichtbar Abweichungen markiert Ursachen beschrieben Trends dargestellt Risiken genannt Maßnahmen beschrieben Verantwortliche benannt Termine genannt Report führt zu Review oder Entscheidung Checkliste SLA-Abweichung analysieren betroffenes SLA-Ziel benannt Zeitraum genannt betroffener Service genannt betroffene Benutzer oder Standorte beschrieben technische Ursache geprüft organisatorische Ursache geprüft Lieferantenbezug geprüft Zusammenhang mit Changes geprüft Problem Record geprüft oder erstellt Maßnahme definiert Owner benannt Wirksamkeitsprüfung geplant Checkliste Datenqualität für Reports Tickets haben korrekte Servicezuordnung Prioritäten sind nachvollziehbar Zeitstempel sind korrekt Statuswerte sind einheitlich CIs sind verknüpft, falls relevant Kategorien werden einheitlich genutzt automatische Antworten werden getrennt bewertet Wartezeiten sind nachvollziehbar Dubletten werden bereinigt manuelle Korrekturen sind dokumentiert Bedeutung für Fachinformatiker für Systemintegration Fachinformatiker liefern viele Daten, die für Service Level Management wichtig sind. Im Arbeitsalltag bedeutet das: Incidents sauber dokumentieren, betroffene Services und CIs korrekt verknüpfen, technische Messwerte richtig interpretieren, Monitoring nicht nur auf Server, sondern auf Servicefunktion ausrichten, Wiederherstellungszeiten nachvollziehbar erfassen, Changes und deren Auswirkungen dokumentieren, wiederkehrende Probleme erkennen, und Reports nicht nur als Kontrolle, sondern als Verbesserungsgrundlage verstehen. 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 8.1 Service Level Management – Ziele, Begriffe und Grundlagen 8.2 SLA, SLR, OLA und Underpinning Contracts 8.4 Service Reviews und Continual Improvement 8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management Measurement and Reporting Incident Management Problem Management Change Enablement Service Configuration Management Knowledge Management 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: Change Enablement PeopleCert – ITIL Practice Guide: Continual Improvement ITIL Foundation – Version 5 Einordnung Die dargestellten: Kennzahlen, Messmethoden, Reporting-Strukturen, SLA-Abweichungsanalysen, Checklisten, und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: Kennzahlenliste, Berechnungsformel, Reporting-Vorlage, Dashboard-Struktur, Ampellogik, Zielwerttabelle, oder Review-Frequenz für alle Organisationen vor. Die konkrete Umsetzung muss an: Services, Service Level Agreements, Kunden, Benutzergruppen, Supportmodell, Monitoring, Toollandschaft, Datenqualität, Lieferanten, Risiken, 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 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: Verfügbarkeit, Reaktionszeiten, Wiederherstellungszeiten, Ticketvolumen, SLA-Erfüllung, Benutzerzufriedenheit, Changes, Major Incidents. Ein Service Review bewertet zusätzlich: Warum wurde ein Ziel erreicht oder verfehlt? Welche Auswirkungen hatten Abweichungen? Welche Risiken bestehen? Welche Ursachen sind bekannt? Welche Maßnahmen laufen bereits? Welche Entscheidung wird benötigt? Welche Verbesserung sollte priorisiert werden? 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: aktuelle Servicequalität, Zielerreichung, Benutzererfahrung, wichtige Incidents, offene Problems, relevante Changes, Lieferantenleistungen, bekannte Risiken, geplante Entwicklungen, und Verbesserungsmaßnahmen. Service Reviews können je nach Kritikalität und Organisation: monatlich, quartalsweise, halbjährlich, oder anlassbezogen stattfinden. Ziele eines Service Reviews Ein Service Review soll: Servicequalität transparent machen, Abweichungen verstehen, Risiken frühzeitig erkennen, Verantwortlichkeiten klären, Maßnahmen priorisieren, Entscheidungen vorbereiten, Kunden- und Benutzerfeedback einbeziehen, Lieferantenleistung bewerten, und Continual Improvement unterstützen. 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: Was bedeutet die Zahl? Warum ist sie so? Welche Benutzer waren betroffen? Ist ein Trend erkennbar? Muss ein Problem untersucht werden? Muss ein Change geplant werden? Muss ein Lieferant eskaliert werden? Muss ein Service Level angepasst werden? Welche Maßnahme wird bis wann umgesetzt? Merke Reporting liefert Informationen. Das Service Review bewertet diese Informationen und löst Entscheidungen aus. Teilnehmer eines Service Reviews Mögliche Teilnehmer: Service Owner, Kunde oder Fachbereich, Service Level Manager, Service Desk, technische Supportgruppen, Problem Management, Change Management, Supplier Management, Information Security, Continual Improvement, Management, wichtige Lieferanten. 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: Serviceleistung bewerten, Risiken vertreten, Stakeholder einbinden, Verbesserungen priorisieren, Entscheidungen vorbereiten, Maßnahmen verfolgen, Abhängigkeiten berücksichtigen, und Serviceziele aktuell halten. 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: Vorbereitung des Reviews, Zusammenstellung von Kennzahlen, Prüfung der SLA-Erfüllung, Abstimmung mit Kunden und Teams, Dokumentation von Abweichungen, Nachverfolgung von Maßnahmen, und Pflege der Service-Level-Vereinbarungen. Die Rolle kann je nach Organisation anders benannt oder verteilt sein. Rolle des Service Desk Der Service Desk liefert wichtige Praxiserkenntnisse. Beispiele: häufige Benutzerfragen, wiederkehrende Incidents, unklare Self-Service-Inhalte, Probleme bei Eskalationen, schlechte Knowledge-Artikel, Benutzerfeedback, häufige Workarounds, auffällige Tickettrends. Der Service Desk kennt oft die tatsächliche Benutzerwahrnehmung besser als rein technische Reports. Rolle der technischen Teams Technische Teams liefern Informationen zu: Ursachen, Plattformzustand, Kapazität, Monitoring, technischen Risiken, Changes, Releases, Sicherheitslücken, Abhängigkeiten, und geplanten Maßnahmen. 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: Unterstützt der Service den Arbeitsprozess? Welche Funktionen sind besonders wichtig? Welche Störungen waren besonders kritisch? Haben sich Anforderungen verändert? Gibt es neue Benutzergruppen? Sind Support und Kommunikation ausreichend? Welche Verbesserungen haben den höchsten Nutzen? 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: SLA- und Service-Level-Berichte, Verfügbarkeitsdaten, Incident-Trends, Major Incidents, Problem Records, Known Errors, häufig genutzte Workarounds, Change-Ergebnisse, Failed Changes, Release-Ergebnisse, Benutzerfeedback, Lieferantenberichte, Security-Risiken, Kapazitätsdaten, offene Verbesserungsmaßnahmen. Die Vorbereitung sollte sich auf wichtige Themen konzentrieren. Ein unübersichtlicher Datenberg erschwert Entscheidungen. Mögliche Agenda Eine kompakte Agenda kann so aussehen: Servicezustand und wichtige Entwicklungen Zielerreichung und SLA-Abweichungen Benutzer- und Kundenfeedback wichtige Incidents und Major Incidents offene Problems und Known Errors Changes und Releases Lieferantenleistung Risiken und kommende Anforderungen Verbesserungsmaßnahmen Entscheidungen, Owner und Termine Die Agenda sollte an den Service angepasst werden. Servicezustand bewerten Zu Beginn sollte ein Gesamtbild entstehen. Mögliche Fragen: Ist der Service stabil? Gibt es aktuell kritische Risiken? Haben sich Nutzerzahlen verändert? Hat sich die Nutzung verändert? Gibt es technische Engpässe? Gibt es bevorstehende Änderungen? Sind Lieferantenleistungen stabil? Gibt es neue Sicherheitsanforderungen? Ein Gesamtbild hilft, einzelne Kennzahlen richtig einzuordnen. SLA-Erfüllung bewerten Zu prüfen ist: Welche Ziele wurden erreicht? Welche Ziele wurden verfehlt? Wie groß war die Abweichung? Handelt es sich um einen Einzelfall oder Trend? Welche Benutzer waren betroffen? Welche Ursache ist bekannt? Welche Gegenmaßnahmen laufen? Muss ein Problem Record erstellt werden? Muss das SLA angepasst werden? 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: Wurde das Ziel erreicht, weil es zu niedrig ist? Wurde eine automatische Antwort als Reaktion gezählt? Wurden Wartungszeiten großzügig ausgeschlossen? Sind Benutzer trotzdem unzufrieden? Werden kritische Einzelfälle durch Durchschnittswerte verdeckt? Stimmen Daten und Servicewahrnehmung überein? Ein grünes Dashboard ist kein Beweis für einen guten Service. Benutzerfeedback einbeziehen Benutzerfeedback kann stammen aus: Ticketumfragen, Serviceportal, Interviews, Beschwerden, Fachbereichsgesprächen, Service-Desk-Rückmeldungen, Artikelbewertungen, Workshops, oder Nutzungsanalysen. Zu prüfen ist: Welche Themen wiederholen sich? Welche Probleme sind technisch nicht sichtbar? Welche Prozesse sind zu kompliziert? Welche Kommunikation ist unverständlich? Welche Self-Service-Angebote fehlen? Welche Funktionen sind besonders wichtig? Qualitatives Feedback ergänzt Kennzahlen. Incidents betrachten Im Service Review sollten nicht alle Incidents einzeln besprochen werden. Wichtig sind: Major Incidents, wiederkehrende Incidents, kritische Incidents, Incidents mit langer Wiederherstellung, Incidents nach Changes, Incidents mit schlechter Kommunikation, häufige Eskalationen, auffällige Standorte oder Benutzergruppen. Ziel ist, Muster und Verbesserungsmöglichkeiten zu erkennen. Major Incidents betrachten Bei Major Incidents sollte geprüft werden: Was war die Ursache? Wie schnell wurde reagiert? War Ownership klar? War Kommunikation ausreichend? Funktionierten Eskalationswege? Waren Runbooks aktuell? Gab es einen Workaround? Wurde ein Problem Record erstellt? Wurden Lessons Learned umgesetzt? Sind weitere Maßnahmen offen? Ein Major-Incident-Review kann Teil eines Service Reviews sein oder separat stattfinden. Problems und Known Errors betrachten Wichtige Fragen: Welche offenen Problems betreffen den Service? Welche Known Errors bestehen? Wie häufig werden Workarounds genutzt? Gibt es eine dauerhafte Lösung? Ist ein Change geplant? Ist das Risiko noch akzeptabel? Sind Service Desk und Benutzer informiert? Müssen Prioritäten angepasst werden? Gibt es gealterte Problem Records? Häufig genutzte Workarounds sind ein Warnsignal. Changes betrachten Zu prüfen ist: Welche wichtigen Changes wurden umgesetzt? Haben sie den erwarteten Nutzen erreicht? Gab es Failed Changes? Sind Incidents nach Changes entstanden? Wurde Knowledge aktualisiert? Wurde die CMDB aktualisiert? Wurden Risiken korrekt bewertet? Stehen wichtige Changes bevor? Gibt es Change-Kollisionen oder Freeze-Zeiten? Changes beeinflussen Servicequalität direkt. Releases betrachten Bei Releases sind wichtig: erfolgreiche Einführung, Benutzerfeedback, Incidents nach Release, bekannte Fehler, neue Workarounds, Supportaufwand, aktualisierte Dokumentation, aktualisierte Knowledge-Artikel, und erreichte Geschäftsziele. Ein technisch erfolgreiches Deployment kann aus Benutzersicht trotzdem unzureichend sein. Lieferantenleistung betrachten Bei externen Abhängigkeiten sollte geprüft werden: Wurden Vertragsziele erreicht? Waren Reaktionszeiten ausreichend? Gab es wiederkehrende Störungen? Waren Eskalationswege wirksam? War die Kommunikation ausreichend? Gibt es offene Herstellerfehler? Müssen Verträge angepasst werden? Bestehen Abhängigkeiten von einzelnen Lieferanten? Gibt es Alternativen oder Notfallverfahren? Lieferantenprobleme dürfen nicht einfach als unveränderlich hingenommen werden. Risiken betrachten Mögliche Servicerisiken: veraltete Software, ablaufende Zertifikate, fehlende Redundanz, bekannte Kapazitätsgrenzen, unklare Owner, fehlende Dokumentation, häufige Emergency Changes, unzureichende Lieferantenleistung, fehlende Backuptests, Sicherheitslücken, hohe Abhängigkeit von Einzelpersonen, geplanter Hersteller-Supportablauf. Risiken sollten mit Auswirkung, Wahrscheinlichkeit, Owner und Maßnahme dokumentiert werden. Kommende Anforderungen betrachten Ein Service Review sollte auch nach vorne schauen. Beispiele: neue Benutzergruppen, steigende Nutzerzahlen, neue Standorte, neue gesetzliche Anforderungen, Cloud-Migration, neues Release, Vertragsende, End of Support, neue Sicherheitsanforderungen, geänderte Geschäftszeiten, neue Schnittstellen, geplante Umstrukturierung. 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: Knowledge-Artikel korrigieren, Monitoringalarm verbessern, Formular vereinfachen, OLA-Eskalation anpassen, Zertifikatsüberwachung einführen, Standard Change definieren, Runbook aktualisieren, Lieferantenvertrag verbessern, Kapazität erweitern, Self-Service automatisieren. 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: neue Anforderungen, neue Technologien, neue Benutzer, neue Risiken, neue Lieferanten, neue Sicherheitslage, neue Fehler, neue gesetzliche Vorgaben. 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: Titel, Beschreibung, Auslöser, betroffener Service, erwarteter Nutzen, Risiko, Priorität, Aufwand, Owner, Zieltermin, Status, Abhängigkeiten, Erfolgskriterien, Ergebnis. 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: gute Ideen gehen verloren, Maßnahmen werden nicht zugewiesen, gleiche Verbesserung wird mehrfach vorgeschlagen, niemand kennt den Status, dringende Themen verdrängen wichtige langfristige Maßnahmen, Lessons Learned werden nicht umgesetzt. Das Register schafft Transparenz und Verantwortung. Verbesserungsideen erfassen Verbesserungsideen können entstehen aus: Service Reviews, Major Incidents, Problem Management, Failed Changes, Benutzerfeedback, Service Desk, Audits, Security Reviews, Lieferantenreviews, Datenqualitätsberichten, Knowledge-Auswertungen, Monitoringtrends, Mitarbeitervorschlägen. Jede Idee sollte kurz beschreiben: Was ist das Problem? Welche Auswirkung besteht? Welche Verbesserung wird vorgeschlagen? Welcher Nutzen wird erwartet? Verbesserungen priorisieren Nicht alle Verbesserungen können gleichzeitig umgesetzt werden. Mögliche Kriterien: geschäftlicher Nutzen, Risiko, Anzahl betroffener Benutzer, Kritikalität des Services, Sicherheitsrelevanz, Häufigkeit des Problems, Kosten, Aufwand, Dringlichkeit, Abhängigkeiten, gesetzliche Anforderungen, erwartete Wirkung. 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: unklaren Artikeltitel ändern, fehlenden Owner ergänzen, Ticketformular vereinfachen, Eskalationskontakt aktualisieren, Monitoringgrenze korrigieren, häufigen Workaround dokumentieren, Service-Desk-Vorlage verbessern. Solche Verbesserungen sollten nicht unnötig durch große Prozesse verzögert werden. Größere Verbesserungen Größere Maßnahmen können sein: Hochverfügbarkeit einführen, Plattform migrieren, neuen Service Desk einführen, Lieferanten wechseln, Self-Service-Portal aufbauen, CMDB einführen, Monitoring grundlegend modernisieren, Service neu gestalten. Solche Maßnahmen benötigen oft: Business Case, Projekt, Changes, Risikoanalyse, Budget, Ressourcen, Kommunikation, und Erfolgsüberwachung. Verbesserung und Change Enablement Viele Verbesserungen werden durch Changes umgesetzt. Beispiele: neue Monitoringregel, Konfigurationsänderung, Automatisierung, Softwareupdate, neuer Workflow, neues Formular, neue Plattform. 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: wiederkehrende Incidents, häufig genutzte Workarounds, technische Schwachstellen, unklare Abhängigkeiten, fehlerhafte Versionen. Diese Erkenntnisse können als Improvement erfasst und priorisiert werden. Verbesserung und Knowledge Management Knowledge Management kann verbessert werden durch: neue Artikel, aktualisierte Runbooks, bessere Suchbegriffe, klarere Zielgruppen, neue FAQ, archivierte Altartikel, bessere Verknüpfungen, Review-Prozesse, Feedbackauswertung. Wissen ist häufig eine schnelle und kostengünstige Verbesserungsmöglichkeit. Verbesserung und Service Configuration Management Configuration-Daten können verbessert werden durch: fehlende CIs ergänzen, Owner aktualisieren, Beziehungen pflegen, Zertifikate erfassen, Cloud-Tags einführen, Dubletten bereinigen, Change-Prozess anbinden, Service Maps erstellen. Gute Configuration-Daten verbessern Incident, Problem, Change und Security Management. Verbesserung und Supplier Management Lieferantenverbesserungen können sein: Eskalationsweg klären, Supportzeiten anpassen, Reporting verbessern, Vertragsziel ändern, Lieferantenreview einführen, technische Alternative prüfen, zusätzliche Redundanz schaffen, Supportkompetenz intern aufbauen. Lieferantenleistung ist Teil der gesamten Servicequalität. Verbesserungen verfolgen Jede wichtige Maßnahme sollte mindestens besitzen: klare Beschreibung, Owner, Priorität, Zieltermin, Status, erwarteten Nutzen, Erfolgskriterium. 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: vorgeschlagen, wird bewertet, genehmigt, geplant, in Umsetzung, blockiert, umgesetzt, Wirkung wird geprüft, abgeschlossen, verworfen. Ein klarer Status erleichtert Nachverfolgung. Blockierte Verbesserungen Verbesserungen können blockiert sein durch: fehlendes Budget, fehlende Ressourcen, Lieferantenabhängigkeit, technische Abhängigkeit, fehlende Entscheidung, Change Freeze, Sicherheitsprüfung, unklare Verantwortung. Blockierungen sollten sichtbar sein. Zu dokumentieren ist: Ursache, verantwortliche Stelle, benötigte Entscheidung, nächste Prüfung, Risiko der Verzögerung. Wirkung messen Nach Umsetzung muss geprüft werden: Hat sich die Kennzahl verbessert? Ist das ursprüngliche Problem reduziert? Sind Benutzer zufriedener? Gibt es weniger Incidents? Wurde das Risiko reduziert? Funktioniert der neue Prozess? Sind neue Nebenwirkungen entstanden? Muss nachgebessert werden? Eine umgesetzte Maßnahme ist nicht automatisch eine erfolgreiche Verbesserung. Verbesserung schließen Eine Verbesserung sollte erst geschlossen werden, wenn: Maßnahme umgesetzt wurde, Ergebnis geprüft wurde, Erfolgskriterien bewertet wurden, Dokumentation aktualisiert wurde, Rest Risiko bekannt ist, Stakeholder informiert wurden, und gegebenenfalls weitere Maßnahmen erfasst wurden. Wenn die Wirkung noch nicht messbar ist, kann der Status „Wirkung wird geprüft“ sinnvoll sein. Service Review dokumentieren Ein Service Review sollte dokumentieren: Datum, Teilnehmer, betrachteter Zeitraum, wichtigste Kennzahlen, Abweichungen, Risiken, Entscheidungen, Maßnahmen, Owner, Termine, offene Fragen, nächster Review-Termin. Die Dokumentation sollte kompakt und handlungsorientiert sein. Entscheidungen dokumentieren Wichtige Entscheidungen können sein: SLA-Ziel anpassen, Problem Record priorisieren, Change starten, Lieferant eskalieren, Risiko akzeptieren, zusätzliche Kapazität bereitstellen, Serviceumfang ändern, Knowledge verbessern, Monitoring erweitern. Zu jeder Entscheidung sollte nachvollziehbar sein: wer entschieden hat, warum entschieden wurde, welche Auswirkung erwartet wird, und wann überprüft wird. 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: Wurden Maßnahmen umgesetzt? Wurden Termine eingehalten? Welche Wirkung ist erkennbar? Welche Blockierungen bestehen? Muss eine Maßnahme angepasst werden? Sind neue Risiken entstanden? Kann eine Verbesserung geschlossen werden? Ohne Folgereview verlieren Maßnahmen schnell an Verbindlichkeit. Praxisbeispiel: Wiederkehrende VPN-Incidents Beobachtung VPN-Incidents steigen über drei Monate. Service Review betroffene Clientversion identifiziert, Workaround wird häufig genutzt, Benutzerfeedback negativ, Known Error vorhanden, dauerhafte Lösung noch nicht umgesetzt. Verbesserung neue Clientversion pilotieren, Rollout planen, Knowledge-Artikel aktualisieren, Incident-Trend nach Rollout prüfen. 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 Verfügbarkeit misst nur Erreichbarkeit, Antwortzeiten werden nicht betrachtet, Fachbereich meldet lange Ladezeiten. Verbesserung Performance-Kennzahl ergänzen, synthetische Transaktion einführen, Kapazitätsanalyse starten, Benutzerfeedback im nächsten Review prüfen. Praxisbeispiel: Lieferantenproblem Beobachtung Mehrere SLA-Abweichungen entstehen durch langsame Herstellerreaktion. Service Review Underpinning Contract passt nicht zum internen SLA, Eskalationsweg ist unklar, kein technischer Workaround vorhanden. Verbesserung Lieferantenvertrag prüfen, Eskalationsweg definieren, interne technische Kompetenz ausbauen, SLA-Risiko transparent machen. Praxisbeispiel: Major Incident Review-Erkenntnisse Monitoring erkannte Fehler zu spät, Service Desk hatte kein aktuelles Runbook, Statuskommunikation war uneinheitlich, Owner war unklar. Verbesserungen Monitoring erweitern, Runbook aktualisieren, Kommunikationsvorlage erstellen, Ownership im Major-Incident-Prozess festlegen, Wirksamkeit bei nächster Übung prüfen. Praxisbeispiel: Self-Service verbessern Beobachtung Viele Tickets entstehen zur MFA-Einrichtung. Analyse Artikel schwer auffindbar, Suchbegriffe fehlen, Formular ist kompliziert, Benutzer besitzen neues Smartphone. Verbesserungen neuen Artikel erstellen, Suchbegriffe ergänzen, Formular vereinfachen, Self-Service-Link im Onboarding ergänzen. 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 betrachteter Service ist klar Berichtszeitraum festgelegt SLA- und Kennzahlendaten vorhanden Datenqualität geprüft wichtige Incidents ausgewählt Major Incidents berücksichtigt offene Problems und Known Errors geprüft Changes und Releases berücksichtigt Benutzerfeedback gesammelt Lieferantenleistung geprüft Risiken aktualisiert offene Maßnahmen aus letztem Review geprüft passende Teilnehmer eingeladen Checkliste Service Review durchführen Gesamtzustand des Services bewertet Zielerreichung geprüft SLA-Abweichungen analysiert Benutzererfahrung berücksichtigt Incident-Trends betrachtet Problems und Workarounds geprüft Change- und Release-Wirkung bewertet Lieferantenleistung betrachtet kommende Risiken besprochen Verbesserungen priorisiert Entscheidungen dokumentiert Owner und Termine festgelegt Checkliste Improvement Register Verbesserung verständlich beschrieben Auslöser dokumentiert betroffener Service genannt erwarteter Nutzen beschrieben Risiko bewertet Priorität festgelegt Aufwand grob bewertet Owner benannt Zieltermin festgelegt Abhängigkeiten dokumentiert Erfolgskriterium definiert Status aktuell Checkliste Wirkung prüfen Maßnahme vollständig umgesetzt Erfolgskriterium messbar Kennzahl vor und nach Verbesserung verglichen Benutzerfeedback berücksichtigt Incident-Entwicklung geprüft Risiken neu bewertet Nebenwirkungen geprüft Dokumentation aktualisiert Stakeholder informiert weitere Maßnahme bei Bedarf erfasst Verbesserung abgeschlossen oder angepasst Checkliste Maßnahmenverfolgung jede Maßnahme besitzt Owner jeder Termin ist realistisch Status wird regelmäßig aktualisiert Blockierungen sind sichtbar benötigte Entscheidungen sind benannt Risiko bei Verzögerung ist bekannt Wirkung wird im nächsten Review geprüft abgeschlossene Maßnahmen werden dokumentiert offene Maßnahmen werden nicht vergessen Bedeutung für Fachinformatiker für Systemintegration Fachinformatiker liefern wichtige technische Erkenntnisse für Service Reviews und Continual Improvement. Im Arbeitsalltag bedeutet das: Incident- und Monitoringdaten verständlich einordnen, technische Risiken früh melden, wiederkehrende Fehler sichtbar machen, Workarounds und Known Errors bewerten, Verbesserungen an Monitoring und Runbooks vorschlagen, Change-Ergebnisse dokumentieren, Configuration-Daten aktuell halten, und die Wirkung technischer Maßnahmen überprüfen. 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 8.1 Service Level Management – Ziele, Begriffe und Grundlagen 8.2 SLA, SLR, OLA und Underpinning Contracts 8.3 Kennzahlen, Messmethoden und Reporting 8.5 Service Level Management im Zusammenspiel mit Incident, Problem, Change und Configuration Management Continual Improvement Measurement and Reporting Incident Management Problem Management Change Enablement Supplier Management Knowledge Management Quellen und Versionsstand Offizielle Grundlagen PeopleCert – ITIL Practice Guide: Service Level Management PeopleCert – ITIL Practice Guide: Continual Improvement PeopleCert – ITIL Practice Guide: Measurement and Reporting PeopleCert – ITIL Practice Guide: Incident Management PeopleCert – ITIL Practice Guide: Problem Management PeopleCert – ITIL Practice Guide: Change Enablement PeopleCert – ITIL Practice Guide: Supplier Management ITIL Foundation – Version 5 Einordnung Die dargestellten: Review-Agenda, Improvement-Register-Struktur, Priorisierungskriterien, Maßnahmenprotokolle, Checklisten, Erfolgskriterien, und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: Service-Review-Agenda, Review-Frequenz, Teilnehmerliste, Improvement-Register-Vorlage, Priorisierungsmatrix, Maßnahmenstruktur, oder Reporting-Form für alle Organisationen vor. Die konkrete Umsetzung muss an: Services, Kritikalität, Kunden, Benutzergruppen, Risiken, Organisationsgröße, Supportmodell, Lieferanten, Datenqualität, 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 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: Incident Management stellt gestörte Services wieder her. Problem Management untersucht wiederkehrende Ursachen. Change Enablement steuert Änderungen am Service. Service Configuration Management zeigt technische Abhängigkeiten. Knowledge Management stellt Lösungen und Workarounds bereit. Supplier Management steuert externe Lieferanten. Monitoring and Event Management liefert Zustandsdaten. Measurement and Reporting bereitet Kennzahlen auf. Continual Improvement verfolgt Verbesserungsmaßnahmen. 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: Anzahl der Incidents je Service, Prioritäten, Auswirkung und Dringlichkeit, Reaktionszeiten, Wiederherstellungszeiten, Lösungszeiten, Major Incidents, Eskalationen, Wiedereröffnungen, Incidents nach Changes, betroffene Benutzer und Standorte, verwendete Workarounds, Benutzerfeedback. 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: vereinbarte Servicezeiten, Supportzeiten, Prioritätsregeln, Reaktionsziele, Wiederherstellungsziele, Kommunikationsanforderungen, Eskalationsregeln, Kritikalität der Services, vereinbarte Statusintervalle, und Erwartungen der Kunden. 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: betroffener Service, Servicekritikalität, Anzahl betroffener Benutzer, betroffener Geschäftsprozess, Dringlichkeit, vorhandener Workaround, Sicherheits- oder Datenschutzbezug, Servicezeit, vereinbarte Serviceziele. 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: Zeitpunkt des Eingangs, Zeitpunkt der Priorisierung, Zeitpunkt der ersten qualifizierten Bearbeitung, Zeitpunkt der ersten Benutzerinformation, Supportzeit, Wartezeiten, Eskalationen. 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: Service wurde nach zwei Stunden wiederhergestellt. Das zugrunde liegende Problem blieb zunächst bestehen. Die endgültige Lösung erfolgte später. Diese Zeitpunkte sollten getrennt gemessen werden. SLA-Verletzung durch Incident Wenn ein Incident zu einer SLA-Verletzung führt, sollte geprüft werden: Wurde der Incident richtig priorisiert? War der Service korrekt zugeordnet? Wurde rechtzeitig eskaliert? Waren Zuständigkeiten klar? War ein Workaround bekannt? War die Kommunikation ausreichend? Haben interne OLAs funktioniert? Hat ein Lieferant verzögert? War das Ziel realistisch? Ist ein Problem Record erforderlich? 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 CI-Zuordnung war unklar. Eskalationskriterien fehlten. OLA mit dem Fachteam war nicht eindeutig. Kein passender Knowledge-Artikel war vorhanden. Verbesserungen Eskalationsregel überarbeiten, OLA präzisieren, Service- und CI-Zuordnung verbessern, Knowledge-Artikel erstellen, Service Desk schulen. Service Level Management und Problem Management Problem Management untersucht Ursachen wiederkehrender oder schwerwiegender Incidents. Service Level Management hilft dabei, Problems zu priorisieren. Relevante Kriterien: wiederholte SLA-Verletzungen, hohe Anzahl ähnlicher Incidents, lange Wiederherstellungszeiten, kritischer Service betroffen, hohe geschäftliche Auswirkung, häufig genutzter Workaround, starke Benutzerunzufriedenheit, Lieferantenabhängigkeit, Sicherheitsrisiko, steigender Trend. 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: Ursache oder wahrscheinliche Ursache, Known Errors, Workarounds, betroffene Services, betroffene Versionen, technische und organisatorische Risiken, dauerhafte Lösungsvorschläge, geplante Changes, erwartete Dauer bis zur Lösung, verbleibendes Risiko. 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: Wie oft wird der Workaround verwendet? Wie viel Arbeitszeit verursacht er? Wie stark beeinträchtigt er Benutzer? Welche Risiken bestehen? Ist er zuverlässig? Gibt es eine dauerhafte Lösung? Warum wurde sie noch nicht umgesetzt? Wird das SLA nur durch den Workaround formal eingehalten? 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 Service ist regelmäßig instabil. Benutzer werden häufig unterbrochen. Fachteam investiert wiederholt Zeit. Ursache ist weiterhin offen. 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: Welches SLA wird gefährdet? Welche Serviceziele werden wiederholt verfehlt? Welche Benutzergruppen sind betroffen? Welche Geschäftsprozesse hängen davon ab? Gibt es einen sicheren Workaround? Wie häufig tritt der Fehler auf? Welche Kosten entstehen? Welche Risiken entstehen bei Nicht-Handeln? 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: Fehlerbehebung, Sicherheitsupdate, Performance-Optimierung, Kapazitätserweiterung, neue Funktion, Plattformmigration, Firewall-Anpassung, Zertifikatserneuerung, Monitoring-Erweiterung. 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: Kritikalität des betroffenen Service, vereinbarte Servicezeit, Wartungsfenster, Verfügbarkeitsziele, Performance-Ziele, betroffene Benutzergruppen, Wiederherstellungsanforderungen, Lieferantenabhängigkeiten, Kommunikationsanforderungen, mögliche SLA-Auswirkungen. Dadurch kann ein Change nicht nur technisch, sondern auch servicebezogen bewertet werden. Was Change Enablement an Service Level Management liefert Change Enablement liefert: geplante Änderungen, betroffene Services und CIs, erwartete Ausfallzeiten, Risiken, Wartungsfenster, Rollback-Möglichkeiten, Testergebnisse, Failed Changes, Incidents nach Changes, erwarteten Nutzen, und Ergebnisse der Nachprüfung. 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: Liegt die Wartung im vereinbarten Wartungsfenster? Wurde sie rechtzeitig angekündigt? Wird sie aus der Verfügbarkeitsberechnung ausgeschlossen? Welche Benutzer sind betroffen? Wurde das Wartungsfenster überschritten? Gab es ungeplante Nebenwirkungen? Sind abhängige Services betroffen? Wurde der Service Desk informiert? 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: Monatsabschluss, Jahresabschluss, Verkaufsaktion, Produktionshochlauf, Prüfungszeitraum, wichtige Veranstaltung, gesetzliche Meldefrist, hohe saisonale Nutzung. 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: zusätzliche Kapazität bereitstellen, Hochverfügbarkeit einführen, Monitoring erweitern, fehlerhafte Version aktualisieren, Automatisierung einführen, Eskalationsworkflow verbessern, Knowledge Base aktualisieren, redundante Verbindung einrichten, Backup- und Restore-Verfahren verbessern. 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 Datenbank ist ausgelastet. Nutzerzahl ist gestiegen. Kapazitätsplanung wurde nicht angepasst. Monitoring zeigt nur Verfügbarkeit. Changes Datenbankressourcen erweitern, Abfragen optimieren, Performance-Monitoring ergänzen, Lasttest einführen. 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: Configuration Items, Serviceabhängigkeiten, Versionen, Standorte, Owner, Supportgruppen, Lieferanten, Zertifikate, Schnittstellen, Monitoring, Backup, Kritikalität. 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: Webserver, Datenbank, Identity Provider, Netzwerk, DNS, Zertifikat, Cloud-Plattform, externem Lieferanten. 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: Welche CIs unterstützen den Service? Welche CIs sind Single Points of Failure? Welche Komponenten besitzen keinen Owner? Welche Lieferanten sind beteiligt? Welche Versionen sind im Einsatz? Welche Zertifikate oder Lizenzen können ablaufen? Welche Systeme besitzen keine ausreichende Überwachung? Welche Abhängigkeiten sind nicht redundant? Welche CIs haben besonders viele Incidents? Diese Informationen helfen, Serviceziele realistisch zu gestalten. Service Level Management verbessert Configuration Management Service Reviews können Datenqualitätsprobleme sichtbar machen. Beispiele: Incident wurde falschem Service zugeordnet. Kritisches CI besitzt keinen Owner. Lieferantenbeziehung fehlt. Service Map ist unvollständig. Zertifikat ist nicht als CI erfasst. veraltete Anwendungsversion ist dokumentiert. Monitoring ist nicht mit dem Service verknüpft. 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 Lieferantenabhängigkeit wurde im SLA nicht berücksichtigt. Monitoring prüfte die API nicht. Eskalationsweg war unklar. Verbesserungen API als relevante Abhängigkeit dokumentieren, Lieferant zuordnen, Monitoring ergänzen, SLA und Underpinning Contract prüfen. Service Level Management und Knowledge Management Knowledge Management beeinflusst Reaktions- und Wiederherstellungszeiten. Gutes Wissen kann: Erstdiagnose beschleunigen, bekannte Fehler schneller erkennen, Workarounds bereitstellen, Eskalationen verbessern, Benutzerkommunikation vereinheitlichen, Self-Service ermöglichen, und wiederkehrende Tickets reduzieren. 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: Service mit vielen Incidents, häufige SLA-Verletzungen, lange Wiederherstellungszeiten, viele Eskalationen, hohe Zahl wiederkehrender Requests, häufig genutzte Workarounds, schlechte Benutzerbewertungen, unklare Statuskommunikation. Daraus können neue oder verbesserte Knowledge-Artikel entstehen. Was Knowledge Management an Service Level Management liefert Knowledge Management liefert: Nutzung von Knowledge-Artikeln, Suchanfragen ohne Treffer, häufig genutzte Workarounds, Artikelbewertungen, Knowledge-Lücken, Self-Service-Erfolgsdaten, Runbooks, Known Errors, Benutzerfeedback. 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 Service Desk besitzt keine einheitlichen Prüfschritte. Eskalationen enthalten unvollständige Informationen. Fachteam wiederholt immer dieselbe Diagnose. Verbesserungen Service-Desk-Artikel erstellen, Diagnose-Checkliste ergänzen, Eskalationsanforderungen definieren, Knowledge-Nutzung im Ticket messen. Erwartete Wirkung Kürzere Erstdiagnose und schnellere Wiederherstellung. Service Level Management und Supplier Management Viele Services hängen von externen Lieferanten ab. Beispiele: Cloud-Anbieter, Internetprovider, Softwarehersteller, Hardwarewartung, Rechenzentrum, SaaS-Anbieter, Telekommunikationsanbieter. Supplier Management sorgt dafür, dass Lieferantenleistungen die vereinbarten Serviceziele unterstützen. Was Service Level Management an Supplier Management liefert Supplier Management benötigt: relevante SLA-Ziele, kritische Services, Supportzeiten, Wiederherstellungsziele, Verfügbarkeitsziele, Sicherheitsanforderungen, Eskalationsanforderungen, Reportingbedarf, Wartungsfenster, und Risiken. Daraus können geeignete Lieferantenverträge und Leistungsziele abgeleitet werden. Was Supplier Management an Service Level Management liefert Supplier Management liefert: Vertragsziele, tatsächliche Lieferantenleistung, Supportzeiten, Eskalationswege, Vertragsverletzungen, geplante Wartungen, Herstellerprobleme, Lieferantenrisiken, End-of-Support-Termine, und Verbesserungsmaßnahmen. 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: Vertrag verbessern, internes Fachwissen erweitern, Redundanz aufbauen, Workaround entwickeln, internes SLA anpassen, Risiko dokumentieren und akzeptieren. Service Level Management und Monitoring and Event Management Monitoring liefert technische und servicebezogene Messdaten. Beispiele: Verfügbarkeit, Antwortzeiten, Transaktionsfehler, Kapazität, Schnittstellenzustand, Zertifikatsablauf, Backupstatus, Datenbankzustand, Anmeldefunktion. Service Level Management definiert, welche Serviceeigenschaften gemessen werden müssen. Monitoring aus Serviceperspektive Unzureichend: Webserver antwortet auf Ping. Besser: Startseite ist erreichbar. Anmeldung funktioniert. zentrale Benutzeraktion ist erfolgreich. abhängige Schnittstelle antwortet. Antwortzeit liegt im Zielbereich. Ein Service kann technisch „grün“ erscheinen, obwohl Benutzer nicht arbeiten können. Monitoring und Messmethode abstimmen Zu klären ist: Welche Messpunkte entsprechen dem SLA? Wird während der richtigen Servicezeit gemessen? Werden geplante Wartungen gekennzeichnet? Werden Teilausfälle erkannt? Werden alle relevanten Standorte berücksichtigt? Werden technische und synthetische Tests kombiniert? Werden Alarme einem Service und Owner zugeordnet? Sind Messdaten für Reporting verfügbar? 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: Zielwerte, Servicezeiten, Messdefinitionen, relevante Kennzahlen, Ausnahmen, Zielgruppen, Reportingfrequenz, und Reviewanforderungen. Measurement and Reporting liefert: Ist-Werte, Trends, Abweichungen, Datenqualitätsinformationen, Dashboards, Reports, und Vergleichswerte. 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: Incident Management: Welche Ausfälle traten auf? Problem Management: Welche Ursachen sind bekannt? Change Enablement: Gab es einen Change davor? Configuration Management: Welche Abhängigkeit war betroffen? Supplier Management: War ein Lieferant beteiligt? Knowledge Management: Gab es einen Workaround? Continual Improvement: Welche Maßnahmen laufen? 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: SLA-Ziel anpassen, Monitoring erweitern, Problem Record priorisieren, Workaround dokumentieren, Change durchführen, OLA verbessern, Lieferantenvertrag anpassen, Configuration-Daten pflegen, Self-Service verbessern, Kapazität erweitern, Benutzerkommunikation verbessern. 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: Ist das Ziel weiterhin fachlich notwendig? Ist die Messmethode korrekt? Sind Daten zuverlässig? Sind Ressourcen ausreichend? Haben sich Anforderungen verändert? Ist die technische Architektur geeignet? Unterstützen Lieferanten das Ziel? Gibt es unverhältnismäßige Kosten? Welche Risiken entstehen bei Anpassung? Ziele sollten realistisch, aber nicht bequem sein. Neue Service-Level-Ziele aus Verbesserungen Neue Erkenntnisse können zusätzliche Ziele erforderlich machen. Beispiele: Performance-Ziel ergänzen, Statuskommunikation bei Major Incidents definieren, Self-Service-Erfolgsziel aufnehmen, Restore-Test-Ziel festlegen, Lieferantenreaktion messen, Knowledge-Aktualisierung nach Changes prüfen, Benutzererfahrung berücksichtigen. 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 Incident ist dem richtigen Service zugeordnet Priorität berücksichtigt Auswirkung und Dringlichkeit Servicekritikalität ist bekannt Reaktionszeit wird korrekt gemessen Wiederherstellungszeit wird korrekt gemessen Workaround wird dokumentiert SLA-Verletzung wird analysiert Eskalationsweg ist bekannt OLA-Beiträge sind abgestimmt Major Incidents werden im Service Review betrachtet Benutzerfeedback wird berücksichtigt Checkliste Zusammenspiel mit Problem Management wiederkehrende SLA-Verletzungen werden untersucht Problems sind mit Services verknüpft häufige Workarounds werden ausgewertet Known Errors sind dokumentiert geschäftliche Auswirkung ist bekannt Problem-Priorität berücksichtigt Servicekritikalität dauerhafte Lösung ist bewertet geplanter Change ist verknüpft Rest Risiko ist dokumentiert Service Review kennt den Problemstatus Checkliste Zusammenspiel mit Change Enablement betroffener Service ist im Change angegeben Servicezeit und Wartungsfenster sind geprüft mögliche SLA-Auswirkung ist bewertet betroffene Benutzergruppen sind bekannt abhängige Services sind geprüft Service Desk wurde informiert Kommunikation wurde vorbereitet Erfolgskriterien beziehen sich auf Servicequalität Incidents nach dem Change werden geprüft Failed Changes werden im Service Review betrachtet geplante Wartung wird korrekt berichtet Checkliste Zusammenspiel mit Service Configuration Management Service besitzt dokumentierte CIs kritische Abhängigkeiten sind sichtbar Single Points of Failure sind bekannt Owner und Supportgruppen sind aktuell Lieferantenbeziehungen sind dokumentiert Zertifikate und Schnittstellen sind berücksichtigt Kritikalität ist nachvollziehbar Configuration-Daten werden bei SLA-Planung genutzt Datenfehler aus Reviews werden korrigiert Änderungen aktualisieren die CMDB Checkliste Zusammenspiel mit Knowledge Management häufige Incidents besitzen passende Artikel Known Errors sind auffindbar Workarounds sind dokumentiert Eskalationskriterien sind beschrieben Service Desk nutzt Knowledge aktiv Knowledge-Lücken werden ausgewertet Artikel nach Changes aktualisiert Benutzerwissen ist verständlich häufige Suchanfragen werden analysiert Knowledge-Nutzung wird im Service Review betrachtet Checkliste Zusammenspiel mit Supplier Management kritische Lieferanten sind bekannt Lieferantenverträge unterstützen SLA-Ziele Supportzeiten sind kompatibel Eskalationswege sind dokumentiert Wartungsfenster sind abgestimmt Lieferantenleistung wird gemessen Vertragsverletzungen werden analysiert Lieferantenrisiken sind dokumentiert Alternativen oder Workarounds sind geprüft Supplier Reviews fließen in Service Reviews ein Checkliste Service Review über alle Practices SLA-Ziele und Ist-Werte geprüft Incident-Trends betrachtet Major Incidents bewertet offene Problems und Known Errors geprüft Changes und Releases bewertet Configuration-Risiken betrachtet Knowledge-Lücken berücksichtigt Lieferantenleistung bewertet Benutzerfeedback einbezogen kommende Risiken und Anforderungen betrachtet Verbesserungen priorisiert Owner, Termin und Erfolgskriterium festgelegt Bedeutung für Fachinformatiker für Systemintegration Fachinformatiker liefern wichtige technische Informationen für das Zusammenspiel der Practices. Im Arbeitsalltag bedeutet das: Incidents dem richtigen Service und CI zuordnen, Wiederherstellungszeiten sauber dokumentieren, wiederkehrende Fehler an Problem Management melden, Changes auf Serviceauswirkungen prüfen, technische Abhängigkeiten nachvollziehbar pflegen, Monitoring aus Serviceperspektive ausrichten, Knowledge-Artikel und Runbooks aktualisieren, Lieferantenabhängigkeiten sichtbar machen, und Verbesserungen technisch umsetzen und überprüfen. 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 8.1 Service Level Management – Ziele, Begriffe und Grundlagen 8.2 SLA, SLR, OLA und Underpinning Contracts 8.3 Kennzahlen, Messmethoden und Reporting 8.4 Service Reviews und Continual Improvement Incident Management Problem Management Change Enablement Service Configuration Management Knowledge Management Supplier Management Monitoring and Event Management Measurement and Reporting Continual Improvement Quellen und Versionsstand Offizielle Grundlagen PeopleCert – ITIL Practice Guide: Service Level Management PeopleCert – ITIL Practice Guide: Incident Management PeopleCert – ITIL Practice Guide: Problem Management PeopleCert – ITIL Practice Guide: Change Enablement PeopleCert – ITIL Practice Guide: Service Configuration Management PeopleCert – ITIL Practice Guide: Knowledge Management PeopleCert – ITIL Practice Guide: Supplier Management PeopleCert – ITIL Practice Guide: Monitoring and Event Management PeopleCert – ITIL Practice Guide: Measurement and Reporting PeopleCert – ITIL Practice Guide: Continual Improvement ITIL Foundation – Version 5 ITIL Service – Version 5 Einordnung Die dargestellten: Informationsflüsse, Rollenbeiträge, Schnittstellen, Checklisten, Ablaufdarstellungen, und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: Schnittstellenmatrix, SLA-Prozessintegration, Incident- oder Problem-Priorisierung, Change-Bewertungsvorlage, Service-Review-Struktur, Reporting-Form, oder Toolintegration für alle Organisationen vor. Die konkrete Umsetzung muss an: Services, Kunden, Benutzergruppen, Risiken, Service Levels, Supportmodell, Organisationsstruktur, Lieferanten, Toollandschaft, Datenqualität, 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