Über unsMediaKontaktImpressum
Dr. Robert Scholderer 08. November 2016

Service Level Agreements effektiv managen

Service Level Agreements (SLAs) effektiv managen gelingt, wenn der IT-Betrieb geregelt ist und wenn die IT-Services klar umrissen sind. Erst auf dieser Basis können die SLAs wirksam zusammengestellt werden. Ziel dieses Artikels ist es, ein Konzept aufzuzeigen das den Zuschnitt der SLA-Dokumente gestaltet und die IT-Servicebeschreibung strukturiert.

Ein neuralgischer Punkt dabei ist die Problematik, IT-Services zu beschreiben. Dies soll an einem einfachen Vergleich verdeutlicht werden. Die Autoindustrie, Druckerei, Weberei haben es gezeigt. Nur Produkte von der Stange lassen sich massenfähig anbieten und absetzen. Dieser Schritt ist in der IT ebenfalls nachzuholen. Doch sind Automobile, Bücher und Kleidung anfassbare einzukaufende Produkte, die in der IT erst klarer umrissen werden. Es finden sich Analogien bei der Übertragung oder beim Hosting. Dies verhält sich bei Applikationen anders, sie sind vielfältig und müssen in ein Schema eingepasst werden, damit eine konfektionsnahe Leistungserbringung möglich ist. 

Die kommenden Abschnitte zeigen, welche Strukturen geschaffen werden müssen, um die Vielfalt an Leistungen so zu kanalisieren, dass ein Konzept entstehen und produktiv zum Einsatz gebracht werden kann. Hierzu ist es besonders wichtig, die Transparenz von IT-Services zu untersuchen.

1. Analyse der Transparenz von IT Leistungsbeschreibungen

Die Leistungskategorien, die sich in der Praxis bewähren, sind ein zentraler Ausgangspunkt in dieser Analyse. Dabei müssen wir u.a. unterscheiden, welche Aspekte in Zusammenhang gebracht werden dürfen. 

Die derzeitigen Leistungsbeschreibungen zeigen das Dienstleistungsspektrum von Betreibern im Gesamten auf. Häufig findet man, dass die betrieblichen Abläufe (z.B. Einkauf) mit dem technischen Dienstleistungsspektrum, z.B. Email-Service, gekoppelt sind – in der Form, dass die Verfügbarkeit eines Arbeitsplatzes sich zusammensetzt aus der Bereitstellungszeit eines Arbeitsplatzes mit Emailbetrieb. Eine Trennung des Email-Services und eine Leistungsbeschreibung der Arbeitsplätze ist erforderlich, um einen Überblick zu behalten. In dem genannten Beispiel würde sich ein negatives Feedback von Kunden des Rechenzentrums nicht klar zuordnen lassen. Ist der Kunde unzufrieden, weil der Service Email nicht wie vereinbart läuft oder weil der Arbeitsplatz nicht ordnungsgemäß funktioniert? Solchen Unschärfen gilt es entgegenzutreten. Zu vermeiden ist die Vermischung der betriebswirtschaftlichen Herangehensweise mit Qualitätsaspekten. Die fehlende Trennung zwischen Abläufen und technischen Leistungen erschwert eine servicenehmergerechte Auswertung der im laufenden IT-Betrieb erbrachten Leistung. Das Ergebnis: Ist mit der IT unzufrieden – und diese Haltung ist subjektiv und schwer verbesserbar.

Diese Situation ist so zu strukturieren, dass Betreiber und deren Kunden ein gemeinsames Verständnis über die erbrachten, bzw. ausgelagerten Dienste erhalten. Im Folgenden wird ein Modell zur Strukturierung der Leistungsaspekte vorgestellt, das anschließend zu einer Standardisierung führt und in Service Level Agreements übernommen werden kann. Um dies zu erreichen, werden die technischen und betrieblichen Sichten aufeinander abgestimmt, um die Unterschiede in der Herangehensweise zu verdeutlichen und die neuralgischen Punkte zu erkennen.

Hierzu müssen für folgende Punkte Festlegungen getroffen werden: 

  1. Definition der zu modellierenden Dienstleistungen;
  2. Bestimmung des Niveaus der Dienstmodellierung.

Für beide Punkte liegen nur isolierte Arbeiten vor. Der Anspruch eines generischen Modells wird dabei nicht erreicht. Im SOUSIS-Ansatz ist das Verständnis über die Geschäftsbeziehung zwischen zwei Outsourcing-Partnern geprägt. In 2015 wurde das entworfene SOUSIS-Modell im vom Bundesministerium für Forschung und Entwicklung geförderten SLA-Richtliniendokument für Cloud-Services neben COBIT, ISO und ITIL zu den Standards gezählt. Das Akronym SOUSIS des Modellnamens steht dabei für:

S O U S I S
SLA OLA UC Service-Katalog IT-Rahmenvertrag Service-Level-Kalkulator

Was ist die Leistung am Kunden? Diese Frage ausführlich zu behandeln, führt zu einem gemeinsamen Begriffsverständnis, auf das sich beide Seiten verständigen, um im Falle einer Unzufriedenheit die IT-Leistung beim Namen nennen zu können. 

2. Vorgehensmodell zur Beschreibung von IT-Leistungen

Jedes IT-Unternehmen sollte in einer transparenten Form die Leistung, die zum Kunden hin angeboten wird, formulieren. Viele Modellierer sind im Einsatz, um die Leistung und die zugehörigen Prozesse zu beschreiben. Einige Gremien kümmern sich darum, wie dies aussehen kann. So ist das Ergebnis für bestimmte Zielgruppen entweder sehr generisch, wie bei ITIL, oder nur für eine einzige Zielgruppe, wie bei eTOM, beschrieben. Ein leicht verständliches Gesamtkonzept ist wichtig. Dieses Gesamtkonzept ist für den IT-Betrieb wichtig und wird in diesem Abschnitt vorgestellt.

Ziel des Vorgehensmodells

Das Vorgehensmodell greift diese Problematik auf und definiert entlang der Anforderungen praktikable und betriebssichere Strukturen. Der Einsatz dieser Strukturen muss auf die Geschäftswelt anwendbar sein, also verschiedene Betriebsabläufe sowie Vertragsbeziehungen berücksichtigen und zugleich die Technik so beherrschen, dass die IT-Services kundenorientiert konfektioniert werden können.  

