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 |
Methodische Grundlagen und Praxislösungen mit COBIT, ISO 20000 und ITIL
2., aktualisierte und erweiterte Auflage
Priv.-Doz. Dr. -Ing. habil. Robert Scholderer
Principal Service-Level-Manager
robert@scholderer.de
www.scholderer.de
Lektorat: Christa Preisendanz
Copy-Editing: Ursula Zimpfer, Herrenberg
Herstellung: Nadine Thiele
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn
Fachliche Betreuung:
Prof. Dr. Matthias Knoll · Hochschule Darmstadt · matthias.knoll@h-da.de
Bibliografische Information der Deutschen Nationalbibliothek
Die 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-7
PDF 978-3-96088-024-0
ePub 978-3-96088-025-7
mobi 978-3-96088-026-4
2., aktualisierte und erweiterte Auflage 2016
Copyright © 2016 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 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
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 Scholderer
Stuttgart, im Juli 2016
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 Scholderer
Stuttgart, im April 2011
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.
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
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]
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.
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.
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.
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.
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].
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).
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: