Management von Service-Level-Agreements E-Book

Robert Scholderer

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2016

Seitenzahl: 503

Beschreibung

Kundenorientierung und ein professionelles Service-Level-Management (SLM) mit seinen Service-Level-Agreements (SLAs) entscheiden langfristig über den Erfolg von Dienstleistungsunternehmen. Dieses Buch zeigt den Weg zur Professionalisierung der Schnittstelle zwischen Servicenehmer und IT-Dienstleister auf. Anhand von Beispielen wird ausführlich erklärt, wie SLAs entworfen und überwacht werden können. Schwerpunkte bilden dabei die in der Praxis anwendbaren und belastbaren SLAs, das Monitoring von Geschäftsprozessen sowie Nachweise zur Einhaltung von SLAs. Weiter wird mit dem SOUSIS-Modell ein neuer Standard vorgestellt, mit dem SLAs einheitlich und beherrschbar erstellt und verwaltet werden können. Auch für das SLA-Management erforderliche Arbeitskonzepte und Werkzeuge werden im Detail erläutert. Interviews mit Service-Level-Managern und ein Fallbeispiel aus der Praxis runden das Buch ab. Aus dem Inhalt: - IT-Standards für den Prozess Service-Level-Management - Entwurf von Service-Level-Agreements und Servicekatalogen - Überwachung von Service-Level-Agreements - Werkbank für Service-Level-Manager: Arbeitskonzepte und Werkzeuge - Stolpersteine bei Service-Level-Agreements Die Neuauflage wurde komplett überarbeitet und aktualisiert. Dies betrifft insbesondere die IT-Standards, Entwicklungen im Bereich Servicekatalog und ein neues Pönalenkonzept für Schadensersatzforderungen.

Leseprobe

Dr. Robert Scholderer arbeitet als Service-Level-Manager für Konzerne und befasst sich seit 1996 mit IT-Services. In seiner Karriere verhandelte er über 1.000 SLAs. Seit 2006 erstellte er über 100 IT-Servicekataloge mit 4.000 IT-Services und hat ein einzigartiges Wissen aufgebaut, wofür er mehrfach den Innovationspreis in Baden-Württemberg erhielt. Seit 2015 zählt sein SOUSIS-Modell offiziell zu den vier internationalen IT-Standards für SLAs. Als Trainer bildet er im deutschsprachigen Raum Service-Level-Manager und Servicekatalog-Manager aus.

Weiter ist er Geschäftsführer der MetaOne GmbH in Karlsruhe. In seiner Beratungstätigkeit mit Schwerpunkt IT-Service-Management leitet er Projekte zu Design, Verhandlung und Management von SLAs, IT-Monitoring-Systemen und Infrastrukturen sowie zu IT-Inventarisierung, IT-Revision, Anforderungs- und Projektmanagement. Durch seine langjährige Erfahrung als Geschäftsführer der G-NE GmbH, als Berater bei der TTI-Tectran GmbH, in seinen Trainings und Seminaren bei Integrata AG und Managementcircle AG verbindet er Praxis mit theoretischen Ansätzen. Er ist in zahlreichen Gremien als Vorstand oder Beirat vertreten. Ferner ist er auf den für das SLM relevanten Konferenzen als Referent und Marktbeobachter geladen.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.de/plus

Management von Service-Level-Agreements

Methodische Grundlagen und Praxislösungen mit COBIT, ISO 20000 und ITIL

2., aktualisierte und erweiterte Auflage

Robert Scholderer

Priv.-Doz. Dr. -Ing. habil. Robert ScholdererPrincipal [email protected]

Lektorat: Christa PreisendanzCopy-Editing: Ursula Zimpfer, HerrenbergHerstellung: Nadine ThieleUmschlaggestaltung: Helmut Kraus, www.exclam.deDruck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Fachliche Betreuung:Prof. Dr. Matthias Knoll · Hochschule Darmstadt · [email protected]

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:Print    978-3-86490-397-7PDF    978-3-96088-024-0ePub    978-3-96088-025-7mobi    978-3-96088-026-4

2., aktualisierte und erweiterte Auflage 2016Copyright © 2016 dpunkt.verlag GmbHWieblinger Weg 1769123 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort zur 2. Auflage

Lieber Leser,

die zweite Auflage liegt nun vor, und das Thema SLA ist aktueller denn je. Mit jedem Jahr gerät es stärker in den Fokus der IT-Führungskräfte. Während man 1998 noch von Qualitätssicherungsblättern sprach, werden sie kurze Zeit später bereits durchgängig Service-Level-Agreements genannt. Nach dem Zusammenbruch des Neuen Markts zwischen 2001–2003 mussten alle sparen. Nur wo? Zu dieser Zeit überlegte man erstmals, welche IT-Leistungen an welchen Stellen gestrichen werden können. Vereinzelt wurden da SLAs zur Kosteneinsparung entdeckt. Spätestens seit 2008 waren mit dem Zusammenbruch des Bankensystems und der weltweiten Krise alle Führungskräfte aufgefordert, kreativ zu sein, wenn es um das Erschließen von Einspar- und Verbesserungspotenzialen ging. Ab da begann der Siegeszug des SLA.

Als die erste Auflage dieses Buches 2011 erschien, wurde das Konzept von SLAs sukzessive vom Management auf der Suche nach einer wirtschaftlichen Lösung aufgegriffen. Je mehr Cloud-Services entstanden, je mehr das Outsourcing oder auch das Insourcing voranschritt und je mehr die interne Leistungsverrechnung in den Konzernen Einzug hielt, desto stärker wurde der Ruf nach SLAs und nach einem effizienten SLM-Prozess. In 2015 wurde das in diesem Buch 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. Die im SOUSIS-Modell entwickelten Strukturen finden sich heute in einer Vielzahl von Ausschreibungen aller Art wieder. Als Autor freue ich mir sehr darüber, dass das SOUSIS-Modell bei seiner Entstehung 2011 so weit vorgedacht war, dass es sich als Standard in der SLA-Welt durchgesetzt hat. Das Besondere an SOUSIS ist die Entkopplung von zwei Kreisläufen. Das SLA mit seinen ausgelagerten IT-Services in Leistungsscheinen liefert eine Basisstruktur. Damit werden Regelungen stark von den Service-Level-Werten getrennt gehalten. Der eine Kreislauf ist die meist jährliche Konzeption und Überprüfung des SLA mit seinen Regelungen. Unterjährig werden Leistungen hinzugenommen oder gekündigt. Dies ist der zweite Kreislauf, der dann im operativen Alltag sehr schnell gehen muss. Dass in jedem Kreislauf nur diejenigen beteiligt werden, die auch dafür vorgesehen sind, dies macht das SOUSIS-Modell robust und auch effizient.

Die Veränderungen in der SLA-Welt habe ich nach der ersten Auflage dieses Buches in vielen SLA-Verhandlungen und -Ausschreibungen beobachtet und auch selbst mitgeprägt. Die wesentlichen Neuerungen sind in der zweiten Auflage eingearbeitet. Zwei Punkte gelten als herausragend, und diesen schenke ich in der neuen Auflage mein Hauptaugenmerk: Pönalen und die managementgerechte Darstellung des SLM-Prozesses.

Bei den Pönalen sind die Vertragspartner deutlich variantenreicher geworden. Je nach Sichtweise – ob Servicenehmer oder Dienstleister – sind in der zweiten Auflage die Richtungen aufgezeigt. Während die Servicenehmer immer stärker nach Steuerungsmöglichkeiten suchen, um das Dienstleisterverhältnis enger zu führen, sind die Dienstleister dazu übergegangen, Hürden in die Pönalen einzubauen. Beide Parteien treffen hier aufeinander und versuchen, sich gegenseitig in eine Vorzugsposition zu bringen. Für beide Seiten sind die Mechanismen in dieser Auflage neu ausgeführt.

Die Straffung des SLM-Prozesses ist der Situation geschuldet, dass durch die steigende Zahl von SLAs auch der Verwaltungsaufwand gestiegen ist. Plötzlich ist es nicht mehr eine One-Man-Show eines einzelnen Service-Level-Managers, vielmehr werden Teams gebildet, um die Bürokratie schultern zu können. Wer hier den SLM-Prozess optimiert fahren kann, wird in den nächsten Jahren zu den Gewinnern gehören und weiterhin auf die One-Man-Show setzen können. Damit man diesen Prozess noch effizienter ausrichten kann, liegt in der neuen Auflage ein managementgerechtes SLM-Prozess-Template vor, das in fünf Prozessschritten alle zentralen Punkte erfasst. Von den erreichten und nächsten Zielen über die Aufgaben bis zu den Schnittstellen mit anderen Abteilungen ist jeder Prozessschritt auf Optimierung ausgerichtet. Als ich das Management-Template entwickelt habe, stand nur die Präsentation des SLM-Prozesses vor dem Management im Vordergrund. Es sollte kurz und knapp das SLM gezeigt werden, wo man steht und welche Richtung man einschlagen möchte. Nach dem ersten Einsatz des SLM-Prozess-Templates kam der zweite Kunde und der nächste und so weiter. Beim zweiten Kunden dachte ich mir, es ist bestimmt ganz problemlos, das SLM-Prozess-Template wieder anzuwenden. Doch das gestaltete sich nicht ganz so einfach. Mit jedem Kundeneinsatz stand ich vor der Problematik, wie kann man das SLM-Prozess-Template ausfüllen, um bei diesem Kunden die Effizienz des SLM zu steigern. Mit jedem Kunden konnte ich das SLM-Prozess-Template verbessern und seine Anwendung optimieren. Damit Sie, lieber Leser, dies auch können, sind zu jedem Prozessschritt auch die häufigsten Ziele und Herausforderungen bereits genannt. Sie müssen sozusagen nur noch auswählen, welche Punkte bei Ihnen zutreffen, und dann gilt es, den SLM-Prozess daraufhin auszurichten.

Ebenso neu in der zweiten Auflage ist das Interview mit Jörg Ziegler, der als IT-Leiter die aktuelle Sicht des Service-Level-Managements repräsentativ für viele Service-Level-Manager verdeutlicht.

Robert ScholdererStuttgart, im Juli 2016

Vorwort

Liebe Leser,

das vorliegende Buch befasst sich mit Service-Level-Agreements (SLAs) und ihrem Management, dem Service-Level-Management (SLM).

In meiner Funktion als Service-Level-Manager habe ich sehr viele SLM-Projekte geleitet, zahllose SLAs entworfen und mir dabei oftmals Hilfestellungen aus der Literatur gewünscht. Bei Internetrecherchen jedoch war die Ausbeute eher dürftig. Mit jedem Buch, das auf den Markt kam, ist das Thema Service-Level-Management gewachsen. Erstaunlicherweise ist der Prozess Service-Level-Management dabei aber deutlich besser ausgestaltet und in der Literatur stärker präsent als Service-Level-Agreements. Gerade die Service-Level-Agreements jedoch sind die Kernobjekte des Service-Level-Managements, und deshalb sollte dieser Aspekt gleichwertig behandelt werden. Aus diesem Grund sind in dieses Buch bewährte Konzepte und umfassende Erfahrungen zu beiden Themenkomplexen aus meinen Beratungs-, Geschäftsführungs- und Schulungstätigkeiten sowie meinen wissenschaftlichen Arbeiten eingeflossen.

