Zum Hauptinhalt springen

SLA - Dienstgütevertrag

Service Level Agreement (SLA) legen das Serviceniveau fest - Dienstleistungsvereinbarungen

Service Level Agreement

Ein Service Level Agreement (SLA) ist eine Vereinbarung zwischen einem IT-Service-Provider (Leistungserbringer) und einem IT-Kunden (Leistungsbezieher) zu IT-Leistungen (IT-Services/IT-Dienstleistungen). Das Leistungsversprechen wird als Beilage verpflichtend zum Vertrag beigelegt. Das SLA bildet eine wichtige Grundlage für das IT-Leistungs-Monitoring.

Die IT-Dokumente Service Level Agreement (SLA) und Operational Level Agreement (OLA) verwenden idR. identische Strukturen. Die folgenden Angaben zu den Service Level Agreements gelten daher gleichermaßen für OLAs.

Das Service Level Agreement (SLA) ist ein Bestandteil einer IT-Leistungsbeschreibung in einen IT-Servicekatalog. Im IT-Referenzmodell ITIL wird für SLAs der Begriff WARRANTIES verwendet. Es bestimmt im Einzelnen die Service-Level-Ziele (Quality of Service Levels), die gegenseitigen Verantwortlichkeiten sowie andere Anforderungen für einen IT-Service und einen bestimmten Kunden oder eine bestimmte Kundengruppe. Der Schwerpunkt bei der Beschreibung von SLAs liegt auf der messbaren Spezifikation der Quality of Service Targets zu den Non-Functional-Anforderungen aus Sicht des Kunden. Das SLA-Dokument entwickelt sich während des Service-Design-Prozesses aus den Service-Level-Anforderungen (Service Level Requirements, SLR). Ein Bezug zu den Service-Level-Anforderungen (SLRs) ist daher für eine nachvollziehbare Ableitung der Servicelevel-Objektives sinnvoll.

Operational Level Agreement

Das Operational Level Agreement (OLA) ist eine Vereinbarung zwischen einem IT-Service-Provider und einem anderen Teil derselben Organisation oder IT-Lieferanten über die Lieferung von IT-Leistungen.

Im SLA wird der geforderte Servicegrad für den vom Leistungserbringer betriebenen Service eindeutig, konsistent und messbar definiert. Der objektive Nachweis der Servicequalität hilft, Meinungsverschiedenheiten zu vermeiden. Ziel ist es, zwischen dem Leistungsbezieher und dem Leistungserbringer das gleiche Verständnis über den zu erbringenden Service zu schaffen. Das SLA schafft Transparenz über die Servicequalität für beide Vertragsparteien und ermöglicht, Anforderungen des Leistungsbeziehers und Leistungen des Leistungserbringers zu vertretbaren Kosten in Einklang zu bringen.

Die Bereitstellung eines abgestimmten SAL-Frameworks ist ein Arbeitsprodukt der IT-Prozesse IT-Qualitätsmanagement, IT-Servicelevel-Management und IT-Monitoring und Eventmanagement sowie des IT-Vertragsmanagements.

SLA-Typen​

In vielen Fällen wird eine SLA-Struktur mit verschiedenen Typen verwendet, um doppelte Inhalte und häufige Änderungen zu vermeiden.

  1. Unternehmensorientierte SLAs befinden sich auf Unternehmens-Ebene. Sie enthält Regelungen, die für eine gesamtes Unternehmens getroffen werden. ZB. werden für den IT-Service Cloud-Storage eine Gesamtkapazität für ein Unternehmens vereinbart.
  2. Serviceorientierte SLAs befinden sich auf der Einzelservice-Ebene. Sie enthält spezifische Regelungen für ausgewählte, bestimmte Services. Dieser Typ wird meist bei IT-Infrastruktur-Services verwendet. ZB. werden für den IT-Service IT-Gästewlan spezifische Ausprägungen zur Verfügbarkeit, Kapazität, IT-Sicherheit etc. festgelegt.
  3. Kundenorientierte SLAs befinden sich auf der Kunden-Ebene. Sie enthält Regelungen, die für einen bestimmten Kunden oder eine Kundengruppe im Unternehmen gelten, unabhängig von den genutzten Services. ZB werden für die Kundenlösung SmartMetering mit den Servicenutzer individuelle Vereinbarungen getroffen.