Im Folgenden werden die essentiellen Anforderungen für das Vorgehensmodell definiert. Das Vorgehensmodell muss für die Konfektionierung von IT-Services die Anforderungen aus diesen drei Bereichen abdecken. Abb.1 verdeutlicht dies.

Die Betriebsstrukturen, Geschäftsstrukturen und die Technologien stellen unterschiedliche Anforderungen, die im Folgenden beschrieben sind:

Anforderungen aus bestehenden Betriebsstrukturen

Anforderungen an das Vorgehensmodell ergeben sich aus Betriebsstrukturen. Diese Strukturen werden im Rechenzentrum aufgebaut, um einen kontrollierten Ablauf im Betrieb zu gewährleisten. Dieser kontrollierte Ablauf ist insbesondere bei der Konfektionierung von Leistungen zu gewährleisten. Hierfür muss das Vorgehensmodell eine probate Lösung liefern.

Die Betriebsstrukturen unterscheiden sich in jedem IT-Betrieb, auch wenn Standards wie ITIL eingehalten werden. Das Vorgehensmodell muss einerseits den Standards genügen, andererseits genügend Flexibilität aufweisen, um generisch anwendbar zu sein. Folgende Anforderungen werden an das Vorgehensmodell gestellt.

Anforderungen aus entstehenden Geschäftsstrukturen

Die Anforderungen die aus dem Betrieb gestellt wurden, zeigen, dass dies nur eine Sichtweise ist. Weitere Anforderungen werden über das Management gestellt. Im konkreten sind damit juristische Geschäftsstrukturen zu betrachten. Entscheidend sind dabei die Vertragspartner und die Leistungsgeber und –nehmer. Diese Geschäftsstrukturen müssen so unterstützt werden, dass sie die Geschäftsbeziehungen, z.B. Provider – Servicenehmer, Provider – Zulieferer, etc. ermöglichen. An das Vorgehensmodell werden somit Anforderungen aus diesen Bereichen gestellt. Diese lassen sich wie folgt ausführen:  

Anforderungen durch technologische Gegebenheiten

Die Vielzahl von technischen Systemen, die in Rechenzentren eingesetzt werden, stellen neue Herausforderungen und somit Anforderungen an das Vorgehensmodell.

In den nachstehenden Abschnitten werden die Objekte umfassend erläutert:

Ablaufbeschreibung zum SOUSIS-Modell

Die Ablaufbeschreibung wird unterteilt in den Standardablauf, die OLA-Erweiterung und die UC-Erweiterung. 

Der Standardablauf beschreibt, wie man die im Servicekatalog dokumentierten Services in das Service Level Agreement übernimmt und um weitere vertragsrelevante Aspekte erweitert.  Anschließend wird die Einordnung des SLAs bzgl. Rahmenverträge etc. vorgenommen. Die agierende Rolle ist dabei das Rechenzentrum, das gegenüber Kunden die IT-Services beschreibt und verkauft. 

Muss das Rechenzentrum interne IT-Abteilungen zur Erbringung einer Kundenleistung koordinieren, so wird eine OLA-Erweiterung erforderlich. Diese Erweiterung beschreibt, wie z.B. mehrere am Service eines Kunden beteiligten IT-Abteilungen ihre Qualität dokumentieren und diese im SLA abstimmt festlegen.

Befindet sich das Rechenzentrum in der Rolle, dass es von externen Unternehmen Leistungen beziehen muss, um die Leistung gegenüber dem Kunden zu erbringen, so sind die nach ITIL definierten "Underpinning Contracts" (UC) erforderlich. Diese müssen ebenfalls mit dem SLA des Rechenzentrums, das als Generalunternehmer gegenüber dem Kunden auftritt, abgestimmt sein. Hierfür müssen besonders die Service Levels (SL) entsprechend kalkuliert sein. 

Die Abb.2 zeigt, wie das Vorgehen im Gesamten dargestellt ist.

Standardablauf 
Den Einstiegspunkt beim Standardablauf bietet der Servicekatalog. Die zentralen im IT-Betrieb vorliegenden IT-Services müssen erhoben werden. Dabei werden vom Servicekatalog wesentliche Strukturen vorgegeben, sodass eine einfache Erhebung der Services aus dem IT-Betrieb möglich ist. Zu jedem Dienst liegen nach Fertigstellung des Servicekatalogs die zentralen Parameter zu Serviceklasse, -betrieb und -überwachung, unabhängig von einer konkreten Kundenbeziehung, vor. Diese Vorarbeit ist zwingend im Vorfeld zu leisten, um die Service Levels und weitere relevante Parameter miteinander vergleichen zu können. Ebenfalls gelten unternehmensweite Service Levels, die im Servicekatalog als übergeordnete Service Levels gekennzeichnet sind und für alle Services gelten.

Aus dem Servicekatalog heraus, werden die Leistungen für das Service Level Agreement zusammengestellt. Der Servicekatalog ist als Vorstufe für das Service Level Agreement zu verstehen. Die einzelnen Dienste sind atomar aufgebaut, sodass sie wie Module behandelt und für den Kunden individuell zusammengestellt werden können. Durch die Normierung können die Werte zu den Diensten nach der Zusammenstellung miteinander abgeglichen werden, sodass eine homogene Kundenlösung entsteht. Müssen mehrere Dienste gegenüber einem Kunden für getrennte Geschäftszwecke – z. B. Callcenter, Buchhaltung, Logistik – gekoppelt werden, so können diese in einem SLA zusammengefasst sein oder in mehrere SLAs aufgetrennt werden. 

Um die Homogenität der Lösung für den Kunden zu gewährleisten, können die Wertebereiche der übergeordneten Service Levels nur reduziert werden, nicht jedoch ausgeweitet werden. Eine Ausweitung kann eine starke Beeinflussung für den täglichen Betriebsablauf des IT-Personals bedeuten. 

Nachdem die Leistungen des Servicekatalogs im SLA abgestimmt sind, werden die Verantwortlichkeiten zwischen beiden Vertragsparteien verhandelt. Dabei sind die Punkte Verantwortung, Durchführung, Mitwirkung und Informationspflicht zur kontinuierlichen Leistungserhaltung und -erbringung gemeinsam zu klären. 

Nachdem das Service Level Agreement in seiner Ausprägung umfassend beschrieben ist, wird es dem entsprechenden IT-Rahmenvertrag zugeordnet. Somit sind im Wesentlichen die technischen Rahmenbedingungen festgelegt. Eine Weiterführung der organisatorisch abzustimmenden Werte erfolgt im IT-Rahmenvertrag. Im vorliegenden Ansatz wurde darauf geachtet, dass das SLA und der IT-Rahmenvertrag überschneidungsfrei aufgebaut sind. Dies erleichtert die Handhabung bei Änderungen durch neu hinzukommende, sich ändernde oder wegfallende Leistungen. Eine Besonderheit ist z. B. die Trennung von Verantwortlichkeiten im SLA und den Verantwortlichen im IT-Rahmenvertrag, die namentlich erwähnt sind und gegenzeichnen müssen. Somit bleiben auch Änderungen auf den IT-Rahmenvertrag begrenzt und sind dadurch ebenfalls beherrschbar.

Der IT-Rahmenvertrag verweist u. a. auf bestimmte unternehmensinterne Dokumente, die z. B. bestimmte Abläufe definieren. Ein zentrales Dokument, dem hier eine besondere Stellung zukommt, ist die Minderungsregelung. Hier wird definiert, wie bei Leistungsverzögerung oder -ausfall im konkreten Fall vorgegangen wird. Dies sind meist Regelungen, die erst ab einem festgelegten Niveau der Leistungsminderung eintreten und eine Reduzierung der Leistungsverrechnung ergeben.

OLA-Erweiterung
Nachdem der Standardablauf erfolgt ist, kann es wie oben genannt zu Erweiterungen kommen. Der interne Betrieb größerer Rechenzentren ist meist in einzelne IT-Abteilungen für z. B. Serverbetrieb und Applikationshosting aufgeteilt. Werden gegenüber Kunden komplexe Leistungen angeboten, die aus den IT-Services der jeweiligen Abteilungen zusammengesetzt werden, so sind Operation Level Agreements nach ITIL zu definieren. Das Modell greift diese Tatsache auf und setzt es über ein gemeinsames Template um. Sowohl die Strukturen des Servicekatalogs, als auch die im Service Level Agreement enthaltenen, kommen hier analog zum Einsatz. Es sind auch die Basisleistungen der IT in einem oder mehreren Servicekatalogen zu definieren. Nach dem Angebot aus dem Servicekatalog, können die einzelnen IT-Abteilungen ein oder mehrere Services in einem OLA zusammenstellen und diesen abstimmen. Basierend auf diesen OLAs, können jetzt die Werte und Service Levels mit einem Service Level Agreement verglichen und abgestimmt werden. 

Innerhalb der OLA-Erweiterung ist ein Service Level Kalkulator aufzubauen, der zur Darstellung und gegenseitigen Berechnung von Service Levels dient. Aus dem Kalkulator werden anschließend die Werte in den jeweiligen OLAs oder SLAs übernommen. Aufgrund des Szenarios, dass Leistungen von "unten" eingekauft und "oben" angeboten werden, ergibt sich meist die Richtung, dass die OLAs maßgeblich das SLA beeinflussen und entscheiden.

UC-Erweiterung
Werden externe Unternehmen bei der Erbringung von IT-Services vertraglich eingebunden, so spricht man lt. ITIL von Underpinning Contracts. Letztlich sind diese Verträge analog zu SLAs zu verstehen. Denn Verträge kommen u. a. auch durch andere Umstände zustande, sodass der direkte Bezug zu einem aktuellen Kundenprojekt zum Vertragsabschluss nicht gegeben war. Wird z. B. eine Netzleistung eingekauft und später mehrfach für den Transport von IT-Applikationen verwendet, so wird aus der Sicht des Providers aus dem SLA ein Underpinning Contract. Die UC-Erweiterung ist flexibel in das gesamte Vorgehensmodell einfügbar. Es sind jedoch einige Besonderheiten besonders zu berücksichtigen. 

  • Die Leistungen sind meist nicht in einem IT-Servicekatalog definiert. Jedes Unternehmen definiert eigene Services. Für diesen Fall müssen die Services dennoch entsprechend normiert werden. Die UC-Erweiterung leistet dies indem das UC das SLA-Template verwendet und somit konform zum OLA und SLA wird. Über diesen Mechanismus lassen sich heterogene, von externen Unternehmen kommende Leistungen normieren.
  • Die UC-Erweiterung setzt sich aus dem Standardablauf und der OLA-Erweiterung zusammen. Vom Standardablauf werden das SLA-Template und das Konzept zur inhaltlichen Trennung im IT-Rahmenvertrag übernommen. Im IT-Rahmenvertrag können ggf. andere Aspekte auftreten, sodass eine inhaltliche Trennung als kleinster gemeinsamer Nenner umsetzbar ist. 
  • Aus der OLA-Erweiterung wird der Service Level Kalkulator verwendet, um die Abstimmung zwischen SLA und OLA vornehmen zu können. 

Für das Vorgehensmodell gilt, dass zum Standardablauf die OLA-Erweiterung sowie die UC-Erweiterung dynamisch hinzugefügt werden können. Dies ist insbesondere dann wichtig, wenn bereits Verträge neu verhandelt werden oder bereits bestehen und zur Anwendung kommen. 

3. Servicekatalog

Der Servicekatalog dient dazu, die IT-Leistungen, die das Rechenzentrum anbietet, in einer einheitlichen Systematik zu beschreiben. Dabei werden alle relevanten Leistungen einem Service zugeordnet. Ziel ist es, die Erstellung von SLAs adäquat zu unterstützen und stark zu formalisieren. 

Der Servicekatalog ist eine Leistung der IT-Produktion. Die Pflege und Aktualisierung wird innerhalb der IT-Produktion in Absprache mit den internen IT-Abteilungen vorgenommen. Weitere Zuständigkeiten sind nicht definiert und gesondert abzusprechen. 

Struktur des Servicekatalogs

Der Servicekatalog ist ein wichtiges Hilfsmittel, um auf Kundenanforderungen optimal zu reagieren oder Service Level Agreements präzise erstellen zu können.

