Die Bedeutung von SLAs beim Abschluss von Serviceverträgen

Die Bedeutung von SLAs
beim Abschluss von
Serviceverträgen
von
Oxana Bisterfeld - 45043, Adriane Kempf - 33437,
Juliana Kotz - 44405, Jonas Leipert - 38901
in der Veranstaltung
Seminar
bei
Prof. Dr. habil. Thomas Thierauf
und Themenbetreuer
Dipl.-Ing. Heiko Rössel
Sommersemester 2014
4. Fachsemester
Bachelorstudiengang Wirtschaftsinformatik
Hochschule Aalen
Inhaltsverzeichnis
1 Einleitung
3
2 Definitionen
4
2.1 Service Level Agreement . . . . . . . . . . . . . . . . . . . .
4
2.2 externe vs. Interne SLAs . . . . . . . . . . . . . . . . . . . . .
4
2.3 Kunde und Dienstleistungsnehmer . . . . . . . . . . . . . . .
5
2.4 Dienstleister und Auftragnehmer . . . . . . . . . . . . . . . .
5
3 Aufbau eines SLA
5
3.1 Grundelemente . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2 Dienstleistungsbezogene Elemente
. . . . . . . . . . . . . .
8
3.3 Managementbezogene Elemente . . . . . . . . . . . . . . . .
9
3.4 Juristische Elemente . . . . . . . . . . . . . . . . . . . . . . . 11
4 Service Level Objectives
12
4.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Problemfelder . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4 Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1 Definition Verfügbarkeit . . . . . . . . . . . . . . . . . 16
1
4.4.2 Berechnung . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4.3 Beispielrechnung . . . . . . . . . . . . . . . . . . . . . 18
4.4.4 Hochverfügbarkeit . . . . . . . . . . . . . . . . . . . . 18
4.4.5 Klassifizierung . . . . . . . . . . . . . . . . . . . . . . 20
4.4.6 Problematik . . . . . . . . . . . . . . . . . . . . . . . . 22
5 Sanktionen
23
5.1 Pauschalierter Schadensersatz und Pönale . . . . . . . . . . 24
5.2 Kündigung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 Fazit
26
Literaturverzeichnis
27
Tabellenverzeichnis
30
Abbildungsverzeichnis
31
2
1
Einleitung
Die IT ist in Unternehmen mittlerweile ein Werkzeug, welches in fast allen
Tätigkeitsfeldern zur Ausführung betrieblicher Aufgaben eingesetzt wird.
Daher ist es wichtig, dass diese IT-Systeme zuverlässig zur Verfügung stehen und einwandfrei funktionieren. In der Realität ist es jedoch aufgrund ihrer Komplexität bei Problemen wie „Performance-Engpässe(n), Systemausfälle(n), Wartungsarbeiten, Inkompatibilitäten etc.“ (Berger, 2005, S. 3 [5])
teilweise aufwändig sie zu betreiben.
In Folge dieser Schwierigkeiten und Qualitätsmängel haben viele Unternehmen bereits den Schritt gemacht, ihre interne IT an dafür vorgesehene
Services auszulagern und somit den Betrieb der IT-Systeme zu optimieren.
Dieser Schritt ist unter anderem durch die einfacher vorzunehmende Vernetzung von Unternehmen und das Sinken der Transaktionskosten möglich. Die dadurch neu aufkommende Problematik beim Outsourcen oder
auch, wenn die IT intern in einer anderen Abteilung erbracht wird, ist wiederum, „dass die Anforderungen an die zu erbringenden Leistung exakt
identifiziert und beschrieben werden und Maßnahmen zur Kontrolle und
Sicherstellung der Einhaltung dieser Anforderungen etabliert werden“ (Berger, 2005, S. 3 [5]).
Um ein funktionierendes und anforderungsgerechtes Zusammenwirken zwischen Fachbereich und internen sowie externen IT-Dienstleister in Bezug
auf die Leistungserbringung zu gewährleisten, werden Service-Level-Agreements
eingesetzt. Da die Arbeitsteilung zwischen Unternehmen stetig zunimmt,
gewinnen auch diese SLAs zunehmend an Bedeutung und werden immer
wichtiger für den geschäftlichen Alltag.
3
2
2.1
Definitionen
Service Level Agreement
Der Begriff Service Level Agreement (Abk.: SLA, deutsch: Dienstgütevereinbarung) bezeichnet einen Vertrag zwischen einem Dienstleistungsanbieter und einem Konsumenten. SLAs dienen dem Konsumenten dazu, zugesicherte Leistungseigenschaften der in Anspruch genommenen Dienstleistung zu kontrollieren. Dies wird ihm durch die im SLA beschriebenen
Service Levels (deutsch: Dienstgüte) ermöglicht. Diese umfassen verschiedene Dienstleistungsparameter, welche in verschiedenen Gütestufen (Levels) zu unterschiedlichen Preisen angeboten werden und aus welchen der
Konsument wählen kann. (vgl. Wikipedia, 2014 [1])
2.2
externe vs. Interne SLAs
Bei Service Level Agreements ist zwischen externen und internen SLAs zu
unterscheiden: Externe SLAs werden zwischen zwei unabhängigen Unternehmen oder Institutionen geschlossen. Sie werden in der Regel als Underpinning Contract (Abk.: UC) bezeichnet.
Interne SLAs dahingegen sind spezielle innerbetriebliche Vereinbarungen
zwischen zwei Fachabteilungen, meist mit der unternehmensinternen ITAbteilung, die Absprachen über die Erstellung von (Teil-)Services in diesem
Bereich enthalten. Dies betrifft zum Beispiel die Verfügbarkeit des Netzwerks oder von Druck-Servern. Interne SLAs werden allgemein als Operational Level Agreements (Abk.: OLA) bezeichnet. (vgl. Frey et al., 2014, S.
12 [6])
4
2.3
Kunde und Dienstleistungsnehmer
In Bezug auf SLAs ist der Dienstleistungsnehmer eine Organisation bzw.
dessen Management. Der direkte Kunde jedoch ist dann ein Vertreter dieser Organisation. Er hat die Befugnis, „im Namen der Organisation(seinheit)
Vereinbarungen über die Inanspruchnahme von IT-Services [...] zu treffen“
(itSMF Deutschland e.V., 2005, S. 127 [7]). Der Kunde ist somit im Normalfall nicht der (End-)Anwender der IT-Services.
2.4
Dienstleister und Auftragnehmer
Der Auftragnehmer ist ein IT-Dienstleistungsunternehmen oder eine interne
IT-Abteilung, die die im SLA vereinbarten Services erbringt. Der Dienstleister bei den Verhandlungen eines SLA ist jedoch „der Vertreter einer Organisation, der befugt ist, im Namen der Organisation Vereinbarungen über
die Erbringung von IT-Services zu treffen“ (itSMF Deutschland e.V., 2005,
S. 127 [7]).
3
Aufbau eines SLA
Der Aufbau von SLAs kann kaum verallgemeinert werden, da er sehr abhängig von der jeweiligen Dienstleistung ist. Gewisse Bestandteile sollten
jedoch immer vorhanden sein und lassen sich beispielhaft wie folgt strukturieren:
5
Abbildung 1: Gliederungsvorschlag für SLAs
6
Diese Struktur wiederum lässt sich grob in vier Bereiche unterteilen:
1. Grundelemente
2. Dienstleistungsbezogene Elemente
3. Managementbezogene Elemente
4. Juristische Elemente
3.1
Grundelemente
Zu den Grundelementen gehören die Gliederungspunkte 1 bis 4 von Abbildung 1.
Die einleitende Präambel geht auf den Gegenstand des SLA ein, welcher
den Inhalt und eine Beschreibung der jeweils betreffenden Dienstleistungen einleitend darlegt. Des Weiteren wird näher auf die spezifischen Ziele
beider Parteien eingegangen. Diese können als Basis für spätere Erfolgskontrollen dienen (vgl. Frey et al., 2014, S. 12 [6]).
Außerdem müssen sowohl der Dienstleistungsanbieter als auch der Dienstleistungsnehmer, genannt Partner, mit ihren Namen, Unternehmen und
Adressen aufgeführt werden. Der Geltungsbereich beschränkt die Gültigkeit des SLA z.B. auf geographische oder organisatorische Einheiten. Dies
bietet die Möglichkeit, für verschiedene Standorte unterschiedliche Vereinbarungen zu treffen. Außerdem zählen hierzu Regelungen zum Inkrafttreten, der Laufzeit und der Beendigung des Vertrags. Besonders wichtig
hierbei sind Kündigungsregelungen, d.h. wann und wie der Vertrag gekündigt werden kann und ob es evtl. eine automatische Laufzeitverlängerung
gibt (vgl. Frey et al., 2014, S. 12 [6]).
7
3.2
Dienstleistungsbezogene Elemente
Die dienstleistungsbezogenen Elemente geben eine nähere Beschreibung
der vereinbarten Dienstleistungen. Hier werden für jede Dienstleistung
einzeln ihr jeweiliger Inhalt, ihre Qualität sowie ihre Kosten dargelegt (vgl.
Frey et al., 2014, s. 12 [6]). Hierunter fällt der Gliederungspunkt 5 von Abbildung 1.
Die inhaltlichen Angaben der Dienstleistung umfassen zum einen eine aussagekräftige Bezeichnung mit einer dazugehörenden Beschreibung, die die
wesentlichen Aspekte und Leistungen sowie die zu erwartenden Ergebnisse enthält. Damit kann der Kunde genau vergleichen, ob dies seinen gesetzten Zielen entspricht. Zum anderen sollte hier auch abgegrenzt werden,
welche Leistungen nicht enthalten sind. Des Weiteren müssen auch Teilleistungen exakt genannt werden, sofern sie zur Vollbringung der Dienstleistung gehören. Auch die Rahmenbedingungen, wie beispielsweise eine Beschreibung der Systemumgebung oder eine erforderliche Mitwirkung
des Kunden müssen an dieser Stelle genannt werden (vgl. Frey et al., 2014,
S. 12-13 [6]).
Die Qualität der Dienstleistung entspricht einer Spezifizierung des zu erbringenden Zustandes. Hierzu werden verschiedene Service Level Objectives mitsamt ihren Leistungskennzahlen (KPIs – Key Performance Indicators) definiert, die auch wieder eine aussagekräftige Bezeichnung samt Beschreibung sowie die jeweilige Berechnungsweise und ihre Bezugsobjekte
beinhalten. Eine genaue Ausführung der Kennzahlen und ihrer Berechnung
befindet sich im Punkt 4 „Service Level Objectives“.
Außerdem müssen für jede Dienstleistung die entsprechenden Kosten für
den Kunden genannt werden. Dies geschieht mit Hilfe von Preismodellen.
Hier wiederum ist zu unterscheiden zwischen fixen und variablen Abrechnungsmodellen. Bei einem fixen Preismodell ist der Preis unabhängig vom
Ausmaß der bezogenen Leistung. Eine variable Abrechnung dahingegen
ist abhängig von der konkreten Nutzung. Die Kosten setzen sich dann aus
einem Preis pro Verrechnungseinheit wie beispielsweise Zeit oder Volumen
zusammen.
8
Da der Teil zur Qualität und den entsprechenden Kosten der entscheidenste im SLA ist, ist dieser am schwierigsten zu erstellen und bietet am meisten
Diskussionspunkte und gegebenenfalls Eskalationen (vgl. Frey et al., 2014,
S. 13 [6]).
3.3
Managementbezogene Elemente
Zu den managementbezogenen Elementen gehören die Punkte 6 bis 11
von Abbildung 1.
Der Punkt Vergütung und Rechnung regelt die Art und Gestaltung der
Rechnungen sowie Zahlungsmodalitäten. Hierzu sollten vorab sowohl die
Zahlungswege und –fristen als auch der Aufbau der Rechnungen mit ihrem
Detailgrad vereinbart werden.
Das Berichtswesen beinhaltet alle Punkte zur Dokumentation, Überprüfung, Benachrichtigung und Kommunikation. Es ist erforderlich, dass das
Management permanent zur Steuerung der Dienstleistungen über den Erreichungsgrad, das heißt die tatsächlich erreichten Service Levels, informiert wird. Hierzu dienen Service Level Berichte, die den Erfüllungsgrad
der Service Levels für einen bestimmten Zeitraum dokumentieren. Diese
Berichte können auch zur Bemessung der Konsequenzen bei einer eventuellen Nichteinhaltung eines Service Levels genutzt werden. Für Zwischenfälle sollten separate Berichte erstellt werden, die den Kunden über Probleme in der Einhaltung der Service Levels informieren.
Es sollte genau festgelegt werden, in welchen Abständen diese regelmäßigen Berichte geliefert werden, damit der Kunde fortlaufend über den Stand
und Erfüllungsgrad seiner Service Levels unterrichtet ist. Auf diese Weise
kann auch reguliert werden, wie viel Information dem Kunden zukommen
soll. Wichtig dabei ist, ein ausgewogenes Mittelmaß zu finden, so dass der
Kunde nicht überflutet wird, jedoch auch keine Informationslücken entstehen. Außerdem muss bei der Definition solcher Berichte der Empfänger
und der Ersteller festgelegt werden. Die wichtigsten Angaben in einem solchen Bericht sind der Bezugszeitraum, die wesentlichen Kennzahlen sowie
das Nutzungsvolumen inklusive der hierfür angefallenen Kosten. Um die
9
Kommunikation reibungslos zu gestalten, sollte zusätzlich vorab die Übermittlungsart und das entsprechende Dateiformat vereinbart werden. (vgl.
Frey et al., 2014, S. 14 [6])
Ein weiterer unabdinglicher Punkt, der geregelt werden muss, sind die Konsequenzen bei der Abweichung von Service Levels. Es kann vorkommen, dass der Erbringungsgrad von Dienstleistungen von den vereinbarten Service Levels abweicht. Zu diesen Fällen müssen im SLA Regelungen festgesetzt werden. Dabei dient ein Soll-Ist-Vergleich als Grundlage für
die Bemessung, wobei die Service Levels der Kennzahlen mit den vereinbarten Service Levels verglichen werden. Zum einen muss klar spezifiziert
werden, wann diese Regelungen der Konsequenzen zu einer Anwendung
kommen, zum anderen sollten darüber hinaus Eskalationsstufen angegeben werden, denen genaue Beträge zugeordnet werden. Die Bemessung
solcher Beträge sollte aber in einem angemessenen Verhältnis zur Abweichung vom Service Level stehen.
Die Konsequenzen teilen sich dabei in Sanktionen bei der Nichterbringung
eines Service Levels auf der einen Seite und in Boni bei Überfüllung auf
der anderen Seite. Beide lassen sich wiederum sowohl in monetärer als
auch in nicht-monetärer Form regeln. Boni kommen dem Anbieter zugute
und sollen diesem als Anreiz dienen, besonders gute Leistungen abzuliefern. Hierbei können beispielsweise Zusatzzahlungen als monetäre Form
vereinbart werden oder besondere Rechte oder Befugnisse wie das Recht
auf Werbung mit dem Namen des Kunden als nicht-monetäre Form. In gleicher Weise funktioniert die Regelung auch bei den Sanktionen: Die monetäre Form wäre hier als Minderung oder Ausgleichszahlung umzusetzen,
die nicht-monetäre als besondere Rechte oder Aktionen, wie zum Beispiel
ein eingeräumtes Sonderkündigungsrecht oder zusätzliche Treffen mit dem
Kunden zur Behebung des Ausfalls. Die Regelungen zu Sanktionen sollen
also einen Ausgleich für den Kunden für die entgangene Dienstgüte und
den eventuell daraus resultierenden Schaden darstellen. Zusätzlich wird
hier jedoch noch nach dem Verschulden unterschieden. Der Anbieter bevorzugt eine verschuldensabhängige Regelung, da der Kunde dann einen
Nachweis erbringen muss, dass die Nichterbringung des Service Levels
tatsächlich durch ein von seitens des Anbieters ausgelöstes Ereignis verur-
10
sacht wurde. Der Kunde dahingegen möchte eine verschuldensunabhängige Regelung, da er dann nicht in der Pflicht steht, einen solchen Nachweis
vorzulegen. In besonderen Fällen können auch schadensunabhängige Vertragsstrafen definiert werden, die in Punkt 5 „Sanktionen“ näher erläutert
werden.(vgl. Frey et al., 2014, S. 15 [6])
Alles in allem sind gerade die Verhandlungen zu den Konsequenzen einer Nichterbringung ein schwieriges Thema. Ein Anwalt wird hierbei nötig,
wenn die definierten Aspekte von Bonus und Malus nicht genügend oder
erhebliche Abweichungen vorliegen. Sonst können diese Aspekte in der
Regel ohne Anwalt geregelt werden. (vgl. Rössel, H., 2014 [8])
In regelmäßigen Abständen sollte geprüft werden, ob die Regelungen im
SLA noch den Kundenerwartungen an die Dienstleistungen und den Zielsetzungen entsprechen. Hierzu finden sogenannte Audits statt, deren Regelmäßigkeit, Umfang sowie die teilnehmenden Personen geklärt werden
sollten. Diese Angaben sind im Punkt Regelungen zur Kontrolle des SLA
zu finden. Die Resultate des Audits fließen dann in den verbesserten SLA
ein. Für den Fall einer solchen notwendigen Änderung sollte definiert werden, in welchem Ausmaß dies möglich ist.
Regelungen zur Lösung von Konflikten beinhalten Schlichtungsverfahren, die bei auftretenden Problemen in der Nutzung von Dienstleistungen
angewendet werden. Je nach Art des Konflikts sollte festgehalten werden,
welche Instanzen beteiligt sind, durch welche Prozesse das Problem gelöst
wird sowie auf welchem Weg der Informations- und Benachrichtigungsfluss
stattfindet. (vgl. Frey et al., 2014, S. 16 [6])
3.4
Juristische Elemente
Ab Gliederungspunkt 12 von Abbildung 1 werden juristische Elemente geklärt. Hierunter fallen unter anderem der Datenschutz, das anwendbare Recht, Haftung und Gewährleistung sowie Schadensersatzregelungen. Diese treten nur in externen SLAs auf und unterscheiden sich nicht
von herkömmlichen Verträgen, weshalb hier nicht näher darauf eingegangen wird. (vgl. Frey et al., 2014, S. 12 [6])
11
4
Service Level Objectives
4.1
Definition
Die Service Level Objectives bzw. Service Level Ziele sind das zentrale Element eines SLA. Sie beschreiben die spezifischen Eigenschaften des Services und werden durch einzelne oder auch mehrere Kennzahlen (Key Performance Indicators) definiert. Sie sollen letztendlich die Qualität des Services beschreiben und den Service gegenüber anderen abgrenzen. (vgl.
TechTarget, Inc., 2014 [9] und Frey et al., 2014, S. ?? [6])
Bei der Formulierung der jeweiligen Ziele sollten gewisse Prinzipien beachtet werden. Eine empfehlenswerte Richtlinie stellt hier zum Beispiel das
SMART-Prinzip dar. Nach dem SMART-Prinzip sollten folgende fünf Grundsätze beachtet werden: (vgl. CORENBERG e.U., 2014 [10])
• Spezifisch: Ziele müssen klar und konkret festgelegt werden, nicht
vage und allgemein.
• Messbar: Ziele müssen messbar sein. Es muss eindeutig sein, wann
ein Ziel als erreicht anzusehen ist. Klare Kriterien sind dafür festzulegen.
• Akzeptiert: Ziele müssen für den Betroffenen auch akzeptabel sein,
er muss mit der Vereinbarung einverstanden sein und die Zielvereinbarung annehmen.
• Realistisch: Die vereinbarten Ziele müssen auch mit realistischem
Aufwand erreichbar sein, keine Wunder und Ausnahmeleistungen vereinbaren.
• Terminierbar: Zu jedem Ziel ist ein Termin festzulegen, bis zu dem
das Ziel zu erreichen ist. Zielvereinbarungen sind nur mit einem konkreten Termin sinnvoll. Vereinbarungen, die zeitlich offen oder vage
bleiben, führen erfahrungsgemäß zu wenig außer einem permanent
schlechten Gewissen und einem diffusen Leistungsdruck.
12
An dieser Stelle ist es noch wichtig zu erwähnen, dass es meist nicht nur
SLOs für den Service allgemein gibt, sondern ebenfalls für einzelne Prozesse wie das Incident Management oder das Change Management. So
können Ziele differenzierter formuliert und so Teilaspekte eines Service klarer definiert werden.
Zudem existiert für jedes SLO, sofern möglich, eine vertraglich festgelegte
Strafe bei Nichteinhaltung.
4.2
Beispiele
Im Folgenden sollen einige gängige SLOs, die häufig Erwähnung innerhalb
der SLAs finden, kurz beschrieben werden. (vgl. Rössel, H., 2014 [8])
SLOs für den Service:
• Verfügbarkeit: Maximale Ausfallzeit des Services bezogen auf einen
bestimmten Zeitraum
• Kapazität: Beschaffenheit der IT-Infrastruktur
• Sicherheit: Anfälligkeit gegenüber Angriffen von außen
• Performance: Maximale Auslastung und Schnelligkeit des Services
SLOs für Prozesse:
• Servicezeit: Zeitraum, in dem der Kunde die Serviceleistungen des
Anbieters in Anspruch nehmen kann bzw. in welchem der Anbieter
die Prozesse erbringt
• Wiederherstellungszeit (Incident Management): Zeitraum zwischen
dem Eingang der Störungsmeldung beim Anbieter, der Störungsbehebung und der Schließung des Tickets
• Reaktionszeit (Incident Management): Definiert den Zeitraum vom
Meldungseingang bis zur Aufnahme der Bearbeitung
13
• Zurückweisungsquote (Change Management): Anzahl zurückgewiesener Changes/ alle Changes
• Problem Erfolgsquote (Problem Management): Anzahl der erfolgreichen PIRs ( = Post Implementation Review) je Problemticket / Anzahl
aller Problemtickets
Es ist noch zu erwähnen, dass viele SLOs voneinander abhängig sind und
sich gegenseitig beeinflussen, wie zum Beispiel die Kapazität und die Performance.
4.3
Problemfelder
Probleme, die sich aus den SLOs ergeben, haben ihren Ursprung fast immer in der Nichteinhaltung der zuvor erwähnten Prinzipien. Diese werden
entweder schon bei der Formulierung vernachlässigt oder später nicht konsequent verfolgt.
Eines der Hauptprobleme stellt hier vor allem die Messbarkeit einzelner
SLOs dar. Viele Aspekte wie zum Beispiel die Sicherheit können nur teilweise in Zahlenwerten ausgedrückt werden. Die Einhaltung einer solchen Anforderung ist letztendlich schwer nachzuvollziehen und kann deshalb auch
meist nur schwerlich bestraft werden.
Des Weiteren stellt auch letztlich die Kontrolle der Einhaltung eine große
Hürde dar. Zum einen sind SLOs häufig relativ umfangreich. Meist werden
über 20 einzelne Prozesse betrachtet, die ja, wie bekannt, jeweils mehrere eigene SLOs besitzen. Zudem kann ein Kunde auch noch mehrere
Verträge mit verschiedenen Anbietern besitzen. Dies steigert die Zahl der
Objekte, die, manuell oder maschinell, überprüft werden müssen, nochmal
erheblich. Letztendlich steht ein enorm großer Verwaltungsaufwand zu Buche, der oft nicht komplett erbracht werden kann.
14
Im Folgenden sollen noch einige weitere Fehler, die häufig im Zusammenhang mit SLOs auftreten, aufgezeigt werden:
Kennzahlen haben keinen direkten Business-Bezug
Kennzahlen werden missbraucht um einen gewissen Qualitätsstandard auszudrücken. Dabei wird außer Acht gelassen, welche Anforderungen eigentlich wirklich für das Geschäft von Nöten sind.
Kennzahlensysteme sind zu umfangreich
Es werden zu viele Kennzahlen erfasst, welche später kaum noch zu überblicken sind.
Anforderungen unrealistisch
Es werden teilweise unerreichbare Werte festgelegt, um nach außen eine
hohe Qualität darzustellen. Gleichzeitig ist man sich aber bewusst, dass
diese Anforderungen nicht einzuhalten sind und deshalb später ignoriert
werden. So verliert das Kennzahlsystem letztendlich seine Wirkung.
Kennzahlen werden nicht regelmäßig aktualisiert
Leistungsanforderungen im IT-Bereich können sich aufgrund neuer Technologien oder technischer Probleme relativ rasch ändern. Deswegen sollten Kennzahlen einer regelmäßigen Überprüfung unterzogen werden.
Isolierte Betrachtung einzelner Kennzahlen
Kennzahlen stehen meist untereinander in Wechselwirkung und können
deshalb nicht nur einzeln betrachtet werden.
Abweichungen werden nicht nachverfolgt
Abweichungen werden meist nicht konsequent untersucht, teilweise auch
aufgrund ohnehin schon schwammiger Formulierungen.
Fehlende Gegenmaßnahmen
Auch wenn Abweichungen festgestellt werden, fehlt es den Mitarbeitern
an Verbesserungsmaßnahmen und Handlungsempfehlungen, wie weiter
zu verfahren ist.
(vgl. Schaffry, A., 2012 [11])
15
4.4
Verfügbarkeit
Die Verfügbarkeit stellt mitunter eines der wichtigsten Qualitätsmerkmale
dar. Die hohe Bedeutung kommt daher, dass heutzutage die Verfügbarkeit der IT-Systeme und –Komponenten für den reibungslosen Ablauf der
unternehmensinternen Geschäftsprozesse absolut grundlegend ist. Selbst
der Ausfall kleinerer Systeme kann teilweise die komplette Produktion stilllegen und je länger ein Ausfall dauert, desto teurer sind am Ende die Umsatzeinbußen. Laut einer Studie aus dem Jahr 2010 kostet der Ausfall von
IT-Systemen deutsche Unternehmen im Mittel jährlich rund 400.000 Euro.
Die gesamte Ausfallzeit beträgt insgesamt rund 14 Stunden jährlich. Zusätzlich kommen hierzu noch jeweils knapp vier Stunden zur Datenwiederherstellung sobald das System wieder reibungslos funktioniert. Europaweit
gesehen beträgt der Schaden jährlich über 17,7 Milliarden Euro und beinahe 630.000 Stunden effektiver Arbeitszeit geht so verloren. Aus der Höhe
der dort genannten Summen kann man leicht erkennen welche Gefahr ein
IT-Ausfall heute darstellt und warum Verfügbarkeit deshalb so enorm wichtig für die Unternehmen ist. (vgl. Heinemann Verlag GmbH, 2011 [12] und
Haglmüller, M., 2011 [13])
4.4.1
Definition Verfügbarkeit
„Ein Service wird als verfügbar bezeichnet, wenn er in der Lage ist, die
Aufgaben zu erfüllen, für die er vorgesehen ist. Als Verfügbarkeit wird die
Wahrscheinlichkeit, dass ein System innerhalb eines spezifizierten Zeitraums funktionstüchtig (verfügbar) ist, verstanden.“ (Held, A., 2005, S. 29
[14])
Services stehen eigentlich immer im direkten Zusammenhang mit technischen Systemen. Dass diese mit ziemlicher Sicherheit früher oder später
Fehler produzieren, nicht ordnungsgemäß funktionieren, beschädigt werden oder kaputt gehen stellt die grundsätzliche Problematik der Verfügbarkeit dar. Des Weiteren wird aus diesem Grund auch im Folgenden vornehmlich von Systemen die Rede sein.
16
4.4.2
Berechnung
Die Verfügbarkeit lässt sich durch folgenden Quotienten berechnen:
V erf ügbarkeit =
Gesamtzeit−Gesamtausf allzeit
Gesamtzeit
Der Beginn eines Ausfalls entspricht grundsätzlich immer dem Zeitpunkt,
ab wann der Ausfall dem Anbieter gemeldet wird. Als Ausfälle gelten zudem nur Downtimes in Zeiträumen, die innerhalb der vereinbarten Zeiten
liegen, in denen der Service verfügbar sein muss. Diese sind also ungeplant. Geplante Downtimes z.B. zur Durchführung von Wartungsarbeiten
liegen außerhalb der vereinbarten Zeiten und zählen somit nicht als Ausfall. Soll ein System also 24 Stunden am Tag und 7 Tage die Woche verfügbar sein, heißt das, dass für Wartungsarbeiten zusätzliche Zeitfenster definiert werden müssen, die aber nicht zur Verfügbarkeit gerechnet werden. In
diesem Zusammenhang wäre es optimal wenn Wartungsarbeiten am laufenden System durchgeführt werden können. (vgl. Wikipedia, 2014 [2] und
Roth, W., 2008 [15])
Bei Computerservices sind die Vorgaben sogar meist noch strenger. Ist die
Reaktionszeit um ein festgelegtes Maß langsamer als vorgeschrieben, wird
dieser Zeitraum ebenfalls als Ausfall angesehen und dementsprechend in
die Verfügbarkeit miteingerechnet. (vgl. Wikipedia, 2014 [2])
Setzt sich ein System aus mehreren Teilsystemen zusammen, wird das
Ausfallrisiko jedes Teilsystems addiert und am Ende von 100 % subtrahiert. Also haben drei zusammengehörige Teilsysteme mit einer Verfügbarkeit von jeweils 99,9 % insgesamt nur eine Verfügbarkeit von 99,7 %
(100 % - 3 * 0,01 % = 99,7 %). (vgl. Wittbecker, T., 2013 [16]) Diese Berechnung erschließt sich aus der Wahrscheinlichkeitstheorie. Die einzelnen
Ausfallwahrscheinlichkeiten werden hier als sich ausschließende Ereignisse angesehen. Deshalb muss man die einzelnen Wahrscheinlichkeiten addieren, um letztendlich auf die Gesamtwahrscheinlichkeit zu kommen, dass
eines der Ereignisse eintritt.
Wann ein Ausfall beginnt und wieder endet und welche Ausfälle letztendlich
vom Betreiber verantwortet werden müssen, sollte sehr genau vertraglich
festgehalten werden.
17
4.4.3
Beispielrechnung
Ausgehend von einem Jahr mit 365 Tagen und dass das System jeden
Tag 24 Stunden verfügbar sein soll (8760 Stunden), ergeben sich folgende
Zahlen:
Verfügbarkeit
99 %
99,1 %
99,2 %
99,3 %
99,4 %
99,5 %
99,6 %
99,7 %
99,8 %
99,9 %
99.99 %
99,999 %
100 %
minimal erwartete
Betriebszeit
(Stunden)
8672,40
8681,16
8689,92
8698,68
8707,44
8716,20
8724,96
8733,72
8742,48
8751,24
8759,124
8759,9124
8760
maximal erlaubte
Ausfallzeit
(Stunden)
87,60
78,84
70,08
61,32
52,56
43,80
35,04
26,28
17,52
8,76
0,876
0,0876
0
maximal erlaubte
Ausfallzeit
(Minuten)
5256
4730,4
4204,8
3679,2
3153,6
2628
2102,4
1576,8
1051,2
525,6
52,56
5,256
0
Tabelle 1: Berechnung der Verfügbarkeit
4.4.4
Hochverfügbarkeit
Meist werden enorm hohe Ansprüche an die Verfügbarkeit eines Systems
gestellt. Eine durchschnittliche Verfügbarkeit ist zu wenig; Systeme müssen „hochverfügbar“ sein.
Eine Definition liefert das Institute of Electrical and Electronics Engineers
(IEEE): „Ein System gilt als hochverfügbar, wenn eine Anwendung auch
im Fehlerfall weiterhin verfügbar ist und ohne unmittelbaren menschlichen
Einfluss weiter genutzt werden kann. In der Konsequenz heißt dies, dass
der Anwender keine oder nur eine sehr kurze Unterbrechung wahrnimmt.
Hochverfügbarkeit bezeichnet also die Fähigkeit eines Systems, auch beim
18
Ausfall einer seiner Komponenten einen uneingeschränkten Betrieb zu gewährleisten.“
Was hier häufig auf Kundenseite vergessen wird, ist, dass sich die Kosten
gegenüber einer höheren Verfügbarkeit exponentiell entwickeln und deshalb eine hohe Verfügbarkeit meist auch mit sehr hohen Kosten verbunden
ist. (vgl. Held, A., 2004, S. 29 [14])
Abbildung 2: Die Kosten der Hochverfügbarkeit
Voraussetzungen
Um eine hohe Verfügbarkeit eines Systems zu gewährleisten, muss gesichert werden, dass selbst beim Ausfall einzelner kritischer Komponenten die wichtigsten Funktionen des Systems weiterhin nutzbar sind. Solche
kritischen Komponenten werden in der Fachsprache auch Single-Point-ofFailure-Risiken (SPOF) genannt. Dies wird dadurch gesichert, dass Komponenten, ohne die das System nicht funktionieren würde, redundant vorhanden sind. Des Weiteren sollte ein System ein insgesamt fehlertolerantes und robustes Verhalten aufweisen.
Zum Einsatz kommen unter anderem unterbrechungsfreie Stromversorgungen, doppelte Netzteile, RAID-Systeme, Techniken zur Serverspiegelung oder auch redundante Cluster. Eine hohe Verfügbarkeit kann also, wie
schon zuvor erwähnt, teils mit immensen Kosten verbunden sein. Gleichzeitig erfordert es auch noch zusätzlich hohe Investitionen seitens des Betreibers in Personal, Ersatzteile, vorbeugende Wartung und in ein verlässliches
19
und schnelles Fehlermeldungssystem. (vgl. Heinemann Verlag GmbH, 2011
[12])
Ausprägungen
• Cold-Standby: Falls ein Rechner ausfällt stehen Anwendungen auf
Ersatzrechner zur Verfügung, allerdings mit Verzögerung
• Hot-Standby: Falls ein Rechner ausfällt stehen Anwendungen auf
Ersatzrechner zur Verfügung, die sofort übernehmen können
• Cluster: Kopplung mehrerer Rechner, sodass diese nach außen als
einer wahrgenommen werden. Es gibt zwei verschiedene Ausprägungen: Bei Failover startet die Anwendung im Fehlerfall auf einem Rechner im Cluster neu. Bei Takeover ist die Anwendung schon vorab auf
mehreren Servern verfügbar. Bei Ausfall eines Servers schaltet der
Cluster einfach auf einen anderen Server um.
(vgl. Heinemann Verlag GmbH, 2011 [12])
4.4.5
Klassifizierung
Die Harvard Research Group (HRG) teilt Verfügbarkeit in ihrer Availability
Environment Classification (kurz: AEC) in sechs Klassen ein:
• Conventional (AEC-0): Funktion kann unterbrochen werden, Datenintegrität ist nicht essenziell.
• Highly Reliable (AEC-1): Funktion kann unterbrochen werden, Datenintegrität muss jedoch gewährleistet sein.
• High Availability (AEC-2): Funktion darf nur innerhalb festgelegter
Zeiten oder zur Hauptbetriebszeit minimal unterbrochen werden.
20
• Fault Resilient (AEC-3): Funktion muss innerhalb festgelegter Zeiten
oder während der Hauptbetriebszeit ununterbrochen aufrechterhalten
werden.
• Fault Tolerant (AEC-4): Funktion muss ununterbrochen aufrechterhalten werden, 24*7-Betrieb (24 Stunden, 7 Tage die Woche) muss
gewährleistet sein.
• Disaster Tolerant (AEC-5): Funktion muss unter allen Umständen
verfügbar sein.
(vgl. Held, A., 2005 [17])
oder auch gemessen an ihrer jährlichen Ausfallzeit:
Verfügbarkeitsklasse
2
3
4
5
6
7
Bezeichnung
stabil
verfügbar
hochverfügbar
fehlerunempfindlich
fehlertolerant
fehlerresistent
Verfügbarkeit in Prozent
99,0
99,9
99,99
99,999
99,9999
99,99999
Tabelle 2: Klassifizierung der Verfügbarkeit
Also erst ab einem Wert von 99,99 % und höher gilt ein System laut der
Harvard Research Group als hochverfügbar. Welche Verfügbarkeit letztendlich als ausreichend bezeichnet werden kann, hängt in hohem Maße
auch vom Einsatzort des Systems ab. Zum Beispiel könnte für ein Flugleitsystem selbst eine Verfügbarkeit von 99,99 % also 52,56 min im Jahr fatal
sein. (vgl. Wikipedia, 2014 [3] und ITWissen, 2014 [18])
21
4.4.6
Problematik
Werden Verfügbarkeiten innerhalb der SLAs vertraglich festgehalten, gibt
es einige Details, die aus Kundensicht gerne vergessen werden und dennoch teilweise enorme Auswirkungen haben können.
Bezugspunkt der Berechnung von Ausfallzeiten
Im Allgemeinen geht man davon aus, dass sich angegebene Zeitangaben
auf ein ganzes Jahr beziehen. Ob ein Zeitraum sich aber auf ein Jahr oder
nur einen Monat bezieht, kann natürlich einen großen Unterschied ausmachen. Hier wird bei Anbietern gerne getrickst und deshalb sollte man hier
als Kunde nochmal besonders Acht geben.
Verfügbarkeit des gesamten Services
Auch häufig außer Acht gelassen wird, dass sich eine Verfügbarkeit manchmal nur auf ein Teilsystem und nicht auf den eigentlichen Service bezieht.
Definiert man beispielsweise vertraglich nur die Verfügbarkeit eines Servers und vergisst dabei aber, dass man ohne Netzanbindung keinen Zugriff
auf diesen hat, kann man Ende den eigentlichen Service nicht nutzen obwohl der Server selbst wie vereinbart zur Verfügung steht. Aus Anbietersicht sollte hier auch darauf geachtet, von welchen Diensten mein eigenes
Angebot eigentlich abhängt. Meist ist man als Anbieter gleichzeitig wieder von anderen Anbietern abhängig und sollte die mit diesen Anbietern
vereinbarten Verfügbarkeiten bei eigenen Kunden mit einbeziehen. Werden beispielsweise Dienste über eine Webseite angeboten, muss beachtet
werden, wie verlässlich eigentlich der eigene Hoster ist.
Ausfälle von einzelnen Funktionalitäten eines Services
Viel wahrscheinlicher als der Ausfall eines kompletten Services, ist, dass
nur einzelne Funktionalitäten Fehler produzieren bzw. nicht nutzbar sind.
Schwierig hierbei ist es festzulegen, welche Funktionen essentiell sind und
ab wann letztendlich der Service an sich nicht mehr verfügbar ist. So schränkt
der Ausfall der Druckfunktionalität wahrscheinlich einen Service nur bedingt
ein. Zu empfehlen ist, genau festzulegen, welche Funktionen verzichtbar
sind und welche nicht. Hier aber eine klare Linie zu ziehen, ist sehr aufwändig und manchmal auch kaum möglich. Deshalb bietet gerade dieser
Punkt häufig Anlass für Streitigkeiten zwischen Kunde und Anbieter.
22
Verteilung der Ausfälle über das Jahr
Betrachtet man zum Beispiel eine Verfügbarkeit von 99,5 % und damit verbundene mögliche Ausfälle von bis zu 43,8 Stunden jährlich scheint das auf
den ersten Blick über das Jahr verteilt doch sehr wenig. Was man hierbei
aber nicht beachtet, ist, dass diese 43,8 Stunden auch an einem Stück auftreten können. Also könnte ein Dienst mit dieser Verfügbarkeit eventuell eine ganze Woche nicht nutzbar sein. Auf diese Weise betrachtet erscheinen
43,8 Stunden schon ganz anders und können so erhebliche Auswirkungen
nach sich ziehen. Deshalb sollte man sich als Kunde bei den vertraglichen
Vereinbarungen Gedanken machen, ob man nicht zusätzlich noch eine maximale Ausfallzeit am Stück vereinbart. (vgl. Wittbecker, T., 2013 [16])
Schwammige Formulierung der Verfügbarkeiten in den SLAs
Formulierungen wie „Wir garantieren höchste Verfügbarkeit“ hören sich auf
den ersten Blick toll an. Bei genauerem Hinsehen merkt man aber schnell,
dass das hier kein genauer Wert ist, den man messen kann. Saubere, eindeutige Formulierungen erfordern technisches, kaufmännisches und auch
juristisches Geschick und sollten dementsprechend durch die Zusammenarbeit von Experten entstehen. (vgl. Roth, W., 2008 [15] und Hackmann, J.,
2013 [19])
5
Sanktionen
Verletzt ein Dienstleister seine vertraglichen Pflichten, so zieht dies die im
SLA vereinbarten oder gesetzlich geregelten Sanktionen nach sich. Solche Pflichtverletzungen treten beispielsweise auf, wenn der Dienstleister
die vereinbarten Verfügbarkeitszeiten nicht einhält oder auch wenn er eine
Störung nicht innerhalb der vereinbarten Wiederherstellungszeit behebt.
In Dienstverträgen sollten immer pauschalierte Schadensersatzansprüche
oder Vertragsstrafen vereinbart werden, da nach dem Miet- oder Dienstvertragsrecht ansonsten Schadensersatzansprüche im Einzelfall nachgewiesen werden müssen. Dies ist aber in der Regel kaum oder nur mit hohem
Aufwand möglich.
23
Die Höhe der Sanktionen hängt vom Anspruch des Kunden an die Verfügbarkeit des Systems und vom Verhandlungsgeschick der Parteien ab. (vgl.
„Lexikon für das IT-Recht“, S. 254 [20])
5.1
Pauschalierter Schadensersatz und Pönale
Die Pönale (auch Vertragsstrafe oder Konventionalstrafe genannt) ist eine fest zugesagte Geldsumme, auf die ein Vertragspartner Anspruch hat,
wenn der andere Vertragspartner nicht rechtzeitig und vertragsgerecht seine Leistung erfüllt (vgl. Wikipedia, 2014 [4]) und ist im BGB §§ 339 bis 345
geregelt. Die Pönale findet Anwendung, sobald einer der im SLA vereinbarten KPIs nicht eingehalten wird. Sie stellt eine schadensersatzunabhängige
Form der Sanktionen dar und ist vor allem bei Service Levels geeignet, die
gut messbar sind. Dies setzt voraus, dass deren KPI eindeutig gezählt und
gestoppt werden kann, wie beispielsweise Zeitangaben in Stunden oder
Minuten, konkret festgesetzte Termine oder Quoten. Besonders pönalerelevant sind somit die Wiederherstellzeit, die Reaktionszeit, die Reopenquote
und der Incident Report Zeitpunkt. Die Parteien können also vereinbaren,
was passiert, wenn zum Beispiel Reaktions- und Wiederherstellungszeiten
nicht eingehalten werden. Beispielsweise dass die Vergütung für den Monat entfällt, in dem die Störung nicht beseitigt wurde.
Entsteht dem Dienstleistungsnehmer durch nicht eingehaltene Vereinbarungen ein Schaden, kann dieser Schadensersatz verlangen. Jedoch hat
er in diesem Fall die Pflicht, den für ihn entstandenen Schaden nachzuweisen. Dies ist meist sehr schwierig und aufwändig, weswegen sich im SLA
die Alternative bietet, einen pauschalierten Schadensersatz zu vereinbaren.
Der pauschalierte Schadensersatz wird im Vertrag weitestgehend als vorweggenommene Schadensschätzung verstanden und ist im BGB § 309 Nr.
5 geregelt. Er wirkt als Beweislastumkehr bei Ersatzanspruch, d. h. behauptet der Schuldiger, es liege ein geringerer als der pauschalierte Schaden vor, so muss er dies auch nachweisen. Der pauschalierte Schadensersatz erleichtert somit die Durchsetzung von Schadensersatzansprüchen.
Zwar kann es so möglicherweise vorkommen, dass ein geringerer Betrag
24
als der tatsächlich entstandene Schaden erstattet wird, jedoch entfallen dafür der Aufwand und die Kosten, die für einen genauen Nachweis anfallen
würden.
Sowohl die Vertragsstrafe als auch der pauschalierte Schadensersatz dienen als Druckmittel für die Sicherung der Vertragserfüllung. Außerdem können durch den pauschalierten Schadensersatz die Durchsetzung von Schadensersatzansprüchen geltend gemacht werden ohne einen Schadensnachweis führen zu müssen. (vgl. „Lexikon für das IT-Recht“, S. 255 [20] und
Meyer-Spasche, G., 2008 [21])
5.2
Kündigung
Es besteht laut § 314 BGB auch die Möglichkeit einer Sanktion in Form von
Kündigung, wenn ein entsprechend wichtiger Grund vorliegt. Dieser „wichtige Grund“ sollte jedoch im Vertrag als Sonderkündigungsrecht geregelt
werden, um die Problematik dieses im Gesetz nicht geregelten „wichtigen
Grundes“ zu entschärfen.
Als wichtiger Grund für fristlose Kündigung sollte zum einen das Überschreiten bestimmter Höchstbeträge an Gutschriften/Vertragsstrafen in definiertem Zeitraum vereinbart werden. Oder auch alternativ das Überschreiten bestimmter SLOs über einen bestimmten Mindestzeitraum bzw. im SLA
zu definierende „schwerwiegende Abweichung“. (vgl. und Meyer-Spasche,
G., 2008 [21])
25
6
Fazit
Die Erarbeitung eines kundenindividuellen SLA ist sehr zeitaufwändig und
fordert von den Vertragspartnern anfangs, sich sehr intensiv mit den theoretischen Inhalten und den eigenen Zielsetzungen zu befassen und diese
sorgfältig zu planen. Denn unzureichende Definitionen der gestellten Anforderungen und angebotenen Leistungen stellen häufig ein großes Konfliktpotenzial dar. Die vom IT-Dienstleister zugesagten Leistungen sollten vor
allem deshalb vorab gut durchdacht sein, da diese im Nachhinein nur sehr
schwer revidierbar sind. Angebotene oder gar schon festgehaltene Inhalte
lassen sich oftmals nicht mehr zurücknehmen.
Jedoch lässt sich aufgrund genau dieses verbindlichen Vertragscharakters des SLA eine positive Entwicklung der Leistungseffizienz zwischen
den Vertragsparteien beobachten. So schafft ein SLA Transparenz über
die Leistungen des IT-Anbieters und deren Kosten bei definierter Qualität,
da alle Informationen für den Kunden zugänglich sind. Im Idealfall weiß der
Kunde somit sowohl genau welche Leistungen er in welcher Qualität erhält,
sowie was ihn das kostet. Langfristig werden dadurch Kosteneinsparungen
ermöglicht, denn die individuelle Anpassung der Services und der benötigten Komponenten führt zu einer optimalen Ressourcenallokation bei beiden
Vertragspartnern. Außerdem haben beide Parteien ein klares Verständnis
ihrer Zuständigkeiten und Funktionen, so dass Unterlassungen und Missverständnisse nicht mehr vorkommen. Im Falle eines dennoch auftretenden
Rechtsstreites können SLAs dann auch zu einer klaren Grundlage der jeweiligen Rechtsposition beitragen. (vgl. Gadatsch, A., 2014 [23] und Fehlmann, E., 2006, S. 28 [24])
Alles in allem lässt sich also sagen, dass ein SLA zu Win-Win-Situationen
führt, da für den Anbieter eine optimale Kostenkalkulation möglich ist und
der Dienstleistungsnehmer die Leistungen kostenoptimiert abrufen kann.
(vgl. mycomputers, 2014 [22])
26
Literatur
[1] Wikipedia
(2014):
Service-Level-Agreement.
http://de.
(Zugriff:
wikipedia.org/wiki/Service-Level-Agreement
15.05.2014). Wikimedia Foundation Inc., San Francisco.
[2] Wikipedia (2014): Verfügbarkeit. http://de.wikipedia.org/wiki/
Verf"ugbarkeit (Zugriff: 06.06.2014). Wikimedia Foundation Inc.,
San Francisco.
[3] Wikipedia (2014): Verfügbarkeit. http://de.wikipedia.org/wiki/
Hochverf"ugbarkeit (Zugriff: 06.06.2014). Wikimedia Foundation
Inc., San Francisco.
[4] Wikipedia (2014): Verfügbarkeit. http://de.wikipedia.org/wiki/
Vertragsstrafe (Zugriff: 15.06.2014). Wikimedia Foundation Inc.,
San Francisco.
[5] Berger,
ment
Thomas
von
G.
(2005):
Konzeption
Service-Level-Agreements
für
und
Manage-
IT-Dienstleistungen.
http://tuprints.ulb.tu-darmstadt.de/570/1/Dissertation_
ThomasBerger_SLAs.pdf (Zugriff: 07.06.2014). Technische Universität Darmstadt, Darmstadt.
[6] Frey et al. (2014): SLA-Richtliniendokument für Cloud Dienstleistungen, Autonomic SLA Management as a Service (ASLAMaaS).
http://www.wolke.hs-furtwangen.de/assets/files/
ASLAMaaS-SLA-Richtliniendokument.pdf
(Zugriff:
15.05.2014).
Bundesministerium für Bildung und Forschung, Berlin.
[7] itSMF Deutschland e.V. (2005): IT Service Management basierend
auf ITIL - eine Einführung. 2. Auflage. Van Haren Publishing,
27
Zaltbommel NL.
[8] Rössel, Heiko, Dipl.-Ing. (2014): mündliche Aussage.
[9] TechTarget, Inc. (2006): What’s the difference between SLO and
SLA?
http://www.techtarget.com/html/privacy_policy.html
(Zugriff: 04.06.2014). TechTarget, Inc., Newton, MA.
[10] CORENBERG
e.U.
(2014):
SMART-Prinzip.
http://www.
corenberg.com/smart-glossar/ (Zugriff: 04.06.2014). CORENBERG e.U., Wien.
[11] Schaffry, Andreas (2012): IT Service Management - Die 7 schlimmsten KPI-Sünden. http://www.cio.de/strategien/2878633/ (Zugriff: 04.06.2014). IDG Business Media GmbH, München.
[12] Heinemann Verlag GmbH (2011): Server / Client - Grundlagen
Hochverfügbarkeit.
http://www.it-administrator.de/themen/
server_client/grundlagen/98988.html
(Zugriff:
06.06.2014).
Heinemann Verlag GmbH, München.
[13] Haglmüller,
Manuel
(2010):
IT-Ausfall
führt
zu
Milliarden-
Schäden - Systemreparaturen kosten Unternehmen Zeit und
Geld. https://www.pressetext.com/news/20100914018 (Zugriff:
06.06.2014). pressetext Nachrichtenagentur GmbH, Wien.
[14] Held, Andrea (2004): Oracle 10g Hochverfügbarkeit. 1. Auflage.
Addison-Wesley, Bonn.
[15] Roth,
keit.
Werner
(2008):
IT
Fundamentals
-
Verfügbar-
http://wernerroth.de/index.php/2008/03/17/
28
it-fundamentals-verfugbarkeit/
(Zugriff:
06.06.2014).
Wer-
ner Roth, Ort unbekannt.
[16] Wittbecker, Thomas (2013): Fallstricke bei der Berechnung
von
Verfügbarkeiten.
http://www.channelpartner.de/a/
fallstricke-bei-der-berechnung-von-verfuegbarkeiten,
2614494 (Zugriff: 06.06.2014). IDG Business Media GmbH, München.
[17] Held, Andrea (2005): Hochverfügbarkeit: Kennzahlen und Metriken.
http://www.tecchannel.de/test_technik/grundlagen/430342/
hochverfuegbarkeit_kennzahlen_und_metriken/index12.html
(Zugriff: 06.06.2014). IDG Business Media GmbH, München.
[18] ITWissen
(2014):
Hochverfügbarkeit.
http:
//www.itwissen.info/definition/lexikon/
(Zugriff:
Hochverfuegbarkeit-high-avaiability-HA.html
06.06.2014). DATACOM Buchverlag GmbH, Peterskirchen.
[19] Hackmann,
Joachim
(2013):
Management.
Versäumnisse
im
SLA-
http://www.computerwoche.de/a/
(Zugriff:
versaeumnisse-im-sla-management,2524793
06.06.2014). IDG Business Media GmbH, München.
[20] Ehmann (Hrsg.) (2013): Lexikon für das IT-Recht 2013/2014: Die
130 wichtigsten Praxisthemen. 4. Auflage. Jehle-Verlag, München.
[21] Meyer-Spasche,
Georg
(2008):
IT
Service
Level
Agree-
ments - Rechtliche Lösungen und Vertragsgestaltung. http:
//www.pmi-muc.de/Vortraege/20080630/Service\%20Level\
%20Agreements\%20short\%20\%20Vortrag\%20GMS\%20\%2030.
6.08.ppt Project Management Institute Munich Chapter e.V.,
29
München.
[22] mycomputers
(2014):
SLA
-
Service
Level
Agreement.
http://www.mpcomputers.de/home/ITManagement/index.php?
AktuelleSeite=frame.php&AktuelleUnterseite=SLA.php (Zugriff:
14.06.2014).
[23] Gadatsch, Andreas, Prof. Dr., (2014): Service Level Agreements
(SLA).
http://www.org-portal.org/fileadmin/media/legacy/
prof._dr._a._gadatsch_sla.pdf (Zugriff: 14.06.2014). ibo Beratung und Training GmbH, Wettenberg.
[24] Fehlmann, Eric (2006): Bedeutung von Service Level Agreements
für
die
Software
Entwicklung
im
IT-Outsourcing.
http://diuf.unifr.ch/main/is/sites/diuf.unifr.ch.main.
is/files/file/studentprojects/M-2006_Eric_Fehlmann.pdf
(Zugriff: 14.06.2014). Universität Fribourg, Fribourg.
Tabellenverzeichnis
1
Berechnung der Verfügbarkeit. Wikipedia (2014): Verfügbarkeit. http://de.wikipedia.org/wiki/Verfügbarkeit (Zugriff: 06.06.2014).
Wikimedia Foundation Inc., San Francisco. . . . . . . . . . . 18
2
Klassifizierung der Verfügbarkeit. Held, Andrea (2004): Oracle
10g Hochverfügbarkeit. 1. Auflage. Addison-Wesley, Bonn.
S. 45. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
30
Abbildungsverzeichnis
1
Gliederungsvorschlag für SLAs. Frey et al. (2014): SLA-Richtliniendokument
für Cloud Dienstleistungen, Autonomic SLA Management as
a Service (ASLAMaaS). http://www.wolke.hs-furtwangen.de/assets/files/ASLAMaaSSLA-Richtliniendokument.pdf (Zugriff: 15.05.2014). Bundesministerium für Bildung und Forschung, Berlin. S. 22 . . . . .
2
6
Die Kosten der Hochverfügbarkeit. Held, Andrea (2004): Oracle
10g Hochverfügbarkeit. 1. Auflage. Addison-Wesley, Bonn.
S. 29. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
31