Bedeutung von SLAs​

SLAs stellen eine grundlegende Vereinbarung zwischen dem IT-Team und IT-Kunden dar und sind damit ein wichtiger Aspekt beim Aufbau von Vertrauen. Sie beschreiben die Kundenerwartungen, sodass dein Team weiß, für welche Aspekte es zuständig ist. Der Einsatz von SLAs ermöglicht ein gemeinsames Verständnis darüber, was von den Services erwartet wird. Dein IT-Team kann in verschiedener Hinsicht von der Implementierung von SLAs profitieren.

  • Formalisierung der Kommunikation: Gespräche mit Stakeholdern über IT-Probleme können schwierig sein. Der IT-Serviceanbieter muss über die Erwartungen des IT-Kunden hinsichtlich der Serviceleistung im Bilde sein. Ein SLA ermöglicht es Stakeholdern, strukturierte Gespräche auf Basis bereits vereinbarter Bedingungen zu führen und diese für die Kommunikation zu verschriftlichen.
  • Stärkung der Beziehung der IT zu Kunden: SLAs reduzieren Bedenken hinsichtlich Risiken, sodass das Vertrauen zwischen den Parteien wächst. SLAs definieren, was im Falle eines Verstoßes geschieht, und reduzieren so Unsicherheiten.
  • Verbesserung der Produktivität und Arbeitsmoral: SLAs definieren die Dringlichkeit eingehender Anfragen. Sie ermöglichen es IT-Teams, sich auf die eingehenden Probleme zu konzentrieren, die am wichtigsten sind.

SLA-Qualitätskriterien - Domain Requirements​

IT-Service-Level-Agreements (SLAs) definieren die vereinbarten Leistungsniveaus zwischen einem IT-Dienstleister und seinem Kunden. Um die Qualität dieser Leistungen zu gewährleisten, werden verschiedene Qualitätskriterien - auch Non Functional Domain Requirements bezeichnet - festgelegt. Diese von den ITIL-Prozessen abgeleiteten IT-Metriken dienen als Maßstab zur Bewertung der erbrachten Leistungen und zur Sicherstellung der Kundenzufriedenheit.