Standards wie COBIT, ISO 20000 und ITIL helfen uns, Service-Level-Management und Service-Level-Agreements einzuordnen und anzuwenden. Umfassende Gremienarbeit wie im itSMF (IT Service Management Forum) oder TeleManagement Forum hat wesentlich dazu beigetragen, dass SLAs von Dienstleistern sinnvoll eingesetzt werden können. Denn ein Umdenken hin zu serviceorientiertem Handeln kann nur dann stattfinden, wenn Anforderungen von Servicenehmern erkannt, aus ihrer Sicht beschrieben und auch nachgewiesen werden können. Die ausschließliche Berufung auf Standards ist dabei aber kein Garant für einen am Servicenehmerbedarf ausgerichteten operativen Betrieb. Vielmehr müssen neue, auf Standards aufbauende Konzepte entworfen werden, um Verbesserungen in der Umsetzung und Anwendung des hinter SLM und SLAs stehenden Grundgedankens zu erreichen. Denn der Schritt vom einfachen Rechenzentrum hin zum wertschöpfenden Dienstleister muss möglichst rasch vollzogen werden, um die von den nachfragenden internen oder externen Kunden dringend benötigte hohe Qualität erreichen und dauerhaft erhalten zu können. Der Weg zur »IT von der Stange« als Ziel wurde zwar bereits von mehreren Dienstleistern beschritten. Konzepte wie »IT aus der Steckdose« sind jedoch auf halbem Weg an der Systemkomplexität gescheitert [Grauer 2006; Gentzsch 2006]. Denn das Abstraktionsniveau der Standards behindert oft eine erfolgreiche Umsetzung. Es endet dort, wo ich beginnen möchte. Mein Ziel ist es mit dem vorliegenden Buch, nicht nur ein Bindeglied zu Ihrem Bedarf herzustellen, sondern Sie auch als Rechenzentrumsleiter, Service-Level-Manager oder IT-Berater sehr gut auf die Erstellung Ihres nächsten Service-Level-Agreements oder auf Ihr nächstes Service-Level-Management-Projekt vorzubereiten.

Mit einer Reihe von ausgestalteten Lösungen, die sich in der Praxis bewährt haben, werden Sie nicht nur Best Practices kennenlernen, sondern auch viele davon einfach direkt übernehmen können. Deshalb finden Sie in allen Kapiteln Praxislösungen. Meine langjährige Beratungserfahrung beruht auf diesen Praxislösungen. Sie sind mir eine große Hilfe, wenn es darum geht, Projekte zu beginnen. Dieses Wissen möchte ich mit Service-Level-Managern teilen, damit das Service-Level-Management weiterentwickelt werden kann und Service-Level-Agreements so gestaltet werden, dass beide Parteien in einer vertrauensvollen/von Vertrauen geprägten Kooperation zusammenarbeiten können. Mein Ziel ist es, Ihnen einen starken Impuls zu geben, um Ihr Service-Level-Management profitabel aufzubauen. In diesem Zusammenhang ist es mein Hauptanliegen, Ihnen als IT-Entscheider bzw. IT-Verantwortlichen pragmatische und vor allem praxistaugliche Lösungen für das Management von Service-Level-Agreements aufzuzeigen.

Robert ScholdererStuttgart, im April 2011

Danksagung

An erster Stelle danke ich Torsten Böttner, mit dem ich seit vielen Jahren zusammenarbeite. Gemeinsam haben wir viele SLAs erstellt oder überprüft. Ebenso haben wir die Konzepte unseres SLM-Prozesses täglich verbessert und diesen so stark industrialisiert, dass er effektiv bleibt, auch wenn sich die internen Organisationseinheiten wandeln.

Direkt neben dem Mann der Wirtschaft danke ich Herrn Prof. Dr. Jochen Seitz, der meine Habilitation als Erstgutachter begleitete. Seine Hinweise und präzise wissenschaftliche Herangehensweise haben mir viele neue Impulse gegeben, das SLM in sich stimmig aufzubauen und Lücken erkennen zu können. Sein umfassender Blick für das Ganze war prägend für die Konzepte.

Weiterhin danke ich Hagen Aescht und Michael Schmid für die vielen Diskussionen, die mir geholfen haben, das SLM einmal aus der Sicht des Contract-Managements zu sehen. Auch die Abstimmung zwischen den Verträgen hat mir viele Hinweise gegeben, wie sich SLAs hin zu anderen Vertragskonstrukten verhalten bzw. sich integrieren.

Ein Dank gebührt Nico Jäckel, meinem langjährigen Geschäftspartner der G-NE GmbH. Die intensiven Diskussionen und daraus entstandenen Veröffentlichungen waren Vorarbeiten für einige Teile dieses Buches. Die Konzepte sind oft aus Herausforderungen des operativen Geschäfts entstanden, um das SLM servicenehmerorientiert zu gestalten.

Einen Dank verdienen Jens Lukowski und Jens Stricker, auf deren Programmiergeschick hin viele Konzepte bewiesen wurden. Der manchmal unmenschliche Dauerprogrammiereinsatz hat gezeigt, welche Ideen zu theoretisch sind und welche sich auch tatsächlich umsetzen lassen.

Meinem Designer Arndt Knieper möchte ich einen Dank aussprechen. Auf sein Grafikerauge ist Verlass. In zahlreichen Diskussionen hat er gezeigt, wie sich viele Abbildungen vereinfachen lassen, sodass der Kern deutlicher erkennbar ist.

Ein herzliches Dankeschön geht an das Verlagsteam, das sich engagiert zur Abrundung des Buches eingesetzt und mir tatkräftig unter die Arme gegriffen hat. Ein besonderer Dank geht an Herrn Prof. Dr. Matthias Knoll, der den Grob- und Feinschliff am Manuskript vorgenommen hat.

Inhaltsübersicht

1      Einführung

1.1    Einsatzfeld des Service-Level-Managements

1.2    Zentrale Begriffe für Service-Level-Manager

1.3    Herausforderung: Service-Level-Management

1.4    Zusammenfassung

2      IT-Standards für den Prozess Service-Level-Management

2.1    Historische Standards für das Service-Level-Management

2.2    Aktuelle Standards für das Service-Level-Management

2.3    Konsolidierung der Standards für das Service-Level-Management

2.4    Praxislösung für den Service-Level-Management-Prozess basierend auf IT-Standards

2.5    Zusammenfassung

3      Entwurf von Service-Level-Agreements und Servicekatalogen

3.1    SOUSIS-Modell: Beschreibung von IT-Services

3.2    Servicekatalog mit SOUSIS-Modell

3.3    Praxislösungen für Servicekataloge

3.4    Service-Level-Agreements mit SOUSIS-Modell

3.5    Praxislösungen für Service-Level-Agreements

3.6    Zusammenfassung

4      Überwachung von Service-Level-Agreements

4.1    Monitoring

4.2    Anforderungen an das IT-Messkonzept

4.3    Messmethoden

4.4    Service-Level-Agreement-Reports

4.5    Praxislösungen für Monitoring und Reporting

4.6    Zusammenfassung

5      Werkbank für Service-Level-Manager: Arbeitskonzepte und Werkzeuge

5.1    Arbeitskonzepte für Service-Level-Manager

5.2    Service-Level-Management-Werkzeugskizzen

5.3    Praxislösungen für die Service-Level-Management-Werkbank

5.4    Zusammenfassung

6      Stolpersteine bei Service-Level-Agreements

6.1    Formale Hürden und Definitionsprobleme

6.2    Betrieb

6.3    Zusammenfassung

7      Interviews und Fallbeispiel

7.1    Interviews mit Service-Level-Managern über die Zukunft

7.2    Fallbeispiel: Neustrukturierung bei einem Dienstleister eines Finanzinstituts

7.3    Praxislösungen zum Benchmark

8      Die 10 größten SLA-Irrtümer

9      Schlussbemerkungen

Anhang

Weblinks

Abkürzungen

Literatur

Index

Inhalt

1      Einführung

1.1    Einsatzfeld des Service-Level-Managements

1.2    Zentrale Begriffe für Service-Level-Manager

1.2.1    IT-Abteilung

1.2.2    IT-Service

1.2.3    Operational-Level-Agreement

1.2.4    Servicekatalog

1.2.5    Service-Levels

1.2.6    Service-Level-Agreement und Underpinning Contract

1.2.7    Service-Level-Manager

1.2.8    Service-Level-Management

1.2.9    Service-Management

1.2.10  Service-Level-Management-Werkzeuge

1.3    Herausforderung: Service-Level-Management

1.3.1    Unterscheidung zwischen Service-Level-Agreements und Operational-Level-Agreements

1.3.2    Service-Level-Agreements sind mehr als nur eine Vereinbarung

1.3.3    Service-Level-Management ist die Qualitätskontrolle

1.3.4    COBIT, ISO 20000 und ITIL

1.4    Zusammenfassung

2      IT-Standards für den Prozess Service-Level-Management

2.1    Historische Standards für das Service-Level-Management

2.2    Aktuelle Standards für das Service-Level-Management

2.2.1    ITIL V3

2.2.2    ISO 20000

2.2.3    COBIT

2.3    Konsolidierung der Standards für das Service-Level-Management

2.3.1    Voraussetzungen für ein standardisiertes Service-Level-Management

2.3.2    Methoden zur Unterstützung des Service-Level-Managements

2.4    Praxislösung für den Service-Level-Management-Prozess basierend auf IT-Standards

2.4.1    Ebene 1: Idealisierter Lebenszyklus

2.4.2    Ebene 2: Prozessstruktur

2.4.3    Ebene 3: Überführung in ein Wertschöpfungskettendiagramm

2.4.4    Ebene 4: Modellierung der Teilprozesse

2.4.5    Ebene 5: Mustervorlage einer Arbeitsanweisung

2.4.6    SLM-Prozess-Template für das Management

2.5    Zusammenfassung

3      Entwurf von Service-Level-Agreements und Servicekatalogen

3.1    SOUSIS-Modell: Beschreibung von IT-Services

3.1.1    Untersuchung von IT-Dienstleisterorganisationen

3.1.2    Ziele und Anforderungen für das SOUSIS-Modell

3.1.3    Das SOUSIS-Modell

3.1.4    Das Service-Fact-Sheet

3.2    Servicekatalog mit SOUSIS-Modell

3.2.1    Technischer vs. Business-Servicekatalog

3.2.2    Zielgruppenbasierte Servicekatalog-Ansätze

3.2.3    Faktenbasierter Servicekatalog mit dem SOUSIS-Modell

3.3    Praxislösungen für Servicekataloge

3.3.1    Beispiele für Servicebeschreibungen

3.3.2    Service-Fact-Sheet für geschäftsprozessbezogene Service-Levels

3.3.3    Service-Fact-Sheet für IT-betriebsrelevante Service-Levels

3.3.4    Kennzahlendefinitionen

3.4    Service-Level-Agreements mit SOUSIS-Modell

3.4.1    Architekturen von Service-Level-Agreements und deren Einsatzfeld

3.4.2    Service-Level-Agreement mit SOUSIS-Modell

3.4.3    Zentrale Sonderstellung: Pönalen/Gelbes Geld/Corporate Pönale

3.4.4    Verhandlungsstrategien

3.4.5    Verhandlungsverlauf

3.4.6    Änderungen an bestehenden Service-Level-Agreements

3.5    Praxislösungen für Service-Level-Agreements

3.5.1    Checkliste

3.5.2    Beispiele für SLA-Gliederungen

3.5.3    Formulierungsbeispiele (inkl. Pönalenregelung)

3.5.4    Zuständigkeitsmatrizen

3.5.5    Pönalen-Vergleichsliste

3.6    Zusammenfassung

4      Überwachung von Service-Level-Agreements

4.1    Monitoring

4.1.1    Grundlagen des Monitorings

4.1.2    Untersuchung der Messmethoden

4.2    Anforderungen an das IT-Messkonzept

4.3    Messmethoden

4.3.1    Applikationsrobotergestützte Ende-zu-Ende-Messung

4.3.2    Komponentenbasierte Ende-zu-Ende-Messung

4.3.3    Messung von gemeldeten Störungen

4.3.4    Erhebung der Verfügbarkeit aus Trouble-Tickets

4.3.5    Approximationsverfahren für die Verfügbarkeit

4.4    Service-Level-Agreement-Reports

4.4.1    Dimensionierung des Reportings

4.4.2    Reporting-Inhalte für einmalige IT-Services

4.4.3    Reporting-Inhalte für wiederkehrende IT-Services

4.5    Praxislösungen für Monitoring und Reporting

4.5.1    Auswahlverfahren von Messmethoden

4.5.2    Vorlagen für Reports

4.5.3    Vorgaben an Messdaten und Reports

4.6    Zusammenfassung

5      Werkbank für Service-Level-Manager: Arbeitskonzepte und Werkzeuge

5.1    Arbeitskonzepte für Service-Level-Manager

5.1.1    Service-Level-Überprüfung

5.1.2    Konsistenzprüfung von Prozessübergängen

5.1.3    Inhaltlicher Überblick über die Service-Level-Agreements

5.1.4    Grafischer Überblick über alle vereinbarten Service-Level-Agreements

5.1.5    Kalkulation der möglichen Verfügbarkeit

5.1.6    Auswertung von Reports

5.2    Service-Level-Management-Werkzeugskizzen

5.2.1    IT-Servicekatalog und Service-Level-Agreement-Eingabeformular

5.2.2    Monitoring

5.2.3    Managementplattformen und -werkzeuge

5.2.4    Soll-Ist-Datenbank

5.2.5    Service-Level-Agreement-Statusanzeige/-Report

5.2.6    Einfluss von Werkzeugen auf den Service-Level-Management-Prozess

5.3    Praxislösungen für die Service-Level-Management-Werkbank

5.3.1    Werkzeugstudie – SLM-Cockpit

5.3.2    Auswahlfragebogen zur Selektion von Monitoring-Werkzeugen

5.3.3    Herstellerverzeichnis von A-Z

5.3.4    Faustregeln

5.4    Zusammenfassung

6      Stolpersteine bei Service-Level-Agreements

6.1    Formale Hürden und Definitionsprobleme

6.1.1    Anwendung von Vorlagen

6.1.2    Sicherstellung der Konsistenz und Vollständigkeit komplexer Vertragswerke

6.1.3    Definition lückenloser Kennzahlen

6.1.4    Wiederherstellungszeit

6.2    Betrieb

6.2.1    Dauerhafte Leistungsabweichung

6.2.2    Klare Regelung der Zuständigkeiten

6.2.3    Abstimmung des Service-Level-Agreement-Ansatzes auf den Service-Level-Management-Prozess

6.3    Zusammenfassung

7      Interviews und Fallbeispiel

7.1    Interviews mit Service-Level-Managern über die Zukunft

7.1.1    Flughafen Nürnberg GmbH

7.1.2    American Express

7.1.3    Coca Cola

7.1.4    Continental

7.1.5    Otto Group

7.1.6    Vodafone

7.1.7    OTRS

7.2    Fallbeispiel: Neustrukturierung bei einem Dienstleister eines Finanzinstituts

7.3    Praxislösungen zum Benchmark

7.3.1    Benchmarks zu Service-Level-Agreements

7.3.2    Benchmark zum Service-Level-Management

8      Die 10 größten SLA-Irrtümer

9      Schlussbemerkungen

Anhang

Weblinks

Abkürzungen

Literatur

Index

»Anhand der Inhalte, der Form und der Konsistenz von SLAs lassen sich Rückschlüsse auf die Leistungsfähigkeit und die betriebliche Organisation eines Dienstleisters ziehen.«

[Fröschle und Kütz 2010, S. 311]

1 Einführung

Die Informationstechnologie (IT) zählt zu den tragenden Säulen einer modernen Industriegesellschaft und wird in Zukunft weiter in den beruflichen und privaten Bereich des Menschen vordringen. Das Schlagwort »Informationsgesellschaft« drückt diese Entwicklung treffend aus.

Damit die IT diese Rolle übernehmen kann, muss gewährleistet sein, dass die geforderte Funktionalität mit einer vorhersagbaren und garantierten Qualität erbracht wird. Erst durch eine die Qualitätseigenschaften überwachende Bereitstellung der Funktionalität im Rahmen sogenannter IT-Services wird sichergestellt, dass der Servicenehmer (also der Abnehmer der IT-Services und damit indirekt der Anwender oder Nutzer der dahinter stehenden IT-Systeme) die gewünschte Servicequalität erhält bzw. nutzen kann. Um einen IT-Betrieb qualitätsgesichert zu steuern und IT-Services bereitzustellen, sind die Methoden und Modelle von COBIT, ISO 20000 und ITIL geeignet (www.icaca.com, www.iso20000.ch, www.itil-officialsite.com). Auf sie wird deshalb im Folgenden intensiv eingegangen.

1.1 Einsatzfeld des Service-Level-Managements

Wie und wo wirkt Service-Level-Management?

Wenn Sie, liebe Leser, heute ein Produkt kaufen möchten und im Supermarkt zu einem Regal gehen, dann erwarten Sie, dass dieses Produkt dort steht. Wie viele Dienstleister, Netzwerke, Server und Anwendungen ineinandergreifen, um genau dieses Ziel zu erreichen, bleibt dem Endkunden verborgen. Die dahinter liegende Lieferkette enthält eine Vielzahl von Technologien zur Beherrschung der Logistik. Es bedarf eines hohen Expertenwissens, um die Komplexität und Abhängigkeiten zu verstehen. Die Logistik, die im Hintergrund wirkt, muss durchgängig korrekt und ausfallsicher konzipiert werden. Hierfür sind die Systeme entsprechend zusammenzuschalten, um den Weg für Ihr Produkt zu bahnen. Wenn Sie dann das Produkt in der Hand halten, damit zur Kasse gehen, und es würde in diesem Moment beispielsweise das Netzwerk, das die Kassen mit dem zentralen Waren-wirtschaftssystem verbindet, nicht funktionieren, könnten Sie Ihr Produkt nicht kaufen.

Sie müssen sich in der Lieferkette also u.a. auf die IT verlassen können. Welche Technologien auch verwendet werden, dahinter verbirgt sich eine Vielzahl von Dienstleistern, die diese Technologien bereitstellen und betreiben. Zu deren Koordination leisten Service-Level-Manager einen Beitrag. Sie entwerfen Regelungen (Service-Level-Agreements), wie das Zusammenspiel funktionieren muss, damit in unserem Beispiel die gesamte Lieferkette, allgemein die Wertschöpfungskette, zum Endkunden steht, wenn dieser eine Dienstleistung oder ein Produkt nachfragt. Der Service-Level-Manager stimmt somit im Rahmen des Service-Level-Managements die für Ihre Dienstleistung oder Ihr Produkt notwendigen, auf IT-Systemen basierenden Einzelleistungen ab, die in der Wertschöpfungskette benötigt werden. Bei diesen Einzelleistungen handelt es sich um die Bereitstellung von sogenannten IT-Services, die stets aus Sicht des Abnehmenden (Servicenehmer) und unter den Aspekten Zuverlässigkeit, Berechenbarkeit und Kosten entsprechend für den Einsatz konfiguriert werden. Servicenehmer können Sie als Endkunde sein oder aber – deutlich häufiger – die jeweilige Fachabteilung des Unternehmens, bei dem Sie etwas erwerben, bzw. ein weiterer (IT-)Dienstleister. Je mehr Dienstleister zusammenwirken müssen, desto komplexer werden die Lieferketten. Es werden deshalb immer umfassendere Regelungen erforderlich, damit die Bereitstellung reibungslos funktioniert. Damit jeder Dienstleister in der Lieferkette weiß, was er vom Vorgänger erwartet und was er dem Nachfolger gegenüber leisten muss, wird die erwartete Qualität (Service-Level) fixiert. Dies ist erforderlich, damit im operativen Betrieb alles reibungslos ineinandergreift und bei – schwerwiegenden – Aus- oder Zwischenfällen feststeht, wie schnell man wieder zum störungsfreien operativen Betrieb in der Lieferkette zurückkehrt. Übertragen auf das Eingangsbeispiel bedeutet dies, wenn Ihr Produkt nicht im Regal steht, kann Ihnen der genaue Zeitpunkt der Wiederverfügbarkeit genannt werden.

Nach dieser Einführung werden die folgenden Kapitel für eine bessere Orientierung und Navigation im Buch kurz vorgestellt. Die Zusammenstellung der SLA- und SLM-Inhalte ist aufgrund der inhaltlichen Vielfalt in mehrere Kapitel aufgeteilt.

Kapitel 2»IT-Standards für den Prozess Service-Level-Management«

Dieses Kapitel zeigt, wie sich das SLM historisch entwickelt hat. Dabei werden die Konzepte und Überlegungen, die auch heute noch für den Service-Level-Manager wichtig sind, herausgearbeitet. Anschließend folgen die aktuellen Standards ITIL V3, ISO 20000 und COBIT mit den neuen Konzepten und Anforderungen an das SLM. Darauf aufbauend werden die historischen und die aktuellen Standards konsolidiert und Praxislösungen entworfen.

Kapitel 3»Entwurf von Service-Level-Agreements und Servicekatalogen«

In Kapitel 3 wird die Erstellung von SLAs konzeptionell und anhand von Beispielen aufgezeigt. Hier finden sich auch Themen wie Servicekatalog und Pönalenregelungen, um Regressansprüche geltend zu machen. Dem Service-Level-Manager wird mit dem hier entwickelten SOUSIS-Modell ein Konzept eröffnet, mit dem er SLAs einheitlich und beherrschbar erstellen und verwalten kann.

Kapitel 4»Überwachung von Service-Level-Agreements«

Nachdem die SLAs entworfen wurden, müssen diese auf deren Einhaltung hin auch überwacht werden. Da die Überwachung ein eigener Themenkomplex ist, wird in Kapitel 4 ein systematisches Vorgehen aufgezeigt, wie sich Messungen geeignet einsetzen lassen. Die erforderliche Darstellung der Messergebnisse in Form von Reports wird ebenfalls anhand von Praxisbeispielen beschrieben.

Kapitel 5»Werkbank für Service-Level-Manager: Arbeitskonzepte und Werkzeuge«

Für das Management von Service-Level-Agreements sind für den Service-Level-Manager auch Arbeitskonzepte und Werkzeuge notwendig. In Kapitel 5 erfährt der Service-Level-Manager, welche Arbeitskonzepte und Werkzeuge sich für ihn eignen. Die erforderlichen Bausteine, die einen Service-Level-Manager unterstützen, sind inhaltlich aufgeführt.

Kapitel 6»Stolpersteine bei Service-Level-Agreements«

In jedem SLA-Projekt gibt es Herausforderungen. Damit der Service-Level-Manager entsprechend gewappnet ist, werden aus der Praxis Stolpersteine aufgezeigt. Somit erhält der Service-Level-Manager ein Spektrum an Erfahrungen, wenn er neu in die Thematik einsteigt, oder er erweitert seine Erfahrungen um die genannten Stolpersteine.

Kapitel 7»Interviews und Fallbeispiel«

In Kapitel 7 werden Interviews mit Service-Level-Managern geführt, die ihre Rolle heute und auch in der Zukunft bewerten. Im Anschluss wird ein Fallbeispiel aus der Praxis ausführlich diskutiert und mit Mengenangaben und Einschätzungen für Manager aufgezeigt.

Kapitel 8»Die 10 größten SLA-Irrtümer«

Zur Vermeidung von Kardinalfehlern werden in diesem Kapitel die 10 größten Irrtümer aufgezeigt. Service-Level-Manager können sehr kompakt ihre oder fremde SLAs überprüfen und schnell gegensteuern, sofern es zu Problemen kommen sollte.

Kapitel 9»Schlussbemerkungen«

