Checkliste SLA OLA UC

<seo metakeywords="itil sla, itil ola, itil uc, sla checkliste" metadescription="Die Checkliste Service Level Agreement (SLA) gilt gleichermaßen für die ITIL-Dokumenttypen OLA und UC, die identische Strukturen verwenden: ..." />

ES - EN - Checkliste SLA OLA UC - Vorlage SLA OLA UC

ITIL-Prozess: ITIL V3 Service Design - Service Level Management bzw. Supplier Management

Checklisten-Kategorie: Checklisten ITIL V3 Service Design

Quelle: Checkliste "Checkliste Service Level Agreement (Service-Level-Vereinbarung, SLA), Operational Level Agreement (Vereinbarung auf Betriebsebene, OLA), Underpinning Contract (Vertrag mit Drittparteien, UC)" aus der ITIL-Prozesslandkarte V3

 

Diese Checkliste dient als Vorlage für ein Service Level Agreement (SLA), Operational Level Agreement (OLA) bzw. einen Underpinning Contract (UC).

Die drei Dokumenttypen verwenden identische Strukturen:

• Service Level Agreement (SLA) – eine Vereinbarung zwischen einem IT Service Provider und einem Kunden
• Operational Level Agreement (OLA) – eine Vereinbarung zwischen einem IT Service Provider und einem anderen Teil derselben Organisation über die Lieferung von Infrastruktur-Services
• Underpinning Contract (UC) – ein Vertrag zwischen einem IT Service Provider und einer Drittpartei, die einen Infrastruktur-Service erbringt

Da UCs formelle Verträge mit externen Suppliern sind, können sie Verweise auf allgemeine Geschäftsbedingungen oder auf einen zusätzlichen ersten Abschnitt mit kaufmännischen und rechtlichen Einzelheiten enthalten.

 

Die folgenden Angaben zu den Service Level Agreements gelten daher gleichermaßen für die OLAs und UCs, wobei ein wichtiger Punkt zu beachten ist: Wenn ein SLA vereinbart wird, fungiert der Service Level Manager als Erbringer von Leistungen für den Kunden; bei einem OLA/ UC ist er dagegen in der Rolle des Kunden.

 

Das Service Level Agreement erweitert die Definition des Services aus dem Servicekatalog. Es bestimmt im Einzelnen die Service-Level-Ziele, die gegenseitigen Verantwortlichkeiten sowie andere Anforderungen für einen speziellen Service und einen bestimmten Kunden oder eine bestimmte Kundengruppe. Der Schwerpunkt liegt hierbei auf der Festlegung der 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 Service Level Agreement enthält in der Regel die folgenden Informationen (die effektive inhaltliche Ausgestaltung hängt vom jeweiligen Servicetyp ab):

 

1. Bezeichnung des Services
2. Freigabeinformationen (mit Ort und Datum)
   1. Service Level Manager
   2. Kunde
3. Laufzeit des Vertrages
   1. Beginn- und Endedatum
   2. Regelungen bezüglich der Beendigung der Vereinbarung
4. Beschreibung/ angestrebtes Kundenergebnis
   1. Business Justification
   2. Kundenseitige Business-Prozesse/ Aktivitäten, die vom Service unterstützt werden
   3. Angestrebtes Ergebnis in Bezug auf Utility (Nutzen, z.B.: „Außendienstmitarbeiter haben jederzeit und von jedem Ort aus Zugang zu den Unternehmensanwendungen xxx und yyy”)
   4. Angestrebtes Ergebnis in Bezug auf Warranty (Gewährleistung, z.B.: „Zugang wird weltweit auf sichere und zuverlässige Weise vereinfacht”)
5. 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)
6. Verweis auf mit geltende Verträge (z.B. auf eine SLA-Master-Vereinbarung, oder im Falle von UCs auf Verträge mit wichtigen Unter-Auftragnehmern)
7. Servicezeiten
   1. Zeiten, zu denen der Service zur Verfügung steht
   2. Ausnahmen (z.B. Wochenenden, Feiertage)
   3. Wartungszeiten
8. 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)
9. 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)
      7. Verfahrensweise bei der Ankündigungen von Serviceunterbrechungen (geplant/ ungeplant)
      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
10. Verpflichtende technische Standards und technische Spezifikation der Service-Schnittstelle
11. 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)
12. Preis der Serviceerbringung
    1. Basispreis für die Serviceerbringung
    2. Regelungen für Vertragsstrafen/ Rückverrechnungen
13. Change-Historie zu diesem Vertrag
14. Liste der Anhänge