In Abb.3 sind die wichtigsten Elemente und deren Anordnung dargestellt.

Die folgende Konzeption wurde für den Aufbau des Servicekatalogs verwendet. 

Es sind die Vorgänge des Prozesses Service Level Management beschrieben, die erforderlich sind, um den Servicekatalog auf die SLAs anwenden zu können. Zusätzlich sind hier die zentralen Werte, die den Betrieb der Services operativ ermöglichen, explizit genannt. Diese Werte sind die "übergeordneten Service Levels" und gelten für alle Dienste und sollten für spezielle Leistungen nicht verändert werden. 

Das Element "Service" nimmt alle Leistungen mit einem vordefiniertem Template auf. Für das Element Service können zusätzlich Kategorien definiert werden, um bei vielen Services eine Strukturierung zu erhalten. Diese ist nicht bindend und kann ggf. aufgegeben werden. Letztlich kommt nur der Service zum Tragen. Diese Flexibilität ist deshalb wichtig, da Services je nach Anwendungsfall unterschiedlich strukturiert werden müssen. Eine starre Hierarchie ist aus diesem Grund nicht sinnvoll und dauerhaft aufrecht zu halten. 

An das Element Service schließt der Bereich "Begriffe und Definitionen" an. Hier werden ähnlich wie bei einem Glossar die Begriffe eingeführt und kurz erläutert, sowie bestimmte Definitionen für Kennzahlen vorgenommen. 

Das abschließende Element wird gesondert zu den Services definiert und behandelt die Kosten, die für einen Service berechnet werden. Diese komprimierte Darstellung aller Services in einer Preisliste erlaubt ein kontinuierliches Aktualisieren der Kosten. Weiterhin kann der Servicekatalog ggf. auch ohne Preisliste an Kunden zur Ansicht weitergegeben werden. Dies ist szenariospezifisch zu berücksichtigen, denn für eine IT-Lösung mittels Services können und müssen bestimmte Bereiche auch individuell kalkuliert werden, sodass eine starre Preisliste kontraproduktiv und somit nicht zielführend wäre.

Der Servicekatalog kann jedoch nicht als vollständiges Kompendium betrachtet werden, das alle Anforderungen im Speziellen behandeln kann. Die zentralen Charakteristika eines Dienstes werden prägnant beschrieben und bestimmte wiederkehrende Serviceklassen vereinheitlicht dargestellt. Ebenfalls wird die Zuteilung betrieblicher Zuständigkeiten dem Verhandlungsprozess überlassen. Der Servicekatalog dient dazu, die Eckpunkte eines Services festzulegen. In der konkreten Umsetzung müssen diese, wie in "Anwendung des Servicekatalogs" beschrieben, ausgestaltet werden. Der Servicekatalog beschränkt sich auf die Erbringung des Services. Die Auslieferung von Diensten mit Lieferzeiten, werden hier nicht berücksichtigt und sind gesondert im Service Level Agreement beschrieben. 

Im folgenden Abschnitt werden die einzelnen Elemente und deren Flexibilität beschrieben.

SLM-Prozess

Der Service Level Management-Prozess besteht aus einer Vielzahl von Rollen, die sich gemeinsam abstimmen müssen, um die IT-Lösung an den Kunden auszuliefern. Um Unstimmigkeiten über die Art des zu liefernden Services zu vermeiden, dient dieser Prozess zur Präzisierung der gegenseitigen Erwartungshaltung. 

Die Ausprägung des Service Level Management unterscheidet sich deutlich an der Art der IT-Leistungen, die ein Rechenzentrum anbietet. Werden kleinere und stark vorkonfektionierte Lösungen für bestimmte Zielgruppen angeboten, so wählt der Kunde aus dem Servicekatalog aus und anschließend kommt der Vertrag zustande. Anders verhält sich das Service Level Management für große IT-Lösungen – z. B. Outsourcing von 4.000 Servern und 600 Applikationen. Deutlich ist, dass auch hier ein Servicekatalog benötigt wird, um die Komplexität zu beherrschen. Die Abstimmung durch alle Abteilungen ist dennoch erforderlich, da bestimmte Details zu klären sind. Das Service Level Management verringert diesen Anteil, indem der Servicekatalog um entsprechende Parameter ergänzt ist. 

Der Ablauf des Service Level Management sieht wie folgt aus: Der Kunde kann aus einem Servicekatalog, oder einem vorkonfektionierten Serviceangebot, seinen benötigten Service auswählen. Entweder entsteht direkt der Vertrag, oder es sind Treffen einzuberufen, um die Anforderungen seitens des Kunden genauer abzustimmen.

Im Service Level Management entsteht der erste Entwurf eines SLAs für den Kunden. Hierfür können ggf. bereichsbezogene Abstimmungen stattfinden. Anschließend wird der intern abgestimmte Entwurf mit dem Kunden diskutiert. Je nach Status des SLA, erfolgt eine neue Iteration, oder es wird der Entwurf als Vertrag formuliert. Die Bereiche Vertragsmanagement und IT-Controlling übernehmen hier die tragende Rolle. Es entsteht der Auftrag und das SLA wird zusammen mit einem IT-Rahmenvertrag verabschiedet. 

Übergeordnete Service Levels

Die übergeordneten Service Levels gelten für alle Services im Servicekatalog. Alle weiteren erforderlichen Service Levels sind bei den einzelnen Services spezifisch festgelegt.

Ziel der übergeordneten Service Levels ist es, einen Betriebsstandard zu prägen und die Erstellung und Verwaltung von SLAs zu vereinfachen. Die Anforderung nach übergeordneten Service Levels resultiert aus der Tatsache, dass bei der Untersuchung von Rechenzentren jeder Service individuell erscheint. Die Analyse zeigt auch, dass eine Diskrepanz zwischen dem tatsächlich gelebten operativen Geschäft und den Betriebsunterlagen existiert. Häufig sind in den Betriebsunterlagen ITIL-konforme Prozesse mit allen potentiellen Ausprägungen beschrieben und bewertet. Das Tagesgeschäft in Rechenzentren zeigt, dass am User Helpdesk und in der Störungsbearbeitung ein Reglement eingehalten wird, man sich intern auf den kleinsten gemeinsamen Nenner geeinigt hat. Die übergeordneten Service Levels nehmen diesen Aspekt auf und definieren dies explizit. Sodass die Werte im Servicekatalog die Rechenzentrumsrealität genauer beschreiben. Sichergestellt werden soll eine kontinuierliche Betriebsstabilität, die auch im Service Level Management bekannt sein muss.  