In diesem Kapitel werden die zentralen Punkte aus dem Buch für SLAs hervorgehoben. Dabei werden generelle Aspekte und auch spezielle Punkte für das SOUSIS-Modell abgehandelt. Es wird die Anwendung des SOUSIS-Modells konzeptionell wie auch in der Realisierung empfohlen.

1.2 Zentrale Begriffe für Service-Level-Manager

In diesem Abschnitt werden die zentralen Begriffe, mit denen Service-Level-Manager tagtäglich arbeiten, eingeführt. Vermieden werden dabei theoretische Konzepte. Nur die tatsächlichen in der Praxis »gelebten« Definitionen sind genannt.

1.2.1 IT-Abteilung

Wenn in diesem Buch von einem »IT-Dienstleister«, der als Unternehmen IT-Services anbietet, gesprochen wird, so wird stets davon ausgegangen, dass dieser IT-Dienstleister aus organisatorischer Sicht intern in verschiedene IT-Abteilungen untergliedert ist. Diese IT-Abteilungen können entweder in die traditionellen Bereiche Netze, Server, Desktops oder auch nach ITIL-Prozessen wie Change-Management organisiert sein. Wichtig in diesem Zusammenhang ist, dass das Service-Level-Management selbst eine IT-Abteilung ist, die sich mit ihren Kollegen in den übrigen IT-Abteilungen abstimmt.

1.2.2 IT-Service