Wichtige Qualitätskriterien bei IT-SLAs sind:

  1. Qualitätsziel zur Verfügbarkeit des IT-Services (aus den ITIL-Prozess Availability Management).
    1. Betriebszeit (BZ) - Uptime des IT-Services.
    2. Verfügbarkeitsklassen (VK) des IT-Services nach dem nach „9er System".
    3. Ausfallzeit - Downtime des IT-Services - Mean Time Between Failures (MTBF), Mean Time To Repair (MTTR)
    4. Wartungszeit - Maintenance Time des IT-Services
  2. Qualitätsziel zur Verfügbarkeit und Kompetenz des IT-Supports (IT-Prozessen mit Customer Touchpoints).
    1. Supportzeit - Servicezeit des IT-Supports definiert den Zeitraum, in dem Nutzer technische Unterstützung erhalten können und der Service-Desk besetzt ist.
    2. Reaktionszeit des IT-Supports bei Anfragen.
    3. Rufbereitschaftszeit von IT-Mitarbeitern außerhalb seiner regulären Arbeitszeit für Notfälle.
    4. Erstlösungsquote - First Call Resolution (FCR) bei Anfragen und Störungen ist ein Qualitätsmaß für die Kompetenz der Service-Mitarbeiter.
    5. CSAT - Customer Satisfaction - Kundenzufriedenheit mit IT-Support aus Anwendersicht. Net Promoter Score (NPS).
  3. Qualitätsziel zur Performance des IT-Services (aus dem ITIL-Prozess Capacity Management).
    1. Performance-Tiers beschreibt das Leistungsniveau (Basic, Enhanced, High-Performance Computing) in Bezug auf Mengenausprägungen und Ausstattung.
    2. Antwortzeit - Resonse Time des IT-Services beschreibt die Leistungsfähigkeit eines IT-Services in Bezug auf Geschwindigkeit hinsichtlich Benutzerfreundlichkeit.
    3. Arbeitslast - Workload beschreibt die Gesamtheit der Aufgaben, die an ein IT-System gestellt werden.
    4. Process-Controls zu IT-Performance-Monitoring and Logging.
    5. Process-Controls zu Prüfzyklen zur IT-Performance-Nachweisen.
  4. Qualitätsziel zur IT-Riskio- und Notfallmanagement IT-Services (aus dem ITIL-Prozess Continuity / Contincency Management).
    1. Verfügbarkeitsstufe - Availability Level (AL) des IT-Services um Auswirkungen (Business Impact) bei Ausfällen zu klassifizieren.
    2. Wiederherstellzeit - Mean Time to Repair (MTTR) des IT-Services gibt an, wie lange es im Durchschnitt dauert, ein ausgefallenes IT-Service wieder in Betrieb zu nehmen.
    3. Recovery Time Objective (RTO ist eien Maß der Widerstandsfähigkeit gegen Ausfälle.
    4. Backup-Häufigkeit - Zeitrahmen.
    5. Process-Controls zu Prüfzyklen zur IT-Backup & Recovery-Nachweisen.
  5. Qualitätsziel zur IT-Security der IT-Services (aus dem ITIL-Prozess Security Management, CISP)
    1. IT-Schutzniveau - Protection-Level (PL) des IT-Services beschreibt den Grad der Sicherheit, den eine Organisation für ihre IT-Systeme und -Daten anstrebt und umsetzt. Meist auch eine Compliance-Vorgaben (siehe NIS2).
    2. Patchmanagement-Level.
    3. Process-Controls zu IH-Zyklus zu Patches.
    4. Process-Controls zu Prüfzyklen zur IT-Patchmanagement Nachweisen.
  6. Qualitätsziel zur IT-Dokumentation der IT-Services (aus dem ITIL-Prozess Knowledge Management).
    1. IT-Service-Knowledgebase-Level je IT-Service beschreibt den Dokumentationsgrad.
    2. IT-Dokumentationsstufen je IT-Service
    3. Process-Controls zu Prüfzyklen zur IT-Dokumentation.
  7. Andere Domain Requirementsje
    1. IT-Service-Maturity je IT-Service beschreibt den Reifegrad des IT-Services anhand von Prüfkriterien.
    2. IT-Controlling-Stufen beschreibt das Leistungsniveau des IT-Services in Bezug auf IT-Controlling.

SLA-Canvas - Einblick​

Ein SLA-Canvas ist ein visuelles Werkzeug, um die Erstellung und das Verständnis von Service-Level-Agreements (SLAs) zu vereinfachen. Es bietet eine strukturierte Möglichkeit, relevanten Aspekte eines SLA in einem einzigen Dokument übersichtlich darzustellen. Die im SLA-Canvas angeführten IT-Servicelevel-Targets sind konkrete, messbare Qualitätsiele zum jeweiligen IT-Service, die definieren, wie gut ein IT-Dienst funktionieren soll. Sie sind ein zentraler Bestandteil von Service Level Agreements (SLAs) und dienen dazu, die Qualität und Verfügbarkeit von IT-Services zu gewährleisten.

platinus-SLA-Framework-compact

Abbildung platinus-SLA-Framework-compact (Bildquelle = platinus)

Warum ein SLA-Canvas?

  • Übersichtlichkeit: Komplexe Informationen werden übersichtlich und auf einen Blick erfassbar.
  • Kommunikation: Erleichtert Diskussionen und stellt sicher, dass alle Beteiligten auf dem gleichen Stand sind.
  • Collaboration: Ermöglicht eine gemeinsame Entwicklung des SLA durch alle Beteiligten.
  • Dokumentation: Dient als lebendiges Dokument, das jederzeit aktualisiert werden kann.

Bei IT-Organisationen mit einen hohen Prozessreifegrad beim IT-Prozess IT-Service-Levelmanagement ('grösser gleich 3 Process Maturity) können weitere Qualitätskriterien (Non-functional Requirements) und somit auch Q-Ziele zum IT-Service ergänzt werden. Die Abbildung zeigt die umfassende Ausprägung des platinus-SLA-Frameworks.

platinus-SLA-Framework-complete

Abbildung platinus-SLA-Framework-complete (Bildquelle = platinus)

SLA-Chart​

Ein SLA-Chart (Service Level Agreement Chart) ist ein Diagramm oder eine Tabelle, die die vereinbarten Planwerte (TO-BE) und die tatsächlichen Messwerte (AS-IS) zur Kommunikation der Einhaltung der im Service Level Agreement (SLA) festgelegten Leistungskennzahlen (KPIs) visuell darstellt. Die Grenzwerte (Threshold-Values) zeigen dabei, wieweit Abweichungen vom Zielwerte zulässig sind. Insgesamt ist ein SLA-Chart ein nützliches und übersichtliches Werkzeug für das Management von Dienstleistungsvereinbarungen und die Sicherstellung der Kundenzufriedenheit.

SLA-Contract - Durchblick​

Ein Service Level Agreement (SLA) enthält in der Regel die folgenden Informationen (die effektive inhaltliche Ausgestaltung hängt vom jeweiligen Servicetyp ab):

Bezeichnung des Services​

Freigabeinformationen​

(mit Ort und Datum)

  1. Service Level Manager
  2. Verantwortlicher Vertreter des Service-Kunden

Laufzeit des Vertrages​

  1. Beginn- und Endedatum
  2. Regelungen bezüglich Verlängerung und Beendigung der Vereinbarung (ggf. auch Regeln für eine vorzeitige Vertragsbeendigung).

Beschreibung/ angestrebtes Kundenergebnis​

  1. Nutzen aus Geschäftssicht.
  2. Kundenseitige Business-Prozesse/ Aktivitäten, die vom Service unterstützt werden.
  3. Link auf die Serivebeschreibung mit Utility and Warranty
    1. Angestrebtes Ergebnis in Bezug auf Utility (Nutzen, z.B.: "Außendienstmitarbeiter haben jederzeit und von jedem Ort aus Zugriff auf die Unternehmensanwendungen xxx und yyy").
    2. Angestrebtes Ergebnis in Bezug auf Warranty (Gewährleistung, z.B.: "Hohe Verfügbarkeit während der Bürozeiten in den Lokationen ...").

Kommunikation zwischen Kunde und Service-Provider​

  1. Verantwortliche Kontaktperson auf Kundenseite mit Kontaktdaten.
  2. Zuständiger Business Relationship Manager auf Seite des Service-Providers mit Kontaktdaten.
  3. Berichtswesen (Inhalte und Intervalle der vom Service-Provider zu erstellenden Service-Berichte).
  4. Verfahren zur Behandlung von Ausnahmen und Beschwerden (z.B. im Falle einer Beschwerde bereitzustellende Informationen, vereinbarte Antwortzeiten, Eskalations-Prozedur).
  5. Kundenzufriedenheits-Umfragen (Beschreibung des Verfahrens zur regelmäßigen Ermittlung der Kundenzufriedenheit).
  6. Service-Reviews (Beschreibung des Verfahrens zum regelmäßigen Durchführen von Service-Reviews mit Beteiligung des Kunden).

Service- und Asset-Kritikalität​

  1. Liste unternehmenskritischer Assets in Zusammenhang mit diesem Service
    1. Vital Business Functions (VBFs, unternehmenskritische Geschäftsprozesse), die von dem Service unterstützt werden
    2. Sonstige kritische Assets, die im Rahmen des Services genutzt werden (z.B. bestimmte Arten von Geschäftsdaten)
  2. Geschätzter Schaden für das Unternehmen durch Verlust des Services oder von Assets (ausgedrückt in finanziellen Beträgen oder unter Verwendung eines Klassifizierungsschemas)

Servicezeiten​

  1. Zeiten, zu denen der Service zur Verfügung stehen muss
  2. Ausnahmen (z.B. Wochenenden, Feiertage)

Erforderliche Support-Typen und -Levels​

  1. Vor-Ort-Support
    1. Bereich/ Standorte
    2. User-Typen
    3. Zu unterstützende Anwendungen und Infrastrukturkomponenten
    4. Reaktions- und Lösungszeiten (nach Prioritäten, Definition von Prioritäten z.B. für die Einordnung von Incidents)
  2. Remote Support
    1. Bereich/ Standorte
    2. User-Typen (User-Gruppen mit Zugang zum Service)
    3. Zu unterstützende Anwendungen und Infrastrukturkomponenten
    4. Reaktions- und Lösungszeiten (nach Prioritäten, Definition von Prioritäten z.B. für die Einordnung von Incidents)

Service-Level-Anforderungen/ -Ziele​

  1. Verfügbarkeitsziele und -verpflichtungen
    1. Bedingungen, unter denen der Service als nichtverfügbar gilt (z.B. falls der Service an verschiedenen Standorten erbracht wird).
    2. Ziele im Hinblick auf Verfügbarkeit (genaue Festlegung der Art und Weise, wie die vereinbarten Availability Levels auf der Grundlage der vereinbarten Servicezeiten und Ausfallzeiten berechnet werden).
    3. Ziele im Hinblick auf Zuverlässigkeit (von einigen Kunden gefordert, in der Regel definiert als MTBF (Mean Time Between Failures – durchschnittliche Zeit zwischen zwei Ausfällen) oder MTBSI (Mean Time Between Service Incidents – durchschnittliche Zeit zwischen zwei Service Incidents))
    4. Ziele im Hinblick auf Wartbarkeit (von einigen Kunden gefordert, in der Regel definiert als MTRS (Mean Time to Restore Service – durchschnittliche Zeit bis zur Wiederherstellung des Services)).
    5. Downzeiten für Wartung (Anzahl erlaubter Downzeiten, Ankündigungsfristen).
    6. Einschränkungen bei der Wartung, z.B. erlaubte Wartungsfenster, saisonale Wartungbeschränkungen und Verfahrensweisen bei der Ankündigung geplanter Service-Unterbrechungen.
    7. Definitionen von Major Incidents sowie Notfall-Changes und -Releases zur Behebung dringender Problemen, einschließlich Verfahrensweise bei der Ankündigungen von ungeplanten Serviceunterbrechungen.
    8. Anforderungen an das Availability-Reporting.
  2. Capacity/Performance-Ziele und -Verpflichtungen
    1. Benötigte Kapazität (Ober-/Untergrenze) für den Service, z.B.
      1. Anzahl und Art von Transaktionen
      2. Anzahl User und User-Typen
      3. Business-Zyklen (täglich, wöchentlich) und saisonale Schwankungen
    2. Antwortzeiten der Anwendungen.
    3. Anforderungen an die Skalierbarkeit (Annahmen über die mittel- und langfristige Zunahme der Auslastung und Inanspruchnahme des Services).
    4. Anforderungen in Bezug auf das Capacity- und Performance-Reporting.
  3. Verpflichtungen in Bezug auf Service Continuity (Verfügbarkeit des Services im Katastrophenfall)
    1. Zeitraum, innerhalb dessen ein festgelegter Service Level wieder erreicht sein muss
    2. Zeitraum, innerhalb dessen normale Service Levels wiederhergestellt sein müssen

Technische Standards/ Spezifikation der Service-Schnittstelle​

Verpflichtende technische Standards und technische Spezifikation der Service-Schnittstelle

Verantwortlichkeiten​

  1. Pflichten des Service Providers
  2. Pflichten des Kunden (Vertragspartner)
  3. Verantwortlichkeiten der Service-Nehmer (z.B. in Bezug auf IT-Sicherheit).
  4. IT-Sicherheitsaspekte, die bei der Nutzung des Services zu beachten sind (ggf. Verweis auf die entsprechenden IT-Sicherheitsrichtlinien).

Preismodell​

  1. Basispreis für die Serviceerbringung.
  2. Regelungen für Vertragsstrafen/ Rückverrechnungen.

Change-Historie zu diesem Vertrag​

Liste der Anhänge und Verweise​

(z.B. auf eine mitgeltende SLA-Master-Vereinbarung)

Glossar​

(falls erforderlich)

Einrichten von SLAs und Leistungsmessung​

SLAs zwingen der IT-Service-Provider die vereinbarten Leistungen zu messen. Daher spielen die IT-Monitoring und IT-Logging eine große Rolle. Die SLAs legen eine Baseline für das Monitoring & Logging fest.