Die übergeordneten Service Levels fassen somit die wichtigsten Eckpunkte des Betriebs des Providers zusammen. Zu diesen Eckwerten zählen z. B. Zeiten aus dem IT-Betrieb. 

Beispiel
Das nachstehende Beispiel zeigt die Kernzeit im Rechenzentrum und ist als bedienter Betrieb ausgewiesen. Werden Wartungen vorgenommen, so erfolgen diese innerhalb vordefinierter Wartungsfenster. Die Erreichbarkeitszeiten werden klar definiert. In diesem Beispiel wird das Gewicht auf die Transparenz des IT-Betriebs gelegt und die Quantifizierung nicht näher erläutert.

Tabelle 1: Beispiel übergeordneter Service Levels

Betrieb  
Bedienter Betrieb Mo. – Fr. 08:00 -18:00 (System, Datenbank)
Wartungszeit Di. 20:00-23:50 Jeder 2. Samstag im Monat 18:00 – 24:00
(Ausnahme: Applikation XYZ Di. 08:00-12:00 Uhr)
Erreichbarkeitszeiten  
Service Desk Mo.- Fr. 07:00 – 20:00
Sa. 08:00 – 16:00
2nd Level Mo. – Fr. 07:00 – 20:00
3rd Level Mo. – Fr. 07:00 – 20:00 (7:00-19:00)
Unbedienter Betrieb (Rufbereitschaft)  
Service Desk keine Rufbereitschaft
2nd Level Außerhalb des bedienten Betriebs
3rd Level Außerhalb des bedienten Betriebs
Reaktionszeit  
1st Level Prio 1 binnen 1 Stunde
2nd Level Prio 2 binnen 3 Stunden
3rd Level schnellstmöglich

Es ist offensichtlich, dass der Betrieb der Services unabhängig von bestimmten SLAs nach einem definierten Schema abläuft. Dieses Schema wird in den übergeordneten Service Levels klar definiert.

Service

Ein Service wird durch mehrere Aspekte charakterisiert. Jeder Service ist in folgende Kategorien unterteilt: Kurzbeschreibung, Serviceklasse, Servicebetrieb und Serviceüberwachung. Unter diesen Kategorien werden alle relevanten Serviceparameter beschrieben. 

Serviceklasse
Innerhalb der Serviceklasse werden Kennzahlen wie Verfügbarkeit, Antwortzeit und Bandbreite definiert und mögliche Levels zum überwachten Betrieb angegeben.

Die nachstehende Tabelle zeigt ein Beispiel:

Tabelle 2: Beschreibung von Serviceklassen

Services Verfügbarkeit pro Monat (%) Durchschnittl. Antwortzeit (sec.) pro Monat Überwachter Betrieb (365 Tage p.a.)
z.B. SAP R/3 99,0 %
98,0%
97,0%
4 msec
7 msec
10 msec
24 Std.* 7 Tage
16 Std.*5 Tage
8 Std.*5 Tage

Aus dem Beispiel geht hervor, dass Serviceklassen, wie Gold, Silber oder Bronze, schwer zu definieren sind. Dies ist bei dedizierten Services möglich, bei komplexen Services ist dieses Prinzip nicht mehr haltbar. Speziell für die Konfektionierung von IT-Services ist dies ein Problem. Ein durchgängiges Serviceklassenmodell ist nur für einen Parameter, z.B. Verfügbarkeit, umsetzbar. Bei mehreren Parametern kann eine Konfektionierung nur innerhalb eines Parameters erfolgen. Wählt ein Kunde unterschiedliche Levels aus, so beschränkt sich die Darstellung der Serviceklasse ausschließlich auf die genannten Werte.   

Servicebetrieb
Der Servicebetrieb legt Parameter wie Priorität von Störungen eines Services, Anzahl betroffener User, Reaktionszeit und Wiederherstellungszeit fest. Also Aspekte, die zum Betrieb des Services von Bedeutung sind. In der Tabelle sind Beispiele aufgeführt.

Tabelle 3: Störungsprioritäten

Priorität Anzahl betroffener User Reaktionszeit Wiederherstellungszeit
1 > 1000 20 min 60 min
2 1000=> User > 500 30 min 120 min
3 <=500 40 min 180 min
4 sonstige 60 min 360 min

Deutlich wird, dass dem Kunden keine explizite Auswahl aufgezeigt wird. Dies begründet sich darin, dass die Parameter sich am Betrieb und der Technik orientieren. Gezeigt wird wie Störungen schnellstmöglichst bearbeitet werden. 

Serviceüberwachung
Zur Überwachung des Services sind der Leistungsübergabepunkt, das Monitoring und das Reporting zu definieren. Der Leistungsübergabepunkt beschränkt sich bei Installationen auf die System-Router, Gateway und Port. An diesen Systemen werden Services übergeben. Die Tabelle gibt vor, um welches System es sich handelt, an welchem Standort es vor untergebracht ist und welche Netzadresse zugeteilt wurde. Werden mehrere Übergabepunkte für einen Service definiert, so kann auch eine Sammeladresse verwendet werden.

Tabelle 4: Struktur für Leistungsübergabepunkte

Beschreibung Standort (Servicenehmer/-geber, Straße, Raum) Netzadresse (IP-Adresse)
Router xxx.xxx.xxx.xxx
Gateway xxx.xxx.xxx.xxx
Port xxx.xxx.xxx.xxx

Das Monitoring konzentriert sich auf die Messung des Services. Dabei ist entscheidend, an welchen Stellen die Messung vorgenommen wird. Der Leistungsübergabepunkt definiert hier die Stelle, an der eine Messung vorzunehmen ist. Die Methode, welche Messung zum Einsatz kommt, wird in dieser Kategorie definiert. 