Das Verständnis des Begriffes IT-Service ist sehr unterschiedlich und wandelt sich hinsichtlich der darunter verstandenen Inhalte und seines Umfangs kontinuierlich. Aktuelle Beiträge in einschlägigen Veröffentlichungen (z.B. http://whitepaper.cio.de) und intensive Diskussionen in einschlägigen Fachgruppen unterstreichen diesen Trend. Nachfolgend wird die Entwicklung beispielhaft anhand der ITIL-Historie dargestellt, daran anschließend werden die in diesem Buch relevanten IT-Services definiert (http://www.knowledgetransfer.net/dictionary/ITIL/en/IT_Service.htm).

IT-Service (ITIL V1):

Ein IT-Service ist eine Reihe von Funktionen, die von IT-Systemen zur Unterstützung von einem oder mehreren Geschäftsfeldern zur Verfügung gestellt wird. Die Funktionen bestehen wiederum aus Software, Hardware und Kommunikationseinrichtungen, die durch den Servicenehmer als kohärente und in sich geschlossene Einheit wahrgenommen werden. Ein IT-Service kann vom Zugang zu einer einzigen Anwendung, wie z.B. ein Reservierungssystem, über eine komplexe Reihe von Einrichtungen, darunter viele Anwendungen sowie Büroautomatisierung, die über eine Reihe von Hardware- und Softwareplattformen verbreitet sind, reichen.

IT-Service (ITIL V2):

Ein IT-Service ist eine Gruppe von Komponenten, die zur Unterstützung eines oder mehrerer Geschäftsprozesse vorgesehen ist. Der IT-Service umfasst eine Reihe von Konfigurationselementen (Router, Arbeitsplatz) und wird vom Servicenehmer und Nutzer als eine in sich geschlossene, einheitliche, kohärente Einheit wahrgenommen.

IT-Service (ITIL V3):

Ein IT-Service ist eine Dienstleistung für einen oder mehrere Kunden von einem Dienstleister. Ein IT-Service basiert auf dem Einsatz von Informationstechnologie und unterstützt die Geschäftsprozesse des Servicenehmers. Ein IT-Service besteht aus einer Kombination von Menschen, Prozessen und Technologie und sollte in einem Service-Level-Agreement definiert werden.

Entlang der Historie zeigt sich, dass ein IT-Service aus der Perspektive des Servicenehmers von der zugrunde liegenden Leistungserbringung (Menschen, Prozessen und Technologie) abstrahiert.

Zu diesen IT-Services gehören etwa Kommunikations- und System- bzw. Anwendungsservices sowie Prozesse. Beispiele hierfür, die in diesem Buch genutzt werden, sind:

Standard-IT-Arbeitsplatz:

Ein Desktop-System wird für einen Benutzer an seinem Arbeitsplatz installiert, konfiguriert, angeschlossen und betriebsbereit geschaltet.

Hardware-Serverbetrieb:

Der Infrastruktur-Service »Hardware-Serverbetrieb« stellt abgenommene Betriebssystemplattformen im Bereich Windows und Unix zur Verfügung.

Fileserver:

Der IT-Service »Fileserver« umfasst die Bereitstellung von Gruppenlaufwerken (Gruppenshares) und expliziten Fileservern in fest definierten maximalen Größen.

Terminalserver:

Im Rahmen dieses IT-Service stellt der Dienstleister abgenommene Plattformen zur Verfügung.

Datenbankserver:

Der IT-Service »Datenbankserver« umfasst die Bereitstellung der Infrastruktur zum Test und zum Betrieb von Datenbanken der entsprechenden Hersteller. Im Rahmen dieses IT-Service wird auch der Betrieb der Datenbank bzw. der Datenbankumgebung angeboten.

EAI-Application Development:

Der EAI-Application-Development-Service unterstützt die Servicenehmer bei der Planung und Implementierung von Prozessen und Datentransfers zwischen unterschiedlichen IT-Systemen im Rahmen von Enterprise Application Integration (EAI).

EAI-System Maintenance & Operations:

Der EAI-Service beinhaltet das Schnittstellenmanagement zwischen operativen IT-Systemen einschließlich der notwendigen Datenkonvertierungen im Rahmen von Enterprise Application Integration.

IT-Security:

Der IT-Dienstleister bietet Servicenehmern auf Aufwandsbasis (i.d.R. Personentage) IT-Services im Bereich IT-Security an. Der IT-Dienstleister berät und unterstützt Servicenehmer hinsichtlich der Security-Aspekte bei der Konzeption, dem Aufbau, der Implementierung und dem Betrieb von IT-Systemen.

Dieses Buch beschäftigt sich vorwiegend mit IT-Services, die Dienstleister, die vernetzte Systeme betreiben, ihren Servicenehmern anbieten. IT-Services sind dadurch gekennzeichnet, dass sie in einer für den (fachlich oder technisch orientierten) Abnehmer verständlichen Form beschrieben sind und direkt durch Nutzung der Ressourcen von vernetzten IT-Systemen realisiert werden [Scholderer 2001].

1.2.3 Operational-Level-Agreement

Ein Operational-Level-Agreement (OLA) ist eine Vereinbarung, die intern, also innerhalb eines Unternehmens, zwischen unterschiedlichen Abteilungen getroffen wird. Der interne Betrieb größerer Rechenzentren ist meist in einzelne IT-Abteilungen für z.B. Serverbetrieb oder Applikations-Hosting aufgeteilt. Werden gegenüber Servicenehmern (Endkunden) komplexe Leistungen angeboten, die aus den IT-Services der jeweiligen Abteilungen zusammengesetzt werden, so sind nach ITIL Operation-Level-Agreements zu definieren [Bon 2008]. Das in diesem Buch erarbeitete Modell greift diese Tatsache auf und setzt das Zusammenspiel aus OLA und SLA über ein gemeinsames Template um. Dies bedeutet: Die Strukturen des IT-Servicekatalogs müssen grundsätzlich auch im Operational-Level-Agreement enthalten sein. Es sind zudem die Basisleistungen der IT in einem oder mehreren IT-Servicekatalogen zu definieren. Nach dem Angebot aus dem IT-Servicekatalog können die einzelnen IT-Abteilungen einen oder mehrere Services in einem OLA zusammenstellen. Basierend auf diesen OLAs können jetzt die Mengen und Service-Levels, wie Verfügbarkeit, mit einem zwischen Dienstleister und Servicenehmer vereinbarten SLA, das auf diesen OLAs aufsetzt, verglichen und abgestimmt werden.

OLAs werden in der Praxis in unterschiedlichen Ausprägungen vorgefunden. Dabei werden Umfang und Inhalt der IT-Services und die Definition der Qualitätsstandards mit einbezogen. Sanktionen bei Nichterfüllung werden in der Praxis nicht vereinbart. Eine Form von Sanktionen aber ist, die gezahlten Kosten für die IT-Services nicht vom Dienstleister, sondern vom Servicenehmer steuern zu lassen. Im Blickpunkt steht, dass die IT-Services verbessert werden (z.B. Anschaffung eines Backup-Servers).

Weil ein OLA eine unternehmens- bzw. konzerninterne Vereinbarung ist, entspricht ein OLA in der Regel keinem Vertrag im juristischen Sinne, sondern einer Dienstleistungsvereinbarung. Das OLA spezifiziert Liefer- und Leistungsbeziehungen zwischen den (beiden) internen Parteien.

Aufgrund des Szenarios, dass IT-Services von Dienstleistern oder über Drittdienstleister eingekauft und gegenüber Servicenehmern angeboten werden, folgt in der Praxis meist, dass OLAs maßgeblich die SLAs beeinflussen. In SLAs können die in OLAs geltenden Vereinbarungen, wie z.B. eine 99%ige Verfügbarkeit, nicht über bzw. unter den Service-Levels abgeschlossen werden.

Der externe Servicenehmer muss wissen, was er vom Dienstleister erwarten kann (z.B. Einschränkungen aufgrund der eingesetzten Plattform). Weitere positive Argumente für die Nutzung von OLAs sind beispielsweise die Zufriedenheit der externen Servicenehmer, Schutz vor »schleichendem« Erwartungsdruck oder eine Ressourcenkontrolle. Um diese positiven Aspekte zu entfalten, müssen OLAs genau definierte und messbare Kennzahlen enthalten.

Setzt sich ein SLA aus IT-Services mehrerer zusammenwirkenden IT-Abteilungen eines Unternehmens zusammen, schließt die für das Service-Level-Management verantwortliche IT-Abteilung ein OLA mit diesem internen Dienstleistern ab (s. Abschnitt 3.1.3).

Praxishinweis:

OLAs entstehen immer nur im Zusammenhang mit SLAs, die von externen Servicenehmern gefordert werden [Fröschle und Kütz 2010].

1.2.4 Servicekatalog

Der Servicekatalog beschreibt IT-Services, die ein Dienstleister seinen Servicenehmern anbietet, in einer einheitlichen Systematik. Diese IT-Services sind Teil eines Serviceportfolios und dort nach Nutzenaspekten bewertet und gegliedert.

In einem Servicekatalog werden alle relevanten Leistungen (z.B. Service-Desk, Backup) einem IT-Service zugeordnet. Der Servicekatalog ist ein wichtiges Hilfsmittel, um auf Anforderungen des Servicenehmers optimal reagieren oder Service-Level-Agreements präzise erstellen zu können. Die Sicht des Servicenehmers ist entscheidend dafür, wie der Servicekatalog in seiner Ausrichtung konzipiert wird. Vor der Erstellung ist zu klären, um welche Zielgruppe es sich handelt [Scholderer 2016]. Ein Servicekatalog, der Technikern dienen soll, ist anders aufgebaut als für Entscheider auf Managementebene. Der Servicekatalog ist eine Leistung des operativen Betriebs und dem ITIL-Prozess Servicekatalogmanagement zugeordnet [ITILv3 2011]. Die Pflege und Aktualisierung wird innerhalb des operativen Betriebs in Absprache mit den internen IT-Abteilungen sowie mit Fachabteilungen vorgenommen.

Den Einstieg in den Servicekatalog bilden die Vorgänge wie Auswahl und Buchung von IT-Services entlang des Prozesses Service-Level-Management. In diesen Vorgängen wird gegenüber dem Servicenehmer deutlich gemacht, wie man den Servicekatalog auf die SLAs oder auf die Änderung von Servicemerkmalen (z.B. Backup-Verfahren von einmal pro Tag auf laufende Sicherungen wie write-through umstellen) anwenden kann. Abbildung 1–1 zeigt, wie ein Servicekatalog aufgebaut sein kann (s. Abschnitt 3.2).

Abb. 1–1 Servicekatalog

Die folgenden Punkte sollten in einem Servicekatalog vorhanden sein:

Prozessbeschreibung:

Eine Beschreibung des Service-Management-Prozesses des Dienstleisters, damit der Servicenehmer die für ihn bereitgestellten Anforderungs- und Bestellvorgänge nachvollziehen kann.

Übergeordnete Service-Levels:

In diesen übergeordneten Service-Levels sind die zentralen Werte (z.B. Betriebs- und Servicezeiten), die den Betrieb der IT-Services operativ ermöglichen, explizit genannt. Diese Werte bilden also die »übergeordneten Service-Levels«. Sie gelten für alle IT-Services und sollten für spezielle IT-Services nicht verändert werden.

Service:

Das Element »Service« nimmt alle Aspekte wie z.B. Verfügbarkeit, Antwortzeit mit einem vordefinierten Template auf. Für das Element Service können zusätzlich Leistungskategorien wie z.B. »Gold«, »Silber« oder »Bronze« definiert werden, um dadurch bei vielen Services eine Strukturierung zu erhalten. Eine solche Strukturierung ist jedoch nicht bindend und kann ggf. bei einzelnen IT-Services aufgehoben werden. Letztlich kommt nur der IT-Service zum Tragen. Diese Flexibilität ist deshalb wichtig, da IT-Services je nach Anwendungsfall unterschiedlich strukturiert werden müssen. Eine starre Hierarchie ist aus diesem Grund nicht sinnvoll und dauerhaft aufrechtzuhalten.

Begriffe und Definitionen:

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 zur Leistungsmessung und Qualitätssicherung vorgenommen.

Kosten:

Das abschließende Element wird separat von den IT-Services definiert und behandelt die Kosten, die für einen IT-Service berechnet werden. Diese komprimierte Darstellung aller IT-Services in einer »Preisliste« erlaubt ein kontinuierliches Aktualisieren der Kosten an einem Ort, ohne Änderungen in den Dokumentationen der IT-Services vornehmen zu müssen. Außerdem kann der Servicekatalog so ggf. auch ohne Preisliste an Servicenehmer zur Ansicht weitergegeben werden. Dies ist szenariospezifisch zu berücksichtigen, denn für eine IT-Lösung mittels IT-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 IT-Service werden prägnant beschrieben und bestimmte wiederkehrende Serviceklassen vereinheitlicht dargestellt. Die Zuteilung betrieblicher Zuständigkeiten wird dem Verhandlungsprozess überlassen. Der Servicekatalog dient dazu, die Eckpunkte eines IT-Service festzulegen. In der konkreten Umsetzung müssen diese beschrieben und ausgestaltet werden. Der Servicekatalog beschränkt sich auf Aspekte der Erbringung des IT-Service. Die Auslieferung von IT-Services mit Lieferzeiten wird hier nicht berücksichtigt und ist daher – wie die oben genannten weiteren Aspekte – gesondert im Service-Level-Agreement beschrieben.

Praxishinweis:

Wenn Servicenehmer umfangreiche IT-Services buchen, dann hat der IT-Servicekatalog sein Ziel erreicht und ist über den Status »Visitenkarte der IT« hinausgewachsen [Fröschle und Kütz 2010].

1.2.5 Service-Levels

Ein Service-Level quantifiziert einen IT-Service [Kütz 2010]. Es handelt sich dabei um Ausdrücke, deren Ergebnis eine Eigenschaft der Dienstleistung charakterisiert. Service-Levels müssen demzufolge Ausdrücke mit einfachen, eindeutig interpretierbaren Ergebnissen beinhalten, wie z.B. »true« und »false« oder die Farben einer Ampel, damit deutlich wird, wann Service-Level nicht eingehalten worden sind [Schmidt 2001]. Bei der begrifflichen Einführung zu den Service-Levels kann zwischen Topkennzahlen, Ergebniskennzahlen und Leistungstreibern unterschieden werden. Anhand von Beispielen aus dem IT-Anwendungsbereich Service-Desk lassen sich diese Service-Levels anschaulich erläutern [Bernhard 2004]: Die Topkennzahlen vermitteln die gesamte Serviceleistung des Dienstleisters gegenüber dem Servicenehmer, z.B. der Customer-Service-Index aus einer IT-Kundenbefragung [Lohrmann u.a. 1997]. Die Ergebniskennzahlen sind Kennzahlen, die gegenüber dem Servicenehmer kommuniziert werden, z.B. Verfügbarkeit, Wiederherstellungszeit, Reaktionszeit (s. Abschnitte 3.3.2, 3.3.3 und 3.3.4). In Abbildung 1–2 ist der Zusammenhang zwischen den unterschiedlichen Kennzahlentypen, den Leistungstreibern und verschiedenen IT-Bereichen detailliert dargestellt. Entscheidend ist dabei, dass die Ergebniskennzahlen und die Leistungstreiber der einzelnen IT-Einheiten die Basis für die Ermittlung der Topkennzahl bilden.

Abb. 1–2 Zusammenhang zwischen Top-, Ergebniskennzahlen, Leistungstreiber [Bernhard 2004]

Die Zusammenhänge sollen am Beispiel des Service-Desk eingehender betrachtet werden:. Wie bereits erläutert, stellt der Customer-Service-Index (oder Customer-Satisfaction-Index) eine Topkennzahl dar. Im Customer-Service-Index wird ein Messverfahren festgelegt, wonach die generelle Zufriedenheit des Benutzers mit dem Dienstleister festgestellt wird [Söbbing 2002]. So können z.B. alle Benutzer, die mit dem Service-Desk in Verbindung stehen, nach ihrer Zufriedenheit mit der Entstörung oder der Erreichbarkeit befragt werden. Diese Befragung kann hinsichtlich des Detaillierungsgrades nach Bedarf und IT-Bereich beliebig gestaltet werden. Zu typischen Service-Levels gehören z.B. Antwortzeit, Reaktionszeit, Verfügbarkeit, Wiederherstellungszeit oder max. Datenverlust [Müller 1999]. Im Fall des Service-Desks wurden die Service-Levels Erreichbarkeit, Reaktions- und Annahmezeit ausgewählt. Die Verfügbarkeit beschreibt, inwiefern ein IT-System in der vereinbarten Betriebszeit zur Verfügung steht. Ein IT-System mag durchaus laufen, doch wenn es mit Transaktionen beschäftigt ist und dadurch kein anderer Benutzer Zugriff erhält, ist das IT-System in diesem Moment nicht verfügbar. Alle Anwendungsbereiche der IT Infrastructure Library lassen sich durch Service-Levels definieren [ITILv3 2011].

1.2.6 Service-Level-Agreement und Underpinning Contract

Ein Service-Level-Agreement (SLA) ist ein Servicevertrag, der die Servicenehmer-Dienstleister-Beziehung beschreibt und regelt (s. Abschnitt 3.4.2). Die Erstellung und Überwachung bzgl. der Einhaltung des vereinbarten IT-Service sind im ITIL-Prozess Service-Level-Management (SLM) verankert [ITILv3 2011].

Werden die einzelnen Wörter des Begriffs Service-Level-Agreement untersucht, so geben diese bereits Hinweise auf den Begriffsgegenstand:

Service (engl. Dienst, Dienstleistung):

Bringt zum Ausdruck, dass es inhaltlich um den Objektbereich des IT-Service geht.

Level (Übersetzung in diesem Kontext: Niveau):

In Kombination mit dem ersten Wort Service führt dies zu dem Begriff Dienstleistungsniveau bzw. Dienstleistungsstandard (Service-Level).

Agreement (engl. Vereinbarung):

Zustimmung oder Vereinbarungen zwischen in der Regel zwei Parteien.

Ein SLA ist eine nicht notwendigerweise formale, aber immer schriftlich dokumentierte, für einen festgelegten Zeitraum abgeschlossene Vereinbarung zwischen einem Auftraggeber (Servicenehmer) und einem Auftragnehmer (Dienstleister). Dabei muss der Auftraggeber nicht notwendigerweise der Anwender des beschriebenen IT-Service sein. Ein SLA wird dazu genutzt, Erwartungen zu identifizieren, Verantwortlichkeiten zu klären und die Kommunikation (z.B. Eskalationsprozeduren, Notfallprozeduren) zwischen einem Auftragnehmer und seinem Auftraggeber zu steuern. Ebenfalls geregelt werden finanzielle Ausgleichszahlungen für die Leistungserbringung, aber auch bei einem Leistungsausfall. Ein SLA definiert Verfahren, die den Nachweis der Einhaltung der Service-Levels regeln, sowie Konsequenzen für den Fall der Abweichung von vereinbarten Service-Levels. Bei einer Nicht- oder Schlechtleistung kann der Servicenehmer auf diesem Weg vom Dienstleister einen Teil der Ausgleichszahlungen einbehalten oder dessen Verwendungszweck bestimmen. Wichtige Voraussetzungen vor der Vereinbarung von Bonus-Malus-Regelungen sind erfolgreiche Servicetests, um die festgelegten Anforderungen auch erfüllen zu können.

Wichtige, im Zusammenhang mit SLAs zu benennende Inhalte und festzulegende Aspekte sind:

Beschreibung der Vertragspartner

Eskalationspfade

Bonus-Malus-Regelungen bei Nicht- oder Schlechterfüllung

Kündigung, Ausstiegsklauseln

Beschreibung des Service, der Servicequalität und Serviceprozesse

Die Definition der durch den Dienstleister zu erbringenden Qualität der Dienstleistungen erfolgt durch die Festlegung von einzuhaltenden Service-Levels (Sollwerten) für bestimmte, gemeinsam definierte, quantifizierbare und für den Auftraggeber relevante Merkmale der IT-Services, die durch Kennzahlen ausgedrückt werden. Typische Service-Levels im Zusammenhang mit SLAs sind:

Übertragungszeiten, Verfügbarkeit, Antwortzeiten der Applikation

Betriebszeiten, Problemlösungszeiten, geplante Ausfallzeiten

Zeitvorgabe für die Annahme von Anrufen

SLAs können nach dem Tätigkeitsbereich des Dienstleisters wie folgt untergliedert werden:

Technische SLAs:

Sie werden zwischen IT-Dienstleistern abgeschlossen, die eher auf spezifische technische Anforderungen bzw. technische Merkmale von IT-Services eingehen möchten, und setzen bei beiden Partnern ein tieferes technisches Verständnis voraus. Beispiel: Betrieb eines Servers, eines Netzwerks sowie der benötigten Endgeräte.

Geschäftsprozessbezogene SLAs:

Sie müssen auf die Belange von Endanwendern eingehen, die weniger an technischen Details interessiert sind, sondern vielmehr am Nutzen für betriebliche Aufgaben. Beispiel: Erbringung eines Geschäftsprozesses, der auf den Betrieb einer oder mehrerer Anwendungen zurückgreift – im SLA als IT-Services dokumentiert – und weitere manuelle Tätigkeiten beinhaltet.

Eine besondere Form von SLAs sind Underpinning Contracts (UC). Als UC bezeichnet man alle SLAs, die IT-Services enthalten, die von Drittdienstleistern bezogen werden. Der Begriff UC ist somit ein Konzept zur besseren inhaltlichen und organisatorischen Differenzierung: Ein Vertrag zwischen dem Servicenehmer und einem IT-Dienstleister wird SLA genannt. Ein Vertrag zwischen dem IT-Dienstleister und seinen Drittdienstleistern hingegen wird als UC bezeichnet.

Hingewiesen sei darauf, dass es sich bei der Abgrenzung von SLA und UC um ein Konzept handelt. In der Praxis sind alle Dokumente mit dem Begriff SLA überschrieben.

Praxishinweis:

Anhand der Inhalte, der Form und der Konsistenz von Service-Level-Agreements lassen sich Rückschlüsse auf die Leistungsfähigkeit und die betriebliche Organisation eines Anbieters ziehen [Fröschle und Kütz 2010].

1.2.7 Service-Level-Manager

Der Service-Level-Manager trägt die Verantwortung für das Verhandeln von Service-Level-Vereinbarungen und stellt sicher, dass diese auch erfüllt werden (s. Abschnitt 2.4). Er gewährleistet, dass alle IT-Service-Management-Prozesse, Vereinbarungen auf Betriebsebene (Operational-Level-Agreements) und Verträge mit Drittparteien (Underpinning Contracts) geeignet sind, um die Ziele der vereinbaren Service-Levels zu erreichen. Der Service-Level-Manager überwacht die Service-Levels und stellt regelmäßig zu vereinbarten Zeitpunkten einen entsprechenden Report zu den Service-Levels zur Verfügung. Zu seinen Aufgaben gehören:

Erstellung und Aktualisierung des Servicekatalogs

Aufnahme der geschäftlichen Anforderungen von Servicenehmern

Definition von SLAs und Service-Levels

Monitoring definierter SLAs, um deren Einhaltung zu überwachen

Proaktiv bei drohenden SLA-Verletzungen auf den Servicenehmer zugehen

Festlegung, Prüfung und Verteilung der entsprechenden Reports

Regelmäßiges Überprüfen, ob SLAs ihre vordefinierten Ziele erreichen

Optimierung und Anpassung bestehender Verträge

Entwicklung und Verwaltung von unterstützenden Verträgen von Drittdienstleistern

Der Service-Level-Manager vermittelt zwischen mehreren Stellen. Die Inhalte zur Erstellung von SLAs werden selten aus einer Hand geliefert, meist sind verschiedene Abteilungen beteiligt. Der Einkauf verhandelt Formelles und Rahmenbedingungen, z.B. Preis und Wartungskosten, allgemeine Geschäftsbedingungen, Mängelfristen. Der Fachbereich definiert den Inhalt, also die Software und/oder Leistung. Die IT hat technische Vorgaben für die Integration und die Standards im eigenen Rechenzentrum. Der Projektleiter des Projekts benötigt klare Regeln über die Abwicklung des Projekts, Eskalationslinien, Änderungsverfahren. Das Rechnungswesen braucht eine budgetäre Sicht, die auch erwartete Änderungen einschließt, aktivierbare und nicht aktivierbare Teile trennt und die Abwicklung künftiger Wartungsleistungen regelt. Der Service-Level-Manager stellt die relevanten Inhalte den entsprechenden Anforderungen der gegenüberstehenden Vertragspartei zur gemeinsamen Verhandlung und Abstimmung im SLA zusammen.

Die Verwaltung von SLAs umfasst den strukturierten Aufbau von vertragsrelevanten Metainformationen zu SLAs und deren Inhalte. Ebenso zum SLM zählt die nachhaltige Verbesserung des SLM-Prozesses, um effektiv und effizient SLAs verwalten zu können. Der Service-Level-Manager überwacht Kündigungstermine und sonstige Fristen.

1.2.8 Service-Level-Management

Als Service-Level-Management (SLM) bezeichnet man die Steuerung und Sicherstellung einer ausreichenden Servicequalität in Übereinstimmung mit Geschäftsprioritäten und akzeptablen Kosten. Dies soll zur Verbesserung von IT-Services für alle IT-Benutzer führen (s. Abschnitt 2.4).

Werden Service-Level-Agreements (SLAs) oder Underpinning Contracts (UC) in einer IT-Outsourcing-Beziehung eingesetzt, müssen zusätzlich immer SLM-Prozesse etabliert werden. Dies bedeutet, dass der IT-Dienstleister durch ein geeignetes IT-Management sicherstellen muss, dass die festgelegten IT-Services in der zuvor definierten Qualität erbracht werden. SLM ist weder eine Technologie noch eine einmalige Einführung von SLAs. Vielmehr handelt es sich um einen kontinuierlichen Prozess, der als zentrales Ziel die Umsetzung des »Servicegedankens« und die stetige Optimierung der Servicequalität verfolgt.

Um die Lücke zwischen den Bedürfnissen des Servicenehmers und den vertraglichen Vereinbarungen möglichst gering zu halten, reichen demzufolge die statische Definition von SLAs und das Monitoring dieser Vereinbarungen nicht aus. Vielmehr muss ein kontinuierlicher Ablauf aufgebaut werden, der im Wesentlichen aus vier Teilprozessen besteht:

Festlegung und Anpassung der Serviceziele und Service-Level-Kennzahlen

Management der definierten Ziele hinsichtlich Leistung, Kosten und Qualität

Leistungsnachweis der erbrachten Serviceleistung

Verbesserung und Optimierung der Leistungsfähigkeit

Innerhalb des SLM-Prozesses existiert eine Vielzahl von Rollen, um den IT-Service an den Servicenehmer auszuliefern. Um Unstimmigkeiten über die Art des zu liefernden IT-Service zu vermeiden, ist die gegenseitige Erwartungshaltung zu gewährleisten. Die Ausprägung des Service-Level-Managements unterscheidet sich deutlich entsprechend der Art der IT-Services, die ein Rechenzentrum anbietet. Werden kleinere und stark vorkonfektionierte Lösungen für bestimmte Zielgruppen angeboten, so wählt der Servicenehmer aus dem Servicekatalog aus, und anschließend kommt das SLA zustande. Anders verhält sich das Service-Level-Management für große IT-Lösungen, z.B. das Outsourcing von 4000 Servern und 600 Applikationen. Deutlich ist, dass auch hier ein Servicekatalog benötigt wird, um die Komplexität zu beherrschen. Die Abstimmung mit allen Fach- und/oder IT-Abteilungen ist dennoch erforderlich, da bestimmte Details (z.B. welche Underpinning Contracts mit gelten) zu klären sind. Das Service-Level-Management verringert diesen Abstimmungsanteil durch Ergänzung des Servicekatalogs um entsprechende Parameter (z.B. Verweise auf relevante Underpinning Contracts).

Abb. 1–3 SLM-Prozess

Der Ablauf des Service-Level-Managements sieht wie in folgt aus (s. Abb. 1–3). Der Servicenehmer kann aus einem Servicekatalog oder einem vorkonfektionierten Serviceangebot seinen benötigten IT-Service auswählen oder individuell Service-Level-Requirements formulieren. Entweder entsteht direkt der IT-Rahmenvertrag, unter dem weitere einzelne SLAs angeordnet werden können, oder es werden Treffen einberufen, um die Anforderungen seitens des Servicenehmers genauer abzustimmen. Im Service-Level-Management entsteht in der Aktivität SLA-Eingang der erste Entwurf eines SLA für den Servicenehmer. Hierfür können ggf. bereichsbezogene Abstimmungen stattfinden. Anschließend wird der intern abgestimmte Entwurf mit dem Servicenehmer diskutiert. Je nach Status des SLA erfolgt eine neue Abstimmungsrunde oder der Entwurf wird als IT-Rahmenvertrag formuliert. Die Bereiche Vertragsmanagement und IT-Controlling übernehmen hier die tragende Rolle. Das Outsourcing-Projekt kommt durch den SLA-Abschluss zustande. Das SLA wird zusammen mit einem IT-Rahmenvertrag verabschiedet. Parallel mit dem neuen SLA werden die Aktivitäten SLA-Überwachung und SLA-Verwaltung gestartet. Der Lebenszyklus eines SLA beinhaltet ebenso Änderungen am SLA, wenn der IT-Service nachgebessert wird. Das SLA endet nach seiner Laufzeit oder wenn der Servicenehmer die Kündigungsfrist einhält [Fröschle und Kütz 2010].

1.2.9 Service-Management

Unter Service-Management (SM) versteht man die Schnittstelle zwischen dem Servicenehmer und den angebotenen Produkten eines Dienstleisters. Der Begriff Service-Management wird im IT-Management häufig synonym mit den Begriffen Business-Service-Management und IT-Service-Management (ITSM) verwendet (s. Abschnitte 2.1 und 2.2).

Unternehmen beziehen immer mehr und vor allem neue IT-Services von Dienstleistern. Damit die Versorgung kontinuierlich aufrechterhalten werden kann, ist es notwendig, dass IT-Dienstleister sich entsprechend auf diesen Bedarf einstellen und ein serviceorientiertes IT-Management implementieren. Die darin gewonnenen Serviceinformationen werden dem Service-Interaction-Management zur Verfügung gestellt. Komplexe vernetzte Systeme, auf deren Basis IT-Services für eine große Anzahl von Benutzern bereitgestellt werden, laufen nicht von selbst – sie benötigen ein IT-Service-Management. Das Service-Management führt weg vom einfachen Rechenzentrum hin zum wertschöpfenden IT-Betrieb. Beschränkten sich Dienstleister bisher auf die reine Beherrschung der Informationstechnologie und die Anpassung von innovativen Technologien, so wird jetzt verlangt, dass der Dienstleister IT-Services anbietet, die die strategischen Geschäftsprozesse des Unternehmens unterstützen. Der Fokus wird somit auf die Kunden- und Serviceorientierung gelegt. In dieser Rolle legt das SM fest, wie diese Kunden- und Serviceorientierung aufgebaut, koordiniert und umgesetzt werden kann. Diese Änderung der Servicekultur beginnt intern mit Operational-Level-Agreements (OLA).

Das SM klärt in diesem Zusammenhang zwei Fragenkomplexe. Zum einen wird festgelegt, welche Services der Servicenehmer wahrnimmt, und zum anderen werden Maßnahmen und Methoden definiert, die erforderlich sind, damit diese IT-Services geeignet bereitgestellt und betrieben werden können.

IT-Services

Für ein geeignetes SM ist es erforderlich festzustellen welche IT-Services unternehmenskritisch sind. Dies wird meist sowohl aus der Bedeutung der Geschäftsprozesse abgeleitet als auch aus der Integrationstiefe der IT-Services in die Geschäftsprozesse. Bei den IT-Services handelt es sich oft um Applikationen und Infrastruktur-Services (z.B. LAN, WAN), die Geschäftsprozesse des Servicenehmers unterstützen und somit effizienter gestalten. Je weiter ein IT-Service in einen Geschäftsprozess integriert ist, desto stärker wirken sich Ausfälle und Störungen auf den Geschäftsbetrieb aus. Entscheidend ist also, wie bedeutend und wie ausfallsicher die IT-Services sind bzw. sein müssen. Das zugrunde liegende Konzept des ITIL-Prozesses Service Validation and Testing [ITILv3 2011] zielt darauf ab, dass die Geschäftsprozesse, entgegen den technischen Widrigkeiten, möglichst störungsfrei bzw. störungsarm erbracht werden. ISO/IEC 20000 [Andenmatten 2008] definiert außerdem einen Prozess für die Planung und Umsetzung von neuen oder geänderten Services (Planning & Implementation new or changed Services). Für die neuen und geänderten Services soll gemäß den kalkulierten Kosten die vereinbarte Servicequalität erbracht werden.

Prozesse

Zur Leistungserbringung wird im SM als Konzept ein prozessbasierter Ansatz gewählt, der alle an der Wertschöpfungskette eines oder mehrerer IT-Services beteiligten Abläufe und Infrastrukturen beschreibt. Zur Implementierung sind entsprechende Prozesse aufzubauen. Diese Prozesse werden dem SM zugeordnet. Die SLAs zwischen Servicenehmern und Dienstleistern veranlassen den Betreiber, alle Prozesse auf die Erfüllung der vom Benutzer gestellten Anforderungen auszurichten. Ist eine Erfüllung nicht gegeben oder liegt eine Übererfüllung vor, so regelt ein Bonus-Malus-System die Leistungsverrechnung. Die Orientierung an den dafür notwendigen Prozessen zur Erfüllung des SLA führt zu einem erhöhten Erfolgsdruck für den Betreiber, bietet im Bonusfall aber auch Anreize zur Effizienz- und Effektivitätsverbesserung. Unter anderem müssen die Prozesse in bestimmter Zeit durchlaufen werden, um die in den SLAs festgeschriebenen Zeitund Terminabsprachen einhalten zu können. Das SM koordiniert die Prozesse so, dass die Leistungserbringung strukturiert erfolgt und im Fehlerfall dedizierte Vorgehensweise dazu führen, dass die Leistungserbringung schnellstmöglich wieder fehlerfrei erbracht wird.

Praxishinweis:

Es bestehen alternative Möglichkeiten zur Strukturierung der Prozesse des SM. Rahmenwerke wie Control Objectives for Information and Related Technology (COBIT, www.isaca.com), IT Infrastructure Library (www.itil-officialsite.com), Enhanced Telecom Operations Map (eTOM, www.tmforum.org), Microsoft Operations Framework (MOF, www.microsoft.com), Integrated Service-Management (ISM, www.kpn.com) und Information Technology Process Model (ITPM, www.ibm.com) liefern mit unterschiedlichen Schwerpunkten Ansätze, wie ein SM geeignet aufgebaut werden kann [Fröschle und Kütz 2010].

1.2.10 Service-Level-Management-Werkzeuge

SLM-Werkzeuge implementieren das im Folgenden vorgestellte SOUSIS-Modell sowie das zwingend notwendige Mess- und Reporting-Konzept. Die Servicewerkzeuge sind dabei modular aufgebaut, sodass ein oder mehrere funktionale Module mit einem am Markt verfügbaren SLM-Werkzeug umgesetzt werden können.

1.3 Herausforderung: Service-Level-Management

Die Herausforderung, die ein Service-Level-Management darstellt, lässt sich an Abbildung 1–4 veranschaulichen.

Der obere Teil der Abbildung zeigt, dass ein Servicenehmer, der interne Prozesse auslagern will, sowohl eigene Wünsche als auch bestimmte eigene Zwänge an den Dienstleister heranträgt. Wünsche sind dabei z.B. Kostenvorstellungen (als eine Verhandlungsbasis), Dienste und Dienstqualität. Unter Zwängen versteht man z.B. das Budget (das maximal ökonomisch Realisierbare oder Sinnvolle), die Verwendung von Legacy-Systemen, Integrationsanforderungen, Netzwerktopologien und zu viel oder zu wenig Personal mit einem bestimmten Qualifikationsprofil. Der Dienstleister selbst unterliegt durch seine eigene Organisation bzw. seine technische Infrastruktur ebenfalls Zwängen. Fasst man die Zwänge und Wünsche des Servicenehmers mit den Vorgaben des Dienstleisters zusammen, so ergeben sich exakte Anforderungen an ein technisches System. Der untere Teil der Abbildung zeigt, wie das Service-Level-Management des Dienstleisters abläuft. Das technische Gesamtsystem muss zunächst vom Dienstleister installiert und konfiguriert werden. Dies ist als Prozess zu sehen, der auch im Tagesbetrieb weiterläuft, z.B. wenn das System erweitert wird. Ferner muss das System permanent überwacht und gewartet werden. Das System selbst leistet eine Funktion, die vom Dienstleister veredelt werden kann. Als Beispiel könnte man ein laufendes Anwendungssystem sehen. Dessen Funktionalität wird nun vom Dienstleister veredelt, indem der Dienstleister beispielsweise die Gehaltsabrechnung des Servicenehmers darauf durchführt. Dieser sogenannte IT-Service wird für den Servicenehmer erbracht.

Abb. 1–4 Herausforderung: Service-Level-Management

Bevor ein Outsourcing-Vertrag abgeschlossen wird, sollte ein Service-Level-Agreement zwischen Servicenehmer und Dienstleister angefertigt werden, in dem Vereinbarungen bzgl. des Erbringens von Leistungen beider Seiten festgehalten werden. Gleichzeitig werden alle erbrachten Dienste im Reporting festgehalten. Falls es Abweichungen zu den in Service-Level-Agreements vereinbarten Größen gibt, werden diese ebenfalls dort festgehalten. Außerdem muss ein laufendes Management des technischen Systems stattfinden, um die vereinbarten Service-Levels einzuhalten. Einerseits vergleicht das Service-Level-Management die technischen Größen, die beim Betrieb eines technischen Systems auftreten, mit denen in Service-Level-Agreements festgelegten Kennzahlen der Service-Levels, meldet Abweichungen und kontrolliert damit den Betrieb des technischen Systems. Andererseits ist dieser Vergleich nicht immer direkt möglich. Insbesondere geschäftsprozessbezogene SLAs erfordern mitunter eine Transformation technischer Größen in die im SLA definierten Kennzahlen zur Messung der Einhaltung von Service-Levels.

1.3.1 Unterscheidung zwischen Service-Level-Agreements und Operational-Level-Agreements

Bevor nun SLAs, OLAs und UCs konkret ausformuliert werden, lohnt sich ein Blick durch die Brille der Juristen, die diese SLAs sehen und auch deren Tragweite und Unterschiede definieren. SLAs können für unterschiedliche IT-Services und an unterschiedlichen Schnittstellen der Wertschöpfungskette definiert werden. Eine grundlegende Systematisierung von SLAs lässt sich anhand der Art der Beziehungen zwischen den beteiligten Akteuren vornehmen [Scholderer 2002a]. Der Servicenehmer und der Dienstleister können entweder der gleichen juristischen Person angehören (interne Einheiten eines Unternehmens) oder jeweils rechtlich voneinander unabhängige Unternehmen darstellen (eigene juristische Personen). Dementsprechend wird an dieser Stelle im Prinzip eine Unterscheidung zwischen SLAs (zwischenbetrieblichen Vereinbarungen) und OLAs (inner-betrieblichen Vereinbarungen) vorgenommen. Bestehen wirtschaftliche Beziehungen zwischen Dienstleister und Servicenehmer, so lassen sich SLAs unterscheiden, die zwischen wirtschaftlich voneinander unabhängigen Unternehmen oder zwischen wirtschaftlich miteinander verbundenen Einheiten (innerhalb von Unternehmen oder Konzernen) abgeschlossen werden. Auch an dieser Stelle ließe sich eine Unterscheidung nach OLAs und SLAs aufstellen. Abbildung 1–5 stellt das grafisch dar.

Aus Gründen der Komplexitätsreduktion wird im Folgenden lediglich zwischen OLAs und SLAs differenziert. Bei SLAs gelten Vereinbarungen zwischen rechtlich und wirtschaftlich unabhängigen Unternehmen. ITIL definiert diese SLAs als Underpinning Contracts [ITILv3 2011]. Bei OLAs gelten Vereinbarungen innerhalb der Unternehmen [ITILv3 2011]. Konzerninterne Vereinbarungen können sowohl als OLAs als auch als SLAs eingestuft werden, da sie Merkmale interner (aufgrund der bestehenden wirtschaftlichen Abhängigkeit) als auch SLAs (beide Partner stellen eine juristische Person dar) aufweisen [Berger 2005]. Im Folgenden werden die Anwendungsbereiche von SLAs anhand konkreter Beispiele dargestellt. Bei OLAs lässt sich unter organisatorischen Aspekten als Anwendungsbereich die Regelung von Leistungsbeziehungen innerhalb eines Unternehmens nennen. In einer Spartenorganisation beispielsweise können die OLAs zur Abstimmung des Leistungsaustauschs zwischen einzelnen Sparten, die als Cost-, Profit- oder Investmentcenter organisiert sein können, und Zentralabteilungen (hier ein interner IT-Dienstleister) verwendet werden. In diesem Zusammenhang stellen diese Vertragsvereinbarungen ein Instrument zur Überwindung der gegebenen Koordinationsprobleme dar [Berger 2005]. Zusammenfassend dargestellt verfolgen OLAs u.a. Zielsetzungen wie beispielsweise die Sicherstellung der vereinbarten Service-Levels zwischen IT und den Geschäftsbereichen, den Aufbau von Servicenehmer-Lieferanten-Verhältnissen innerhalb der IT, den Aufbau von SLM-Prozessen und die Einführung einer Servicekultur [Bernhard 2004]. SLAs werden primär bei der Fremdvergabe (auch Fremdnutzung) von IT-Services an externe Unternehmen oder beim IT-Outsourcing verwendet [Berger 2005]. Entscheidend dabei ist, dass SLAs als Grundlage für den Aufbau und die Gestaltung einer IT-Outsourcing-Beziehung dienen. Werden SLAs für das Management und die Steuerung eines IT-Outsourcing-Partners angewendet, stellen die SLAs vom IT-Outsourcing-Partner die vertragliche Festlegung der zu erbringenden IT-Services für seinen Servicenehmer dar. Beispiele hierfür sind Netzwerkbetrieb, Serverbetrieb, Datensicherung, Problembehebung (Service-Desk) etc. SLAs verfolgen Zielsetzungen wie z.B. die Sicherstellung einer juristisch unangreifbaren Formulierung der Vertragsvereinbarungen und die Gewährleistung einer kontinuierlichen Optimierung der SLAs zwischen den IT-Outsourcing-Partnern [Bernhard 2004].

Abb. 1–5 Zusammenhang SLA, OLA, UC

1.3.2 Service-Level-Agreements sind mehr als nur eine Vereinbarung

Ein SLA ist also eine vertraglich bindende Vereinbarung, die dazu genutzt werden kann, Erwartungen zu identifizieren, Verantwortlichkeiten zu klären und die Zusammenarbeit zwischen einem Dienstleister und seinem Servicenehmer oder auch die Leistungsbeziehungen im Unternehmen zwischen internen Abteilungen zu steuern. Das SLA soll auch dazu genutzt werden, die Kommunikation zwischen Servicenehmer und Dienstleister zu verbessern. Durch den Verhandlungsprozess im Rahmen der Erstellung/Entwicklung eines SLA wird die Kommunikation zwischen beiden Parteien intensiviert. Ein SLA soll beiden Parteien einen Eindruck über die Bedürfnisse, Prioritäten und Anliegen des Vertragspartners bieten, es wird damit zum Kommunikationswerkzeug. In der Verhandlung eines SLA gewinnen beide Parteien sehr früh größere Klarheit über die eigentlichen Ziele. Servicenehmer und IT-Dienstleister einigen sich auf bestimmte erfüllbare Anforderungen und Erwartungen. Somit dient das SLA auch als Instrument zum Management von Erwartungen. Wissen beide Parteien nur wenig über die Anforderungen des jeweiligen Vertragspartners, so sind Konflikte vorprogrammiert. Durch die Kommunikation während des Entstehungsprozesses des SLA wird die andere Partei von einem Fremden zu einem kompetenten Verhandlungspartner. Das Konfliktpotenzial wird durch den direkten Kontakt von Servicenehmer und IT-Dienstleister in der Regel deutlich geringer [Böning 1999]. Wenn nun auch noch genau definiert wird, nach welchen Prozessen im Konfliktfall vorzugehen ist, wird die Gefahr von unlösbaren Konflikten minimiert. Ohne klar definierte Anforderungen und Zusicherungen hingegen werden beide Parteien die Effektivität des erbrachten Service und dessen Service-Levels unterschiedlich bewerten. Durch die klare Spezifikation der Services und Service-Levels im SLA wird daher eine exakt definierte Liste erstellt, welche Anforderungen in welchem Umfang zu erfüllen sind. Dadurch wird eine objektive Bewertung, ob ein SLA eingehalten ist, möglich. Ohne ein SLA sind die Bemühungen, Service-Levels zu steuern und zu kontrollieren, wenig mehr als eine Sammlung guter Absichten. SLAs setzen einen Standard gegen den gemessen und verglichen wird. Der Verzicht auf ein SLA kann auch mit der Verwendung eines Thermometers ohne Maßskala verglichen werden. Man kennt in diesem Fall den Messbereich des Thermometers nicht, seine Verwendung hat damit einen denkbar geringen Wert.

1.3.3 Service-Level-Management ist die Qualitätskontrolle

Ein SLA ist nichts Statisches, das einmal definiert und dann niemals geändert wird. Es unterliegt aufgrund der wechselnden Anforderungen von Servicenehmer und IT-Dienstleister ständigen Änderungen. Daher ist ein kontinuierlicher Änderungsprozess bei einem SLA sehr wichtig. Es muss ein fortlaufender Prozess definiert werden, wie Veränderungen in die SLAs einfließen können und wer sie initiieren kann oder darf.

Für den IT-Dienstleister ist das Service-Level-Management (SLM) damit essenziell, was sich mit einer Analogie aus der Produktherstellung verdeutlichen lässt. Die Produkte des IT-Dienstleisters sind die IT-Services, die er seinen Servicenehmern liefert. Das SLM ist die Qualitätskontrolle der hergestellten Produkte. Die Zufriedenheit des Servicenehmers ist der wichtigste Grund für die Implementierung des SLM. In der Praxis wird ein SLM spätestens dann eingeführt, wenn es mit entscheidenden Servicenehmern Probleme und Streitigkeiten gibt, die den Umsatz signifikant beeinflussen. Das SLM zwingt die Servicenehmer dazu, ihre Anforderungen und Erwartungen klar zu spezifizieren. Wenn Dienstleister und Servicenehmer sich auf einen für beide Seiten akzeptablen IT-Service einigen, erzeugen sie einen Benchmark, gegen den die IT-Performance des IT-Dienstleisters gemessen werden kann. Das ist für beide Seiten wichtig, denn Trends zeigen, dass Benutzererwartungen immer weiter steigen [Bernhard 2003]. Durch eine Dokumentation der Erwartungen wird eine schleichende Steigerung der Erwartungen gebremst und dem IT-Dienstleister eine Referenz an die Hand gegeben, auf die er immer verweisen kann, wenn es zu Unzufriedenheit beim Servicenehmer kommt. Durch Service-Level Agreements (SLAs) ist es für politisch starke Minderheiten in einem Unternehmen zudem deutlich schwerer, unverhältnismäßig viele Ressourcen an sich zu binden und damit die Interessen der Mehrheit zu übertreffen. Daher können Service-Levels und vor allem das Maß ihrer Erfüllung oder Verletzung als Indikatoren für System- und Kapazitätsanforderungen des Servicenehmers betrachtet werden. Vor der Einführung des SLM bestand zwischen IT-Abteilungen und Servicenehmern höchstens bei auftretenden Problemen Kontakt, was die Servicenehmer dazu bewog, die IT-Abteilung als notwendiges Übel und Verursacher von Systemausfällen zu sehen. Stattfindende Servicegespräche als Wertstellungsnachweis hingegen machen es den Servicenehmern bewusst, wenn sehr gute Arbeit geleistet wird, und dienen – richtig geführt – im Fall sehr guter Leistungen auch als Motivator für den IT-Dienstleister. Auf diese Weise ist das SLM ein hervorragendes Marketingwerkzeug in beide Richtungen. Durch den Einsatz des SLM hat der Dienstleister andererseits ein Werkzeug, um sich effektiv vor Benutzerbeschwerden zu schützen. Aber auch in Bezug auf die Kostenkontrolle hilft das SLM. Es unterstützt den IT-Dienstleister, den vereinbarten Service-Level bereitzustellen, ohne ungenaue Schätzungen anstellen zu müssen. Diese Schätzungen führen nämlich leicht zu übermäßigem Einsatz von Ressourcen (Personal, Rechenkapazität, Bandbreite etc.).

1.3.4 COBIT, ISO 20000 und ITIL

Ziel der Standards ist die Professionalisierung der Schnittstelle zwischen Servicenehmer und Dienstleister. Die Beschreibung und der Nachweis von Leistungen sind heute essenzielle Probleme, die in der IT gelöst werden müssen. Die Standards COBIT, ISO 20000 und ITIL verweisen darauf, dass dies durch SLAs und Messwerte erfolgt. Im Folgenden wird die Ausrichtung der Standards skizziert:

COBIT:

Control Objectives for Information and Related Technology ist das international anerkannte Framework zur IT-Governance und gliedert die Aufgaben der IT in Prozesse und Kontrollziele (www.isaca.com).

ISO 20000:

Die ISO/IEC 20000 ist ein international anerkannter Standard zum IT-Service-Management, in dem die Anforderungen für ein professionelles IT-Service-Management dokumentiert sind (www.iso20000.ch).

ITIL:

Die IT Infrastructure Library ist eine Sammlung von Best Practices, die eine mögliche Umsetzung eines IT-Service-Managements beschreiben und inzwischen international als De-facto-Standard hierfür gelten (www.itil-officialsite.com).

Alle drei Standards basieren darauf, die aus- und nachgewiesene Leistung zwischen Servicenehmer und IT-Dienstleister exakt beschreiben und messen zu können: Der Servicenehmer bezieht von einem oder mehreren Rechenzentren IT-Services. Beteiligt sind dabei Applikationen, die Geschäftsprozesse des Servicenehmers unterstützen und diese somit effizienter gestalten. Die Bedeutung einer Applikation (und damit eines IT-Service) in einem Geschäftsprozess macht sich an ihrer Integrationstiefe fest. Je weiter die Applikation in den Geschäftsprozess integriert ist und diesen umfassend unterstützt, desto stärker wirken sich Ausfälle und Störungen auf den Geschäftsbetrieb aus. Applikationen sind also entsprechend bedeutend und müssen ausfallsicher sein. Die fachlich notwendigen Applikationen werden jeweils zum benötigten IT-Service zusammengefasst und in SLAs festgeschrieben. Mittels geeigneter Nachweise wird der IT-Service offengelegt, um die bezogenen Kontingente transparent nachvollziehen zu können.

Die Einhaltung von SLAs nachzuweisen ist ein zentrales Ziel, das IT-Dienstleister und Servicenehmer verfolgen. Der Servicenehmer betrachtet dies aus der Perspektive desjenigen, der die Leistung, die er erhalten hat, auch bezahlt oder ggf. Abschläge vornimmt. Der IT-Dienstleister, der seine Leistung transparent machen muss, um keine finanziellen Nachteile durch z.B. Abschläge zu erhalten, verfolgt das Ziel aus dieser Sicht. Der Nachweis ist jedoch für IT-Services sehr komplex. Einerseits sollen die technischen IT-Services transparent werden, was in heterogenen und stark verteilten IT-Umgebungen eine Konsolidierung von IT-Systemen erfordert. Andererseits müssen ständig Faktoren des IT-Betriebs, wie Störungsmeldungen durch Servicenehmer, berücksichtigt und beherrscht werden. Störungen können im schlimmsten Fall zur Betriebsunterbrechung führen. Die Berechnung einer solchen Ausfallzeit muss für den Nachweis eindeutig sein. Die Standards COBIT, ISO 20000 und ITIL verweisen alle ausdrücklich darauf, dass Unschärfen entstehen, wenn dies nicht klar geregelt ist, die auf beiden Seiten zur Einschätzung führen können, dass die Einhaltung von SLAs nicht eindeutig bestimmt werden kann – oder eine Einschätzung der Einhaltung tatsächlich nicht vorgenommen werden kann. Um diesem Entscheidungsproblem zu entgehen, müssen Festlegungen in SLAs einfließen, wie Prozesse und technische Messungen in ein einheitliches Modell gebracht werden.

Der Schwierigkeit, genau diese Sachverhalte umfassend und adäquat abbilden und abwickeln zu können, wenden sich die Standards COBIT, ISO 20000 und ITIL zu.

1.4 Zusammenfassung

Dieses Buch soll dazu beitragen, einen Grundstein zur Entwicklung von umsetzbaren SLAs und einem praxisnahen SLM-Modell zu legen. Nachdem das Einsatzfeld des SLM abgesteckt ist und die zentralen Begriffe eingeführt wurden, kann sich der Service-Level-Manager auf die Herausforderungen, die das Service-Level-Management und die Service-Level-Agreements bereithalten, konzentrieren. In den folgenden Kapiteln werden die zentralen Begriffe pragmatisch mit Bezug zu den Standards COBIT, ISO 20000 und ITIL V3 angewendet. Es werden Zusammenhänge erläutert, die aufzeigen, warum SLM und SLAs sich gegenseitig bedingen und man den Prozess SLM nicht losgelöst von SLAs betrachten kann (s. Abschnitte 3.4.1 und 6.2.3). Auch wird deutlich gemacht, wie der Servicekatalog und das SLA zusammenwirken. Vermieden werden sollen Fehler bei der Konzeption des Servicekatalogs, dessen definierte IT-Services anschließend nicht mehr in das SLA übernehmbar sind (s. Abschnitte 3.2.3 und 3.4.2). Ebenfalls hilfreich in der Praxis ist die Beschreibung von Prozessen entlang mehrerer Abstraktionsebenen. Dies hilft dem Service-Level-Manager, dass sein SLM-Prozess auch tatsächlich gelebt werden kann (s. Abschnitt 2.4).

Für alle ad hoc eingesetzten Service-Level-Manager, die sich nicht auf eine lang vorbereitete Infrastruktur für ihren SLM-Prozess stützen können, werden Arbeitskonzepte entworfen, damit sie sofort arbeitsfähig sind und sich den Servicenehmern gegenüber sicher bewegen können (s. Abschnitt 5.1). Da sich der Service-Level-Manager nach Abschluss aller Vereinbarungen auf die Überwachung konzentriert, ist es für ihn von essenzieller Bedeutung, dass Kennzahlen definiert sind und Messsysteme zum Einsatz kommen. Damit Kennzahlen keine Lücken enthalten, wird bei den Definitionen auf Besonderheiten in der Praxis hingewiesen (s. Abschnitte 3.3.4 und 6.1.3). Im Rahmen der Auswahl eines geeigneten Messsystems steht der Service-Level-Manager vor der Entscheidung, welches Messverfahren er einsetzen soll, damit er die Kennzahlen korrekt ermitteln kann. Dabei benötigt er sowohl die Grundlagen für das Monitoring als auch eine Beschreibung, welches Messverfahren er wofür einsetzen kann. Dies soll ihm helfen, den Aufwand für die Implementierung eines Messverfahrens abschätzen zu können (s. Kap. 4). Speziell aus Dienstleistersicht wird ihm verdeutlicht, dass alle Anstrengungen für gute SLAs im Rahmen eines effizienten und effektiven SLM-Prozesses über ein ungenaues und unzeitgemäßes Reporting aufgehoben werden. Denn ein Servicenehmer, der das Reporting nicht akzeptiert und ihm auch nicht vertraut, macht alle Vorarbeiten des Service-Level-Managers zunichte (s. Abschnitt 4.4).

2 IT-Standards für den Prozess Service-Level-Management

Auf Basis der Informationstechnologie werden für unternehmensinterne wie auch-externe Servicenehmer die unterschiedlichsten IT-Services angeboten. Die IT-Landschaft ist durch den technologischen Fortschritt in Verbindung mit neuen Serviceangeboten einem kontinuierlichen Wandel unterzogen. Nicht nur um die Veränderungen in der IT-Umgebung unter Kontrolle zu halten, ist ein IT-Service-Management heute unabdingbar. Es gewährleistet vor allem auch die Qualität der angebotenen IT-Services. Die Verbesserung der IT-Servicequalität bei gleichzeitiger Standardisierung der IT-Services und Senkung der Bereitstellungskosten generiert Wettbewerbsvorteile.