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