Beispiel: Am Servicenehmerstandort wird ein aktiver MessPC installiert, der mit einem Roboter über definierte Klickstrecken das Benutzerverhalten (z. B. Login, selektive Useraktionen) auf kritischen Applikationen simuliert. Die Messung wird alle 10 Minuten vorgenommen.

Wie im Beispiel vorgestellt, wird auch der Messtakt definiert, somit wird die Messtoleranz transparent. 

Das Reporting definiert, welche Aspekte gegenüber Kunden als Leistungsnachweis verwendet werden. 

Beispiel: Reporting (Alle Reports sind online verfügbar)

  • Darstellung der Netzwerktopologie
  • Ausfallstatistik (Standorte, Datum, Beginn, Ende, Dauer, Ursache, Problemlösung, Priorität)
  • Gerätekonfiguration (HW+ SW-Version) / Änderungen des Monats, Systemkonfig. Changes
  • Portstatus (enabled/disabled) je Komponente (inkl. der gelagerten Switche)
  • Ressourcen mit Ansprechpartner/Tel., Lokationsdaten, Inbetriebnahme 
  • Erstellung und Pflege einer Auftragsübersicht
  • Lesen von Calls im Trouble-Ticket-System auf 10 User limitiert

Zusätzlich zu den Reportingaspekten wird u. a. auch der Abruf definiert (z. B. monatlich, tagesaktuell.

Mit den Punkten Serviceklasse, Servicebetrieb und Serviceüberwachung sind die zentralen Eckwerte zu einem Service definiert und können später für ein SLA übernommen werden.

Definitionen

Damit die im Servicekatalog angegebenen Parameter klar definiert sind, müssen die jeweiligen Definitionen hierfür getroffen werden. Zu den Kennzahlen werden im folgenden Definitionen geliefert.

Tabelle 5: Definition von zentralen Begriffen

Kennzahl Definition
Verfügbarkeit Analog zur Antwortzeit gelten die Zeitpunkte für die Messung. Kann keine Antwortzeit ermittelt werden, gilt die Nichtverfügbarkeit.
Die Gesamtverfügbarkeit wird pro Monat ermittelt und berechnet sich nach folgender Formel:

TSLA-Laufzeit: Dienste, die zwischen Servicegeber und Servicenehmer vereinbart werden, sind zeitlich begrenzt. Der Zeitraum der Messung wird auf die SLA-Laufzeit beschränkt.
TWartungsfenster: Zeiträume, in denen der Service durch geplante und abgestimmte Wartungsarbeiten nicht bereitgestellt wird.
TNichtverfügbarkeit: Zeitraum, in dem der Service ungeplant nicht zur Verfügung steht. Er berechnet sich aus der Summe der einzelnen Ausfälle.
Reaktionszeit Die Reaktionszeit wird wie folgt definiert:

RZ = EZPReaktion - SZPReaktion

RZ: Reaktionszeit
SZPReaktion: Der Startzeitpunkt referenziert auf den Zeitstempel im Trouble Ticket System, nachdem eine Störung am Service Desk gemeldet wurde und als Ticket formuliert ist.
EZPReaktion: Der Endzeitpunkt ist durch den Zeitstempel im Trouble Ticket System gekennzeichent, nachdem ein Problembearbeiter festgelegt wurde.

Deutlich wird, dass speziell bei Kennzahlen die Verrechnung selten ein Problem darstellt. Wichtiger ist die Definition von Beginn und Ende der Messung. D. h. die im Betrieb abgenommenen Zeitstempel müssen eindeutig sein. Weiterhin ist zu beachten, dass die Zeitstempel weitestgehend automatisch protokolliert werden. Ansonsten ist ein kontinuierliches Messen nicht möglich.

Kostendarstellung

Die Kostendarstellung wird dem Servicekatalog kompakt beigefügt. Dabei beschränkt sich die Darstellung auf die Werte Mengeneinheit und Preis. Die Positionsnummer ist geeignet anzufügen, um die Vielzahl der Leistungen geeignet dokumentieren zu können und somit die Kundenkommunikation bei der Fertigstellung einer Offerte zu erleichtern.

Tabelle 6: Kostenstruktur

Positions-nummer SAP ID Servicename Preismodell für Einzelpreis Georderte Menge Gesamtpreis
01 00001 Rail IP      

4. Service & Operation Level Agreement und Underpinning Contracts

Wenn davon ausgegangen wird, dass ein Servicekatalog definiert ist, so stellt sich die Frage, ob dies bereits genügt. Denn wenn der Kunde seinen Service und seine Leistungsklasse gewählt hat, dann wäre alles geregelt? Dies ist nicht der Fall. Das Service Level Agreement nimmt die ausgewählten Bestandteile auf, erweitert diese um zusätzliche Zusicherungen. Die meisten Unternehmen unterschätzen oftmals die Bedeutung der vereinbarten Service Level Agreements. Beispielsweise ist zu regeln, ab wann bei Überschreitung der SLA-Werte die ersten finanziellen Kompensationen geleistet werden. Dabei ist entscheidend, ob absolute, verbindliche Grenzwerte oder Mittelwerte definiert sind und nicht durch Formulierungen wie "in der Regel" oder "normalerweise" verwässert werden. Alle angegebenen Werte sollten genau beschrieben sein, sodass Messungen zum Nachweis zweifelsfrei möglich sind und nicht nur bloße Zahlen im Vordergrund stehen.

Für Service Level Agreements, Operation Level Agreements und Underpinning Contracts wird ein einheitliches Template verwendet. Dieses Template ist in Abb.5 umgesetzt.

Die Module des Service Level Agreements werden in den anschließenden Unterabschnitten beschrieben.

Leistungsbeschreibung

Die Leistungsbeschreibung umfasst die Punkte Betreibermodell und Beistellleistung.

Beistellleistung
Basierend auf dem Betreibermodell wird die konkrete Leistung, die im einzelnen zu erfüllen ist, beschrieben. Diese Leistungspunkte dienen später zur Verdeutlichung der Verantwortlichkeiten.

Beispiel: Das Rechenzentrum bietet als Beistellleistung für die Leistungserbringung Folgendes an:

  • Kalkulation der erforderlichen Leistungsgrößen
  • Bereitstellung der für die IT-Services erforderlichen Lizenzen
  • Beschaffung von IT-Arbeitsplätzen
  • Bestückung und Vorkonfektionierung von IT-Arbeitsplätzen
  • Einrichten der Useraccounts
  • Auslieferung der IT-Arbeitsplätze
  • Inbetriebnahme der IT-Arbeitsplätze
  • Abnahme der Lieferleistung der zu erbringenden IT-Services
  • Übernahme der Lösung in die Produktionsumgebung
  • Aufrechterhaltung des kontinuierlichen Betriebs
  • Fernwartung von IT-Arbeitsplätzen
  • Aktualisierung von Securitymodulen
  • Aufrechterhaltung von Securitymodulen
  • Information bei betrieblichen Veränderungen (z. B. Rollout)
  • Monitoring und Reporting der bereitgestellten Services
  • Bereitstellung eines 24x7-Services für Problemmeldungen

Derartige Leistungen lassen sich für IT-Unternehmen normiert aufbauen und ggf. in einem Aufgabenverzeichnis dokumentieren. Für dieses Modell ist es zweckmäßiger, dass die Aufgaben in den zentralen Templates zur Vorkonfektionierung von SLAs, OLAs oder Underpinning Contracts bereitgestellt sind. Diese prägnante Leistungsbeschreibung mit zusätzlichem Fokus auf die Verantwortlichkeiten leistet die Abbildung hin zum Kunden und dessen Verständnis der Leistung.

Installation

Die zur Durchführung der Installation bereitzustellenden Systeme, sowie die entsprechenden Lieferzeiten, werden im Template des Service Level Agreements hinterlegt. Bei den bereitzustellenden Systemen ist auf folgende Kategorien zu achten.

Tabelle 7: Bereitstellungskomponenten

Systeme Beispiel Beschreibung Wachstum
Software Alle im Warenkorb definierten Services
 - Softwarepakete und dazugehörige Lizenzen.
 
Storage Startmenge ist 1.000 GigaByte zum Produktivstart. Prognostiziertes Wachstum jährlich ca. 15 Prozent.
Hardware - Hardware mit einem maximalen Lebenszyklus von drei Jahren.
- Ausfallsichere Plattensubsysteme gespiegelt über zwei Standorte.
- Netzwerkkomponenten ab Leistungsübergabepunkt ins Netz des Rechenzentrums.
 

Über die Kategorie Wachstum, kann die Nachlieferung bereits im Vorfeld geklärt werden, sodass die Nachlieferung entsprechend kontrollierbar ist und konfektioniert für die Abwicklung vorbereitet ist.

Zeiten
Die Lieferzeit kann sich neben den oben genannten Systemen u. a. auch auf Einrichtungswerte beziehen. Dabei sind Aspekte für die Bereitstellungszeit, Anzahl der einzurichtenden Benutzer, geeignet zu berücksichtigen.

Tabelle 8: Struktur zur Modellierung der Bereitstellungszeit

Bereitstellungszeit nach Auftragserteilung Anzahl der Citrix-Useraccounts Bemerkung
2 Wochen <=50  
4 Wochen 50< Accounts <= 100  
8 Wochen > 100  

Das Anlegen, Ändern oder Löschen von Useraccounts erfolgt nach Abstimmung zwischen einem Vertreter des Servicenehmers und des Servicegebers im Regelfall innerhalb von 5 Werktagen.

Tabelle 9: Struktur zur Beschreibung der Einrichtungszeit

Einrichtungszeiten von Useraccounts Anzahl der User Bemerkung
2 Tage <=50  
4 Tage 50< User <= 100  
8 Tage > 100  

Übergeordnete Service Levels

Die übergeordneten Service Levels werden aus dem Servicekatalog ohne Veränderung übernommen. Sollten Einschränkungen stattfinden, so ist es sinnvoll, dies in den gesonderten Vereinbarungen vorzunehmen. 

Service

Aus dem Servicekatalog heraus werden die entsprechenden Services genommen und für Kundendienst-Services zusammengestellt. 

Tabelle 10: Vereinbarte IT-Services im SLA

Services Verfügbarkeit pro Monat (%) Durchschnittl. Antwortzeit (sec.) pro Monat Überwachter Betrieb (365 Tage p.a.)
SAP R/3 97,5 % 5 sec 24 Std. * 7 Tage
Citrix 97,5 % 5 sec 24 Std. * 7 Tage
Banking 97,5 % 5 sec 24 Std. * 7 Tage
Webapplication 97,5 % 5 sec 24 Std. * 7 Tage

Die jeweiligen Parameter sind im Vorfeld über den Servicekalkulator abgestimmt.

Gesonderte Vereinbarungen

Einige Absprachen müssen individuell mit Kunden vorgenommen werden. Zum Beispiel die Absprachen zu Wartungsfenstern, die außerhalb eines vordefinierten Zeitraums liegen. Die nachstehende Tabelle zeigt, wie dies vorgenommen werden kann.

Tabelle 11: Wartungsfenster

Service Beschreibung Wartungsfenster / Wartungsankündigung
Individuell vereinbarte Wartung (z. B. zum Anwendungs-Releasewechsel) In Ab- und Rücksprache mit den betroffenen Anwendern / Verantwortlichen, nachts zwischen 22:00 und 6 Uhr. Zur vereinbarten Zeit
Die Termine sind 7 Werktage im Voraus anzumelden.
Beseitigung akuter kritischer Störungen (Prio 1 und 2) Frühestmögliche Zeit, nach Rücksprache mit den betroffenen Verantwortlichen.
Benachrichtigung betroffener Anwender.
Innerhalb von 15 Minuten an Eschborner Werktagen;
Innerhalb von 30 Minuten in der übrigen Zeit

Die Ergänzung um weitere Vereinbarungen oder Einschränkungen im Servicekatalog vordefinierter Serviceklassen, erfolgt durch das Hinzufügen der jeweiligen Bedingung in diesem Abschnitt.

Verantwortlichkeiten

Entsprechend der Leistungsbeschreibung werden die Aufgaben zwischen Servicenehmer und  -geber in einer Zuständigkeitsmatrix aufgeteilt. Dabei werden drei Tätigkeitstypen unterschieden:

  • V = Verantwortlich
  • D = Durchführung
  • M = Mitwirkung

Tabelle 12: Verantwortlichkeitsmatrix

Bereich Servicenehmer Servicegeber
Kalkulation der erforderlichen Leistungsgrößen V/D
Bereitstellung der verbindlichen Lizenzen V/D
Accountmanagement von Citrix-Userprofilen V/D
Aktualisierung von Securitymodulen V/D
Aufrechterhaltung von Securitymodulen V/D
Information bei betrieblichen Veränderungen (z. B. Rollout) V/D
Monitoring und Reporting der bereitgestellten Services V/D

Zur weiteren Auftrennung der Verantwortlichkeiten werden zusätzliche Aufgaben abgestimmt. Diese resultieren z. T. aus den Mitwirkungspflichten seitens des Servicenehmers. 

Tabelle 13: Verantwortlichkeiten zur Bereitstellung seitens Servicenehmer

Bereich Servicenehmer Servicegeber
Update und Upgrade von Soft- und Hardwaresystemen V/D
Führung von Benutzerlisten und Profilen V D
Bereitstellung der Bürostellplätze V/D 
Bereitstellung der IT-Arbeitsplätze | V/D |
Bereitstellung eines Messsystems | V/D |
Bereitstellung der Stromversorgung / inhouse Verkabelung | V/D |
Bereitstellung Local Area Network (LAN) | V/D |
Bereitstellung Wide Area Network (WAN) | | V/D
Bereitstellung Leistungsübergabepunkt | V/D | V/D

5. Service Level Kalkulator

Der Service Level Kalkulator dient zur Abstimmung der Service Levels aus den OLAs und den Werten für die SLAs. Der Kalkulator umfasst die Bereiche:

  • Antwortzeit 
  • Verfügbarkeit
  • Wartungsfenster

Für diese Kennzahlen können die Werte klar bestimmt werden. Je nach Anwendungsfall – also vollständige Outsourcing- oder Teiloutsourcing-Lösung – sind die Werte gekennzeichnet.

Die im Operation Level Agreement vereinbarten IT-Services, sowie deren Service Levels, werden zusammengefasst. Somit entsteht ein Überblick über die tatsächlichen Leistungen, die einzelne Abteilungen eines Rechenzentrums erbringen. Gegenüber Kunden werden jedoch nur einige Komponenten benötigt. Diese werden für die im SLA vereinbarte Leistung ausgewählt und kalkuliert. Die Verfügbarkeit im Service Level Agreement ist das Produkt aus den Teilleistungen. Dabei können diese Werte nur als Kalkulation verstanden werden. Sie liefern das obere Limit, mit dem eine IT-Leistung im SLA vereinbart werden sollte. Die einzelnen Applikationen können jedoch besser abschneiden. Die Kalkulation der Werte über Komponenten oder Teilleistungen aus den Abteilungen, sind für die Messmethode nicht ausschlaggebend. Ob ein Service Level Agreement eingehalten wird, lässt sich somit unabhängig von der Messmethode nachweisen.  

6. IT-Rahmenvertrag

Der IT-Rahmenvertrag behandelt im Wesentlichen die organisatorischen Aspekte, die zur Anwendung kommen. Dabei sind folgende Kategorien konkret berücksichtigt worden:

  • Verwaltung: Innerhalb dieser Kategorie sind alle Verfahren und ihre Beteiligten festgelegt. Eine Erweiterung um neue Verfahren kann durch das kontrollierte Hinzufügen problemlos erfolgen.
  • Leistungen: Die Leistungen sind hier inhaltlich beschrieben, sodass die in der IT zur Verrechnung vorkommenden Aspekte aufgezeigt sind. Das Hinzufügen weiterer Leistungen kann einfach vorgenommen werden.  
  • Sonstige Bestimmungen: Hier handelt es sich im Wesentlichen um Mitwirkungspflichten, die auf beiden Seiten gelten. 

Der IT-Rahmenvertrag dient als Vorlage für typische Outsourcingprojekte, die unabhängig von der vollständigen Outsourcing- oder Teiloutsourcing-Lösung angewendet werden kann.

7. Zusammenfassung

Durch die Festlegung der Semantik von Begriffen, wird die anschließende Anwendung der Begriffe in der Leistungsbeschreibung zu einer einfachen Handlung, die klar vollzogen werden kann. Ebenfalls bringt der Einfluss aus der Technik einen Beitrag, um ein klares Bild entstehen zu lassen. 

Die zusätzlichen Kennzahlen zeigen, wie man Leistungen parameterisieren kann. Die Kennzahlen sind u.a. von zentraler Bedeutung, denn durch sie wird die IT-Factory gesteuert und die Leistung gegenüber dem Kunden entsprechend geregelt. Sofern dieser sich auch an die Vereinbarung und Mitwirkungspflichten hält. Typisches Praxisbeispiel ist das Beziehen einer höheren Leistung durch mehr Arbeitsplätze, sofern diese der Servicenehmer in seiner eigenen Hoheit hat. Aber auch hier helfen Kennzahlen, wenn das Mengengerüst dadurch auch nach oben hin entsprechend formalisiert wird. 

Innerhalb des oben genannten Abschnitts wurde der Umgang mit den Kennzahlen u.a. noch nicht vorangetrieben. Überlegungen, wie man die Verfügbarkeit steigern kann oder die Antwortzeit verbessert, sind noch außen vor. 

Die Frage wie die Leistung beschrieben werden kann, ist bereits erfolgt. Es fehlen jedoch die im Business gelebten Strukturen, in die diese Basisfunktionen Einzug halten. Der kommende Schritt befasst sich mit der Konfektionierung von Leistungen. Objekte wie Servicekatalog, Kennzahlensystem und Service Level Agreement müssen für den IT-Betrieb definiert werden.

Weitere Informationen:

Dr. Robert Scholderer: SLA. SERVICE Level Agreements.

Autor

Dr. Robert Scholderer

Robert Scholderer arbeitet als Service-Level-Manager und Servicekatalog-Manager für Konzerne. Er befasst sich seit Mitte der 90er-Jahre mit Outsourcing-Verträgen. In seiner beruflichen Laufbahn hat er mehr als 1.000 SLAs...
>> Weiterlesen
Bücher des Autors:

botMessage_toctoc_comments_9210