Ralf Buchsein Frank Victor Holger Günther Volker Machmeier
IT-Management mit ITIL® V3
Edition CIO Herausgegeben von Andreas Schmitz und Horst Ellermann
Der Schlüssel zum wirtschaftlichen Erfolg von Unternehmen liegt heute mehr denn je im sinnvollen Einsatz von Informationstechnologie. Nicht ob, sondern WIE die Informationstechnik der Motor für wirtschaftlichen Erfolg sein wird, ist das Thema der Buchreihe. Dabei geht es nicht nur um Strategien für den IT-Bereich, sondern auch deren Umsetzung – um Architekturen, Projekte, Controlling, Prozesse, Aufwand und Ertrag. Die Reihe wendet sich an alle Entscheider in Sachen Informationsverarbeitung, IT-Manager, Chief Information Officer – kurz: an alle IT-Verantwortlichen bis hinauf in die Chefetagen. Konsequente Ausrichtung an der Zielgruppe, hohe Qualität und dadurch ein großer Nutzen kennzeichnen die Buchreihe. Sie wird herausgegeben von der Redaktion der IT-Wirtschaftszeitschrift CIO, die in Deutschland seit Oktober 2001 am Markt ist und in den USA bereits seit 19 Jahren erscheint. Chefsache Open Source Von Theo Saleck Chefsache IT-Kosten Von Theo Saleck IT-Controlling realisieren Von Andreas Gadatsch Outsourcing realisieren Von Marcus Hodel, Alexander Berger und Peter Risi Von der Unternehmensarchitektur zur IT-Governance Von Klaus D. Niemann Optimiertes IT-Management mit ITIL Von Frank Victor und Holger Günther Management von IT-Architekturen Von Gernot Dern Führen von IT-Service-Unternehmen Von Kay P. Hradilak IT-Management mit ITIL® V3 Von Ralf Buchsein, Frank Victor, Holger Günther und Volker Machmeier
www.vieweg.de
Ralf Buchsein Frank Victor Holger Günther Volker Machmeier
IT-Management mit ITIL® V3 Strategien, Kennzahlen, Umsetzung Mit 77 Abbildungen
Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über
abrufbar.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne von Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen. Höchste inhaltliche und technische Qualität unserer Produkte ist unser Ziel. Bei der Produktion und Auslieferung unserer Bücher wollen wir die Umwelt schonen: Dieses Buch ist auf säurefreiem und chlorfrei gebleichtem Papier gedruckt. Die Einschweißfolie besteht aus Polyäthylen und damit aus organischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffe freisetzen.
1. Auflage 2007 Alle Rechte vorbehalten © Friedr. Vieweg & Sohn Verlag | GWV Fachverlage GmbH, Wiesbaden 2007 Lektorat: Günter Schulz / Andrea Broßler Der Vieweg Verlag ist ein Unternehmen von Springer Science+Business Media. www.vieweg.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Umschlaggestaltung: Ulrike Weigel, www.CorporateDesignGroup.de Druck und buchbinderische Verarbeitung: MercedesDruck, Berlin Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier. Printed in Germany ISBN 978-3-8348-0270-5
Vorwort ITIL als Basis für eine neue Sicht auf die IT hat sich in den letzten Jahren rasant in deutschen Unternehmen verbreitet und das mit anhaltendem Erfolg. Der Grund liegt daran, dass ITIL in der Version 2 gut verständlich ist und so die Grundideen des IT Service Managements leicht transportierbar sind. Seit Juni 2007 ist nun ITIL in der Version 3 am Markt verfügbar. Es scheint so, als sehe nun vieles anders aus als in Version 2, da das Gesamtwerk völlig neu strukturiert worden ist und neue Inhalte hinzugekommen sind. Wir haben für Sie die ersten Erfahrungen gemacht und sind überzeugt, dass die ITIL Version 3 keineswegs komplizierter ist als ITIL Version 2, dafür aber in wesentlichen Aspekten genauer und im Gesamtbild viel integrativer. Unser Buch gibt Antworten auf zwei Fragen, die in der Praxis für den Erfolg einer modernen IT entscheidend sind: – Welche Kennzahlen und Kennzahlensysteme sollte man in der IT einsetzen? – Welche Strategien sind zur Umsetzung und Steuerung von IT Service Management Prozessen geeignet? Sie werden sich vielleicht fragen, wieso wir gerade diese beiden Themen in einem Buch behandeln. Die Antwort ist: Das sind die Themen, die aktuell in der Praxis relevant sind und Hunderte von Unternehmen – nicht nur in Deutschland – beschäftigen. Das Erstaunliche ist, dass die beiden Themen eng zusammenhängen und sich gegenseitig beeinflussen. Das Erfreuliche ist, dass mit ITIL V3, COBIT 4 und ISO 20000 ein Best Practice Werkzeugkasten zur Verfügung steht, mit dem man einen Großteil der Herausforderungen an die IT in den Griff bekommt. Kurzum – wir sahen den Bedarf, ein Praxisbuch für IT-Manager, CIOs, CTOs, Prozess und Service Manager sowie für IT-Berater herauszubringen, das die Lücke zwischen ITIL und Kennzahlen sowie zwischen Theorie und Praxis schließt. Dabei setzen wir Grundkenntnisse des IT Service Managements und Fachbegriffe voraus. Die Beispiele, die wir aufgenommen haben, basieren auf unseren Erfahrungen als auch auf Referenz- und Kundenprojekten, die wir begleitet haben.
V
Vorwort Ein Buch, wie dieses, entsteht nur, wenn ausgezeichnete Leute dazu beitragen. Besonders bedanken möchten wir uns bei – – – – – – – – – – – – – –
Frau Dr. Manuela Claßen, Victor GmbH, Bonn Herrn Jürgen Esterle, München Herrn Flavio Gaj, Mailand Herrn Gerhard Göttert, Autobahn Tank & Rast GmbH, Bonn Herrn Dr. Jan Hadenfeld, Altana Pharma AG Herrn Karl-Heinz Herfs, KESS DV-Beratung GmbH Frau Jacqueline Jordan, London Herrn Sascha Kurth, KESS DV-Beratung GmbH Herrn Hans Joachim Lohr, Rohrbach Herrn Peter Pieronczyk, KESS DV-Beratung GmbH Frau Gabriele Ruf, München Herrn Mirko Seithe, Bonn Herrn Gottfried Weibler, VOSS Automotive GmbH, Wipperfürth Herrn Michael Zaddach, Flughafen München GmbH
Für Ann-Kathrin
Ralf Buchsein Hagen, im Juni 2007
Für Manuela, Christina und Luisa
Frank Victor Bonn, im Juni 2007
Für meine Eltern, Inge und Heinz
Holger Günther Aachen, im Juni 2007
Für Anna Elisabeth und Gustav
Volker Machmeier Mailand, im Juni 2007
Haben Sie Fragen zum IT Service Management oder zu Kennzahlen? Wir helfen Ihnen gerne persönlich weiter: http://www.KESS-DV.de
[email protected]
http://www.VictorGmbH.de
[email protected]
Copyrights ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. COBIT© Copyright 1996-2007 by the IT Governance Institute (ITGI)
VI
Inhaltsverzeichnis 1 Einführung und Überblick ..............................................................................1 2 IT Service Management ...................................................................................5 2.1 Management Summary ............................................................................5 2.2 ITIL und ISO 20000....................................................................................5 2.3 Die Struktur gemäß ITIL Version 2.........................................................7 2.3.1
Das Service Management auf Basis der ITIL Version 2...........7
2.3.2
Der prozessorientierte Ansatz von ITIL Version 2...................8
2.4 Die Struktur gemäß ITIL Version 3.......................................................11 2.4.1
ITIL und der Service Lifecycle ..................................................14
2.4.2
Service Strategy...........................................................................15
2.4.3
Service Design.............................................................................18
2.4.4
Service Transition .......................................................................19
2.4.5
Service Operation .......................................................................21
2.4.6
Continual Service Improvement...............................................22
2.4.7
Der prozessorientierte Ansatz von ITIL Version 3.................23
2.5 ITIL Kennzahlen für IT Service Management-Prozesse.....................27 2.5.1
Ausgewählte Kennzahlen der ITIL Version 2.........................27
2.5.2
Ausgewählte Kennzahlen der ITIL Version 3.........................32
2.6 ISO 20000 ..................................................................................................50 2.6.1
Die Geschichte der ISO 20000 ...................................................51
2.6.2
Der Aufbau der ISO 20000.........................................................51
2.6.3
Die Inhalte der ISO 20000 ..........................................................53
2.6.4
Die ISO 20000 und Kennzahlen ................................................54
2.7 COBIT........................................................................................................56 2.7.1
Entwicklung von COBIT ...........................................................57
2.7.2
Struktur von COBIT ...................................................................57
2.7.3
Prozess-Management gemäß COBIT .......................................59
2.7.4
COBIT und die IT Service Management-Prozesse .................64
2.7.5
Metriken für IT Service Management-Prozesse .....................66
2.7.6
COBIT Metriken für IT Service Management-Prozesse ........66
VII
Inhaltsverzeichnis 2.8 Monitoring und Reporting von SLAs ...................................................72 2.8.1
Definition und Interpretation des Begriffs „IT Service“........73
2.8.2
Service Level Agreements .........................................................77
2.8.3
Das Zusammenwirken von SLAs, OLAs und UCs................78
2.8.4
Der Aufbau von SLAs ................................................................79
2.8.5
Die Inhalte von SLAs..................................................................81
2.8.6
Monitoring und Reporting von SLAs, OLAs und UCs .........85
2.8.7
Abgrenzung der Kennzahlen....................................................88
2.9 Integrationsinstrument: Balanced Scorecard .......................................88 2.9.1
Kernideen.....................................................................................89
2.9.2
Anwendung auf den IT-Bereich ...............................................94
2.9.3
Ausprägungen der Balanced Scorecard ..................................95
2.10 Konsequenzen........................................................................................97 3 IT Prozess-Management ..............................................................................101 3.1 Management Summary ........................................................................101 3.2 PDCA-Zyklus.........................................................................................101 3.3 Etablierung des Prozess-Managements..............................................104 3.3.1
Der Charakter von IT-Prozessen ............................................105
3.3.2
Rollen im Prozess-Management .............................................109
3.4 Definition der Prozessziele und -Kennzahlen ...................................115 3.4.1
Definition der Prozessziele......................................................115
3.4.2
Definition der Prozess-Kennzahlen .......................................124
3.4.3
Dokumentation der Prozess-Kennzahlen..............................130
3.4.4
Reporting der Prozess-Kennzahlen........................................131
3.5 Von der Kennzahl zur Verbesserungsmaßnahme ............................137 3.6 Kennzahlen müssen reifen ...................................................................140 3.7 Der Umgang mit Kennzahlen ..............................................................141 4 IT Kennzahlensysteme.................................................................................143 4.1 Management Summary ........................................................................143 4.2 Ziele .........................................................................................................144 4.3 Überblick.................................................................................................147 4.3.1 SVD 1980 ...........................................................................................148
VIII
Inhaltsverzeichnis 4.3.2 Diebold 1984.....................................................................................149 4.3.3 Kargl 1996 .........................................................................................150 4.3.4 Van der Zee 1996 .............................................................................151 4.4 Bewertung ..............................................................................................152 4.5 Konsequenzen........................................................................................153 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen .......155 5.1 Management Summary ........................................................................155 5.2 Klassifikationsschema für IT-Kennzahlen .........................................155 5.2.1
Key Success Factors..................................................................157
5.2.2
Key Performance und Customer Satisfaction.......................160
5.2.3
IT-Controls und Controls on Demand...................................164
5.3 Prozess-Kennzahlen ..............................................................................166 5.3.1
Service Strategy.........................................................................169
5.3.2
Service Design...........................................................................173
5.3.3
Service Transition .....................................................................189
5.3.4
Service Operation .....................................................................202
5.3.5
Continual Service Improvement.............................................217
6 Lessons learned: Empfehlungen und Ratschläge ....................................221 6.1 Management Summary ........................................................................221 6.2 ITIL-Einführung ....................................................................................222 6.2.1
Analyse der bestehenden Prozesse ........................................222
6.2.2
Prozess-Einführungen..............................................................226
6.2.3
Die Organisation gewinnen ....................................................229
6.2.4
Rollenbeschreibungen..............................................................230
6.3 Kontinuierlicher Verbesserungsprozess.............................................233 6.3.1
KVP der bestehenden Prozesse ..............................................234
6.3.2
KVP der neuen Prozesse..........................................................236
6.3.3
Wettbewerb der Prozesseinführung ......................................241
6.3.4
Reifegradanalyse der Prozesse im laufenden Betrieb..........242
6.4 Kennzahlen.............................................................................................243 6.4.1
IT-Prozesse am Tagesgeschäft ausrichten .............................244
6.4.2
ITIL abgestimmt auf die Business- und IT-Strategie ...........247
IX
Inhaltsverzeichnis 6.4.3
ITIL Refresh oder wie geht es weiter?....................................250
7 Praxisbeispiel: ALTANA Pharma AG .......................................................257 8 Praxisbeispiel: Autobahn Tank & Rast GmbH .........................................265 9 Praxisbeispiel: Flughafen München...........................................................269 10 Praxisbeispiel: VOSS Gruppe....................................................................285 11 Anhang.........................................................................................................289 11.1 Quellenverzeichnis ..............................................................................289 11.2 Abkürzungsverzeichnis.......................................................................297 11.3 Abbildungsverzeichnis .......................................................................299 11.4 Sachwortverzeichnis ...........................................................................302
X
1 Einführung und Überblick 1955 hatte Frank Sinatra einen Welterfolg mit seinem Song „Love and Marriage“: Love and marriage, love and marriage, Go together like a horse and carriage, This I tell you brother, You can’t have one without the other.
ITIL und Kennzahlen: You can’t have one without the other.
Ein halbes Jahrhundert später mag sich einiges im gesellschaftlichen Leben geändert haben. Für ein modernes und erfolgreiches IT-Management gehören jedoch (mindestens) zwei Dinge zusammen: ITIL und Kennzahlen: „You can’t have one without the other“. Kennzahlen dienen im Allgemeinen zur Steuerung von Bereichen und Prozessen. Für die IT sind von jeher IT-Controls als auch Prozess-Kennzahlen vorgeschlagen und eingesetzt worden. ITIL als Best Practice Ansatz unterstützt explizit die Steuerung der IT-Prozesse auf der Basis von Kennzahlen. In ITIL V3 werden für jeden Prozess die „Key Performance Indicators“ bzw. „Metrics“ genannt. Verwendet man die Kennzahlen des IT Service Managements, so ergänzt man einerseits die Steuerung der IT um wichtige Stellgrößen, andererseits hat man auch eine viel größere Anzahl von Kennzahlen zu erheben, um diese in Reports darzustellen. Sie werden sich fragen: „Und, ist das schlimm?“ In unseren Projekten haben wir die interessante Beobachtung gemacht, dass fast alle IT-Organisationen über eine beachtliche Anzahl von Kennzahlen verfügen. In einem kleinen mittelständischen Unternehmen haben wir die Kennzahlen bei der Ist-Aufnahme einfach einmal gezählt: In der IT-Organisation mit 12 Personen wurden in der Tat monatlich ca. 500 (!) Kennzahlen gemessen und an den CIO weitergegeben. Dieses Phänomen haben wir in fast allen Unternehmen gesehen und schließen daraus: Es gibt kaum eine Organisationseinheit, die über so viele Kennzahlen verfügt wie die IT. Dies liegt vor allen Dingen daran, dass die IT es gewohnt ist, mit Kennzahlen zu arbeiten – hier vor allen Dingen mit technischen Kennzahlen aus dem System- und Netzmanagement. Vielleicht denken Sie, man könne auf die Mehrzahl der Kennzahlen verzichten? Da müssen wir Sie enttäuschen: 95 % der Kennzahlen sind notwendig und sinnvoll. Sie müssen erhoben werden! Aber wie kann man sie in dieser Komplexität managen und beherrschbar machen?
1
ITIL V3 enthält ProzessKennzahlen.
1 Einführung und Überblick Das A und O ist – und dies gilt für alle komplexen Systeme –, dass man sich Gedanken über das Design des Systems macht. Möchte man ein ITKennzahlensystem entwickeln und einführen, so sollte man im Vorfeld die richtigen Fragen stellen: – – – – – top down Verfahren zur Entwicklung von ITKennzahlensystemen.
Welche Ziele verfolgen wir mit dem Kennzahlensystem? Welche Kennzahlensysteme sind für meine IT relevant? Wen adressiert das Kennzahlensystem? Welche Kennzahlen können (nicht) gemessen werden? Welchen Aufwand darf das Kennzahlensystem verursachen?
Die Beantwortung dieser oder ähnlicher Fragen führt zu einem top down Ansatz für IT-Kennzahlensysteme, den wir oft in Praxisprojekten eingesetzt haben. Aber dies ist nur die eine Seite der Medaille: Für die reale Einführung eines IT-Kennzahlensystems ist es enorm wichtig, die ITOrganisation dort abzuholen, wo sie steht. Hier bietet sich ein bottom upVerfahren an, durch das ermittelt wird, welche Kennzahlen bereits in verschiedenen Bereichen erhoben und genutzt werden. In unserem Buch beschreiben wir diesen Ansatz in einem Praxisleitfaden, der beide Aspekte enthält.
bottum up Verfahren zur Erhebung von Kennzahlen.
Die Frage, ob man mit der Entwicklung eines IT-Kennzahlensystems auf der „grünen Wiese“ beginnt, stellt sich in der Praxis nicht! Es gibt keine „kennzahlenlose“ IT.
ITKennzahlensysteme sind Guidelines.
Die Quintessenz: IT Kennzahlensysteme sagen, was man messen könnte, aber nicht, was man messen sollte! Sie sind damit Guidelines – nicht mehr und nicht weniger!
Wir haben ca. 15 IT-Kennzahlensysteme identifiziert, die veröffentlicht worden sind und in der Praxis eingesetzt werden. Herauszustellen ist, dass COBIT 4 die größte Überdeckung mit IT Service Management-Ansätzen, wie ITIL, liefert. Aus der Tradition der IT-Revision heraus und zum Nachweis von Compliance-Anforderungen seitens der Wirtschaftsprüfer wird COBIT in sehr vielen Unternehmen eingesetzt. In unseren Projekten haben wir uns allerdings nie nur auf COBIT und ITIL beschränkt, sondern immer verschiedene Kennzahlensysteme „nebeneinander gelegt“. Auffallend dabei ist, dass der Überdeckungsgrad der Kennzahlensysteme eher gering ist: Jedes Kennzahlensystem liefert neue Aspekte!
Im Wesentlichen hängt diese Tatsache davon ab, dass ein Kennzahlensystem sich in der Praxis aus dem Zielsystem der IT ableiten muss und daher strategische und taktische Dimensionen hat.
2
1 Einführung und Überblick Eine IT-Organisation ist gut beraten, ihr eigenes IT-Kennzahlensystem aufzubauen und es nicht nur zur reinen Steuerung der IT einzusetzen, sondern über das Kennzahlensystem Teile der IT-Strategie umzusetzen.1 In diesem Zusammenhang verstehen wir Kennzahlensysteme – etwas überspitzt formuliert – als mögliche Instrumente des Ist-Marketings. Dies ist insbesondere dann der Fall, wenn als Adressat das Top Management angesprochen werden soll und es darum geht, über die „Lage der IT im Unternehmen bzw. im Konzern und die Unterstützung der Business Prozesse und Anforderungen“ zu berichten. Im Buch stellen wir die wichtigsten Kennzahlensysteme kurz vor und zeigen auf, wie man zu einem eigenen Kennzahlensystem kommt. Hierbei spielt die Balanced Scorecard eine tragende Rolle.
Wir glauben, dass das IT Service Management einen der wichtigsten Meilensteine für die IT darstellt. Wir glauben auch, dass IT Service Management ohne IT-Kennzahlen, und IT-Kennzahlen ohne IT Service Management keinen Sinn machen. Unser Buch ist gedacht als Brücke zwischen diesen beiden Ansätzen. Ein wesentlicher Teil unserer Ausführungen beschäftigt sich daher mit Steuerungsmechanismen, die von ITIL, COBIT und ISO 20000 bereitgestellt werden, so wie mit den Kernideen des ITIL-basierten ProzessManagements. Die in ITIL V3 verfügbaren IT-Kennzahlen werden in entsprechende Zusammenhänge eingeordnet und nach ihrem Einsatz in der Praxis klassifiziert.
Unser Buch füllt damit in den ersten 5 Kapiteln eine „Toolbox“, die ITVerantwortliche zum Aufbau eines Kennzahlensystems einsetzen können. Insbesondere mit der ITIL Version 3 werden die Best Practices für das IT Service Management in Richtung Business Integration beschrieben. Damit steht das Management häufig vor der Herausforderung, in einer bestehenden Organisation die Prozesse zu verankern und die Mitarbeiter von den notwendigen Veränderungen zu überzeugen. Wir haben die Erfahrung gemacht, dass keine noch so gut ausgestattete Toolbox ein Garant für den Erfolg eines Projekts ist. Unabdingbar ist die Tatsache, dass man die Menschen mitnimmt. In den Projekten, die wir begleitet haben, waren Ängste, Hoffnungen, persönliche Schicksale, Präferenzen, Einstellungen, Interessen, Flexibilität und
1
Kaplan und Norton haben dies als „Translating Strategy into Action“ bezeichnet (vgl. [Kaplan et al., 1996]).
3
Michael Hammer: „The Balanced Scorecard – A Landmark Achievement“
1 Einführung und Überblick Fähigkeiten einzelner Personen wesentliche Determinanten für Erfolg oder Misserfolg. Die Qualität und Ausprägung der Veränderungs- und Überleitungsprozesse und das damit verbundene Vorgehen sind wichtige kritische Erfolgsfaktoren für IT Service Management und Kennzahlen-Projekte. Change und Veränderungs-Prozesse sind wesentliche Bestandteile des Vorgehensmodells.
Unser Buch beschäftigt sich mit diesem sensiblen und interessanten Thema im 6. Kapitel, das wir mit „Lessons learned“ überschrieben haben. Basierend auf unseren Projekterfahrungen stellen wir ein Vorgehensmodell vor, mit dem die notwendigen Veränderungs- und Überleitungsprozesse – auch im Hinblick auf einen kontinuierlichen Verbesserungsprozess – besser und erfolgreicher gesteuert werden können.
Überblick über das Buch – ein Leseleitfaden Unser Buch ist umfangreicher geworden als wir anfangs gedacht haben. Im Laufe der Zeit ist es von der geplanten kurzen Darstellung unserer Erfahrungen in den Bereichen IT Service Management und Kennzahlen zu einem kleinen Nachschlagewerk geworden. Wir haben uns daher bemüht, die Kapitel weitgehend unabhängig voneinander zu formulieren. Springen Sie einfach in ein Kapitel, das Sie interessiert: – Kapitel 2: IT Service Management und verwandte Themen aus Sicht der Praxis mit ISO 20000, ITIL V3, COBIT 4, SLAs und Balanced Scorecard. – Kapitel 3: IT Prozess-Management mit Rollen, Zielen, Kennzahlen und kontinuierlichem Verbesserungsprozess. – Kapitel 4: Die wichtigsten IT-Kennzahlensysteme in der Praxis und die Konsequenzen hinsichtlich der Fragestellung: Welche ITKennzahlen setzen wir ein? – Kapitel 5: Praxisleitfaden zur Entwicklung von IT-Kennzahlensystemen mit Klassifikationsschemata und Prozess-Kennzahlen aus ITIL V3 und unseren Projekterfahrungen. – Kapitel 6: Wie geht man am besten in IT Service Management Projekten vor? Empfehlungen aus unseren Projekten für Transition und Change Prozesse. Praxisbeispiele: – Kapitel 7: IT Service Management im regulierten Umfeld am Beispiel der ALTANA Pharma AG – Kapitel 8: Autobahn Tank & Rast GmbH mit einem Kennzahlensystem, das gemeinsam mit dem Controlling entwickelt wurde. – Kapitel 9: IT Service Management beim Flughafen München – Kapitel 10: IT Management Report in der VOSS Gruppe.
4
2 IT Service Management 2.1 Management Summary Die Kernideen des IT Service Managements sind nicht neu und in der Praxis seit mehreren Jahrzehnten bekannt. Sie lassen sich in Form von drei Faktoren beschreiben: – IT liefert Services – IT ist Produktionsfaktor – IT braucht klare Kommunikationswege ITIL, COBIT, ISO 20000 und die Balanced Scorecard gelten gemäß ihrer konzeptionellen Ansätze heute als Best Practice. Dabei weisen COBIT und ITIL eine große Überstimmung hinsichtlich der IT Service ManagementProzesse auf, während die Balanced Scorecard als Integrationsinstrument prädestiniert ist. In diesem Kapitel gehen wir auf diese Best Practices ein und stellen heraus, wie die einzelnen Ansätze im Hinblick auf die Entwicklung von Kennzahlensystemen zu positionieren sind. Bezüglich der Kennzahlen nehmen wir die Beschränkung vor, dass wir nur die behandeln, die aus unserer Sicht eine hohe Praxisrelevanz haben. Die Fragestellung, welcher Ansatz der geeignete zum Aufbau eines Kennzahlensystems ist, führt im Allgemeinen nicht zum Ziel. Es geht vielmehr darum, herauszufinden, wie die Komponenten der verschiedenen Ansätze in einem Puzzle zusammengefügt werden können, um das bestmögliche Kennzahlensystem für die jeweilige IT-Organisation aufzubauen. Wichtige Voraussetzung ist dabei immer, dass es definierte Ziele für die jeweiligen IT Service Management-Prozesse gibt und dass das Prozessund IT-Management das Kennzahlensystem als Führungsinstrument versteht und aktiv einsetzt.
2.2 ITIL und ISO 20000 ITIL und ISO 20000 „IT Service Management“ sind zwei international bewährte Practices zur erfolgreichen Etablierung eines IT Service Managements. Die Zielsetzung eines IT Service Managements besteht in der Bereitstellung von IT-Leistungen (IT Services) zur Unterstützung der Geschäftsprozesse. Hierzu sind die notwendigen Leistungen zu planen, bereitzustellen, zu überprüfen und bei Bedarf zu optimieren.
5
2 IT Service Management Um die Ziele des IT Service Managements zu erreichen, haben sich in den letzten Jahren IT-Prozesse etabliert, die ein wirksames Management sicherstellen und grundsätzlich in allen IT-Organisationen etabliert werden können. Diese IT Service Management-Prozesse sind in den ITIL Best Practices sowie der ISO 20000 dokumentiert. Der Ansatz von ITIL Version 2 bestand in der Bereitstellung von Best Practices zur Gestaltung, Implementierung, Betrieb und Optimierung der notwendigen IT Service Management-Prozesse. Mit der Veröffentlichung der ITIL Version 3 wurden die Ausrichtung und der Inhalt umfangreich erweitert. ITIL deckt nun den „Service Lifecycle“ ausgehend von der Strategie bis zu einer ständigen Verbesserung des Service Managements ab. Hierzu werden nicht nur Prozesse beschrieben, sondern vollständige Modelle für den Service und das Service Management. ITIL beinhaltet ein generisches Prozessmodell und bewährte Vorgehensweisen zur Einführung und zum Management des Service Management und dessen Integration in das Business. Die ISO 20000 enthält dagegen die Anforderungen an ein IT Service Management. Daher ergänzen sich ITIL und die ISO 20000 ideal. Während die ISO 20000 die Mindestanforderungen an ein IT Service Management definiert, liefert ITIL hierzu Best Practices für den Aufbau des organisationsspezifischen IT Service Managements. Die Prozessorientierung von ITIL und der ISO 20000 stellt eine weitgehende Unabhängigkeit von Organisationsstrukturen sicher. Das IT Service Management auf der Basis von ITIL und der ISO 20000 ist ein prozessorientierter Ansatz.
Innerhalb der ITIL Best Practices und der ISO 20000 werden die relevanten IT-Prozesse zur Bereitstellung professioneller IT Services beschrieben. Kennzahlen dienen dem Prozess-Management und ermöglichen unter anderem die Überprüfung der Prozesse hinsichtlich ihrer Wirksamkeit. Das Verständnis der Prozessziele ist die wichtigste Grundvoraussetzung für die richtige Interpretation von Kennzahlen. Ohne ausreichende Kenntnisse der Prozessziele und der damit verbundenen Prozessaktivitäten besteht die Gefahr einer Fehlinterpretation von Kennzahlen. Als Beispiel hierfür soll der Prozess des Incident Managements dienen. Das Ziel des Incident Managements besteht in der schnellstmöglichen Wiederherstellung des vereinbarten Service für den Geschäftsablauf. Hierzu wird in der Regel als Kennzahl „Anzahl der Störungen“ oder „Dauer bis zur Wiederherstellung des Service“ gemessen. Steigt die „Anzahl von Störungen“ oder die „Dauer bis zur Wiederherstellung des Service“ an, so wäre es eine Fehlinterpretation, das Incident Management hierfür verantwortlich zu machen. Die Kennzahl „Anzahl von Störungen“ wird zwar in
6
2.3 Die Struktur gemäß ITIL Version 2 diesem Prozess gemessen, aber die Identifizierung von Störungsursachen und deren nachhaltige Behebung liegen nicht in der Verantwortung des Incident Management-Prozesses. Daher hat das Incident Management den Anstieg der Störungen nicht zu verantworten. Die Definition und Interpretation von Kennzahlen für IT Service ManagementProzesse setzt voraus, dass die Prozessziele dokumentiert und insbesondere dem Management bekannt sind.
ITIL Version 2 und ITIL Version 3 Innerhalb der ITIL Best Practices sind bewährte Umsetzungsmaßnahmen für die Einführung, Etablierung und Optimierung der IT Service Management-Prozesse dokumentiert. ITIL ist ein De-facto-Standard für das IT Service Management, da die meisten IT-Organisationen nach ITIL ausgerichtet sind. Heute muss man 2 Versionen von ITIL unterscheiden: – ITIL Version 2 (wurde am 1. Juni 2007 durch die Version 3 abgelöst) – ITIL Version 3 Im Folgenden stellen wir die Struktur dieser beiden Versionen vor. Gehen aber schwerpunktmäßig auf Version 3 ein, da ITIL Version 2 den meisten Lesern bekannt sein dürfte und Anfang Juni 2007 durch die Version 3 abgelöst wurde.
2.3 Die Struktur gemäß ITIL Version 2 2.3.1
Das Service Management auf Basis der ITIL Version 2
Die wichtigsten Aspekte der ITIL Best Practices in der Version 2 sind in sieben Publikationen dokumentiert. Dabei beinhalten die Publikationen „Service Support“, „Service Delivery“ und „Security-Management“ die relevanten IT Service Management-Prozesse. Die Rahmenstruktur in Abbildung 1 aus [OGC, 2005a] beschreibt die ITIL Best Practices auf Basis des Standardwerks „Best Practice Einführung in ITIL“. An dieser Stelle möchten wir auf ein sehr gutes Buch verweisen. In „Optimiertes IT Management mit ITIL“ [Victor et al., 2005] werden die wesentlichen Aspekte von ITIL 2 und ein Einführungsleitfaden beschrieben.
7
2 IT Service Management
Planning to Implement Service Management T h e B u s i n e s s
T h e
Service Management Service Support The Business Perspective
Service Delivery
ICT Infrastructure Management
Security Management
Application Management
Abbildung 1:
T e c h n o l o g i e
ITIL Rahmenstruktur
Abbildung 2 stellt einen Überblick über die 10 ITIL Prozesse der Version 2 dar.
2.3.2
Der prozessorientierte Ansatz von ITIL Version 2
Bei den ITIL Best Practices handelt es sich um einen prozessorientierten Ansatz. Für das IT Service Management sind in den ITIL-Publikationen der ITIL V2 „Service Support“, „Service Delivery“ und „Security-Management“ hierzu insgesamt elf erforderliche IT-Prozesse dokumentiert. Gemäß ITIL ist ein Prozess „eine zusammenhängende Folge von Aktivitäten mit dem Ziel, einen gegebenen Input in einen definierten Output zu transformieren.“
Der Output eines Prozesses muss aus der geschäftlichen Zielsetzung abgeleitet werden und kann Input für einen anderen Prozess darstellen. So nimmt zum Beispiel der Prozess des Capacity Managements in enger Zusammenarbeit mit dem Service Level Management (SLM) die Kundenanforderungen an einen IT Service auf. Insofern ist das SLM der „Anfang“ des ITIL Prozessmodells und steht in enger Verbindung mit dem Kunden. Die Anforderungen bezüglich der Verfügbarkeit sind der Input für das Availability Management zur Planung und Überprüfung der IT-Verfügbarkeit. Jeder IT Service Management-Prozess hat eine charakteristische Ziel-
8
2.3 Die Struktur gemäß ITIL Version 2 richtung und trägt im Zusammenwirken mit den anderen IT Service Management-Prozessen dazu bei, dass dem Kunden die notwendigen IT Services zur wirkungsvollen Unterstützung seiner Geschäftsprozesse geliefert werden. Die ITIL Best Practices beinhalten Prozessbeschreibungen mit wechselseitigen Aktivitäten.
Service Level Management Continuity Management
Service Delivery
Financial Management
Capacity Management
Availability Management
Incident Management Configuration Management
Release Management Abbildung 2:
Service Support
Problem Management
Change Management
Die 10 ITIL-Prozesse und der Service Desk
Gemäß der ITIL Best Practices ist die Aufgabe der Prozesssteuerung bzw. des Prozess-Managements „der Prozess der Planung und Regelung; mit dem Ziel, einen Prozess in einer effektiven und effizienten Weise durchzuführen“.
Hierzu sind in einem generischen Prozessmodell die wichtigsten Aufgaben beschrieben (siehe Abbildung 3, aus „Best Practice Einführung in ITIL“, [OGC, 2005a]).
9
2 IT Service Management Ziele des Prozesses
ProzessOwner Qualitätsparameter und KPIs Prozessmanagement
Aktivitäten und Subprozesse
Input
Output
Prozessausführung
Ressourcen
Rollen
Prozessbedingungen Abbildung 3: Der Prozess Owner gibt die Prozessziele vor und kann anhand der KPIs die Erreichung der Ziele feststellen.
Generisches ITIL-Prozessmodell
Auf Basis der vom Prozess Owner vorgegebenen Prozessziele gilt es, die notwendigen Aktivitäten und Subprozesse der jeweiligen IT Service Management-Prozesse zu designen und zu implementieren. Angesichts der Komplexität der Prozessdurchführung in IT-Organisationen muss eine formelle Überprüfung der Zielerreichung sichergestellt werden. Dazu dienen die definierten Qualitätsparameter und Leistungsindikatoren (Key Performance Indicators, KPIs). Zielsetzung von ITIL war die Beschreibung von (weitgehend) organisationsneutralen Best Practices. Daher werden zur Durchführung von Prozessaktivitäten Rollen definiert, die mit den erforderlichen Ressourcen zu unterstützen sind. Die Leistungsindikatoren (KPIs) dienen auch zum Management der eingesetzten Ressourcen. Ohne Qualitätsparameter und Leistungsindikatoren (KPIs) ist ein wirksames Prozess-Management unmöglich.
Um ein wirksames Prozess-Management zu erreichen, muss kontinuierlich überprüft werden, ob die definierten Prozessziele wirkungsvoll erreicht werden (Effektivität) und mit welchem Aufwand dieses Ergebnis erzielt wird (Effizienz).
10
2.4 Die Struktur gemäß ITIL Version 3 ITIL und insbesondere die ISO 20000 fordern, für jeden IT Service Management-Prozess ein wirksames Prozess-Management zu etablieren. Bei der Definition von ITIL Kennzahlen gilt es, IT Service Management-Prozesse zu messen und so die Voraussetzung für deren Management zu schaffen.
Die ITIL Best Practices sind als Guidelines für die Implementierung und Etablierung des IT Service Managements in einer IT-Organisation gedacht. Die ITIL Best Practices beschreiben was zu tun ist. Die Festlegung, wie die Maßnahmen konkret umzusetzen sind, ist Aufgabe des Prozessdesigns. Die Umsetzung erfolgt immer organisationsspezifisch, in Abhängigkeit von den Geschäftsanforderungen der Kunden und unter Berücksichtigung sozialer Belange. Demzufolge liefert ITIL generische Empfehlungen für das IT Service Management, aber die Prozesse mit ihren konkreten Zielen und Aktivitäten sind immer auf die spezifischen Belange der IT-Organisation auszurichten. Diese Philosophie hat auch Auswirkungen auf die ITIL Best Practices für Kennzahlen. Die ITIL Best Practices für Kennzahlen sind Guidelines. Die Definition von „ITIL Kennzahlen” muss immer auf die organisationsspezifischen Prozesse mit ihren Zielen und Aktivitäten ausgerichtet sein. Die ungeprüfte Übernahme von empfohlenen Kennzahlen ist nicht zielführend.
Die Version 2 der ITIL Best Practices wurde über einen Zeitraum von sechs Jahren herausgegeben – angefangen von Service Support im Juni 2000 bis zu „The Business Perspective Part 2“ im November 2006. Daher sind in den einzelnen ITIL-Publikationen geringfügige Abweichungen in den ausgewiesenen Leistungsindikatoren (KPIs) festzustellen.
2.4 Die Struktur gemäß ITIL Version 3 Mit der Publikation von ITIL Version 3 richten sich die ITIL Best Practices noch stärker auf die Business-Anforderungen aus. Speziell mit der zentralen Publikation „Service Strategy“ wird ein wichtiger Betrag zum IT Governance geliefert. Die Zielsetzung von ITIL mit der Version 3 besteht in der Business Integration.
Mit der neuen Version von ITIL ist nicht mehr die Abkürzung für “IT Infrastructure Library” verbunden, sondern ITIL ist nun ein Synonym für Service Management.
11
ITIL Kennzahlen sind lediglich Empfehlungen.
2 IT Service Management Hierzu definiert die ITIL Version 3 den Begriff ITIL wie folgt: A set of Best Practice guidance for IT Service Management. ITIL is owned by the OGC and consists of a series of publications giving guidance on the provision of Quality IT Services, and on the Processes and facilities needed to support them.
Mit der Herausgabe der ITIL Version 3 hat sich auch der Fokus des Service Managements erweitert. Während in der früheren Version von ITIL das Service Management noch als „das zur Erfüllung der Kundenanforderungen erforderliche Management“ definiert wurde, lautet die Definition jetzt wie folgt (vgl. „Service Strategy“, [OGC, 2007a]): “Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services.”
Sinngemäß würde dies bedeuten: „Service Management ist die Gesamtheit spezialisierter organisatorischer Fähigkeiten, um den Kunden in Form von Services einen Wert zu liefern.” Den Service definiert ITIL (Version 3) als: Service: “A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.”
Sinngemäß bedeutet damit der Begriff Service: „Ein Service ist eine Dienstleistung, die einen Nutzen für den Kunden bringt und die Ergebnisse liefert, die er erwartet. Dabei kann er sich entspannen, denn die durch den Service verursachten Kosten und Risiken liegen im Allgemeinen nicht bei ihm sondern beim Service Provider." Innerhalb der Publikation „Service Strategie“ wird der Bezug eines Service zu den Geschäftsprozessen des Business deutlich herausgestellt. Letztendlich stellen die Services die Geschäftsprozesse des Business sicher bzw. stellen zum Teil den Service aus Sicht des Kunden dar (Abbildung 4, aus „Service Strategy“, [OGC, 2007a]). Damit verbunden ist auch die Erweiterung der Definition für den IT Service (aus „Service Strategy“, [OGC, 2007a]): IT Service: “A Service provided to one or more Customers by an IT Service Provider. An IT Service is based on the use of Information Technology and supports the Customer's Business Processes. An IT Service is made up from a combination of people, processes and technology and should be defined in a Service Level Agreement."
12
2.4 Die Struktur gemäß ITIL Version 3
Business Service
Business Service
Business Prozesse
Zerlegung
Abstraktion und Zusammensetzung
Services
Services
Ressourcen und Fähigkeiten Internet
Personal Abbildung 4:
Die Ausrichtung der Services auf das Business
Sinngemäß lässt sich der IT Service wie folgt definieren. – „IT Services werden von einem IT Service Provider für einen oder mehreren Kunden bereitgestellt. – IT Services nutzen die Informationstechnologie und unterstützen die Business Prozesse der Kunden. – IT Services definieren sich aus Personen, Prozessen und Technologien. – IT Services sind in Service Level Agreements zu definieren.“
13
2 IT Service Management IT Services bestehen in der Regel aus verschiedenen Systemen und Teilleistungen mit unterschiedlichen Verantwortungen und Zuständigkeiten. Da dies in der Vergangenheit zu Kompetenzproblemen geführt hat, wird in ITIL Version 3 auch die Rolle des Service Owners spezifiziert (vgl. [OGC, 2007e]): Der Service Owner ist verantwortlich für einen spezifischen Service, unabhängig davon, wo innerhalb der Organisation die zugrundeliegenden technologischen Komponenten, Prozesse oder professionellen Fähigkeiten angesiedelt sind.
In der ITIL Version 3 sind nicht nur Prozesse für das Service Management beschrieben, sondern der gesamte Service Lifecycle. Angefangen von der Strategie (Service Strategy), über das Design (Service Design), der Überführung in den Betrieb (Service Transition) und der operationelle Betrieb (Service Operation). Diese Phasen und damit verbundenen Aktivitäten unterliegen einem kontinuierlichen Verbesserungsprozess (Continual Service Improvement). Hierzu werden nicht nur Service Management-Prozesse beschrieben, sondern zum Beispiel auch die strategische Ausrichtung der IT, Methoden oder notwendige Aufgaben wie das Risiko Management. ITIL mit der Version 3 ist mehr als eine Sammlung von Prozessen. ITIL Version 3 ist ein ganzheitlicher integrierter Ansatz von Best Practices für das Service Management.
2.4.1
ITIL und der Service Lifecycle
Die ITIL Library besteht aus den folgenden Komponenten: – Der ITIL Core als Leitfaden für alle Organisationen, die Dienstleistungen anbieten. – Die ITIL Complementary Guidance als ergänzender Leitfaden für industrielle Bereiche, Organisationstypen, Betriebsmodelle und technologische Architekturen. – Die ITIL Web Support Services mit Zusatzprodukten, Prozessmodellen, Templates und Studien. Der ITIL Core besteht aus fünf Publikationen: – – – – –
Service Strategy (vgl. [OGC, 2007a]) Service Design (vgl. [OGC, 2007b]) Service Transition (vgl. [OGC, 2007c]) Service Operation (vgl. [OGC, 2007d]) Continual Service Improvement (vgl. [OGC, 2007e])
Ergänzt werden diese Publikationen um eine allgemeine Einführung „The Official Introduction to Service Lifecycle“ ([OGC, 2007e]).
14
2.4 Die Struktur gemäß ITIL Version 3 Die fünf Core Publikationen bilden die Phasen eines iterativen und mehrdimensionalen Lifecycles für die Services. Lernen und Reifen der Organisationen sollen ermöglicht werden. Ziele sind: Struktur, Stabilität und Stärke auf der Basis dauerhafter Prinzipien, Methoden und Werkzeuge. Dies soll dem Schutz von Investitionen dienen. Was hier angestrebt wird ist ein Kreislauf aus Messen, Lernen und Verbesserung. Abbildung 5 verdeutlicht das Zusammenspiel dieser 5 Phasen.
Continual Service Improvement Service Transition
Service Strategy Service Design
Abbildung 5:
2.4.2
Service Operation
Die 5 Phasen des Service Lifecycles nach ITIL V3.
Service Strategy
Im Zentrum des dargestellten Service Lifecycles steht die Phase Service Strategy (vgl. [OGC, 2007a]). Hier werden die strategischen Entscheidungen getroffen. Es gut um das Design, die Entwicklung und Implementierung des Service Managements nicht nur im organisatorischen sondern vielmehr im strategischen Sinne. Service Management Richtlinien (Policies), Anleitungen und Prozesse über den gesamten ITIL Service Lebenszyklus hinweg werden hier entwickelt und unterstützt. Service Strategy bildet im Kern des Kreislaufs das zentrale
15
2 IT Service Management strategische Fundament für die Phasen Service Design, Service Transition, Service Operation und den alles umfassenden permanenten Verbesserungskreislaufs des Continual Service Improvement. Ausgangspunkt der Phase Service Strategy sind die Identifizierung, Auswahl und Priorisierung von Geschäftschancen und Marktplätzen. Betrachtungen und Analysen der Marktentwicklung und die Definition von Zielen und Erwartungen führen zur Formulierung von Serviceleistungen gegenüber Kunden und Marktplätzen. Mit Unterstützung des Finanzmanagements wird ein Service Portfolio definiert und die Entwicklung eines Service Katalogs vorbereitet. Auch Themen wie Organisationsentwicklung sowie Kosten- und Risikobetrachtungen im Hinblick auf das Service Portfolio werden angegangen. Neben dem Faktor operationelle Effizienz geht es entscheidend um ganzheitliche, nachhaltige und effektvolle Entscheidungen und Leistungen und deren Entwicklung. Strategische Reviews helfen, Fähigkeiten zu verbessern tragen zum weiteren Ausbau von Geschäftsstrategien und -chancen bei. Das Fazit in einem kurzen Satz wäre wohl folgendermaßen zu formulieren: Erst das WAS, dann das WIE! Im gesamten Service Lifecycle wird eines sehr deutlich: die Ausrichtung der Services an den Anforderungen und am wirklichen Bedarf des Kunden und seines Geschäftes. Dieses Ziel wird stringent verfolgt. Services der Lieferanten werden auf die Business Services fokussiert, damit deren Leistungen zur direkten Unterstützung der Geschäftsziele dienen. Business Service Management liefert hierfür ein Modell mit den entsprechenden Metriken (vgl. Abbildung 6). Business Service Management is the ongoing practice of governing, monitoring and reporting on the IT and the business services it impacts.
16
2.4 Die Struktur gemäß ITIL Version 3
Business Service
IT Service
C D
Business Prozesse Informationen
Management
Personen
Workflow
Applikationen
Infrastruktur
Knowledge
ermöglicht
lose Koppelung
Service Plattform Availability Continuity
Informationen
Workflow
Capacity Security
Gewährleistung
Applikationen
Infrastruktur
Knowledge
Nutzen
A Schließt ein
B
Management
Personen
Nutzen
A
IT Applikationen
B
Service Plattform Availability Continuity
Capacity Security
Gewährleistung
A – Bündelung Business Prozess und IT Applikation zu einem Service. B – Bereitstellung einer Service- Schnittstelle und sicherstellen, dass der Service für die Nutzung verfügbar ist, mit einer adäquaten Kapazität, Kontinuität und Sicherheit. C – Verbessern der Business Prozesse um den Nutzen für die Business Service zu verbessern. D – Verbessern der IT Applikationen um die Gewährleistung der IT Services zu steigern. Abbildung 6:
Verbindung zwischen IT Service und Business Service
Wurde das Service Management bisher als taktische oder operative Aufgabe angesehen, so stellt das Service Management jetzt einen geschlossenen Regelkreis dar, wobei die Phase Service Strategie die Basis bildet (siehe Abbildung 7, aus „Service Strategy“, [OGC, 2007a]).
17
2 IT Service Management
Strategie Implementierung Service Design Anforderungen Service Strategy •Service Portfolio •Service Katalog
Service Transition Anforderungen
Service Design
Service Transition
Service Operation Service Operation Anforderungen
Abbildung 7:
2.4.3
Messung und Bewertung
Continual Service Improvement
Messung und Bewertung
Service Strategy Prozesse
Service Design
Die Phase Service Design (vgl. [OGC, 2007b]) dient dem Design und der Entwicklung von Services und Service Management-Prozessen. Ausgehend von den strategischen Zielen, die in der Phase Service Strategy definiert wurden, findet hier die Transformation zu einem Portfolio von Services statt. Wichtigstes Ergebnis dieser Stufe ist das Design einer effektiven und effizienten Service-Lösung. Die sich ständig verändernden Anforderungen des Business und der IT erfordern eine ständige Interaktion mit allen anderen Bereichen und Prozessen. Abbildung 8 verdeutlicht dies. Beim Design werden diese Bereiche und Prozesse in den Service Design Aktivitäten berücksichtigt, um alle ServiceLösungen mit existierenden Lösungen konsistent und kompatibel zu gestalten. Dies beinhaltet auch Änderungen und Verbesserungen, die notwendig werden, um sowohl den Wert der Services für den Kunden über den Lebenszyklus der Services hinweg zu erhalten, als auch die Kontinuität der Services, das Erreichen der Service Qualität (Level) und die Konformität zu Standards und Regeln.
18
2.4 Die Struktur gemäß ITIL Version 3 Siehe hierzu Abbildung 8, die Service Design Prozesse aus „Service Design“, [OGC, 2007b].
Betrieb Neue Anforderungen
Neue Anforderungen
Service Strategy
Strategie und Bedingungen
Analyse Anforderungen, dokumentieren & vereinbaren
Service Design Package
Bereitstellung vorgezogene Lösung
Beurteilung alternativer Lösungen
Design Service Lösung
Service Transition
Entwicklung der Lösung
Service Operation
Service Design
Architekturen Messmethoden
Service Portfolio
Service Katalog
Key Service Design Prozesse SLM: Policy, Pläne, SIP, SLRs, SLAs, OLAs, Reports
Service Katalog M.
Capacity: Policy, Pläne, CIMS,Reports, Sizing, Forecast
Service Level Management
Availability: Policy, Pläne, Designkriterien, AMIS, ..
Capacity Management
IT SCM: Policy, Pläne, BCPs, IT SCPs, Risiko-Analyse, ..
Availability Management
Security: Policy, Pläne, Controls, Reports, Klassifizierung, .
ITSC Management
Security Management
Supplier: Policy, Pläne, contracts, SCD, Reports.
Supplier Management
Input aus anderen Bereichen wie Incidents, Probleme, Request Fulfillment, Access, Change, Configuration, Knowledge, Release Planning, Risk Evaluation, Testing, …
Abbildung 8:
2.4.4
Service Design Prozesse
Service Transition
Die Phase Service Transition (vgl. [OGC, 2007c]) umfasst das Management und die Koordination von Prozessen, Systemen und Funktionen, um ein Release zu paketieren, zu bauen, zu testen, auszuliefern und in die Produktion zu übernehmen und die durch Kunden und Stakeholder spezifizierten Anforderungen umzusetzen.
19
2 IT Service Management Hierzu werden die Anforderungen aus den Phasen Service Stategy und Service Design für einen effektiven Service Betrieb realisiert. Hier findet das Management komplexer Änderungen bei den Services und Service Management-Prozessen und die Verhinderung unerwünschter Konsequenzen statt: Risiken sollen kontrollierbar bleiben; gleichzeitig der Versuch, Raum zu lassen für Innovation. Ein wesentlicher Aspekt ist auch die kontrollierte Übergabe von Verantwortung für Services vom Service-Lieferanten zum Kunden. Die Aufgaben der Phase Service Transition sind Abbildung 9 zu entnehmen („Service Transition“, [OGC, 2007c]). Continual Service Improvment
Change Management RFC1
RFC2
RFC3
RFC4
RFC5
RFC6
Service Asset and Configuration Management BL
BL
BL
BL
BL
BL
BL
Service Transition Planning and Support Oversee Management of Organisation and Stakeholder Change Evaluation of a Change or Service E1 Service Strategy
Service Design
Plan and prepare Release
Build and Test
E3
E2 Service Plan and Testing and Prepare for Pilots Deployment
Release and Deployment Management
Transfer, Deploy, Retire
Review and Close Service Transition
Service Operation
Early Life Support
Service Validation and Testing Knowledge Management
other ITIL Core Book
ITIL process in this Book that supports the whole service Life Cycle Abbildung 9:
20
Focus of Activity Related to Service Transition
Service Transition Prozesse
Ex = Point to Evaluate RFCx = Request f. Change BL = Capture Baseline
2.4Die Struktur gemäß ITIL Version 3
2.4.5
Service Operation
In dieser Phase geht es um das Management des Service Betriebs (Service Operation). Sie enthält Anleitungen für effektive und effiziente Lieferung und Support der Services, um den gewünschten W ert für die u Knden und den Service-Lieferanten sicherzustellen. Die strategischen Ziele werden in dieser letzten Stufe letztendlich durch Service Operation realisiert, was seine kritische Bedeutung erkennen lässt. Angestrebt wird ein stabiler Service Betrieb, um Änderungen an Design, Skalierung, Inhalt und Service Level zu erlauben. Inhalte sind u. a.: – – – – – –
Management der Service-Verfügbarkeit Anforderungsmanagement und -K ontrolle Optimierung der K apazitätsnutzung Einplanung und Scheduling von Betriebsoperationen Problemlösung Unterstützung des Betriebs durch neue Modelle und Architekturen (z. B. Shared Services, Utility o Cmputing, eW b Services und Mobile o Cmputing) – fortlaufendes Management der zugrunde liegenden Technologien – tägliche Überwachung der Leistungsparameter und -werte (Monitoring). Auch in dieser Phase des Service Lifecycle steht nach wie vor im Vordergrund, die Services am Bedarf des Business auszurichten. Hierzu müssen Aktivitäten und Prozesse so koordiniert und ausgeführt werden, dass die vereinbarten Service Level eingehalten werden. Das Zusammenwirken der Service Operation Prozesse ist in der Abbildung 10 aus [K ESS, 2007c] dargestellt.
21
2 IT Service Management Problem Management
Event Management
Filter
Change Management
Request Fulfilment
Self Help
Incident Management
Access Management
Prozess aus „Service Transition“
Abbildung 10:
2.4.6
Deployment
Service Operation Prozesse
Continual Service Improvement
ITIL fordert IT Service Provider nicht nur dazu auf, konsistente und wiederholbare Prozessaktivitäten anzustreben, um Service Qualität zu demonstrieren, sondern geht darüber hinaus und fordert als Teil der angestrebten Service Qualität einen Prozess permanenten Strebens nach Verbesserungen. Primärer Zweck des Continual Service Improvement (CSI) (vgl. [OGC, 2007e]) ist die kontinuierliche Anpassung der IT Services an die sich ständig verändernden Anforderungen aus den Geschäftsprozessen. Ziel ist es, sowohl Prozess-Effektivität und -Effizienz als auch Kosten-Effektivität zu verbessern. Insofern geht es um die Aufrechterhaltung und Verbesserung des „Business Value“ für den Kunden im Hinblick auf Design, Einführung und Betrieb der Services. Für eine optimale Unterstützung der Geschäftsprozesse müssen die IT Service Management-Prozesse nach klar definierten Zielen und mit relevanten Messsystemen implementiert, verwaltet und unterstützt werden.
22
2.4 Die Struktur gemäß ITIL Version 3 Hierfür ist es außerordentlich kritisch und wichtig, zu verstehen, was gemessen und warum es gemessen werden muss, und Erfolgsfaktoren sorgfältig zu definieren. Siehe hierzu die übergreifende Aufgabenstellung des Continual Service Improvement auf Basis der Darstellung in „Continual Service Improvement“, [OGC, 2007e] (siehe Abbildung 11).
Business / Kunden
Anforderungen
Service Strategy
Service Portfolio
Service Design
Service Transition Service Katalog
Service Operation Continual Service Improvement
Abbildung 11:
2.4.7
Operationelle Services
Improvement Pläne u. Aktionen
Continual Service Improvement
Der prozessorientierte Ansatz von ITIL Version 3
Mit der aktuellen ITIL Version 3 hat sich nicht nur der Scope des Service Managements erweitert, sondern auch die Anzahl der beschriebenen Service Management-Prozesse. Diese Erweiterung der bestehenden Prozesse betrifft insbesondere die Phase „Service Transition“. Bei den ITIL-Publikationen der Version ITIL Version 3 sind dies in den Publikationen „Service Design“, „Service Transition“, „Service Operation“ und „Continual Service Improvement“ insgesamt 26 IT Service Management-Prozesse vgl. [OGC, 2007b-e]). Hinzu kommen aus der Phase „Service Strategy“ noch die Aufgaben des Financial Managements“, des
23
2 IT Service Management „Service Portfolio Managements“ und des „Demand Managements“ , die ebenfalls als Prozesse anzusehen sind. Diese umfangreiche Erweiterung mag den Leser vielleicht zunächst erschrecken, dabei darf aber nicht außer Acht gelassen werden, dass ein Teil dieser Prozesse in ITIL Version 2 bereits in anderen weniger beachteten Publikationen, wie zum Beispiel „Applikation Management“ oder „ICT Infrastructure Management“ beschrieben waren. Andererseits sind nun Prozesse dokumentiert, die in vielen Organisation bereits so implementiert sind, wie zum Beispiel das „Event Management“ zur Entdeckung und Interpretation von Ereignissen, die über entsprechend Tools generiert und behandelt werden. Mit der ITIL Version 3 werden das notwendige Prozess-Management und die damit verbundenen Aspekte stärker hervorgehoben. Als Prozess wird definiert (vgl. Service Design, [OGC, 2007b]): Ein Prozess ist eine strukturierte Folge von Aktivitäten, die geplant werden, um ein bestimmtes Ziel zu erreichen. Ein Prozess benötigt einen oder mehrere definierte Inputs und transformiert diese Inputs zu definierten Outputs. Ein Prozess beinhaltet die notwendigen Rollen, die Verantwortlichkeiten, die Tools und die Management Controls, um den Output zu liefern. Ein Prozess definiert dazu die notwendigen Grundsätze (Policies), Standards, Richtlinien, Aktivitäten und Arbeitsanweisungen.
Prozesse weisen gemäß ITIL Version 3 die folgenden Merkmale auf: – Messbar: Die Prozesse sind in einer relevanten Art zu messen. Prozesse sind leistungsgetrieben. Manager wollen Kosten, Qualität und andere Variable messen, während sich die Ausführenden mit Dauer und Produktivität beschäftigen. – Spezifizierte Ergebnisse: Prozesse existieren, um ein bestimmtes Ergebnis zu liefern: Dieses Ergebnis muss individuell identifizierbar und zählbar sein. – Kunden: Jeder Prozess liefert einem Kunden oder einer Interessengruppe seine Ergebnisse. Der Prozess muss den Erwartungen der internen oder externen Kunden entsprechen. – Reagieren auf bestimmte Ereignisse: Da ein Prozess fortlaufend oder sich wechselseitig beeinflussend sein kann, sollte er zu einem spezifischen Trigger verfolgbar sein. Mit der ITIL Version 3 wurde das bestehende Prozessmodell umfassender beschrieben und dargestellt (im Hauptteil des Buches und nicht im Anhang) vgl. „Service Design“, [OGC, 2007b] (siehe Abbildung 12).
24
2.4 Die Struktur gemäß ITIL Version 3 ProzessOwner
ProzessDokumentation Trigger
ProzessZiele ProzessPolicy
ProzessFeedback
Prozess-Steuerung
ProzessAktivitäten
ProzessInput
ProzessProzeduren
ProzessRollen
ProzessMetriken Prozess-Arbeits -anweisungen
ProzessImprovement
Prozess-Durchführung
ProzessOutput inklusive Prozess-Reports und -Reviews
Prozess-Bedingungen ProzessRessourcen
Abbildung 12:
ProzessBefähigungen
ITIL Version 3 Prozessmodell
Die Betrachtungsbereiche „Prozess-Steuerung“ (Process Control), „Prozess-Durchführung“ (Process) und „Prozess-Bedingungen“ (Process Enablers) sind zwar gegenüber der Version 2 grundsätzlich gleich geblieben, aber die zugehörigen Aspekte wurden detaillierter ausgewiesen. Die Definition, Steuerung und Verbesserung des Prozesses erfolgt innerhalb des Bereichs der „Prozess-Steuerung“. ITIL Version 3 definiert diesen Aufgabenbereich wie folgt (vgl. „Service Design“, [OGC, 2007b): Die Prozess-Steuerung ist die Aktivität, einen Prozess zu planen und zu regulieren, mit dem Ziel, den Prozess effektiv, effizient und in einer einheitlichen Art und Weise auszuführen.
Sobald die Prozesse definiert sind, werden deren Dokumentation und Steuerung erforderlich. Hierzu sind entsprechende Metriken zu entwickeln und als Messpunkte in den Prozess zu integrieren. Mithilfe der implementierten Messpunkte werden Kennzahlen generiert, die in ProzessReports einfließen und eine Steuerung des Prozesses sicherstellen.
25
2 IT Service Management ITIL Version 3 sieht in den Prozessen entsprechende Metriken vor, die als Prozesskennzahlen in Service-Reports enthalten sind und ein Feedback zur ProzessDurchführung liefern. Effektivität und Effizienz eines Prozesses
Der Output eines Prozesses muss den betrieblichen Anforderungen entsprechen, die aus den Geschäftszielen abgeleitet sind. Werden diese Anforderungen hinsichtlich des Outputs erreicht, so ist die Effektivität des Prozesses sichergestellt. Werden die damit verbundenen Aktivitäten mit einem minimalen Ressourceneinsatz durchgeführt, so ist die notwendige Effizienz gegeben. Prozessanalysen, Metriken und Prozessergebnisse sind in ManagementReports darzustellen und bieten die Basis für gegebenenfalls notwendige Verbesserungsmaßnahmen. Die mit der ITIL Version 3 beabsichtigte Business-Integration findet sich ausdrücklich in den Prozesszielen wieder. So wird in ITIL herausgestellt, dass der erforderliche Output eines Prozesses aus den Geschäftszielen abgeleitet wird.
Um diese Ziele zu erreichen, müssen die notwendigen Rollen definiert und die Verantwortlichkeiten in der Organisation zugewiesen werden. Hierzu stellt die ITIL Version 3 folgende Anforderungen (vgl. „Service Design“, [OGC, 2007b): Jedem Prozess ist ein Prozess Owner zugeordnet, der für die Zielereichung und die Verbesserung verantwortlich ist. Die Prozessziele sind in messbarer Hinsicht zu definieren und stehen in Bezug mit den Vorteilen für das Business und der zugrunde liegenden Unternehmensstrategie. Prozess Owner und Prozess Manager
Während in der ITIL Version 2 keine exakte Definition und Beschreibung für den Prozess Owner und Prozess Manager existieren, werden in der ITIL Version 3 diese Rollen definiert und unterschieden: Die Prozess Owner ist dafür verantwortlich, dass ein Prozess zweckmäßig ist. Die Verantwortung des Prozess Owners schließt die Unterstützung, das Design, das Change Management und die beständige Verbesserung des Prozesses und der damit verbunden Messsysteme ein. Die Prozess Manager ist für das operationelle Managements des Prozesses verantwortlich. Die Verantwortung des Prozess Managers umfasst die Planung und Koordinierung aller Aktivitäten, deren Monitoring und deren Berichterstattung. In größeren Organisationen kann es durchaus mehrere Prozess Manager für einen Prozess geben, wie zum Beispiel regionale Change Manager pro Niederlassung.
26
2.5 ITIL Kennzahlen für IT Service Management-Prozesse In kleineren Organisationen übernimmt der Prozess Owner auch die Aufgaben des Prozess Managers.
2.5 ITIL Kennzahlen für IT Service Management-Prozesse Mit der veröffentlichten Version 3 der ITIL Best Practices befindet sich das IT Service Management in einer Übergangsphase. Unternehmen, die bereits IT Service Management-Prozesse implementiert haben, nutzen hierzu die Version 2. Eine Aktualisierung dieser implementierten Prozesse wird kontinuierlich erfolgen, aber nicht kurzfristig umzusetzen sein. Unternehmen, die vor der Implementierung stehen, werden dahingehend wahrscheinlich die Version 3 als Basis für das IT Service Management heranziehen. Um beiden Interessengruppen gerecht zu werden, werden in diesem Buch ausgewählte Kennzahlen aus beiden Versionen dargestellt. Die in diesem Kapitel dargestellten Kennzahlen sind beispielhafte Kennzahlen und erheben keinen Anspruch auf Vollständigkeit. Sie sollen die Inhalte der Version 2 bzw. Version 3 beispielhaft wiedergeben. Innerhalb des Kapitels 5 „Entwicklung von IT-Kennzahlensystemen“ geben wir Kennzahlen an, die sich in der Praxis bewährt haben und gehen insbesondere darauf ein, wie diese Kennzahlen in ein übergeordnetes Kennzahlensystem zu integrieren sind. Aufgrund des generischen Ansatzes werden in ITIL mögliche Leistungsindikatoren und Metriken aufgezeigt. Die konkrete Ausgestaltung der Metrik mit detaillierter Spezifikation und Bedeutung für das ProzessManagement ist Aufgabe des Prozessdesigns. In ITIL und COBIT sind viele Kennzahlen dokumentiert. Wir beschränken uns in diesem Kapitel aber auf die, die im Rahmen unserer Projekterfahrung eine wichtige Rolle spielen bzw. gespielt haben. Später werden diese „Praxis-“Kennzahlen näher spezifiziert und ihre Bedeutung wird für den jeweiligen Prozess dargestellt.
2.5.1
Ausgewählte Kennzahlen der ITIL Version 2
Incident Management Ziel des Incident Managements ist die schnellstmögliche Wiederherstellung des normalen Service-Betriebs bei minimaler Störung des Geschäftsbetriebs. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:
27
In ITIL und COBIT sind viele Kennzahlen dokumentiert
2 IT Service Management – Anzahl der aufgetretenen Störungen – Durchschnittliche Zeitdauer bis zur Behebung oder Umgehung der Störung in Relation zur Priorität – Anteil der Störungen, die innerhalb der vereinbarten Reaktionszeit bearbeitet wurden – Höhe der durchschnittlichen Kosten pro Störung – Lösungsrate von Störungen im Service Desk – Anzahl der bearbeiteten Störungen pro Arbeitsplatz im Service Desk – Anzahl und Anteil der Störungen die remote ( ohne Vor-Ort-Support) behoben werden konnten Bei der Auswertung entsprechender Leistungsindikatoren ist zu beachten, dass ITIL „Incident“ als Oberbegriff für Störungen und Service-Requests nutzt. Im Incident Management-Prozess werden daher auch Service-Requests erfasst und bearbeitet. Für die Aussagekraft der obigen Kennzahlen müssen daher im Rahmen der Kennzahlenermittlung Störungen und Service-Requests differenziert betrachtet werden.
Problem Management Das Problem Management hat die Stabilisierung der IT Services durch die Vermeidung von Incidents zum Ziel. Hierzu werden vom Prozess reaktive und proaktive Aktivitäten durchgeführt. Zu den reaktiven Aufgaben zählen die Aktivitäten von der Identifizierung von Problemen bis zu einer möglichen Umsetzung über das Change Management. Die proaktiven Aktivitäten sollen dagegen sicherstellen, Störungen zu verhindern bevor sie auftreten. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: – Anzahl der vom Problem Management eröffneten RFCs (Request for Change) und Auswirkung dieser RFCs – Durchschnittlicher Zeitaufwand für die Feststellung von Bekannten Fehlern (Known Error); Zeitdauer vom Auftreten eines entsprechenden Problems bis zur Identifizierung des Bekannten Fehlers – Anzahl und Auswirkung von Störungen bevor das zugrunde liegende Problem gelöst ist – Häufigkeit der Probleme unterteilt nach Status, IT Service, Auswirkung, Kategorie und Kunde – Durchschnittliche und maximale Zeitdauer bis zum Abschluss des Problems
28
2.5 ITIL Kennzahlen für IT Service Management-Prozesse
Configuration Management Das Configuration Management dient der Definition, Kontrolle, Pflege und Verifizierung der Service- und Infrastrukturkomponenten sowie der Verwaltung korrekter Konfigurationsinformationen. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: – Anteil der Konfigurationen, die nicht dem autorisierten Zustand entsprechen – Anteil fehlerhafter Changes aufgrund falscher Daten in der CMDB (Configuration Management Database) – Bearbeitungsdauer bis zur Aktualisierung der CMDB – Anteil und Anzahl nicht genutzter Lizenzen – Anteil nicht autorisierter IT-Komponenten Darüber hinaus werden unter anderem die folgenden Berichte an das Management empfohlen: – Anzahl der erfassten CIs (Configuration Item) aufgeschlüsselt nach Kategorien, Typ und Status – Dokumentationsqualität der CIs – Angaben zum Wachstum des CI-Bestandes – Wert der CIs
Change Management Das Ziel des Change Managements ist es, sicherzustellen, dass durch standardisierte Methoden und Verfahren durchzuführende Änderungen effizient und schnellstmöglich umgesetzt werden. Dabei ist darauf zu achten, dass die Änderungen möglichst geringe Auswirkungen auf die Qualität der IT Services haben. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: – Anzahl durchgeführter Änderungen, als Summe und gegliedert in IT Service, CI-Typ usw. – Anteil zurückgewiesener RFCs – Anteil erfolgreicher Änderungen – Anteil termingerechter Änderungen – Anteil Backouts (Fallback; zurückgesetzte Änderungen) – Anteil Änderungen innerhalb des geplanten Budgets
Release Management Das Release Management hat die Bereitstellung, Verteilung und Verfolgung eines oder mehrerer Changes in einem Release in der Produktionsumge-
29
2 IT Service Management bung zum Ziel und soll durch die Anwendung formeller Verfahren und Prüfungen die Produktionsumgebung schützen. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: – – – – –
Anteil eingehaltener Release-Termine Anteil eingehaltener Release-Budgets Anteil zurückgesetzter Releases (Backout) Anzahl von Problemen aufgrund neuer Releases Größe und Kapazität der DSL (Definierte Softwarebibliothek)
Service Level Management Das Ziel des Service Level Managements ist es, Servicequalität zu sichern und kontinuierlich zu verbessern. Dies erfolgt in einem fortlaufenden Zyklus von Definition, Verhandlung, Vereinbarung, Messung, Berichterstattung und Reviews der IT Services. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: – – – – –
Anzahl bzw. Anteil von Services mit SLAs Anteil von SLAs mit OLAs und UCs Anteil eingehaltener SLAs Kundenzufriedenheit Einhaltung von Review-Terminen
Financial Management für IT Services Ziel des Financial Managements für IT Services ist die kostenwirksame Verwaltung der IT-Komponenten, die für die Erbringung der IT Services benötigt werden. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: – Die Budgetpläne werden termingerecht erstellt – Die monatlichen, vierteljährlichen und jährlichen finanziellen Geschäftsziele werden erreicht – Verringerung des Anteils der indirekten Kosten – Die Leistungsverrechnungen werden vom Kunden als angemessen bzw. fair akzeptiert
Capacity Management Ziel des Capacity Managements ist die Sicherstellung ausreichender ITKapazitäten zu vertretbaren Kosten, um den aktuellen und zukünftigen Geschäftsanforderungen des Kunden gerecht zu werden.
30
2.5 ITIL Kennzahlen für IT Service Management-Prozesse Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: – Anteil von Störungen durch nicht ausreichende Kapazitäten – Anteil von SLA-Verletzungen aufgrund mangelnder Performance – Anzahl der Kapazitätsanforderungen, die nicht im Kapazitätsplan enthalten sind – Reduzierung von Überkapazitäten
IT Service Continuity Management Das Ziel des IT Service Continuity Managements ist die Unterstützung des übergreifenden Business Continuity Managements, durch die gesicherte Wiederherstellbarkeit von IT Services innerhalb der erforderlichen und vereinbarten Zeit. Wesentliche Leistungsindikatoren gemäß der ITIL Best Practices sind: – Anzahl festgestellter Mängel am IT Service Continuity-Plan – Zeitspanne zwischen Änderungen mit Auswirkungen auf den IT Service Continuity-Plan und der Aktualisierung des Plans – Anzahl durchgeführter Übungen / Tests des IT Service ContinuityPlans
Availability Management Zielsetzung des Availability Managements ist die Gewährleistung der Service-Verfügbarkeit, um die Verpflichtungen gegenüber dem Business erfüllen zu können. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: – Anzahl von Störung aufgrund der Nicht-Verfügbarkeit – Abweichung zwischen geplanter und tatsächlicher Verfügbarkeit – Dauer der Nichtverfügbarkeit
Security Management Ziel des Security Managements ist es, einen definierten Grad an Sicherheit für die Informationen und IT Services zu gewährleisten. Hierzu zählt einerseits die Erfüllung der Sicheranforderungen aus den SLAs und anderer externer Anforderungen. Andererseits ist ein definierter Grundschutz zu schaffen. Die Publikation „ITIL Best Practice für Security-Management“ spezifiziert für diesen Prozess keine Leistungsindikatoren (vgl. [OGC, 2006a]). Die ITIL Best Practices zum Security-Management verfolgen das Konzept, dass die Sicherheitsanforderungen, bestehend aus Verfügbarkeit, Vertrau-
31
2 IT Service Management lichkeit und Integrität, als Service Level innerhalb der SLAs mit dem Kunden vereinbart werden. Diese Sicherheitsanforderungen gehen ein in die OLAs (Operational Level Agreements) und UCs (Underpinning Contracts). Die Leistungsindikatoren des Security-Managements entsprechen demzufolge den übrigen Service Level eines SLA / OLA / UC und sind eine Ausprägung der Service-Berichte. Aus der Prozessaktivität „Berichtswesen“ können folgende Leistungsindikatoren abgeleitet werden: – Anteil von SLAs, OLAs und UCs mit Sicherheitsverletzungen – Anzahl von Security-Incidents – Reaktionszeit auf Security-Incidents
2.5.2
Ausgewählte Kennzahlen der ITIL Version 3
Wenn man sich mit den Kennzahlen der ITIL Version 3 beschäftigt, spielen die 5 Phasen des Service Lifecycle mit ihren entsprechenden Prozessen die grundlegende Rolle. Die aus der ITIL Version 2 bekannten Prozesse haben wir in Abbildung 13 hervorgehoben. Dabei wird deutlich, dass einige Prozesse der ITIL Version 2 teilweise hinsichtlich der Ziele und Aufgabenstellung verändert wurden. So werden zum Beispiel die Service Requests nicht mehr im Incident Management aufgenommen oder Aufgaben des Service Level Managements aus der ITIL Version 2 finden sich in anderen, neuen Prozessen wieder. Diese durchgeführten Anpassungen gegenüber der ITIL Version 2 haben auch Auswirkungen auf die damit verbundenen Kennzahlen und Metriken, deren Definition und deren Vergleichbarkeit.
32
2.5 ITIL Kennzahlen für IT Service Management-Prozesse
Service Transition
Continual Service Improvement
Service Asset and Configuration M.
Release and Deployment M.
Service Validation and Testing
Change Management
Evaluation
Transition Planning and Support Service Level Management
Supplier M. Information Security M.
Knowledge Mgmt.
Service Portfolio M.
Demand M.
Service Level M.
Abbildung 13:
Request Fulfilment
Financial Management
Capacity M.
Service Catalogue M.
Service Reporting
Incident Management
Strategy
Availability M.
The Business Questions for CSI
Event Management
Service
Service Continuity M.
Service Design
The 7 Step Improvement Process
Service Operation
Problem M. Access Management Service Desk
Service Measurement
Return on Investment (ROI) for CSI
Die 5 Phasen des Service Lifecycles und ihre Prozesse
Im Folgenden werden die 5 Phasen des Service Lifecycle mit ihren Prozessen vorgestellt und die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren beispielhaft beschrieben.
33
2 IT Service Management
2.5.2.1 Service Strategy
Service Portfolio M.
Demand M.
Service
Strategy Financial Management
Abbildung 14:
Service Strategy
Die Publikation „Service Strategy“ ([OGC, 2007a]) weicht von den übrigen vier Publikationen dahingehend ab, dass sie kein Kapitel „Prozesse“ enthält. Im Rahmen des Kapitels „Service Economics“ werden Aspekte beschrieben, die einen Charakter von Prozessen haben. Als Prozesse sind dabei das „Financial Management“, das „Service Portfolio Management“ und das „Demand Management“ anzusehen.
Financial Management Financial Management quantifiziert IT Services, ihre zugrunde liegenden Assets und sogar operationelle Vorhersagen mit Metriken aus der FinanzTerminologie. Die Frage, die hier im Raum steht, ist die nach dem Wert für das Business und die IT. Es gibt einen Wandel in der Wahrnehmung der IT und ihres Wertes für das Business. Financial Management hilft bei der Identifizierung, Dokumentation und Akzeptanz des Wertes der erhaltenen Serviceleistungen und ermöglicht die Modellierung und das Management von Service-Anforderungen.
Service Portfolio Management Ein Service Portfolio beschreibt die Services eines Providers im Hinblick auf deren Wert für die Geschäftsprozesse (Business Value). Service Portfolio Management formuliert die geschäftlichen Anforderungen und die Antwort des IT Service Providers auf diese Bedürfnisse.
34
2.5 ITIL Kennzahlen für IT Service Management-Prozesse
Demand Management Demand Management (Anforderungsmanagement) behandelt kritische Aspekte des Service Managements: Unsicherheiten bei der Anforderungsaufnahme bergen Risiken für IT Service Provider, wie Überkapazitäten oder ungenügende Kapazitäten mit Auswirkung auf die Qualität der Services. Service Level Agreements, Vorhersagen, Planung und feste Koordination mit dem Kunden können die Unsicherheiten bei den Anforderungen reduzieren, diese aber nicht vollständig eliminieren.
2.5.2.2 Service Design
Supplier M. Information Security M. Service Continuity M. Availability M.
Service Design
Capacity M. Service Level M. Service Catalogue M.
Abbildung 15:
Service Design
Service Catalogue Management Ziel des Prozesses Service Catalogue Management (SCM) ist die Erstellung und Pflege eines Service Katalogs mit genauen Informationen über alle aktuellen und geplanten operationalen Services. Hierzu werden die vom Service Portfolio Management definierten Services entsprechend spezifiziert und sind als Teilmenge bzw. konkrete Ausprägung des Service Portfolios anzusehen.
35
2 IT Service Management Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – die Anzahl der aufgenommenen und verwalteten Services innerhalb des Service Katalogs als Prozentsatz der Services, die ausgeliefert und übergeben wurden und sich in der „Live-Umgebung“ befinden – die Anzahl von Abweichungen zwischen den Informationen im Service Katalog und der „realen Welt“.
Service Level Management Der Service Level Management Prozess definiert und vereinbart für alle aktuellen und zukünftigen IT Services die damit verbundenen Service Level und die erreichbaren Zielwerte (Service Level Targets). Außerdem stellt er sicher, dass Services auf diesem Level ausgeliefert werden. Proaktive Messungen und Reports helfen bei den notwendigen Verbesserungen zur Zufriedenheit der Kunden. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – prozentuale Verringerung nicht erfüllter SLA-Ziele – prozentuale Verringerung bedrohter SLA-Ziele – prozentualer Anstieg der Kunden-Wahrnehmung und -Zufriedenheit von SLA-Leistungen via Service Reviews und Kunden Zufriedenheits-Befragungen – prozentuale Verringerung von SLA-Verletzungen, die durch Unterauftragnehmer verletzt wurden.
Capacity Management Das Capacity Management (Kapazitätsmanagement) stellt sicher, dass ITKapazitäten zu gerechtfertigten Kosten jederzeit in allen IT-Bereichen existieren und rechtzeitig die abgestimmten aktuellen und zukünftigen Anforderungen des Business abdecken. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – akkurate Business Vorhersagen (Vorhersagen über Arbeitsauslastungen in der Produktion; prozentuale Genauigkeit der Vorhersagen von Business Trends, etc.) – Wissen über aktuelle und zukünftige Technologien (Fähigkeit, Performance und Durchsatz aller Services und Komponenten zu monitoren; rechtzeitige Ausrichtung und Implementierung neuer Technologien, abgestimmt auf die Business-Anforderungen, etc.)
36
2.5 ITIL Kennzahlen für IT Service Management-Prozesse – Fähigkeit, Kosten-Effektivität zu demonstrieren (eine Verringerung von Käufen in letzter Minute für die Behebung dringender Performance-Probleme; Verringerung von Überkapazitäten der IT, etc.) – Fähigkeit zur Planung und Implementierung der angemessenen ITKapazitäten zur Befriedigung der Business-Anforderungen (prozentuale Verringerung der Anzahl von Incidents, die durch schlechte Performance ausgelöst werden; prozentuale Verringerung verlorener Geschäftschancen aufgrund unzulänglicher Kapazitäten, etc.).
Availability Management Der Availability Management-Prozess (Verfügbarkeitsmanagement) stellt sicher, dass die Verfügbarkeit aller ausgelieferten Services die aktuellen und zukünftigen Anforderungen kosteneffektiv befriedigt oder übertrifft. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – prozentuale Verringerung in der Nichtverfügbarkeit von Services und Komponenten – prozentualer Anstieg in der Verlässlichkeit von Services und Komponenten – effektives Review und Verfolgung aller Verletzungen bei SLAs, OLAs und UCs – prozentuale Verbesserung in der allumfassenden end-to-end Verfügbarkeit von Services.
IT Service Continuity Management Das IT Service Continuity Management (ITSCM) unterstützt den allumfassenden Business Continuity Management Prozess. Es stellt sicher, dass die IT-technischen Betriebsmittel und Services (einschließlich Rechnersysteme, Netzwerke, Anwendungen, Datenbestände, Telekommunikationsanlagen, technischer Support und Service Desk) nach einem Ausfall oder einer Störung innerhalb der erforderlichen und vereinbarten Zeitgrenzen wieder in Betrieb gehen und verfügbar sind. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – regelmäßige Audits der ITSCM Pläne, um das Erreichen der vereinbarten Wiederherstellungsanforderungen des Business sicherzustellen – alle Service-Wiederherstellungsziele sind in SLAs vereinbart und dokumentiert und sind erreichbar innerhalb der ITSCM-Pläne – regelmäßige und umfassende Tests der ITSCM-Pläne
37
2 IT Service Management – regelmäßige, mindestens jährliche Reviews der Business- und IT Continuity-Pläne mit den Geschäftsbereichen.
Information Security Management IT Sicherheit muss auf das Sicherheitsbedürfnis des Business abgestimmt werden. Information Security Management verfolgt dieses Ziel über ein effektives Management der Informations-Sicherheit in allen Services und Service Management-Aktivitäten. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – prozentuale Verringerung der im Service Desk berichteten Sicherheits-Verletzungen – prozentuale Verringerung bei den Auswirkungen von SicherheitsVerletzungen und Incidents – prozentualer Anstieg der SLA-Konformität zu den Sicherheitsbestimmungen – Abnahme der Anzahl von Abweichungen des Information Security Management-Prozesses von Business Security-Policy und -Prozess.
Supplier Management Supplier Management ist das Management von Lieferanten und ihren Services, um dem Business die vereinbarte Service-Qualität zukommen zu lassen und sicherzustellen, dass Ausgaben bei den Lieferanten wieder eingenommen werden können.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – Anstieg der Anzahl von Lieferanten, die vertraglich vereinbarte Ziele einhalten – Anstieg der Anzahl der mit Lieferanten durchgeführten Serviceund Vertrags-Reviews – Reduzierung der Anzahl von durch Lieferanten verursachten Service-Verletzungen – Anstieg der Anzahl von Lieferanten mit ernanntem Lieferanten-Manager.
38
2.5 ITIL Kennzahlen für IT Service Management-Prozesse
2.5.2.3 Service Transition Service Transition Release and Service Asset and Configuration M. Deployment M. Service Validation Change Management and Testing Evaluation Transition Planning and Support Knowledge Mgmt.
Abbildung 16:
Service Transition
Transition Planning and Support Transition Planning and Support plant und koordiniert Ressourcen für eine effektive Realisierung der in Service Strategy definierten und in Service Design entwickelten und umgesetzten Anforderungen. Potentielle Risiken und Störungen der Transitions-Aktivitäten werden identifiziert und kontrolliert.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – die Anzahl implementierter Releases, die – im Hinblick auf Kosten, Qualität, Scope und Release-Zeitplan – die mit dem Kunden vereinbarten Anforderungen erfüllen – Reduzierung von Abweichungen der aktuellen gegen die vorhergesagten Werte Inhalt (Scope), Qualität, Kosten und Zeit – gestiegene Kunden- und Anwender-Zufriedenheit mit Plänen und der Kommunikation, die das Business in die Lage versetzen, seine Aktivitäten mit den Service Transition Plänen in Einklang zu bringen – Reduzierung der Anzahl von Problemen, Risiken und Verzögerungen, die durch unzulängliche Planung verursacht werden.
Change Management Die Anforderungen im Business des Kunden verändern sich fortlaufend. Change Management reagiert auf diese Änderungsanforderungen und maximiert den Wert für den Kunden, während gleichzeitig Incidents, Störungen und Überarbeitungen reduziert werden. Die Reaktionen auf die Än-
39
2 IT Service Management derungsanforderungen des Business und der IT sorgen für eine Ausrichtung der Services am Bedarf des Business. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – Anzahl der Änderungen (Changes) an den Services, die die mit den Kunden vereinbarten Anforderungen z. B. hinsichtlich Qualität/Kosten/Zeit erfüllten (ausgedrückt als Prozentsatz an allen Änderungen) – der Nutzen der Änderungen, ausgedrückt als „Wert der durchgeführten Verbesserungen“ + „verhinderte oder beendete negative Auswirkungen“, verglichen mit den Kosten des Änderungsprozesses – Reduzierung der Anzahl von Störungen am Service, Mängel und Überarbeitungen, die durch nicht exakte Spezifikation oder schlechte/unvollständige Bewertung der Auswirkungen verursacht wurden. – Reduzierung der Anzahl nicht autorisierter Änderungen – Reduzierung des Rückstands von Änderungsanträgen.
Service Asset and Configuration Management Service Asset und Configuration Management liefert ein logisches Modell der IT Infrastruktur und stellt – falls erforderlich – den Zusammenhang zwischen den IT Services mit notwendigen IT-Komponenten her.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – prozentuale Verbesserung bei der Zeitplanung für Wartungsarbeiten eines Assets (nicht zu viel, nicht lange) – Grad der Abstimmung zwischen unterstützter Wartung und Business Support – als Ursache von Service-Ausfällen identifizierte Assets – verbesserte Geschwindigkeit für das Incident Management zur Identifizierung fehlerhafter Cis und die Wiederherstellung des Service – Auswirkung von Incidents und Fehlern mit Bezug auf bestimmte CI-Typen, z. B. von bestimmten Lieferanten oder Entwicklungsgruppen.
Release and Deployment Management Das Ziel von Release und Deployment Management ist die Auslieferung und Überführung von Releases in die Produktion. Hier werden die Services
40
2.5 ITIL Kennzahlen für IT Service Management-Prozesse den Kunden zur Verfügung gestellt und sichergestellt, dass die Services sinnvoll und produktiv genutzt werden können. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – Abweichung von der vom Kunden geforderten Service Performance (Service Leistung) – Anzahl von Incidents bzgl. des Service – Reduzierter Einsatz von Ressourcen und Kosten für die Diagnose und die Behebung von Incidents und Problemen in Entwicklung und Produktion – Verstärkte Umstellung des Service Transition Common Framework auf Standards, wiederverwendbare Prozesse und Support.
Service Validation and Testing Service Validation and Testing überprüft und sichert den Wert der Services für die Kunden und ihr Business. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – Vertrauen, dass ein Release die erwarteten Ergebnisse und den Wert für die Kunden innerhalb der projektierten Kosten, Kapazitäten und Beschränkungen liefert – Die Bestätigung, dass ein Service seinen Zweck und die geforderte Performance ohne unerwünschte Beschränkungen erfüllt – Sicherstellen, dass ein Service bestimmte Spezifikationen innerhalb der spezifizierten Rahmen- und Nutzungsbedingungen erfüllt – Bestätigung, dass Anforderungen der Kunden und Stakeholder für neue oder veränderte Services korrekt definiert sind und die Beseitigung jeglicher Fehler oder Abweichungen möglichst früh im Service Lebenszyklus erfolgt, da dies beträchtlich billiger ist als die Fehlerbeseitigung in der Produktion.
Evaluation Evaluation bewertet Performance-Veränderungen bei einer Service-Änderung. So können Abweichungen zu gewünschten und vorhergesagten Performance-Werten entsprechend behandelt werden. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – – – –
Abweichung der Service Performance Anzahl von Incidents bzgl. des Service Anzahl fehlerhafter Designs, die überführt wurden Zykluszeit für die Durchführung der Evaluation.
41
2 IT Service Management
Knowledge Management Knowledge Management liefert die Grundlage für fundierte Entscheidungen. Die im Verlauf des Lebenszyklus der Services gewonnenen Informationen und Daten werden bereitgestellt. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – Incidents und verlorene Zeiten, kategorisiert als „Mangel an Anwender-Wissen“ – durchschnittliche Diagnose- und Reparatur-Zeit für Fehler, die inhouse behoben werden – Incidents bzgl. neuer oder veränderter Services, die durch Referenz auf die Wissensbasis behoben wurden.
2.5.2.4 Service Operation
Event Management Incident Management Request Fulfilment Problem M.
Service Operation
Access Management Service Desk
Abbildung 17:
Service Operation
Event Management Event Management befähigt zur Entdeckung und Interpretation von Ereignissen (Events) und ermöglicht deren Steuerung. Deshalb ist Event Management die Basis für „Operational Monitoring and Control“.
42
2.5 ITIL Kennzahlen für IT Service Management-Prozesse Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – Anzahl von Ereignissen je Kategorie – Anzahl von Ereignissen nach Signifikanz – Anzahl und Prozentsatz an Ereignissen, die menschliche Intervention erforderten und ob dies durchgeführt wurde – Anzahl und Prozentsatz an Ereignissen, die in Incidents oder Änderungen resultierten.
Incident Management Das primäre Ziel des Incident Management-Prozesses ist die schnelle Wiederherstellung des Service Betriebs mit der Qualität, wie sie in den Service Level Agreements (SLA) vereinbart wurde. Hierbei soll die Auswirkung des Incidents auf die Geschäftsprozesse minimiert werden. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – Gesamtzahl der Incidents (als Kontroll-Wert) – Aufschlüsselung der Incidents in jeder Stufe (z. B. aufgezeichnet, in Bearbeitung, geschlossen) – Rückstand aktueller Incidents – Anzahl und Prozentsatz schwerwiegender (major) Incidents – mittlere Ablaufzeit bis zur Lösung/Wiederherstellung oder Umgehungslösung, aufgeschlüsselt nach Auswirkung (impact code).
Request Fulfilment Request Fulfilment ist der für die Behandlung der Service Requests verantwortliche Prozess. Er stellt definierte Informationskanäle für die Anwender bereit, mit denen Anforderungen gestellt und Services entgegengenommen werden können. Darüber hinaus werden Informationen über die Verfügbarkeit von Services und Prozeduren für deren Nutzung bereitgestellt. Standardleistungen, wie z. B. Lizenzen und Software-Medien, werden beschafft und ausgeliefert.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – Gesamtzahl an Service Requests – Aufschlüsselung der Service Requests auf die einzelnen Stufen (z. B. aufgezeichnet, in Bearbeitung, geschlossen) – Rückstand bei der Bearbeitung von Service Requests – mittlere Ablaufzeit bei der Behandlung der verschiedenen Typen von Service Requests.
43
2 IT Service Management
Problem Management Der Prozess Problem Management ist verantwortlich für den Lebenszyklus aller Probleme1. Das Problem Management hat hierzu die Ursachen zu identifizieren und sicherzustellen, dass die erarbeiteten Lösungen über die Control Prozesse – hauptsächlich Change Management – implementiert werden. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – Gesamtzahl der Probleme (als Kontroll-Wert) – Prozentsatz von Problemen, die innerhalb der SLA-Ziele gelöst bzw. nicht gelöst wurden – Anzahl und Prozentsatz von Problemen, die ihre maximalen Lösungszeiten überschritten haben – der Rückstand bei ausstehenden Problemen und ihr Trend (statisch, verringernd oder ansteigend?).
Access Management Access Management berechtigt Anwender, einzelne Services oder Gruppen von Services zu nutzen. Insofern ist es für die Ausführung der im Securityund Availability Management definierten Richtlinien und Aktionen zuständig.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – Gesamtzahl der Zugriffsanforderungen (Service Request, RFC, etc.) – Instanzen gewährter Zugriffe, nach Service, Anwender, Abteilung, etc. – Instanzen gewährter Zugriffe nach Abteilung oder individuellen Zugriffsrechten – Anzahl an Incidents, die ein Zurücksetzen der Zugriffsrechte erfordern.
Service Desk Beim Service Desk handelt es sich um keinen Prozess, sondern um eine organisatorische Anforderung an die Organisation.
1
44
Ein Problem bezeichnet in der ITIL-Terminologie die Ursache für einen oder mehrere Incident. Die Ursache ist normalerweise bei der Eröffnung eines Problems nicht bekannt. Der Prozess des Problem Managements ist für die weitere Untersuchung der Ursache verantwortlich.
2.5 ITIL Kennzahlen für IT Service Management-Prozesse Der Service Desk als Anforderung an die Organisation ist im Kapitel „Organizing Service Operation“ beschrieben. Primäres Ziel des Service Desk ist die Wiederherstellung des „normalen Service“ so schnell wie möglich (siehe auch Incident Management). Dies kann neben der Behebung eines technischen Fehlers ebenso die Erfüllung eines Service Requests bzw. grundsätzlich alles sein, was erforderlich ist, damit der Anwender seine Arbeit wieder so erledigen kann, wie dies sein Geschäftsprozess erfordert. Zur Verantwortung des Service Desk gehört auch die Dokumentation eingehender Incidents und Service Requests, deren Kategorisierung und Priorisierung, die Durchführung einer ersten Diagnose und Eskalationsschritte, falls vereinbarte Zeitgrenzen überschritten werden. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: – Prozentsatz von Calls (Anrufen), deren Requests bzw. Störungen sofort während des ersten Kontaktes am Service Desk gelöst werden konnten – Prozentsatz „gelöster Calls“ ohne die Unterstützung anderer Gruppen – Prozentsatz „gelöster Calls“ mit Unterstützung anderer Gruppen.
45
2 IT Service Management
2.5.2.5 Continual Service Improvement
Continual Service Improvement
The 7 Step Improvement Process
Service Reporting
Service Level Management
The Business Questions for CSI
Abbildung 18:
Service Measurement
Return on Investment (ROI) for CSI
Continual Service Improvement
The 7 Step Improvement Process Hier werden Fragen gestellt nach den Business Treibern hinter der ITILImplementierung, der finanziellen Bewertung von IT-Investitionen, dem Reifegrad, der Effektivität und Effizienz aktueller Prozesse, den Gaps und Problemen bei der Bereitstellung von Services, der Bewertung von Ressourcen (Time and Budget) zum Schließen der Lücken und schließlich nach den Ergebnissen der Aktivitäten beim Streben nach „Service Improvement ROI“. Der 7 Step Improvement Process umfasst die folgenden Forderungen:
46
1.
Definieren, was gemessen werden soll
2.
Definieren, was gemessen werden kann
3.
Daten sammeln
4.
Daten bearbeiten
2.5 ITIL Kennzahlen für IT Service Management-Prozesse 5.
Daten analysieren
6.
Informationen präsentieren und nutzen
7.
Korrekturen durchführen
Abbildung 19 aus „Continual Service Improvement (vgl. [OGC, 2007e]) veranschaulicht diesen Prozess: Identifiziere: ¾ Vision ¾ Strategie ¾ Taktische Ziele ¾ Operative Ziele
1. Definiere, was Du messen solltest 2. Definiere, was Du messen kannst
7. Implementiere Korrekturmaßnahmen
Ziele 6. Präsentiere und nutze die Informationen
3. Sammle Daten
5. Analysiere Daten Abbildung 19:
4. Bearbeite Daten
7 Step Improvement Prozess
Key Performance Indikatoren sind zu diesem Prozess nicht ausgeführt, sondern allgemeine Anforderungen an die Metriken. Dabei wird unterschieden zwischen technischen Metriken und Metriken für Prozesse und Services. Technische Metriken sind häufig mit den eingesetzten Komponenten und Applikationen verbunden und betrachten technische Aspekte wie Performance, Verfügbarkeit etc. Prozess Metriken erfassen CSFs, KPIs und Messgrößen für Tätigkeiten der Service Management-Prozesse. Diese Metriken ermöglichen eine Beurteilung der Prozesse. Die Metriken sollten die vier Aspekte „Qualität“, „Performance“, „Nutzen“ und „Compliance“ abdecken. Service Metriken sind das Ergebnis einer end-to-end Betrachtung der Services.
47
2 IT Service Management Innerhalb „The 7 Step Improvement“ sind allgemeine Fragestellungen hinsichtlich der Definition von KPIs dokumentiert:
– Was sagt uns der KPI über die Zielerreichung aus? – Wie leicht ist es, den KPI zu interpretieren? – Wann brauchen wir die Information? Wie oft? Wie rasch sollte die Information verfügbar sein? – In welchem Maß ist der KPI stabil und genau? Ist er von externen unkontrollierbaren Einflüssen abhängig? – Wie leicht ist es, den KPI selbst zu ändern? Wie leicht ist es, das Maßsystem an sich verändernde Umstände anzupassen oder Änderungen in Bezug zu den Zielen durchzuführen? – Wer ist der Owner des KPIs? Wer ist verantwortlich für das Sammeln und die Analyse der Daten? Wer ist für Verbesserungen basierend auf den gewonnenen Informationen verantwortlich?
Service Reporting Das Service Reporting liefert die notwendigen korrekten Berichte, die den Kundenerwartungen entsprechen. Aus der Vielzahl der vorliegenden Daten sind hierzu die Daten so aufzubereiten, dass das Business die notwendigen Informationen erhält. Dazu gehört auch die Berichterstattung der letzten Periode. Key Performance Indikatoren sind zu diesem Prozess nicht ausgeführt.
Service Measurement Das Service Measurement stellt sicher, dass die Services bezüglich der Aspekte der Verfügbarkeit (Availability), Zuverlässigkeit (Reliability) und Performance gemessen werden können. Dabei ist die Kundensicht auf den Service ( end-to-end) von großer Bedeutung, da hiervon die Geschäftsprozesse des Business abhängig sind. Als Key Performance Indikatoren für das Service Management werden aus Kundensicht demzufolge herausgestellt: – Verbesserte Verfügbarkeit (durch Service / Systems / Applikationen) – Verringerung der Service Level Verletzungen (durch Service / Systems / Applikationen) – Verringerung „mean time to repair“ (gemessen anhand von Prioritäten) – Verringerung „Major Incidents“
48
2.5 ITIL Kennzahlen für IT Service Management-Prozesse
Return on Investment (ROI) for CSI Um die Aufgabe des Return on Investments (ROI) für das Continual Service Improvement (CSI) erfüllen zu können, sind viele Faktoren in Betracht zu ziehen. Auf der einen Seite sind dies die Kosten für die Durchführung dieser Phase des Service Lifecyle, bestehend zum Beispiel aus den Personalkosten, Tools, Beratungskosten, etc. Auf der anderen Seite ist zu bewerten, welche geschäftlichen Vorteile durch diese Tätigkeiten erzielt werden. Letztlich geht es um eine geschäftliche ROI Betrachtung. Daher sind die Vorteile auch nicht nur aufseiten der IT zu bewerten, sondern primär aus Sicht des Business. Eine mögliche Betrachtung wäre zum Beispiel die Kosten von Ausfallzeiten auf der Seite des Business. Key Performance Indikatoren sind zu diesem Prozess nicht ausgeführt
The Business Questions for CSI Die Business Integration von ITIL Version 3 wird auch dadurch zum Ausdruck gebracht, dass das Business in das Continual Service Improvement einzubinden ist. Mögliche Verbesserungen sind dahingehend zu bewerten, welche Maßnahmen den größten Vorteil für das Business mit sich bringen. Hierzu ist zu bewerten „Wo stehen wir heute?“ und gemeinsam zu definieren „Was wollen wir?“ Key Performance Indikatoren sind zu diesem Prozess nicht ausgeführt.
Service Level Management Service Level Management ist ein für das CSI kritischer und wichtiger Prozess. Das Service Level Management entscheidet darüber, was gemessen wird, welche Anforderungen an die Überwachungen gestellt werden, wie das Erreichen von Service Level berichtet wird und wo mit dem Business bei neuen Service Requests oder Änderungen an existierenden Services zusammengearbeitet wird. So werden die Aktivitäten des CSI unterstützt und Verbesserungsprojekte priorisiert.
Das Service Level Management stellt einen wichtigen Trigger für den Service Plan (SIP) dar. Key Performance Indikatoren sind zu diesem Prozess nicht ausgeführt.
49
2 IT Service Management
2.6 ISO 20000 Nach der umfassenden Akzeptanz und Verbreitung der ITIL Best Practices innerhalb von IT-Organisationen geht das Thema „Professionelle Serviceorientierung in der IT“ in die nächste Runde. Mit der seit dem 15. Dezember 2005 gültigen ISO 20000 „Information Technology - Service Management“ haben IT-Organisationen nun erstmalig die Möglichkeit, ihre IT Service Management-Prozesse durch eine unabhängige Auditierungs-Organisation auf der Basis einer internationalen Qualitätsnorm zertifizieren zu lassen. Mit dieser Norm wird dem steigenden Bedarf des Nachweises eines wirksamen IT Service Managements Rechnung getragen. In diesem Zusammenhang muss nochmals die Zielsetzung von ITIL herausgestellt werden. Innerhalb der IT Infrastructure Library sind bewährte Vorgehensweisen (Best Practices) dokumentiert. Sie sind als Leitfaden (Guidelines) für die Implementierung von IT Service Management-Prozessen gedacht. Dabei bleibt es den Organisationen überlassen, wie und in welchem Maße dieser Leitfaden zur Gestaltung der unternehmensspezifischen IT Service Management-Prozesse genutzt wird. Aufgrund der steigenden internationalen Anerkennung und Nutzung wird ITIL auch als De-facto-Standard für das IT Service Management bezeichnet und zum Teil irrtümlich als Standard – im Sinne einer Norm – verstanden. ITIL ist kein Standard im Sinne einer Norm. Eine „ITIL Zertifizierung“ für Organisationen ist nicht möglich.
Demzufolge können die implementierten IT Service Management-Prozesse einer IT-Organisation nicht nach ITIL zertifiziert werden. Nur Personen können sich auf Basis der ITIL Best Practices zertifizieren lassen. Damit wird das Know-how der Person um die ITIL Best Practices dokumentiert. Der Nachweis ITIL-zertifizierter Mitarbeiter ist jedoch noch keine Garantie dafür, dass die IT Service Management-Prozesse tatsächlich implementiert sind und den Mindestanforderungen genügen, zumal in den ITIL Best Practices keine Mindestanforderungen spezifiziert sind. Daher wurde mit der ISO 20000 „IT Service Management“ eine gemeinsame internationale Referenz (Norm) für alle IT-Organisationen bereitgestellt, die IT Services für interne oder externe Kunden erbringen.
50
2.6 ISO 20000 Die ISO 20000 beinhaltet sämtliche Aspekte, die für IT-Organisationen gültig sind und die es umzusetzen gilt. Die ISO 20000 kann so als international definierte Mindestanforderung an das IT Service Management angesehen werden. Mit der ISO 20000 existiert seit dem 15. Dezember 2005 eine international anerkennte Norm für das IT Service Management. Auf der Basis dieser Norm ist eine Zertifizierung der implementierten IT Service Management-Prozesse einer Organisation möglich.
Eine Zertifizierung von Organisationen ist nur auf Basis der ISO 20000 möglich
In einer Analyse kommt Gartner zu dem Ergebnis, dass "…bis Ende 2008 mindestens 60 % der relevanten Beschaffungsvorhaben der öffentlichen Hand und mindestens 30 % des privaten Sektors in entwickelten Volkswirtschaften eine ISO 20000-Zertifizierung verlangen werden" (vgl. [Gartner, 2006]).
2.6.1
Die Geschichte der ISO 20000
Die im September 2005 veröffentliche ISO 20000 geht zurück auf einen British Standard, den BS 15000 (vgl. [BS 15000-1, 2002] und [BS 15000-2, 2002]). Bereits auf der Basis des BS 15000 konnte das IT Service Management einer IT-Organisation zertifiziert werden. Die erste Version des BS 15000 wurde im November 2000 veröffentlicht. An der Definition dieses Standards haben die Autoren der ITIL Best Practices maßgeblich mitgewirkt. Dadurch ist eine weitgehende Überstimmung zwischen den ITIL Best Practices für das IT Service Management und BS 15000 bzw. ISO 20000 sichergestellt. Auch viele deutsche Unternehmen, wie zum Beispiel die Siemens AG IT Operations (ITO), haben auf Basis des BS 15000 ihr IT Service Management zertifizieren lassen. Da es sich aber um einen Britischen Standard handelt und die dort beschriebenen Ansätze internationale Anerkennung finden sollten, wurde der BS 15000 in die ISO 20000 übergeleitet. Die dabei durchgeführten Änderungen waren sehr gering, sodass die ISO 20000 weitestgehend dem BS 15000 entspricht.
2.6.2
Der Aufbau der ISO 20000
Die ISO 20000 besteht aus den beiden Dokumenten ISO 20000-1 und ISO 20000-2. Der erste Teil der Norm „ISO 20000-1: Specification“ (vgl. [ISO 20000-1, 2005]) enthält die formelle Spezifikation des Standards. In der ISO 20000-1 sind die Vorgaben dokumentiert, die eine Organisation einhalten, sicherstellen und nachweisen muss, um die Zertifizierung zu erhalten. Die
51
ISO 20000-1 enthält die Muss-Anforderungen
2 IT Service Management ISO 20000-1 enthält die Muss-Kriterien des Standards und umfasst inklusive Deckblatt und Inhaltsverzeichnis insgesamt 36 Seiten. ISO 20000-2 enthält die Soll-Anforderungen
Teil zwei der Norm „ISO 20000-2: Code of Practice“ (vgl. [ISO 20000-2, 2005]) ergänzt die Anforderungen des ersten Teils um Erläuterungen. Die ISO 20000-2 bietet die Leitlinien und die Empfehlungen für IT Service Management-Prozesse im Rahmen des formellen Standards. Die ISO 20000-2 umfasst 44 Seiten. Anhand des Umfangs der Dokumentation kann die Zielsetzung der ISO 20000 leicht nachvollzogen werden. Die Norm definiert Anforderungen an die Prozesse (ISO 20000-1) und Umsetzungsempfehlungen (ISO 20000-2), liefert aber keine generischen Prozessbeschreibungen, wie sie durch die ITIL Best Practices zur Verfügung gestellt werden. Als Beispiel hierzu soll das Service Level Management dienen. Die ISO 20000-1 fordert für das Service Level Management unter anderem, die IT Services mittels SLAs zu definieren und zu vereinbaren (vgl. [ISO 20000-1, 2005], Kapitel 6.1 „Service Level Management“): „Each service provided shall be defined, agreed and documented in one or more service level agreements (SLAs).“ Die ISO 20000-2 enthält Empfehlungen zu den Inhalten der SLAs (vgl. [ISO 20000-2, 2005], Kapitel 6.1.2 „Service Level Agreements“): „The minimum content that should be in an SLA or that can be directly referenced from an SLA is: brief service description; validity period and/or SLA change control mechanism; authorization details.“. Die ITIL Best Practices beschreiben dagegen die Prozessaktivitäten zur Definition und Vereinbarung von SLAs (vgl. [OGC, 2005b], Kapitel 3.4.3 „Planen der SLA-Struktur“): „… muss das Service Level Management eine SLA Struktur planen, die am besten geeignet ist, sicherzustellen, dass alle Services …“.
ITIL und ISO 20000 stehen nicht im Wettbewerb, sondern ergänzen sich zweckmäßig
Wie das Beispiel zeigt, stehen die ITIL Best Practices und die ISO 20000 nicht in Konkurrenz zueinander, sondern ergänzen sich zweckmäßig. Ungeachtet einer möglichen Zertifizierung liefern die ITIL Best Practices Guidelines zum Aufbau der IT Service Managements. Die notwendigen IT Service Management-Prozesse werden beschrieben, Rollen definiert, Dokumente wie SLAs, RFCs werden beschrieben, kritische Erfolgsfaktoren identifiziert und mögliche Leistungsindikatoren beschrieben. Mithilfe von ITIL können Organisationen wirkungsvoll und mit einer größeren Planungssicherheit ihr IT Service Management etablieren. IT-Organisationen, die die ITIL Best Practices als Leitfaden zum Design ihrer IT Service Management-Prozesse nutzten, haben so eine gute Basis für eine ISO 20000 Zertifizierung geschaffen. Die ISO 20000 definiert Mindestanforderungen und hilft dadurch, sich zunächst auf die Mindestanforderungen zu konzentrieren. Hierzu die Presseerklärung des Flughafens München zur er-
52
2.6 ISO 20000 folgreichen ISO 20000 Zertifizierung „… um die Prozessneugestaltung mit der erforderlichen Motivation durchzuführen, wurde die Zertifizierung des Servicebereichs nach BS15000 (jetzt ISO 20000) als Meilenstein definiert. Die Zertifizierung als erste Zielmarke zu definieren, um einerseits das Augenmerk des Bereichsmanagements und aller betroffenen Mitarbeiter klar zu fokussieren, andererseits die Bearbeitungstiefe in den Prozessen zu begrenzen und eine pragmatische 'Flughöhe' zu halten, erwies sich dabei als sehr hilfreich und gab allen beteiligten Mitarbeitern eine klare Zielorientierung …“ (vgl. [KESS, 2006a]). Die ITIL Version 2 ist nicht mit der ISO 20000 gleichzusetzen. Es lassen sich strukturelle Unterschiede zwischen den ITIL Best Practices der Version 2 und der ISO 20000 feststellen, wie zum Beispiel das übergeordnete Managementsystem. Mit der Herausgabe der ITIL Version 3 werden mit dem übergeordneten Management (Service Strategy) und dem Continual Service Improvement wesentliche Managementprozesse abgedeckt, die in der ISO 20000 gefordert werden. Allerdings sind in der ITIL Version 3 die Prozesse gegenüber der ISO 20000 erweitert worden, wie zum Beispiel durch die Aufteilung des „alten“ Incident Managements in „Incident Management“ und „Request Fulfilment“. Ungeachtet dieser geringfügigen Unterschiede lassen sich die Anforderungen der ISO 20000 mit der ITIL Version 3 einfacher umsetzen. Die ISO 20000 definiert die Mindestanforderungen an das IT Service Management, die ITIL Best Practices liefern hierzu generische Prozessbeschreibungen.
2.6.3
Die Inhalte der ISO 20000
In der ISO 20000-1 (Specification) und der ISO 20000-2 (Code of practice) sind die zu implementierenden IT Service Management-Prozesse sowie die übergeordneten Prozesse und Aufgaben dokumentiert. Insbesondere mit den Anforderungen an ein übergeordnetes Managementsystem enthält die ISO 20000 eine wichtige Ergänzung zu ITIL Version 2. Mit der ITIL Version 3 ist mit der „Service Strategy“ und dem „Continual Service Improvement“ das übergeordnete Managementsystem ebenfalls beschrieben. Explizit fordert die ISO 20000 einen strategischen Planungsprozess für das IT Service Management. Er soll unter anderem kurz-, mittel und langfristige Planungen miteinander vereinen. Damit wird die Integration des IT Service Managements in die IT-Strategie sichergestellt. Innerhalb der folgenden Abbildung 20 werden die geforderten IT Service Management-Prozesse, ergänzt um das übergeordnete Managementsystem der ISO 20000, dargestellt (vgl. [ISO 20000-1, 2005]).
53
2 IT Service Management
Anforderungen an ein Management System Planung und Implementierung des Service Managements Planen und Implementieren neuer oder geänderter Services Service Delivery Prozesse Capacity Management Service Continuity and Availability Management
Release Prozesse
Service Level Management Service Reporting
Control Prozesse Configuration Management Change Management
Resolution Prozesse Release Management
Abbildung 20:
Information Security Management
Incident Management Problem Management
Budgeting and accounting for IT services
Relationship Prozesse Business Relationship Management Supplier Management
IT Service Management-Prozesse der ISO 20000
Unternehmen, die eine ISO 20000-Zertifizierung anstreben, müssen sämtliche dargestellten Prozesse implementieren. Eine Zertifizierung für einzelne Prozesse ist nicht möglich. Dagegen können einzelne IT-Bereiche zertifiziert werden, sofern in diesen Bereichen sämtliche Prozesse verantwortlich durchgeführt werden.
2.6.4
Die ISO 20000 und Kennzahlen
Innerhalb der ISO 20000 werden keine Kennzahlen für die IT Service Management-Prozesse vorgeben bzw. empfohlen. Die ISO 20000 verlangt allerdings eine Etablierung der Prozessverantwortung und das Prozess-Management (Management Control) für sämtliche IT Service Management-Prozesse. Es ist innerhalb der eigenen Organisation für alle Prozesse der ISO 20000 nachzuweisen: – – – –
54
Kenntnis und Steuerung des Inputs Kenntnis, Nutzung und Interpretation des Outputs Festlegung und Bewertung von Metriken Objektiver Nachweis über die Prozessfunktionalität in Übereinstimmung mit der Norm ISO 20000
2.6 ISO 20000 – Bestimmung, Messung und Prüfung von Prozessverbesserungen (Service Improvement Plan) Die geforderte Kenntnis des Inputs / Outputs sowie die Festlegung und Bewertung von Metriken hat zur Folge, dass für sämtliche IT Service Management-Prozesse Kennzahlen zu definieren sind. Hinzu kommt, dass der kontinuierliche Verbesserungsprozess integraler Bestandteil der ISO 20000 ist. Hierzu wird in der Norm die Plan-DoCheck-Act-Methodik beschrieben (aus [van Bon, 2006], vgl. Abbildung 21). GeschäftsAnforderungen
Management von Services
KundenAnforderungen
Management von Verantwortlichkeiten
Anforderungen neue/geänderte Services
KundenZufriedenheit Neue oder geänderte Services
PLAN Planen des Service Managements
Weitere Prozesse, z.B. Geschäfts-, Lieferanten-, Kundenprozesse
DO
ACT
Service Desk
Implementieren des Service Managements
Kontinuierliche Verbesserung
CHECK
Weitere Teams, z.B. Security, IT-Betrieb
Abbildung 21:
GeschäftsErgebnisse
Überwachung, Messen und Review
Weitere Prozesse, z.B. Geschäfts-, Lieferanten-, Kundenprozesse Zufriedenheit im Team und bei den Beteiligten insgesamt
PDCA-Methodik
Dieser kontinuierliche Verbesserungsprozess ist nicht nur für die übergeordneten Managementaufgaben, sondern auch für die einzelnen IT Service Management-Prozesse zu etablieren. Wie in Kapitel 3 „IT Prozess-Management” ausgeführt, ist die Messung von Prozessen die unabdingbare Voraussetzung dafür, deren Wirksamkeit sicherzustellen (vgl. [van Bon, 2006]): „You cannot control what you cannot measure.”
55
2 IT Service Management Im Rahmen einer ISO 20000 Zertifizierung werden Prozesskennzahlen überprüft.
Im Rahmen einer ISO 20000-Zertifizierung muss dieser Nachweis für sämtliche IT Service Management-Prozesse sowie für das übergeordnete Managementsystem erbracht werden. Dabei wird von der Zertifizierungsorganisation auch überprüft, wie die ermittelten Kennzahlen mit den Zielen korrespondieren und welcher Handlungsbedarf aus den Kennzahlen abgeleitet werden kann. Die Anforderungen und Empfehlungen der ISO 20000 hinsichtlich Monitoring und Reporting von SLAs beschreiben wir in Kapitel 2.8.6 „Monitoring und Reporting von SLAs, OLAs und UCs“.
2.7 COBIT Je bedeutender und kritischer die IT-Unterstützung für die Geschäftsprozesse einer Organisation ist, umso wichtiger ist der Einsatz eines geeigneten Steuerungsinstruments für die Aktivitäten der IT. Vor diesem Hintergrund wurde COBIT (Control Objectives for Information and Related Technology) als Steuerungsmodell der gesamten IT konzipiert. Ursprünglich wurde COBIT von der Information Systems Audit and Control Foundation (ISACF) entwickelt, dem Forschungsinstitut der Information Systems Audit and Control Association (ISACA). Wie der Organisationsname bereits verrät, war COBIT speziell für den Einsatz bei Wirtschaftsprüfern vorgesehen. Aufgrund der Ausrichtung an der Auditierung liegen die Stärken von COBIT naturgemäß in den definierten Steuerungszielen, und insbesondere in der damit verbundenen Überprüfung und Auditierung von IT-Prozessen. Vergleichbar mit den ITIL Best Practices konzentriert sich COBIT darauf, zu dokumentieren „Was“ erreicht werden soll. Dabei wird in COBIT ausdrücklich betont, dass die praktische Ausgestaltung organisationsspezifisch und durch die Integration mit anderen eingesetzten Methoden und Verfahren erfolgen sollte (vgl. [COBIT, 2005]). Häufig wird COBIT im Zusammenhang mit IT Governance genannt. Es existiert keine einheitliche Definition des Begriffs IT Governance. Allgemein werden unter dem Thema IT Governance Grundsätze, Verfahren und Maßnahmen zusammengefasst, die sicherstellen, dass mit Hilfe der eingesetzten IT die Geschäftsziele abgedeckt, die Ressourcen verantwortungsvoll eingesetzt und Risiken angemessen überwacht werden. COBIT, aber auch die ITIL Best Practices, sollen diese Maßgaben der IT Governance sicherzustellen. ITIL Version 3 definiert den Begriff „IT Governance“ und bezieht sich dabei auf eine Definition des IT Governance Instituts (vgl. [OGC, 2007e]):
56
2.7 COBIT IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership, organizational structures and processes that ensure that the organization’s IT sustains and extends the organization’s strategies and objectives. (Board Briefing on IT Governance, 2nd Edition, 2003, IT Governance Institute – ITGI)
2.7.1
Entwicklung von COBIT
Auslöser für die Entwicklung von COBIT war der Wunsch, eine gemeinsame Basis für die Auditierung von IT-Organisationen innerhalb von Prüfungsorganisationen zu schaffen. Hierzu wurden analog zu der Entwicklung von ITIL entsprechende Best Practices von Experten unterschiedlicher Organisationen zusammengeführt und dokumentiert. Die erste Version von COBIT wurde bereits 1996 veröffentlicht. Mit der stärkeren Ausrichtung auf die IT Governance wurde die Weiterentwicklung im Jahr 1999 an das unabhängige IT Governance Institute übertragen. Bei der Entwicklung von Version 4.0 wurden unter anderem die ITIL Best Practices (vgl. [COBIT, 2004a] und [COBIT, 2004b]) und die ISO 17799 (vgl. [ISO 17799, 2005]) berücksichtigt, sodass diese verschiedenen Best Practices besser aufeinander abgestimmt sind. Speziell im Zusammenhang mit der Nachweispflicht des Sarbanes-Oxley Acts (SOX)2 (vgl. [COBIT, 2006]) für an der amerikanischen Börse notierte Unternehmen hat die Nutzung von COBIT zugenommen. Bis zum Jahr 2008 soll die COBIT Version 5 entwickelt werden, wobei strategische Betrachtungen größere Berücksichtigung finden sollen als bisher. So ist unter anderem die Zusammenfassung von IT-Prozessen in einem Bereich (Domain) „IT Governance“ geplant. Die im folgenden Kapitel beschriebenen Prozesse und Kennzahlen basieren auf der COBIT Version 4.0.
2.7.2
Struktur von COBIT
Analog zu ITIL definiert COBIT Best Practices, die sicherstellen, dass die eingesetzte IT die Geschäftsziele unterstützt, dass Ressourcen verantwortungsvoll eingesetzt und Risiken angemessen überwacht werden. 2
Der Sarbanes-Oxley Act wurde benannt nach seinen Verfassern, dem Senator Paul S. Sarbanes und dem Abgeordneten Michael Oxley, die ein Gesetz zur Verschärfung der Rechnungslegungsvorschriften in Folge der Bilanzskandale von Unternehmen wie Enron oder Worldcom erließen.
57
COBIT sind Best Practices.
2 IT Service Management Speziell beim Aufbau eines internen Steuerungssystems in der IT und bei der Messung der Zielerreichung soll COBIT die zuvor genannten Aufgaben der IT Governance unterstützen. COBIT identifiziert und dokumentiert insgesamt 34 Prozesse, die für ein erfolgreiches Management der IT erforderlich sind. Diese 34 IT-Prozesse werden in vier übergeordneten Domains gruppiert, die einen geschlossenen Lebenszyklus (Life Cycle) bilden (vgl. [COBIT, 2005], Abbildung 22): Prozesse - Überwache und bewerte IT-Performance - Überwache und bewerte interne „Controls” - Stelle die angeordnete Compliance sicher - Sorge für IT-Governance
Geschäftsziele
ME: Monitor and Evaluate
Prozesse - Def. u. Manage Service Level - Manage Services von Dritten - Manage Performance und Kapazitäten DS: Deliver - Manage kontinuierliche and Support Services - Stelle Systemsicherheit sicher - Identifiz. u. verrechne Kosten - Schule u. trainiere Anwender - Manage Service Desk und Incidents - Manage die Konfigurationen - Manage Probleme - Manage Daten - Manage technisches Umfeld - Manage den Betrieb Abbildung 22:
58
PO: Plan and Organise
AI: Acquire and Implement
COBIT Prozess-Übersicht
Prozesse - Definiere stragischen IT-Plan - Def. Informationsarchitektur - Def. technolog. Ausrichtung - Definiere die IT-Prozesse, Organisation, Beziehungen - Manage IT-Investitionen - Kommuniziere Ziele und Ausrichtung des Mgmts. - Manage IT-PersonalRessourcen - Manage die Qualität - Beurteile und Manage die Risiken - Manage Projekte
Prozesse - Identifiziere automatisierte Lösungen - Beschaffe und warte Anwendungssoftware - Beschaffe und warte technische Infrastruktur - Ermögliche Betrieb und Nutzung - Beschaffe IT-Ressourcen - Manage Changes - Installiere u. genehmige Lösungen und Changes
2.7 COBIT Für jeden der 34 IT-Prozesse dokumentiert COBIT die jeweilige Best Practice in folgender Form: – – – – – – –
Generische Prozessbeschreibung Prozessziele Wichtigste Aktivitäten Input und Output des Prozesses Mögliche organisatorische Verantwortlichkeiten Wichtigste Metriken Verknüpfte IT-Ziele
Zusätzlich bietet COBIT die Möglichkeit, den Reifegrad dieser Prozesse zu bestimmen. Hierzu sind zu jedem Prozess die Reifegradanforderungen spezifiziert.
2.7.3
Prozess-Management gemäß COBIT
In COBIT sind für jeden Prozess „Control Objectives“ definiert. COBIT versteht Control Objectives als Minimalanforderungen für ein wirkungsvolles Prozess-Management (vgl. [COBIT, 2005]). Control wird häufig mit Kontrolle übersetzt, wodurch die eigentliche Bedeutung der Steuerung bzw. des Managements verfälscht wird. Aus diesem Grund wird im Folgenden der englische Begriff verwendet.
Die Control Objectives dokumentieren das Ziel oder den Zweck eines Prozesses und definieren so die Mindestanforderung, die zu erreichen ist. Pro Prozess existiert immer ein übergeordnetes Control Objective. Die Prozesse sind so bezeichnet, dass sich das übergeordnete Control Objective direkt aus dem Prozessnamen ergibt. Zu jedem Prozess stellt COBIT eingangs das übergeordnete Control Objective gemeinsam mit den wichtigsten Prozesszielen und Metriken dar. Zusätzlich sind anschließend zu jedem Prozess mehrere daraus abgeleitete, detaillierte Control Objectives beschrieben. Diese detaillierten Control Objectives können als Best Practice für das Management des jeweiligen Prozesses angesehen werden. Es sind Minimalanforderungen, die die Zielerreichung sicherstellen. Beispiel „Manage Changes“ (AI6 Manage Changes): Innerhalb des übergeordneten Control Objective wird als Zielsetzung für das „Manage Changes“ gefordert, dass sämtliche Changes an der Infrastruktur und den Applikationen in der produktiven Umgebung nach standardisierten Methoden und Verfahren vorgenommen werden. Zu diesen Changes zählen auch Notfall-Changes und Patches. Jeder Change muss vor der Implementierung aufgezeichnet, bewertet und autorisiert
59
Control Objectives dienen der Steuerung, nicht der Kontrolle
2 IT Service Management sowie nach der Implementierung anhand der geplanten Ergebnisse überprüft werden. Diese Aktivitäten schließen Changes an Verfahren, an Prozessen, an Systemen und an Services ein. Durch diese Aktivitäten sollen die Risiken von Changes minimiert werden, die sich negativ auf die Stabilität und Integrität der Produktivumgebung auswirken. COBIT definiert für den Prozess „Manage Changes“ insgesamt 6 detaillierte Control Objectives. Ein detailliertes Control Objective lautet „Notfall Changes (AI6.3: Emergency Changes). Dieses Control Objective fordert, einen Prozess für die Definition, Aufnahme, Beurteilung und Genehmigung von Notfall-Changes zu erstellen. Dokumentationen und Tests können unter Umständen auch nach der Implementierung erfolgen. Die folgende Abbildung 23 (textuell angelehnt an [COBIT, 2005]) stellt die detaillierten Control Objectives für den Prozess „Manage Changes“ dar.
AI6: Manage Changes
AI6.1: Standard-Changes und Prozeduren AI6.2: Bewertung von Auswirkungen, Priorisierung und Freigabe AI6.3: Notfall-Changes AI6.4: Statusverfolgung und Reporting AI6.5: Abschluss und Dokumentation Abbildung 23:
Zusammenhang zwischen Control Objectives in COBIT
Die COBIT Control Objectives sind den Prozesszielen und Prozessaufgaben der ITIL Best Practices gleichzusetzen.
Durch definierte Prozessaktivitäten soll sichergestellt werden, dass die Control Objectives erreicht werden, was gleichbedeutend damit ist, dass der Prozess die gewünschten Zwecke erfüllt.
60
2.7 COBIT Während ITIL die Leistungsindikatoren der Prozesse pauschal als Key Performance Indikators (KPIs) bezeichnet, betrachtet COBIT die Leistungsmessung der Prozesse als „Performance Messung“ und unterscheidet bei den Metriken zwischen den Key Goal Indicators (KGIs) und den Key Performance Indicators (KPIs). Mit den KGIs wird gemessen, ob ein Prozess seine definierten Ziele erreicht (Effektivität). KGIs sind daher an dem jeweiligen Prozess-Output orientiert. Mit den KPIs wird dagegen die Leistungsfähigkeit eines Prozesses in Relation zu den eingesetzten Ressourcen gemessen (Effizienz). Der Fokus der KPIs liegt also auf einer Messung der prozessinternen Aktivitäten. Die KGIs sind demzufolge die wichtigeren Kennzahlen für die Bewertung eines Prozesses, da sie dem Management aufzeigen, ob ein Prozess die definierten Anforderungen erfüllt. Die KGIs messen die Effektivität eines Prozesses, während die KPIs die Effizienz betrachten. Hauptaugenmerk sollte zunächst auf den KGIs liegen.
COBIT beschreibt aber nicht nur Metriken für die einzelnen IT-Prozesse, sondern legt auch Ziele und Metriken für den gesamten IT-Bereich fest. Dabei werden die Ziele und Metriken von den Geschäftsanforderungen bestimmt. Die Vorgehensweise erfolgt top down. Aus den Geschäftsanforderungen ergeben sich die Ziele für den IT-Bereich. Diese übergeordneten Ziele bestimmen dann die jeweiligen Prozessziele und mit den Prozesskennzahlen (KGIs, KPIs) erfolgt die Messung, ob die Prozesse die Zielsetzungen erfüllen. Prozessziele und Kennzahlen für Prozesse werden top down definiert. Sie ergeben sich aus den IT-Zielen aus den Geschäftsanforderungen.
Die Messgrößen für die übergeordneten IT-Ziele bezeichnet COBIT als „IT Key Goal Indicators“. Da die Prozessziele mit den übergeordneten IT-Zielen korrespondieren bzw. aus ihnen abgeleitet werden, stehen die Prozesskennzahlen mit den IT Key Goal Indicators in einem unmittelbaren Zusammenhang. Bei den Metriken auf Basis der COBIT Best Practices wird so aus dem KGI für die Prozessmessung ein KPI für die Messung der IT-Ziele. COBIT definiert dies als Performance Messung. So ist zum Beispiel „Nacharbeiten an Applikationen, die durch mangelnde Spezifikation hervorgerufen werden“ ein KGI für den Prozess „Manage Changes“. Für das zugeordnete IT-Ziel „Reduziere Mängel und Nacharbeiten bei Lösungen und dem Servicebetrieb“ ist diese Kennzahl dagegen ein KPI.
61
COBIT gliedert die PerformanceMessung in Kriterien für Effektivität und Effizienz
2 IT Service Management COBIT definiert KPIs und KGIs auf Ebene der Prozesse und der IT-Ziele. Dabei wird aus einem KGI der Prozessebene ein KPI auf Ebene der IT-Ziele.
Die Metriken und deren Ebenen stellen sich in COBIT wie folgt dar (hier verdeutlicht am Beispiel „Manage Changes“, vgl. [COBIT, 2005], siehe Abbildung 24):
Ziel der Aktivitäten
Ziel des Prozesses
¬ Definition und Kommunikation der Verfahren für Changes inklusive Notfalländerungen patches ¬…
¬ Führe genehmigte Änderungen an der IT-Infrastruktur und Anwendungen durch ¬ Bewerte die Auswirkungen der Changes auf die ITInfrastruktur, … ¬…
Ziel der IT ¬
¬
¬
Werden gemessen durch
Werden gemessen durch
KPI
¬
¬
% der nicht erfolgreichen Änderungen der Infrastruktur, die durch ungeeignete Änderungsspezifikationen hervorgerufen sind …
Metriken für Prozesse
62
¬
Anzahl der Unterbrechungen oder Datenfehler, die durch ungenaue Spezifikation oder unvollständige Beurteilung der Auswirkungen hervorgerufen ist
KGI
KPI Abbildung 24:
IT Key Goal Indicators treiben
¬ % der aufge-zeichneten und mit automatisierten Tools verfolgten Änderungen ¬ % der Änderungen, die formale Änderungskontrollpro zesse befolgen ¬…
Reagiere auf Geschäftsanforderungen in Übereinstimmung mit der Unternehmensstrategie Reduziere Mängel und Nacharbeit bei Lösungen … …
Werden gemessen durch
Key Goal Indicators
Key Performance Indicators treiben
Messung der Zielerreichung
Definierte Ziele
Metriken für IT-Ziele
Ziele, Prozesse und Metriken in COBIT
KGI
2.7 COBIT Während COBIT Version 3.0 (vgl. [COBIT, 2000]) für die einzelnen Prozesse noch die kritischen Erfolgsfaktoren (Critical Success Factors, CSFs) dokumentierte, werden die CSFs in der Version 4.0 nicht mehr gesondert ausgewiesen. Die CSFs wurden aufgeteilt in die Input-Beschreibung („was benötige ich von anderen“) und in die Aktivitätenbeschreibung („was muss ich in meinem Prozess durchführen“). COBIT enthält darüber hinaus generelle Anforderungen an das Management von Prozessen. Die folgenden Kriterien sind für jeden Prozess zu erfüllen: – Für jeden Prozess ist der Prozess Owner und dessen Verantwortung zu definieren – Jeder Prozess muss wiederholbar sein – Für die Prozesse sind klare Ziele und Vorgaben zu definieren – Die Rollen, Aktivitäten und Verantwortlichkeiten sind zu definieren – Die Prozesse sind hinsichtlich ihrer Zielerreichung zu messen – Die dokumentierten, überprüften, aktuellen und unterzeichneten Grundsätze (Policy), Pläne und Verfahren sind allen Beteiligten zu kommunizieren. Die hier beschriebenen Best Practices von COBIT für das Prozess-Management stellen sich wie folgt dar (siehe Abbildung 25): Anforderung Prozessmanagement
Control Objectives
KPI
KGI
Prozess
Input
Ziele
Output
Aktivitäten
Abbildung 25:
Prozess, Ziele und Kontrollebenen in COBIT
63
2 IT Service Management
2.7.4 Mit der Version 4.0 hat sich COBIT stärker an den ITIL Best Practices ausgerichtet.
Es gilt, die Vorteile von ITIL und COBIT zu nutzen.
COBIT und die IT Service Management-Prozesse
COBIT enthält relevante Prozesse und Metriken für den gesamten IT-Bereich. Die Prozesse, die innerhalb der ITIL Best Practices für das IT Service Management beschrieben sind, können als eine echte Teilmenge des Spektrums der in COBIT dargestellten Prozesse betrachtet werden. Die in COBIT beschriebenen Prozesse stehen somit nicht im Widerspruch zu den ITIL Best Practices. Mit der Veröffentlichung von COBIT Version 4.0 hat sich COBIT den ITIL Best Practices sogar noch weiter angenähert. Während in älteren Versionen von COBIT zum Beispiel das Incident und Problem Management in einem gemeinsamen Prozess beschrieben wurden, hat COBIT Version 4.0 die ITIL Prozessstruktur mit getrennten Prozessen für das Incident und Problem Management übernommen. Es geht daher nicht um den Wettstreit konkurrierender Best Practices, sondern vielmehr darum, wie die verschiedenen Best Practices konvergieren und gewinnbringend genutzt werden können. Die Vorteile und Stärken von ITIL liegen zum einen in der generischen und sehr ausführlichen Beschreibung von Prozessaktivitäten und in den Empfehlungen zur Gestaltung und Umsetzung der Prozesse. Zum anderen erhöht die enge Verbindung zur ISO 20000 die praktische Relevanz des ITIL Ansatzes. Bei der Prozessbeschreibung begnügt sich COBIT hingegen mit einer kurzen Aufzählung von Aktivitäten. Für den Prozess „Manage Changes“ beispielsweise sind die Prozessaktivitäten in fünf Sätzen dokumentiert. COBIT liefert jedoch im Gegensatz zu ITIL, gute Ansätze für die Definition von Metriken, die zum Teil Wirtschaftsprüfern bekannt sind und bei einer Auditierung hilfreich sind. Während die Vorteile von ITIL in den Prozessbeschreibungen und Empfehlungen für die Umsetzung liegen, bietet COBIT gute Ansätze für Metriken. Die Prozesse für das IT Service Management stimmen in den Best Practices grundsätzlich überein, sodass aus beiden Ansätzen die Stärken zusammengeführt werden können.
Eine Analyse der COBIT Best Practice und der IT Service ManagementProzesse auf Basis der ITIL Best Practices zeigt eine große Überstimmung von Prozessen und deren Ziele bzw. Aktivitäten (vgl. [Kurth, 2006]). Die übereinstimmenden IT Service Management-Prozesse zwischen den ITIL Best Practices Version 2 und COBIT wurden seitens des IT Governance Institute analysiert und dokumentiert (vgl. [COBIT, 2007]). Der fol-
64
2.7 COBIT genden Abbildung 26 können diese übereinstimmenden Prozesse für das IT Service Management entnommen werden. Innerhalb des dokumentierten Mappings zwischen ITIL und COBIT wird der Prozess “DS 5 Stelle Systemsicherheit sicher” nicht als übereinstimmend ausgewiesen. Im Rahmen der ISO 20000 ist aber das Security Management als Prozess des IT Service Managements definiert. Daher wurde in der folgenden Darstellung aus [COBIT, 2007] (Abbildung 26) der Prozess “DS 5 Stelle Systemsicherheit sicher” ebenfalls hervorgehoben. Prozesse - Überwache und bewerte IT-Performance - Überwache und bewerte interne „Controls” - Stelle die angeordnete Compliance sicher - Sorge für IT-Governance
Geschäftsziele
ME: Monitor and Evaluate
Prozesse - Def. u. Manage Service Level - Manage Services von Dritten - Manage Performance und Kapazitäten DS: Deliver - Manage kontinuierand Support liche Services - Stelle Systemsicherheit sicher - Identifiz. u. verrechne Kosten - Schule u. trainiere Anwender - Manage Service Desk und Incidents - Manage die Konfigurationen - Manage Probleme - Manage Daten - Manage technisches Umfeld - Manage den Betrieb Abbildung 26:
PO: Plan and Organise
AI: Acquire and Implement
Prozesse - Definiere stragischen IT-Plan - Def. Informationsarchitektur - Def. technolog. Ausrichtung - Definiere die IT-Prozesse, Organisation, Beziehungen - Manage IT-Investitionen - Kommuniziere Ziele und Ausrichtung des Mgmts. - Manage IT-PersonalRessourcen - Manage die Qualität - Beurteile und Manage die Risiken - Manage Projekte
Prozesse - Identifiziere automatisierte Lösungen - Beschaffe und warte Anwendungssoftware - Beschaffe und warte technische Infrastruktur - Ermögliche Betrieb und Nutzung - Beschaffe IT-Ressourcen - Manage Changes - Installiere u. genehmige Lösungen und Changes
Mapping der Prozesse in ITIL Version 2 und COBIT
65
2 IT Service Management Mit der ITIL Version 3 wird eine noch größere Abdeckung erreicht. Ein entsprechendes Mapping ist aber zurzeit noch nicht publiziert.
2.7.5
Metriken für IT Service Management-Prozesse
Zu jedem Prozess sind in Klammern die Originalbezeichnung, die übergeordnete Domain, sowie die Nummer innerhalb der Domain dargestellt. Die Bezeichnungen der Domains lauten folgendermaßen: -
Plan and Organise (PO)
-
Acquire and Implement (AI)
-
Deliver and Support (DS)
-
Monitor and Evaluate (ME).
Aufgrund des generischen Ansatzes werden in COBIT zweckmäßige KGIs und KPIs aufgezeigt. Die konkrete Ausgestaltung der Metriken mit detaillierten Spezifikationen und die Bedeutung für das Prozess-Management sind dagegen nicht in COBIT dokumentiert. Diese Festlegungen und Ausgestaltungen sind Aufgabe des Prozessdesigns. In Kapitel 5 sind die Best Practices auf der Basis von ITIL, COBIT, ISO 20000 und unserer Projekterfahrungen dokumentiert. Für die Definition von Metriken hat COBIT pragmatische Anforderungen: – Es ist ein gutes Verhältnis zwischen Aussagekraft und Aufwand zur Generierung der Messdaten sicherzustellen. – Es ist besser, wenige gute Metriken zu etablieren, als umfangreiche Kennzahlen mit einer niedrigen Qualität. – Die Kennzahlen sollten extern vergleichbar sein. – Die Kennzahlen sollten intern vergleichbar sein Im folgenden Abschnitt werden die in COBIT dokumentierten Prozessziele und die daraus resultierenden KPIs und KGIs ausgewiesen (vgl. [COBIT, 2005]).
2.7.6
COBIT Metriken für IT Service Management-Prozesse
Manage Service Desk und Incidents (Manage Service Desk and Incidents: DS8) Zielsetzung dieses Prozesses ist die wirkungsvolle Nutzung der IT-Systeme durch die Lösung und Analyse von Anwenderanfragen und Incidents. Zur Zielerreichung ist die Etablierung eines Service Desks und eines Incident Managements notwendig. Die in COBIT dokumentierten KPIs sind:
66
2.7 COBIT – Anzahl der pro Mitarbeiter im Service Desk stündlich bearbeiteten Anrufe (Calls) – Anteil der Incidents, die einen Vor-Ort-Support benötigen – Arbeitsrückstand ungelöster Anfragen Die in COBIT dokumentierten KGIs sind: – Durchschnittliche Bearbeitungszeit nach Gewichtung (severity) – Anteil wieder geöffneter (reopen) Incidents – Durchschnittliche Reaktionszeit Die in COBIT dokumentierten IT Key Goal Indicators sind: – Anwenderzufriedenheit mit dem Service Desk – Anteil der innerhalb der vereinbarten Zeit gelösten Incidents
Manage Probleme (Manage Problems: DS10) Das Ziel des Problem Managements ist die Gewährleistung der Anwenderzufriedenheit und die Reduzierung von Mängeln an Services. Dies soll durch die Ermittlung der zugrunde liegenden Ursachen für alle wichtigen Probleme und durch die Definition von Lösungen für die identifizierten Probleme erreicht werden. Die in COBIT dokumentierten KPIs sind: – Durchschnittliche Dauer zwischen Problemerfassung und der Identifizierung der Ursache – Anteil der Probleme, für die eine Ursachenanalyse betrieben wurde – Häufigkeit der Berichte oder Aktualisierung über anhaltende Probleme, basierend auf deren Gewichtung (severity) Die in COBIT dokumentierten KGIs sind: – Anteil der Probleme, die innerhalb der vorgeschriebenen Zeit gelöst wurden – Mittelwert und Standardabweichung der Zeitdauer zwischen der Identifizierung und der Problemlösung – Mittelwert und Standardabweichung der Zeitdauer zwischen der Problemlösung und dem Abschluss Die in COBIT dokumentierten IT Key Goal Indicators sind: – Anzahl der wiederkehrenden Probleme mit Auswirkung auf das Business – Anzahl der Geschäftsunterbrechungen aufgrund operationeller Probleme
67
2 IT Service Management
Manage die Konfigurationen (Manage the configuration: DS9) Das Configuration Management hat die Optimierung der IT-Infrastruktur, der Ressourcen und Kapazitäten sowie den Nachweis der IT-Anlagen zum Ziel. Basis hierfür ist die fehlerfreie und vollständige Erfassung und Speicherung der Konfigurationsattribute der IT-Anlagen und der Baselines, sowie die Prüfung, ob sie mit den tatsächlichen Konfigurationen übereinstimmen. Die in COBIT dokumentierten KPIs sind: – Anzahl der Abweichungen in Bezug auf unvollständige oder fehlende Konfigurationsinformationen – Durchschnittliche Zeitdauer zwischen der Identifizierung einer Abweichung und deren Korrektur Die in COBIT dokumentierten KGIs sind: – Anzahl der Abweichungen zwischen den gespeicherten und tatsächlichen Konfigurationsdaten – Anteil der erworbenen Lizenzen und der nicht in der Datenbank gespeicherten Lizenzen Die in COBIT dokumentierten IT Key Goal Indicators sind: – Anteil der Compliance Probleme aufgrund unzulässiger Konfigurationen von IT-Anlagen
Manage Changes (Manage Changes: AI6) Das Ziel des „Manage Changes“ ist, Änderungen innerhalb der Produktivumgebung auf eine formell gesteuerte Art und Weise durchzuführen. Zu Changes zählen neben Änderungen an der Infrastruktur und an bestehenden Anwendungen auch Notfall-Changes und Patches. Die in COBIT dokumentierten KPIs sind: – Verhältnis zwischen den akzeptierten und den abgelehnten RFCs – Anzahl und Art der Notfall-Changes – Anzahl und Art der Patches Die in COBIT dokumentierten KGIs sind: – Anteil der Notfall-Changes am gesamten Change-Aufkommen – Reduzierter Aufwand und Zeitaufwand zur Durchführung von Changes – Anteil nicht erfolgreicher Changes, aufgrund von untauglichen Change-Spezifkationen Die in COBIT dokumentierten IT Key Goal Indicators sind:
68
2.7 COBIT – Anteil der Serviceunterbrechungen durch ungenaue Spezifikationen oder fehlerhafte Beurteilung der Auswirkungen
Installiere und genehmige Lösungen und Changes (Install and accredit solutions and changes: AI7) Dieser Prozess hat das Ziel, sicherzustellen, dass neue oder geänderte Systeme nach der Installation ohne größere Probleme betrieben werden können. Dieses Ziel soll unter anderem durch eine Releaseplanung und die Etablierung von Testmethoden erreicht werden. Die in COBIT dokumentierten KPIs sind: – Anteil der Fehler, die während des Qualitätsmanagement-Reviews bei der Installations- und Zulassungsprüfung gefunden werden – Anzahl der beim Post-Implementation-Review erkannten Verbesserungen – Anteil der Projekte mit dokumentierten und genehmigten Testplänen Die in COBIT dokumentierten KGIs sind: – Anteil der Installations- und Zulassungsfehler, die während Audits gefunden werden – Nacharbeiten nach der Implementierung, die auf ungenügende Akzeptanztests zurückzuführen sind – Ausfallzeiten der Anwendung, die durch ungenügende Tests hervorgerufen werden Die in COBIT dokumentierten IT Key Goal Indicators sind: – Anteil der Interessenvertreter, die mit der Daten-Integrität der neuen Systeme zufrieden sind
Definiere und Manage Service Level (Define and manage service levels: DS1) Das Service Level Management hat die Ausrichtung der wesentlichen IT Services an der Geschäftsstrategie zum Ziel. Hierzu sind Serviceanforderungen zu identifizieren, die Service Level sind zu vereinbaren und deren Einhaltung ist zu überwachen. Die in COBIT dokumentierten KPIs sind: – Anzahl der jährlichen SLA-Reviews mit dem Business – Anteil der berichteten Service Level – Anteil der automatisch berechneten Service Level Die in COBIT dokumentierten KGIs sind: – Anzahl der erbrachten Services, die nicht im Katalog enthalten sind
69
2 IT Service Management – Anteil der eingehaltenen Service Level – Anteil der gemessenen Service Level Die in COBIT dokumentierten IT Key Goal Indicators sind: – Anteil der Interessenvertreter, die mit den erreichten Service Level zufrieden sind
Identifiziere und verrechne Kosten (Identify and allocate cost: DS6) Dieser Prozess soll die Transparenz und das Verstehen von IT-Kosten gewährleisten und auf der Basis dieser Informationen eine Steigerung der Kosteneffizienz durch kostenbewusste Verwendung der IT Services erreichen. Hierzu sind die IT-Kosten vollständig und genau zu erfassen, ein faires Verrechnungssystem ist zu vereinbaren und über die IT-Kosten und die IT-Nutzung ist rechtzeitig zu berichten. Die in COBIT dokumentierten KPIs sind: – Anteil der Kosten, die automatisch / manuell verrechnet werden – Häufigkeit der Überprüfung des Verrechnungsmodells Die in COBIT dokumentierten KGIs sind: – Anteil der Abweichungen zwischen Budget, vorhergesagten und aktuellen Kosten – Anteil der Gesamtkosten, die nach dem vereinbarten Kostenmodell verrechnet wurden – Anteil der Kosten die mit dem Business umstritten sind Die in COBIT dokumentierten IT Key Goal Indicators sind: – Anteil der vom Business akzeptierten, verrechneten Services – Kundenzufriedenheit mit dem Verrechnungsmodell für IT Services
Manage die IT-Investitionen (Manage the IT-Investment PO5) Innerhalb dieses Prozesses ist ein System zum Management der Investitionsplanung zu etablieren und zu betreiben. Dieses Managementsystem umfasst die Betrachtung der Kosten, des Nutzens und der Priorisierung von Investitionen innerhalb des geplanten Budgets. Die in COBIT dokumentierten KPIs sind: – Prozent der Projekte mit einem definierten Nutzen – Prozent der Projekte, für die ein Review nach dem Abschluss durchgeführt werden Die in COBIT dokumentierten KGIs sind: – Anzahl von Budgetabweichungen
70
2.7 COBIT – Prozentuale Darstellung der Budgetabweichung gegenüber dem Gesamtbudget – Prozentualer Anteil der IT-Investitionen, die den zuvor definierten Nutzen erzielen Die in COBIT dokumentierten IT Key Goal Indicators sind: – Prozentualer Anteil der IT-Investitionen, die den zuvor definierten Geschäftsnutzen erzielen oder übertreffen – Prozent der IT-Werttreiber, abgebildet auf die Business-Werttreiber
Manage Performance und Kapazitäten (Manage performance and capacity DS3) Das Ziel des Capacity Managements liegt in der Performanceoptimierung der IT-Infrastruktur, der Ressourcen und Kapazitäten in Übereinstimmung mit den Geschäftsanforderungen. Hierzu sind die im SLA vereinbarten Antwortzeiten einzuhalten, die Ausfallzeiten zu minimieren und eine kontinuierliche Verbesserung der IT-Perfomance und Kapazitäten durch Monitoring und Messungen sicherzustellen. Die in COBIT dokumentierten KPIs sind: – Häufigkeit der Performance- und Kapazitätsprognosen – Anteil der Anlagen, die in Kapazitäts-Reviews betrachtet werden – Anteil der Anlagen, die durch zentrale Systeme überwacht werden Die in COBIT dokumentierten KGIs sind: – Lastspitzen und Auslastungsrate – Anteil der Spitzenlastzeiten, die über die Zielauslastung hinausgehen – Anteil der Antwortzeiten, die nicht den SLAs entsprechen Die in COBIT dokumentierten IT Key Goal Indicators sind: – Anzahl der Ausfallstunden pro Anwender und Monat aufgrund unzureichender Kapazitätsplanung
Manage kontinuierliche Services (Ensure continuous service: DS4) Dieser Prozess soll sicherstellen, dass mögliche Ausfälle der IT Services minimale Auswirkungen auf die Geschäftsprozesse haben. Die in COBIT dokumentierten KPIs sind: – Zeitdauer zwischen den Tests aller Bestandteile des IT-Kontinuitätsplans – Häufigkeit der Reviews des IT-Kontinuitätsplans – Anteil der kritischen IT-Komponenten mit automatisierter Verfügbarkeitsüberwachung
71
2 IT Service Management Die in COBIT dokumentierten KGIs sind: – Anteil der SLAs, die die Verfügbarkeitszeit erfüllen – Anteil der erfolgreichen Tests der IT-Kontinuitätspläne – Häufigkeit der Serviceunterbrechung bei kritischen Systemen Die in COBIT dokumentierten IT Key Goal Indicators sind: – Anzahl der Ausfallstunden pro Anwender und Monat aufgrund ungeplanter Unterbrechungen
Stelle Systemsicherheit sicher (Ensure system security: DS5) Das Security Management hat die Aufrechterhaltung der Integrität von Informationssystemen und die Minimierung der Auswirkungen von Sicherheitsschwachstellen und Security Incidents zum Ziel. Die in COBIT dokumentierten KPIs sind: – Häufigkeit und Art der gemeldeten Security Incidents – Anzahl und Art von veralteten Benutzerkonten – Anzahl der Zugriffsberechtigungen, die autorisiert, widerrufen, gelöscht oder geändert wurden Die in COBIT dokumentierten KGIs sind: – Anzahl und Art der vermuteten und tatsächlichen Zugangsverstöße – Anzahl und Art von verhinderten bösartigen Codes – Anteil der Anwender, die die Password-Standards nicht einhalten Die in COBIT dokumentierten IT Key Goal Indicators sind: – Anzahl der Incidents mit Auswirkungen auf das Business
2.8 Monitoring und Reporting von SLAs Die drei Hauptziele des IT Service Managements bestehen darin, die IT Services auf die gegenwärtigen und zukünftigen Anforderungen des Unternehmens und seiner Kunden auszurichten, die Qualität der erbrachten IT Services zu verbessern sowie die langfristigen Kosten der ServiceTätigkeit zu reduzieren (vgl. [itSMF, 2001]). Um diese Ziele zu erreichen, haben sich international anerkannte Best Practices für IT-Prozesse durchgesetzt. Diese sind in ITIL und COBIT dokumentiert. Es handelt sich dabei jedoch nicht um die Best Practices einzelner isolierter Prozesse, sondern vielmehr um einen integrierten Prozessansatz. Die dokumentierten Prozesse sind über definierte Schnittstellen und gemeinsame Dokumente und Daten miteinander verknüpft. Der Output eines Prozesses dient als Input für einen anderen Prozess. Dieses Grundprinzip kann anhand der Prozesse des Problem und Change Managements verdeutlicht
72
2.8 Monitoring und Reporting von SLAs werden: Werden innerhalb des Problem Managements notwendige Maßnahmen zur Behebung von Problemen bzw. Fehlern identifiziert, so erstellt der Problem Management-Prozess als Output einen RFC (Request for Change), der dem Change Management als Input dient und von diesem Prozess weiter bearbeitet wird. Die volle Leistungsfähigkeit der ITIL und COBIT Best Practices ergibt sich erst dann, wenn sämtliche Prozesse umgesetzt werden. Daher verlangt die ISO 20000 auch die nachweisliche Implementierung aller dokumentierten Prozesse mit ihren in der ISO 20000-1 definierten Mindestanforderungen.
In der ersten Version von ITIL, die Ende der 80er Jahre herausgegeben wurde, erfolgte die Betrachtung der Best Practices für das IT Service Management noch aus IT-Sicht. Diese Sichtweise wandelte sich mit der Herausgabe der ITIL Version 2, bei der sich die ITIL Best Practices auf die Ausrichtung des IT Service Managements und die Gestaltung der entsprechenden Prozesse im Hinblick auf die bestmögliche Unterstützung der Geschäftsziele einer Organisation konzentrieren. Mit der vorliegenden Version 3 wird diese Entwicklung konsequent in Richtung der Business Integration und des Service Lifecycle fortgesetzt. Die Prozesse des IT Service Managements stellen mit ihren jeweiligen Prozesszielen und ihrer unternehmensspezifischen Ausrichtung sicher, dass die geschäftlich notwendigen IT Services wirkungsvoll erbracht werden und so die Ziele des IT Service Managements erreicht werden können. Das Hauptaugenmerk der Kunden liegt auf der Lieferung der geschäftlich notwendigen und mit der IT-Organisation vereinbarten IT Services. Die Betrachtung der damit verbundenen IT-Prozesse ist für den Kunden sekundär. Sie ist primär an deren Output im Rahmen der gelieferten IT Services und der Sicherstellung von internen und externen Anforderungen (Compliance) orientiert. Demzufolge ist die Definition der IT Services und deren Sicherstellung eine Schlüsselfunktion für eine professionelle IT-Organisation. Technologische Lösungen können ausgetauscht und ersetzt werden. Aber das Verständnis der Business-Anforderungen, die professionelle Ausrichtung der IT Services an die Business-Anforderungen und deren Sicherstellung differenziert eine professionelle IT-Organisation von Technologiebetreibern.
2.8.1
Definition und Interpretation des Begriffs „IT Service“
Bedingt durch die historische Entwicklung innerhalb der IT konzentrierte sich die IT-Organisation zunächst auf die Bereitstellung von technischen Systemen. Diese Systeme, zum Beispiel eine auf dem Host implementierte
73
Der Fokus der Kunden liegt auf den IT Services.
2 IT Service Management Applikation, unterstützten die Durchführung geschäftlicher Aktivitäten. Mit der steigenden Komplexität der Applikationen und deren zunehmender Bedeutung für einen reibungslosen Geschäftsprozess wurde offensichtlich, dass die ausschließliche Betrachtung des technischen Betriebs eines Systems nicht mehr ausreichend ist. Hieraus hat sich zum Beispiel der Aufbau eines Service Desk als Unterstützungssystem für den Anwender entwickelt. Mit der Weiterentwicklung innerhalb der InformationsTechnologie greifen eine Vielzahl von einzelnen Systemen ineinander, um die Durchführung von Geschäftsprozessen des Kunden zu gewährleisten. Damit wandelte sich auch die Sicht des Kunden auf die IT. Der Kunde sieht nur den Output der miteinander in Verbindung stehenden Systeme. Hierzu führt ITIL aus „Bei der Erbringung von Services steht die Wahrnehmung des Kunden im Mittelpunkt“ (vgl. [OGC, 2005a]). Die heutige Interpretation des IT Service-Begriffes konzentriert sich demzufolge auf die konsequente Ausrichtung der IT und ihrer Prozesse auf die Unterstützung der Geschäftsprozesse eines Unternehmens. ITIL, ISO 20000 und COBIT stellen ausdrücklich heraus, dass die beschriebenen Prozesse die Geschäftsziele der Organisation und die Kundenanforderungen zu unterstützen haben. So betont die ISO 20000 in der Einleitung: „ISO 20000 promotes the adoption of an integrated process approach to effectively deliver managed services to meet the business and customer requirements.” (vgl. [ISO 20000-1, 2005]). ITIL, ISO 20000 und COBIT stellen heraus, dass die dokumentierten Prozesse primär der Bereitstellung von IT Services bzw. der notwendigen IT-Unterstützung zur Erfüllung der Geschäfts- und Kundenanforderungen dienen. Von der System- zur ServiceOrientierung.
Die IT ist in vielen Branchen und Bereichen zu einem wichtigen, teilweise zum wichtigsten Produktionsfaktor geworden. Zum Teil laufen heute einzelne Geschäftsprozesse vollständig IT-gestützt ab und benötigen keinerlei manuelle Eingriffe mehr, wie zum Beispiel das „Online-Banking“. Um sich der Bedeutung der IT für die geschäftlichen Tätigkeiten eines Unternehmens bewusst zu werden, ist die Frage „was würde beim Ausfall der IT-Systeme geschehen“ sehr hilfreich. Damit die geschäftlichen Aktivitäten entsprechend unterstützt werden können, ist in der Regel das Zusammenwirken verschiedener IT-Systeme notwendig. In IT-Organisation herrscht heute aber zum Teil noch eine technologische Betrachtung vor. Systemspezialisten fokussieren sich auf „ihr System“. Dieses System stellt aber nur ein Rädchen im Getriebe dar und die Funktionalität des Gesamtsystems ist für die Unterstützung der Geschäftsprozess entscheidend. Die IT-Organisation muss erkennen, dass der Systembetrieb keinen Selbstzweck darstellt, sondern zweckdienliche Geschäftsprozesse mit der notwendigen IT-Unterstützung für den Unternehmenserfolg entscheidend sind.
74
2.8 Monitoring und Reporting von SLAs Für das Selbstverständnis der IT ist es wichtig zu erkennen, dass die Bereitstellung der IT Services in erster Linie der Unterstützung der betrieblichen Primäraktivitäten bzw. der Kerngeschäftsprozesse dient und damit über den Erfolg eines Unternehmens entscheidet.
So führt Porter3 in seinem Wertschöpfungsdiagramm aus, dass die primären Aktivitäten eines Unternehmens die Kundenanforderungen bedienen und die Wertschöpfung eines Unternehmens sicherstellen. Die unterstützenden Prozesse oder sekundären Aktivitäten unterstützen die Durchführung der primären Aktivitäten bzw. Geschäftsprozesse. Die IT gehört in der Regel zu den unterstützenden Aktivitäten und muss demzufolge in erster Linie die übergeordneten Wertschöpfungsprozesse sicherstellen (vgl. Abbildung 27). IT Service Management Unternehmensinfrastruktur
IT-Service
Personalwirtschaft
IT-Service
… IT-Service
IT-Service
Beschaffung
Produktion
= Primäre Prozesse / Aktivitäten
Wertschöpfung
IT-Service
IT-Service
Marketing & Vertrieb
KundenService
= sekundäre Prozesse / Aktivitäten = geforderte und gelieferte IT-Unterstützung (IT-Service)
Abbildung 27:
3
Wertschöpfungskette nach Porter
Michael E. Porter, Professor für Wirtschaftswissenschaften an der Harvard Business School und einer der führenden Ökonomen auf dem Gebiet des strategischen Managements.
75
2 IT Service Management ITIL stellt den IT Service in direkten Bezug zum Geschäftsprozess
Aus Sicht der IT gibt es eine Vielzahl von unterschiedlichen Business- und Kundenanforderungen, die aus den primären und sekundären Prozessen bzw. Aktivitäten resultieren. Die erforderliche IT-Unterstützung für die Geschäftsprozesse definiert ITIL Version 2 prägnant als einen IT Service; der IT Service ist „ein oder mehrere IT-Systeme, die einen Geschäftsprozess ermöglichen“ (vgl. [OGC, 2006b]). Mit ITIL Version 3 wird der Kundenbezug des Service noch stärker herausgestellt (vgl. [OGC, 2007a]): IT Service Management ist eine Menge von spezialisierten organisatorischen Fähigkeiten, um den Kunden einen Nutzen für das Business in Form von IT Services zu liefern.
Innerhalb der IT wird der Begriff des Systems häufig mit einem technischen System gleichgesetzt. Ein System ist vielmehr „ein integrierter Komplex, der eine oder mehrere Komponenten, zum Beispiel Prozesse, Hardware, Software, Einrichtungen und Personen umfasst und das Erfüllen bzw. Erreichen einer erklärten Anforderung bzw. Zielsetzung ermöglicht“ (vgl. [OGC, 2006b]). Hiermit wird deutlich, dass der IT Service aus ein oder mehrere Prozessen, Hardware, Software, Einrichtungen und Personen besteht, die einen Geschäftsprozess ermöglichen. Innerhalb des Glossars wird diese Gesamtsicht zum IT Service nochmals deutlich herausgestellt; „Die Erbringungskriterien der IT Service Organisation aus Sicht der Kunden, die Services, umfassen nicht nur die Bereitstellung von Computerressourcen zur Verwendung durch die Kunden“ (vgl. [OGC, 2006b]). Ein IT Service ergibt sich aus der Sicht des Kunden und unterstützt die optimale Durchführung von Geschäftsprozessen. Dazu ist ein bestmögliches Zusammenwirken von Personen, Produkten, Prozessen und Partnern erforderlich.
Diese Anforderungen an einen IT Service unterscheiden sich in Abhängigkeit der Bedeutung der Geschäftsprozesse für das Unternehmen stark in ihrer Art der Leistung und Qualität. Das Kundeninteresse liegt primär in der notwendigen Unterstützung der Geschäftsprozesse. Damit nimmt der Kunde die IT-Organisation mit den geleisteten IT Services als maßgeblichen Output wahr. Die damit verbundenen IT Service Management-Prozesse sind in der Regel eine interne Betrachtung der IT-Organisation. Die Kunden- und Geschäftssicht ist bei der Definition der notwendigen IT-Unterstützung entscheidend. Die geleisteten IT Services sind der maßgebliche Output und bestimmen die Wahrnehmung der IT.
76
2.8 Monitoring und Reporting von SLAs
2.8.2
Service Level Agreements
Das Service Level Management hat die Kundeanforderungen an einen IT Service aufzunehmen. Diese Anforderungen werden in Service Level Requirements (SLRs, Service Level Anforderungen) dokumentiert. Auf der Basis dieser Anforderungen wird vom IT Service Provider die Möglichkeit der Leistungserbringung geprüft. Mit dem Kunden werden daraufhin Verhandlungen geführt und es kommt zu einem iterativen Prozess, in dem die Kundenanforderungen auf die zu erbringende Servicequalität abgestimmt werden. Letztendlich wird zwischen dem Kunden und dem IT Service Provider eine Vereinbarung getroffen und in einem Service Level Agreement (SLA) dokumentiert. Die ITIL Best Practices definieren einen SLA als „eine schriftliche Vereinbarung zwischen einem Service-Anbieter und einem Kunden, in der vereinbarte Service Level für einen Service dokumentiert sind.“ (vgl. [OGC, 2006b] und [OGC, 2007b]): Ein IT Service stellt die notwendige, ganzheitliche IT-Unterstützung für einen Geschäftsprozess des internen oder externen Kunden sicher. Die Qualität eines IT Service und somit das Maß der gewünschten IT-Unterstützung des Geschäftsprozesses werden in einem SLA (Service Level Agreement) dokumentiert.
Zur Absicherung des SLAs werden intern Operational Level Agreements (OLAs) und extern Lieferantenverträge (Underpinning Contracts, UCs) abgeschlossen. Die Struktur und die möglichen Inhalte von SLA, OLA und UC werden im nächsten Kapitel erläutert. Sowohl in ITIL, als auch in COBIT wird die Aufgabe der Erstellung und Pflege der erforderlichen Dokumente, bestehend aus Service Katalog, Service Level Agreement (SLA), Operational Level Agreement (OLA) und Underpinning Contract (UC) dem Prozess des Service Level Managements zugewiesen. COBIT nimmt bei der Definition von Control Objectives und Leistungsindikatoren (KGI, KPI) Bezug auf den Service Katalog, die SLAs, die OLAs und die UCs. Aber: Anforderungen an deren inhaltliche Gestaltung sind in COBIT nicht dokumentiert. So weist lediglich das Control Objective „DS1.3 Service Level Agreement“ darauf hin, dass die Rahmenbedingungen für Verfügbarkeit, Performance, Verlässlichkeit, Wachstumsfähigkeit, Support-Level, Kontinuitätsplanung, Sicherheit und Nachfrage im SLA zu berücksichtigen sind. Dagegen umfassen ITIL und die ISO 20000 die Best Practices zu den notwendigen Inhalten von SLAs. Diese Inhalte werden in Kapitel 2.8.5 beschrieben.
77
ITIL und ISO 20000 enthalten Best Practices für die Inhalte von SLAs.
2 IT Service Management Die ITIL Best Practices und die ISO 20000-2 enthalten Empfehlungen für die inhaltliche Gestaltung der SLAs. Weiterhin sind Anforderungen an deren Messung sowie an das Reporting beschrieben.
2.8.3
Das Zusammenwirken von SLAs, OLAs und UCs
In einem SLA werden die Geschäftsanforderungen an einen IT Service zwischen dem Kunden und dem IT Service Provider vereinbart. Der Kunde ist der Auftraggeber des IT Service. Der IT-Provider ist der für die Bereitstellung des IT Service verantwortliche Auftragnehmer. Die ISO 20000 definiert ein Service Level Agreement (SLA) als „written agreement between a service provider and a customer that documents services and agreed service levels”.
Um die mit dem Kunden vereinbarte IT Servicequalität dauerhaft sicherstellen zu können, bedient sich das Service Level Management weiterer Absicherungsverträge wie OLAs (mit internen Erbringungseinheiten) und UCs (mit externen Lieferanten). Die Summe der vereinbarten OLAs und UCs sichern die SLAs. Die folgende Abbildung 28 dient der Erläuterung und zeigt, wie zum Beispiel für einen IT Service „Gehaltsabrechnung“ die Anforderungen an die Verfügbarkeit in einzelne OLAs und UCs einfließen könnten.
78
2.8 Monitoring und Reporting von SLAs SLA „Gehaltsabrechnung“
OLA „HR / Server“
Leistungsgegenstand: „Beschreibung der Funktionalität des IT-Service“
Leistungsgegenstand: „Bereitstellung Server für Modul SAP-HR“
Leistungsumfang: SAP-HR inkl. Lizenzen für 25 Benutzer, Support und Anpassungen“
Verfügbarkeit: 99,8% p.W.
Servicezeit: gem. Betriebskalender 7:00 – 18:00 Uhr Verfügbarkeit: 96% p.W. am Arbeitsplatz Kontinuität: max. 2 Stunden Totalausfall Lösungszeiten Prio 1: 80% in 2 Stunden Abbildung 28:
2.8.4
OLA „HR / LAN“ Leistungsgegenstand: „Bereitstellung LAN“ Verfügbarkeit: 99,6% p.W. UC „HR / WAN“ Leistungsgegenstand: „Anbindung Niederlassung X“ Verfügbarkeit: 99,4% p.W.
Zusammenhang zwischen SLAs, OLAs und UCs
Der Aufbau von SLAs
Es ist wichtig zu betonen, dass die Inhalte und die Struktur der IT Services und der damit verbundenen SLAs unternehmensspezifisch sind. Es gibt nicht „den SLA“, der für jede Organisation passend ist. Dies vorzugeben ist nicht die Intention der ITIL Best Practices. ITIL stellt ausdrücklich heraus: „... es ist nicht leicht, generelle Aussagen zu machen, da jede Situation einzigartig ist.“ (vgl. [OGC, 2006b]).
Die Struktur der SLAs ist unternehmens spezifisch.
Vor dem Aufbau und der inhaltlichen Gestaltung von SLAs gilt es zunächst, die bestehenden Kundenanforderungen aufzunehmen sowie das existierende Leistungsportfolio, also die bestehenden IT Services zu erfassen und zu strukturieren (vgl. [Victor et al., 2005]). Erst im Anschluss, das heißt wenn die Strukturierung der IT Services vorliegt, sollten die einzelnen SLAs mit den Kunden vereinbart werden. IT Services entsprechen der Sicht der Kunden bzw. der zu unterstützenden Geschäftsprozesse auf die notwendige IT-Unterstützung. IT Services müssen sich daher über (bestehende) organisatorische und systemtechnische Grenzen innerhalb der IT-Organisation hinwegsetzen.
79
IT Services werden System- und organisationsübergreifend erbracht.
2 IT Service Management Die ISO 20000-2 dokumentiert die Vorgehensweise aus Kunden- und Geschäftssicht wie folgt: “the customer’s business needs and budget should be the defining force for the content, structure and targets of the SLA.” Von entscheidender Bedeutung für die Definition der IT Services und für die Vereinbarung von SLAs, OLAs und UCs ist die Serviceorientierung eines IT Service im Sinne der ITIL-Definition. Die ISO 20000-2 empfiehlt darüber hinaus, dass die Kundenanforderungen nicht nur die Ziele und den Inhalt, sondern auch die Struktur der SLAs bestimmen sollten.
Im Einklang mit der ISO 20000 empfiehlt ITIL vor der Vereinbarung von SLAs die notwendige SLA-Struktur zu planen. Hierzu wird in ITIL eine serviceorientierte und kundenbasierte und eine mehrschichtige SLAStruktur beschrieben. SLA-Strukturen reduzieren Aufwendungen.
Um die Aufwendungen für das Monitoring und Reporting zu reduzieren, bietet eine mehrschichtige SLA-Struktur viele Vorteile (siehe Abbildung 29). Hinzu kommen weitere Vorteile wie zum Beispiel geringere Aufwendungen für die Aktualisierung und die Reduzierung von Inkonsistenzen.
- Unternehmens-Ebene: -
Unternehmensweite SLAVereinbarungen Allgemeine Definitionen und Regelungen zum Monitoring
- Kunden-Ebene: -
Kundenbezogene SLAVereinbarungen
- Unterstes Level: -
Servicebezogene SLAVereinbarungen Ausgestaltung des auf Unternehmens-Ebene definierten Monitoring
Abbildung 29:
Beispiel für mehrschichtige SLAs
Mehrschichtige SLAs bilden ein hierarchisches System. Auf der obersten Ebene werden allgemeine Regelungen getroffen, die für das gesamte Un-
80
2.8 Monitoring und Reporting von SLAs ternehmen gültig sind. Damit werden Redundanzen und Widersprüche vermieden, wie zum Beispiel mehrfache, unterschiedliche Definitionen von Verfügbarkeit. In der nächsten Ebene der SLA-Struktur können dann zum Beispiel übergreifende Vereinbarungen mit den einzelnen Kunden beschrieben werden, um dann auf der dritten Ebene die einzelnen IT Services zu vereinbaren. Bei mehrschichtigen SLAs können auf der obersten Ebene, der Unternehmens-Ebene, allgemeine Regelungen für das Monitoring und Reporting der IT Services vereinbart werden. So kann zum Beispiel beschrieben werden, wie generell die Verfügbarkeit von Applikationen gemessen wird. Zusätzlich kann auch das einzusetzende Messwerkzeug definiert werden. Auf Ebene der einzelnen IT Services sind dann nur noch die konkreten Messkriterien, die Messpunkte und die Messtermine mit dem Kunden zu vereinbaren.
Messwerkzeuge und einheitliche Messverfahren sollten einheitlich vorgegeben werden.
Durch diese Struktur wird sichergestellt, dass die SLAs nach einheitlichen Messverfahren und mit standardisierten Messwerkzeugen gemessen werden. Dies reduziert nicht die Aufwendungen für die konkreten Messungen, stellt aber die Vergleichbarkeit der einzelnen IT Services sicher.
2.8.5
Die Inhalte von SLAs
2.8.5.1 Vorgaben / Empfehlungen der ISO 20000 Die ISO 20000-1 beschreibt die Mindestanforderungen an die Dokumentation von IT Services mittels SLAs. So fordert die ISO 20000-1: „Der gesamte Umfang der gelieferten Services mit den zugehörigen Service Levesl und Auslastungs-Kriterien müssen zwischen den Parteien vereinbart und aufgezeichnet werden“ oder „Jeder gelieferte Service muss in einem oder mehreren SLAs definiert, vereinbart und dokumentiert werden.“ (vgl. [ISO 20000-1, 2005]). Vorgaben zur inhaltlichen Gestaltung der SLAs macht die ISO 20000-1 nicht. Die ISO 20000-1 enthält Mindestanforderungen an die Verwendung von SLAs. Im Fokus stehen dabei die Anforderungen an den Prozess des Service Level Managements.
Innerhalb der ISO 20000-2 wird dagegen auf die inhaltliche Gestaltung der notwendigen Dokumente eingegangen. So sind Best Practices zum Service Katalog und ein Leitfaden für die inhaltliche Gestaltung der SLAs dokumentiert. Im Zusammenspiel zwischen Service Katalog und SLA empfiehlt die ISO 20000-2, eine Referenzierung vom SLA zum Service Katalog aufzubauen.
81
Service Level und Auslastungs-Kriterien sind zu vereinbaren und aufzuzeichnen.
2 IT Service Management Die ISO 20000-2 empfiehlt die folgenden Inhalte für einen SLA: – – – – –
–
– – – – – – – –
– – – – – –
Kurze Beschreibung des Service Gültigkeitsdauer und / oder Change-Mechanismen Detaillierte Vollmachten Kurzbeschreibung der Kommunikation inklusive des Reportings Nähere Angaben über Ansprechpartner, die dazu bevollmächtigt sind, in Notfällen zu handeln und die bei Incidents, Problembehebungen, Recovery und Workarounds mitwirken Servicezeiten (zum Beispiel 09:00 - 17:00 Uhr), festgelegte kritische Geschäftszeiten (zum Beispiel Wochenenden, gesetzliche Feiertage und Ferien), Ausnahmen und unterstützter Systembetrieb Geplante und vereinbarte Unterbrechungen, inklusive festgelegter Ankündigungsprozedur und Anzahl pro Periode Verantwortlichkeiten des Kunden, zum Beispiel Sicherheit Verantwortlichkeiten und Verpflichtungen des IT Service Providers, zum Beispiel in Bezug auf die IT Sicherheit Richtlinien für Auswirkungen und Prioritäten (Zuordnung) Eskalations- und Benachrichtigungsprozess Beschwerdeverfahren Service-Ziele (Service Targets) Workload-Begrenzungen, zum Beispiel die Fähigkeit, eine vereinbarte Anzahl von Anwendern / Arbeitsvolumen / Systemdurchsatz zu unterstützen Übergeordnete Finanzinformationen, zum Beispiel Kostenschlüssel etc. Notwendige Aktionen im Fall einer Serviceunterbrechung Organisatorische Abläufe Begriffsdefinitionen Unterstützte und zugeordnete Services Jede Ausnahme zu den angegebenen Bedingungen des SLA
Die ISO 20000-2 dokumentiert international anerkannte Best Practices für das IT Service Management. Eine Organisation ist daher gut beraten, die in der ISO 20000-2 beschriebenen Inhalte für ein Service Level Agreement (SLA) umzusetzen.
Die ISO 20000-2 beinhaltet die Definition von „Service-Zielen“ (Service Targets). Service-Ziele machen die vereinbarten Ziele für einen Service Level messbar. Mögliche Service-Ziele könnten zum Beispiel eine „Verfügbarkeit von x % pro Woche“ oder eine „Erstlösungsquote von x % pro Woche“ sein.
82
2.8 Monitoring und Reporting von SLAs Die Einhaltung von Service Level und SLAs wird mittels vereinbarter ServiceZiele definiert, überwacht und berichtet.
Zur Definition der Service-Ziele empfiehlt die ISO 20000-2: “The targets, against which the delivered service should be measured, should be defined from a customer perspective.” (vgl. [ISO 20000-2, 2005]). Daraus resultiert die Anforderung, die SLAs und insbesondere die Service Level und Service-Ziele in einer Sprache zu verfassen, die der Kunde versteht und die seiner Perspektive entspricht. So sollten zum Beispiel in einem SLA Begriffe wie „Buchungsvorgänge“ und „Anzahl gespeicherter Artikel“ verwendet werden. Messgrößen wie „CPU-Auslastung“ oder „Datenbankgröße“ entsprechen dagegen in der Regel nicht der Kundenperspektive und sind zu vermeiden.
Service-Ziele sind aus der Kundenperspektive zu definieren.
Es können nicht alle Geschäfts- und Kundenanforderungen in einem SLA vereinbart werden. Insbesondere wenn innerhalb einer Organisation noch keine Erfahrungen mit SLAs vorliegen, sollte man sich zunächst auf die wichtigsten Aspekte begrenzen, Erfahrungen sammeln und diese Erfahrungen bei der nächsten Version umsetzen. Hinzu kommt, dass SLAs verwaltet werden müssen. Die Einhaltung muss gemessen und berichtet werden. Diese Aktivitäten führen zu Aufwendungen und Kosten für den IT Service. Die ISO 20000-2 empfiehlt daher: „The SLAs should include only an appropriate subset of the targets to focus attention on the most important aspects of the service.”
Konzentration auf die wesentlichen Service Level
In einem SLA sollte eine angemessene Anzahl der wichtigsten Aspekte eines IT Service enthalten sein.
2.8.5.2 Empfehlungen der ITIL Best Practices Die ITIL Best Practices zur Gestaltung von SLAs sind dem Prozess Service Level Management zu entnehmen. Die Inhalte der ISO 20000 sind an den Prozessbeschreibungen der ITIL Best Practices ausgerichtet und ergänzen diese komplementär (zum Teil wurden die Texte von den gleichen Autoren verfasst). Daher sind die in ITIL und die in der ISO 20000-2 dokumentierten Empfehlungen weitestgehend deckungsgleich. Allerdings sind die Beschreibungen in den ITIL Best Practices umfangreicher gegenüber denen aus der ISO 20000-2. ITIL definiert die gebräuchlichen Inhalte eines SLA wie folgt: – Einleitung - Parteien der Vereinbarung - Bezeichnung und Kurzbeschreibung der Vereinbarung - Unterzeichnende
83
2 IT Service Management -
–
–
–
–
–
–
–
84
Datumsangaben: Anfang, Ende, Review Geltungsbereich der Vereinbarung, was wird zugesichert und was ist ausgenommen - Pflichten des IT Service Providers und des Kunden - Beschreibung des zugesicherten IT Service Service-Zeiten - Die Zeiten, in denen der Service gewöhnlich benötigt wird - Vereinbarungen für die Anforderung von ServiceErweiterungen, inklusive der erforderlichen Mitteilungszeiten - Besondere Zeiten (zum Beispiel Feiertage) - Service-Kalender Verfügbarkeit - Verfügbarkeits-Ziele während der vereinbarten Zeiten - Normalerweise als Prozentsatz definiert - Festgeschriebene Messperioden und -verfahren Zuverlässigkeit - Wird üblicherweise als Anzahl der Service-Unterbrechungen oder als MTBF (Mean Time Between Failures) bzw. als MTBSI (Mean Time Between System Incidents) ausgedrückt Support - Support-Zeiten (sofern diese nicht mit den Service-Zeiten identisch sind) - Vereinbarungen für die Anforderung von SupportErweiterungen, inklusive der erforderlichen Mitteilungszeiten - Besondere Zeiten (zum Beispiel Feiertage) - Ziel für die Reaktionszeit - Ziel für die Lösungszeiten, abgestuft nach den Prioritäten der Incidents Durchsatz - Angaben des voraussichtlichen Datenvolumens und Durchsatzaktivitäten (zum Beispiel Anzahl der Transaktionen, die Anzahl der gleichzeitig aktiven Anwender) Antwortzeitverhalten - Zielvorgaben für durchschnittliche oder maximale Antwortzeiten am Arbeitsplatz (zum Beispiel 95 % innerhalb von 2 Sekunden) Batch-Bearbeitungszeiten - Zeiten für die Lieferung von Input und Output und Ort für die Lieferung des Outputs
2.8 Monitoring und Reporting von SLAs – Changes - Zielvorgaben für die Genehmigung, Bearbeitung und Implementierung von RFCs; üblicherweise bezogen auf Kategorie oder Dringlichkeit/Priorität – Kontinuität und Sicherheit der IT Services - Eine kurze Benennung des IT Service Continuity Plans und wie er aktiviert wird - Ausführungen zu Sicherheitsfragen, insbesondere Verantwortungen des Kunden (zum Beispiel Backup von nicht angebundenen PCs, Passwort-Änderungen) - Einzelheiten zu verminderten oder geänderten ServiceZielen für den Katastrophenfall (falls kein separates SLA für solche Situationen existiert) – Leistungsverrechnung - Einzelheiten zum Verteilungsschlüssel und zu den Zeiträumen der Leistungsverrechnung (sofern die Leistungen in Rechnung gestellt werden) – Service-Berichte und Reviews - Der Inhalt, die Häufigkeit und Verteilung der Service-Berichte - Die Häufigkeit der Service-Review Besprechungen – Leistungs-Anreize / Strafen - Einzelheiten zu Vereinbarungen über finanzielle Anreize oder Strafen in Abhängigkeit der Service Level
2.8.6
Monitoring und Reporting von SLAs, OLAs und UCs
Der Prozess Service Level Management ist nicht nur für die Vereinbarung der IT Services mit den Kunden und der Absicherung dieser SLAs durch entsprechende OLAs und UCs verantwortlich. Weiterhin gehören auch die Aufgaben des Monitorings und des Reporting in die Verantwortung des Service Level Managements. Dabei werden die SLAs und die damit in Verbindung stehenden OLAs und UCs gemessen und die Ergebnisse den jeweiligen Organisationsbereichen berichtet. In der ISO 20000-1 heißt es hierzu: „Service Level sind zu überwachen und gegenüber den vereinbarten Zielen (Service Targets) zu berichten.“ (vgl. [ISO 20000-1, 2005]). Die in den SLAs, OLAs und UCs spezifizierten Vereinbarungen sind hinsichtlich der Zielerreichung vollständig zu überwachen und die Ergebnisse sind zu berichten.
Um das Monitoring der SLAs, OLAs und UCs sicherzustellen, müssen sämtliche beschriebenen Service Level messbar sein (siehe Kapitel 2.9.5.1
85
2 IT Service Management und 2.9.5.2). Werden im SLA zum Beispiel Regelungen für Changes, wie etwa Genehmigungszeiten getroffen, so sind diese Bearbeitungszeiten zu messen und zu berichten. In einem SLA werden Service-Ziele für einen IT Service vereinbart und sind im Rahmen des Monitorings zu messen. Um die daraus resultierenden Anforderungen an die Messbarkeit zu verstehen, erfolgt hier nochmals die Darstellung der Kundensicht auf den IT Service. Der Kunde benötigt die IT Services zur Durchführung seiner geschäftlichen Aktivitäten dort, wo die Aufgaben durchzuführen sind. Er erwartet, dass zum Beispiel die Finanzverwaltungsaktivitäten am Arbeitsplatz seines Mitarbeiters durchgeführt werden können. In der Regel ist dieser Arbeitsplatz der PC des Mitarbeiters. Service Level sind dort zu messen, wo der Service wahrgenommen wird.
Diese Anforderung mag an dieser Stelle trivial und selbstverständlich klingen, aber welcher IT Service Provider garantiert dem Kunden heute die Bereitstellung des IT Service mit garantierten Service Level am PCArbeitsplatz? Den Kunden interessiert es nicht, ob die Applikation am Server verfügbar ist. Sie muss am Arbeitsplatz seines Mitarbeiters verfügbar und nutzbar sein. Welche verschiedenen IT-Systeme dazu betrieben werden müssen und ineinander greifen, sollte für den Kunden nicht von Belang sein. Der Kunde benötigt eine ganzheitliche IT-Unterstützung zur Durchführung seiner Aktivitäten und nicht ein Puzzle von Einzelvereinbarungen. Es ist sinnlos, Service Level und Service-Ziele zu definieren, wenn diese nicht überprüfbar sind. So ist zum Beispiel die Zusicherung eines Service Level mit dem Ziel einer Verfügbarkeit von 95 % überflüssig, wenn die Verfügbarkeit nicht gemessen werden kann. Daher muss die IT überlegen, wie geeignete Messungen vorgenommen werden können. Zum Beispiel könnten Messroboter eingesetzt werden, die an vereinbarten Lokationen und zu vereinbarten Zeiten die Verfügbarkeit des IT Service messen. Die festgelegten Messverfahren und Messkriterien sind dem Kunden zu erläutern und als Anlage zum SLA zu vereinbaren. Ist ein Service Level nicht messbar, stellt sich die Frage, ob dieser Service Level überhaupt wichtig ist. Wäre der Service Level wichtig, so würden auch Anstrengungen unternommen diese Messung sicherzustellen bzw. den Service Level so zu spezifizieren, dass die Messung möglich wird. Gegebenenfalls kann statt einer Messung auch eine Bewertung, wie zum Beispiel im Rahmen einer Kundenzufriedenheitsumfrage herangezogen werden. Nicht messbare Service Level bergen ein Konfliktpotenzial zwischen IT Service Provider und Kunde in sich. Solange der Kunde zufrieden ist, mögen noch keine Probleme auftreten. Aber wenn der Kunde unzufrieden ist
86
2.8 Monitoring und Reporting von SLAs und den Nachweis der Einhaltung der Service-Ziele einfordert, ist der Streit vorprogrammiert. Bei der Messbarkeit von SLAs darf nicht außer Acht gelassen werden, dass Kunden und Anwender die IT in der Regel nur dann bemerken, wenn sie ausfällt. Diese Ausfälle bestimmen daher häufig das Erscheinungsbild der IT. Durch das Monitoring und Reporting kann der IT Service Provider dazu beigetragen, diese negative Kundenwahrnehmung der IT zu verändern. Das Monitoring und Reporting der Service Level und der Nachweis der Einhaltung der Service-Ziele tragen zur Steigerung der Kundenzufriedenheit bei. Das Monitoring und das Reporting der Service Level und der eingehaltenen Service-Ziele muss im Eigeninteresse des IT Service Providers liegen. Daher sind die SLAs, OLAs und UCs eindeutig zu formulieren, dürfen keine mehrdeutigen Interpretationen zulassen und sind gegenüber den festgelegten Service-Zielen zu messen.
In der ISO 20000-1 wird aber nicht nur verlangt, dass die Service Level zu messen und gegenüber den Service-Zielen zu berichten sind, sondern die Forderung wird fortgeführt: „…showing both current and trend information. The reasons for non-conformance shall be reported and reviewed.” (vgl. [ISO 20000-1, 2005]). Aus dieser Empfehlung ergeben sich weitere Anforderungen an die Aufzeichnung und das Reporting von SLAs. Die erreichten Service Level sind chronologisch aufzuzeichnen und im Rahmen der Service-Berichte als Trend darzustellen. Die Qualität eines IT Service kann so an der Einhaltung der definierten Service-Ziele und anhand des Trends bewertet werden. Die Trenddarstellung macht es für die Beteiligten offensichtlich, ob die Qualität gleich bleibend, steigend oder unter Umständen sinkend ist. Die ISO 20000-1 erfordert eine Trenddarstellung der erreichten Service Level gegenüber den Service-Zielen.
Darüber hinaus fordert die ISO 20000-1 eine Darstellung der Ursachen, wenn die vereinbarten Service-Ziele nicht erreicht werden. Diese Ursachen sind im Service-Bericht darzustellen und zu bewerten. Eine weitere Anforderung der ISO 20000-1 besteht in der Darstellung und Bewertung der Ursachen für die Nichterreichung ( Unterschreitung) der festgelegten Service-Ziele.
87
Die ISO 20000 verlangt auch die Darstellung von Trends.
2 IT Service Management
2.8.7
Abgrenzung der Kennzahlen
Die SLAs mit den Service Level und den entsprechenden Service-Zielen definieren die vereinbarte IT-Unterstützung für die Aktivitäten und Geschäftsprozesse einer Organisation. Sie stellen die Außensicht auf die ITOrganisation dar. Das Kundeninteresse besteht in der Einhaltung der zugesicherten Service-Ziele. Eine Betrachtung der IT-internen Prozesse steht nicht im Fokus des Kunden. Im Außenverhältnis berichtet die IT-Organisation über die Einhaltung der definierten Service Level und der Auslegungskriterien. Die Einhaltung dieser Kriterien und des Trends sind vom IT Service Provider nachzuweisen. Hierzu werden entsprechende Service-Ziele im SLA definiert.
Innerhalb der IT ist ein Management der IT Service Management-Prozesse erforderlich. Mittels Kennzahlen wird überprüft, ob die Prozesse die definierten Ziele hinsichtlich der Effektivität und Effizienz erreichen. So wird zum Beispiel die Effektivität des Prozesses Service Level Management mittels der Kennzahl „Anteil eingehaltener Service Level” gemessen. Im Innenverhältnis benötigt das Management Kennzahlen, um die IT-Prozesse zu steuern. Hierzu dienen die jeweiligen Key Goal Indicators (KGIs) und die Key Performance Indicators (KPIs).
2.9 Integrationsinstrument: Balanced Scorecard
Die Balanced Scorecard ist ein Kennzahlen- und ManagementSystem.
Die von Robert S. Kaplan und David P. Norton Anfang der 90er Jahre entwickelte Balanced Scorecard 4 ist nicht nur ein Messsystem, sondern vielmehr ein exzellentes Management- und Steuerungssystem. Sie kann in unterschiedlichen Unternehmensbereichen eingesetzt werden. Nach unserer Erfahrung eignet sie sich besonders gut als Management- und Reporting-Instrument für IT-Organisationen bzw. deren Bereiche. Wir verwenden die Balanced Scorecard als Integrationsinstrument, das in der Lage ist, Kennzahlen aus unterschiedlichen Systemen zusammenzuführen, zu verknüpfen und für entsprechende Adressatenkreise geeignet darzustellen. In den Projekten, die wir in IT-Organisationen unterschiedlicher Größen und Branchen durchgeführt haben, hat sich immer wieder gezeigt, dass es durch Anwendung der Balanced Scorecard möglich ist, die Lage der IT in ihrem jeweiligen Geschäftsumfeld realitätsnah, transparent und korrekt darzustellen. Richtig eingesetzt, hält die Balanced Scorecard damit nicht nur das operative IT-Geschäft sondern insbesondere die stra-
4
88
Häufig abgekürzt als „BSC“, für den IT-Bereich als „IT-BSC“.
2.9 Integrationsinstrument: Balanced Scorecard tegische Ausrichtung der IT-Organisation bis hin zum IT-Marketing in der Balance.
2.9.1
Kernideen
Die Kernideen der Arbeiten von Robert S. Kaplan und David P. Norton sind einfach und faszinierend. Liest man die ersten Seiten aus [Kaplan et al., 1996], fällt es schwer, das Buch zur Seite zu legen. -- Zitatanfang --
„Imagine entering the cockpit of a modern jet airplane and seeing only a single instrument there. How would you feel about boarding the plane after the following conversation with the pilot? – Question: I’m surprised to see you are operating the plane with only a single instrument. What does it measure? – Answer: Air speed. I’m really working on air speed this flight. – Question: That’s good. Air speed certainly seems important. But what about altitude. Wouldn’t an altimeter be helpful? – Answer: I worked on altitude for the last few flights and I’ve gotten pretty good on it. Now I have to concentrate on proper air speed. – Question: But I noticed you don’t even have a fuel gauge. Wouldn’t that be useful? – Answer: You are right: fuel is significant, but I can’t concentrate on doing too many things well at the same time. So, on this flight I’m concentrating on air speed.” -- Zitatende -Die Frage, ob man nach diesem Gespräch hier mitfliegen würde, lässt sich leicht beantworten: Unabhängig vom Können des Piloten und unabhängig von der Qualität des Flugzeugs bleibt der fade Nachgeschmack, dass eine einzige Kennzahl, dir zur Steuerung der Maschine „reported“ wird, nicht ausreicht – selbst wenn der Pilot mit dieser Methode in der Vergangenheit gute Erfahrungen gemacht hat. Ein Ansatzpunkt der Balanced Scorecard ist gerade die Kritik an der tradierten strategischen Unternehmensführung, die sich im Wesentlichen an finanziellen Kennzahlen (z. B. Return on Investment oder Eigenkapitalrentabilität) orientiert. Diese Kennzahlen werden als eindimensional und vergangenheitsorientiert kritisiert. Sie würden außerdem zu einer kurzfristig orientierten Investitionspolitik führen, da Zukunftsmaßnahmen, z. B. im Bereich Forschung und Entwicklung, sich kurzfristig in der Erfolgsrechnung nur auf der Kostenseite niederschlagen. Die Balanced Scorecard in der von Kaplan und Norton vorgestellten Form ergänzt daher die traditionelle finanzielle Perspektive um drei weitere
89
2 IT Service Management Perspektiven. Auf diese Weise erhält man ein 4-dimensionales Modell, dass ein und dasselbe Objekt, z. B. einen Unternehmensteilbereich, aus verschiedenen Blickwinkeln beleuchtet und bewertet. Die von Kaplan und Norton vorgeschlagene Balanced Scorecard ist 4-dimensional. Sie enthält die 4 Perspektiven: Finanzen, Kunden, Prozesse5 und Potenziale6. Die Balanced Scorecard ist ein mehrdimensionales und ausgewogenes Zielsystem.
Neben der Mehrdimensionalität des Zielsystems basiert die Balanced Scorecard auf einer weiteren Idee, die sich leicht im täglichen Leben wiederfinden lässt. Der Begriff „balanced“ sagt aus, dass die Perspektiven ausgeglichen bzw. ausgewogen sein müssen. Bemüht man weitere wörtliche Übersetzungen des Begriffs, so bietet sich die technische Interpretation „ausgewuchtet“ an, die verdeutlicht, dass das Gesamtsystem der Scorecard nur dann Sinn macht, wenn die einzelnen Komponenten richtig auf einander abgestimmt sind. Nach dem Prinzip der Balanced Scorecard macht es keinen Sinn, eine Perspektive in den Vordergrund zu schieben und dafür andere zu vernachlässigen. Es handelt sich um ein Zielsystem, in dem die Mehrdimensionalität nicht nur als Option enthalten ist sondern explizit gefordert und garantiert wird. Wendet man die Balanced Scorecard auf den IT-Bereich an, so hat dies eine gravierende Konsequenz: Die alleinige Bewertung der IT anhand von Kostenzahlen ist nicht mehr state of the art.
Es geht nicht um kurzfristige Gewinne sondern um Kontinuität.
Die Balanced Scorecard berücksichtigt insbesondere strategische Aspekte. Ein wesentliches Ziel ist in diesem Zusammenhang die Garantie des mittel- und langfristigen Erfolgs der zu betrachtenden Unternehmenseinheit. Es geht damit weniger um kurzfristig realisierbare Unternehmensgewinne sondern mehr um Kontinuitätsgesichtspunkte. Die Balanced Scorecard versucht, Wertschöpfungsprozesse mit dem „richtigen Augenmaß“ zu bewerten und herauszufinden, welche Faktoren für den langfristigen Erfolg des Unternehmens ausschlaggebend sind.
Die Balanced Scorecard ist ein top downInstrument zur Strategieumsetzung.
Wichtigstes Ziel der Balanced Scorecard ist die Umsetzung von Unternehmenszielen auf allen Ebenen. Dies wird dadurch erreicht, dass sich, ausgehend von der Vision, die Strategie des Unternehmens ableiten lässt und sich daraus konkrete Ziele definieren lassen. Der Aspekt der Vision und Strategie steht damit im Mittelpunkt einer jeden Balanced Scorecard. In [Kaplan et al., 1996] wird dies mit den 5
Die Prozessperspektive wird im Original „Interne Geschäftsprozesse“ genannt.
6
Die Potenzialperspektive wird im Original „Lernen und Entwicklung“ genannt.
90
2.9 Integrationsinstrument: Balanced Scorecard Schlagworten „translating strategy into action” und „measures that drive (future) performance” herausgestellt. Um den Kern von Vision und Strategie ranken sich vier Betrachtungsweisen (vgl. Abbildung 30): – Finanzielle Ziele: Wie soll das Unternehmen gegenüber Teilhabern und Kapitalgebern auftreten, um finanziellen Erfolg zu erreichen? – Kundenbezogene Ziele: Wie soll das Unternehmen gegenüber Kunden auftreten, um seine Vision zu verwirklichen? – Prozessbezogene Ziele: In welchen Geschäftsprozessen muss das Unternehmen an der Spitze stehen, um seine Teilhaber und Kunden zu befriedigen? – Mitarbeiter- und Innovationsbezogene Ziele: Wie kann das Unternehmen Veränderungs- und Wachstumspotenziale fördern, um seine Vision zu verwirklichen? Finanzperspektive Ziel
Kenn- Vorzahl gabe
Maßnahme
Kundenperspektive Ziel
Kennzahl
Vorgabe
Prozessperspektive
Vision und Strategie
Maßnahme
Ziel
Kenn- Vorzahl gabe
Maßnahme
Protenzialperspektive Ziel
Abbildung 30:
Kenn- Vor- Maßzahl gabe nahme
Allgemeine Balanced Scorecard
91
2 IT Service Management Diese Ziele lassen sich beispielsweise folgendermaßen detaillieren:7
Finanzielle Ziele – Kostenreduktion – Strategische Ausrichtung von Investitionen – Umsatzsteigerung
Kundenbezogene Ziele – Gewinnung neuer Kundensegmente – Umsatzerhöhung pro Kunde – Festigung der Kundentreue
Prozessbezogene Ziele – Lean Management realisieren – Best of breed Technologien einsetzen – Grundideen des Business Process Re-engineering umsetzen
Mitarbeiter- und Innovationsbezogene Ziele – Erhöhung der Mitarbeiterzufriedenheit – Etablieren eines Unternehmenswerte-Systems – Durchführung von Qualifikationsmaßnahmen Die Verknüpfung der Unternehmensstrategie und der operativen Maßnahmenplanung erfolgt über Ursache-Wirkungsketten (siehe Abbildung 31). In der Praxis können diese Wirkungszusammenhänge sehr kompliziert, ja sogar konfliktär sein. In [Kaplan et al., 1996] sind die Schritte dargestellt, die notwendig sind, um ein Balanced Scorecard Konzept zu erstellen. Dabei sind 10 Teilaufgaben zu lösen, ausgehend von Aufgabe 1: Select the appropriate organizational unit bis zu Aufgabe 10: Finalize the implementation plan. Es sollen nicht mehr als 25 Kennzahlen (4 bis 7 je Perspektive) verwendet werden. Die Kennzahlen sollen Vergangenheit, Gegenwart und Zukunft messen. Vor allen Dingen sollen die Kennzahlen strategisch dimensioniert sein, denn das Konzept der Balanced Scorecard dient der beschleunigten Strategieumsetzung.
7
92
Die Detaillierung leitet sich aus der IT-Strategie und dem Zielsystem des Unternehmens ab.
2.9 Integrationsinstrument: Balanced Scorecard
Finanzperspektive
Kundenperspektive
Prozessperspektive
Potentialperspektive Abbildung 31:
Finanzielles Ergebnis (Gewinn, Rentabilität, ...) Kundenzufriedenheit Kosten der Prozesse
Kundentreue
Qualität der Prozesse
Qualifizierte Mitarbeiter
Geschwindigkeit der Prozesse
Motivierte Mitarbeiter
Ursache-Wirkungskette
Dass sich die Balanced Scorecard immer aus den Unternehmenszielen und der Strategie ableitet, verdeutlicht Abbildung 32 aus [Preißner, 2006].
Unternehmensziele Strategien
Kundenperspektive Finanzperspektive
interne Prozessperspektive Lern- & Entwicklungsperspektive
operative Umsetzung Erfolgskontrolle Abbildung 32:
Stellung der BSC im Unternehmensplanungsprozess
93
2 IT Service Management
2.9.2
Anwendung auf den IT-Bereich
Die Anwendung der Balanced Scorecard Methode in IT-Bereichen ist inzwischen weitgehend akzeptiert. Der Nutzen im Hinblick auf Performance-Steigerung und Strategie-Überprüfung liegt auf der Hand. Es geht darum, die IT-Organisation als Ganzes über ihre verschiedenen Funktionen hinweg zu steuern. Es geht darum, dass dies konform mit der ITStrategie geschieht und darum, dass diese aus der Geschäftsstrategie abgeleitet ist. So ist es nicht verwunderlich, dass die Balanced Scorecard als empfohlenes Werkzeug explizit Eingang in ITIL V3 gefunden hat, da ITIL V3 gerade die Verzahnung von Business und IT sowie der Beitrag der IT zur Wertschöpfung des Unternehmens am Herzen liegen. Auch ITIL V3 liefert natürlich keine Balanced Scorecard für die IT, die eins zu eins in einer IT-Organisation einsetzbar ist – und damit auch kein Kennzahlensystem, das diesen Zweck erfüllt. Nach [Kütz, 2007] „kann es wegen der Vielzahl der Steuerungsobjekte in der IT und Verschiedenheit der Rahmenbedingungen ein Standard-Kennzahlensystem nicht geben ... Umfang und Ausprägungen müssen dann im konkreten Fall spezifisch erarbeitet werden.“ ITIL V3 kommt jedoch mit seinem erweiterten und modifizierten Prozessmodell dem Ziel der Vereinheitlichung von IT Service-Prozessen8 einen gewaltigen Schritt näher. Dies wird zumindest zu einer weiteren Vereinheitlichung von IT-Kennzahlensystemen führen. ITIL V3 schlägt in Anlehnung an Kaplan und Norton vier Perspektiven für eine IT Balanced Scorecard vor (vgl. [OGC, 2007e]): -- Zitatanfang --
– Financial: As customers how do we view the costs of IT provision? – Customer: What do we as customers expect of IT provision? – Innovation: Does our IT infrastructure enable us to continue to improve the business? – Internal: What must our IT providers (internally) excel at? -- Zitatende --
Die Grundidee von ITIL V3 ist richtig und bestätigt unsere Arbeiten in vielen Projekten, in denen es darum ging, Kennzahlensysteme zur Steuerung und zum Reporting einzusetzen:
8
94
Hier ist insbesondere die Vereinheitlichung im Sinne der Etablierung eines allgemein akzeptierten Sprachstandards gemeint.
2.9 Integrationsinstrument: Balanced Scorecard Es gibt viele Möglichkeiten, Perspektiven für eine IT Balanced Scorecard zu definieren.
Allerdings wird sich in der Praxis beweisen müssen, ob die in ITIL V3 genannten vier Perspektiven für die IT die geeigneten sind und ob es nicht mehr oder weniger als vier sind.
2.9.3
Ausprägungen der Balanced Scorecard
Mit der Fragestellung, was die geeigneten Perspektiven der Balanced Scorecard für den IT-Bereich sind und welche Kennzahlen man für jede dieser Perspektiven erhebt, haben sich einige Ansätze beschäftigt. In der lesenswerten Masterarbeit von Jakob Bung werden einige dieser Ansätze gegenübergestellt [Bung, 2006]. Wir gehen hier nicht auf die Details ein, sondern geben das Ergebnis in Form einer Tabelle an (siehe folgende Seite, in Anlehnung an [Bung, 2006], Seite 27). Die Gegenüberstellung der verschiedenen Ansätze zeigt, dass es schwerfällt, einen allgemein gültigen Ansatz zur Strukturierung der Perspektiven einer Balanced Scorecard anzugeben. Es fällt auf, dass es keinen Sprachstandard gibt. Möchte man in der Praxis eine Balanced Scorecard für den IT-Bereich entwickeln9, so bietet es sich an, das Beste aus allen Welten zu nehmen. Dies verdeutlichen wir später in unserem Kennzahlenmodell und in den Praxisbeispielen.
9
Wir sprechen hier immer von einer (!) Balanced Scorecard, um den Sprachgebrauch einfach zu halten. Für IT-Bereiche können auch mehrere Balanced Scorecards existieren, die gegebenenfalls zusammenhängen.
95
2 IT Service Management
Entwicklungsstufen zur IT Balanced Scorecard
Ansatz von
Perspektiven
Jahr
Anmerkung
Kaplan und Norton
– – – –
1996
Kein expliziter Bezug zur IT.
Van Grembergen und Saull
– Beitrag zum Kerngeschäft – Kundenorientierung – Operative Leistungen – Zukunftsorientierung
2001
Die Kundenorientierung wird beibehalten, drei neue Perspektiven werden vorgeschlagen, insb. die Bestimmung des Added Values der IT.
Kütz
– – – – – –
Finanzmanagement Kundenmanagement Prozess-Management Innovationsmanagement Mitarbeitermanagement Lieferantenmanagement
2003
Zusätzlich wird die Lieferantenperspektive eingeführt. Die Potenzialperspektive wird in Mitarbeiter- und Innovationsmanagement aufgeteilt.
Wiggers, Kok und de Boerde Wit
– – – –
Finanzen Kunden Geschäftsprozesse Lernen u. Entwicklung
2004
Enthält die gleichen Perspektiven wie Kaplan et al., diese werden allerdings inhaltlich an die IT angepasst.
SchmidKleemann
– – – – –
Unternehmensbeitrag Kunden IT-Leistungserstellung IT-Einsatz Zukunft
2004
Auch hier der Versuch, den Wertbeitrag der IT zu bestimmen. Die Zukunftsperspektive und der IT-Einsatz leiten sich aus der Potenzialperspektive ab.
ITIL 2
– – – –
Finanzen Kunden Interne Prozesse Innovation (bzw. Lernen und Entwicklung)
2000 und 2007
4 Perspektiven, die mit denen der Original BSC übereinstimmen. Die Beschreibung der Perspektiven ist in V 3 wesentlich differenzierter als in V 2.
und ITIL V3
96
Finanzen Kunden Geschäftsprozesse Lernen u. Entwicklung
2.10 Konsequenzen
2.10 Konsequenzen Die Auswahl der „richtigen“ Kennzahlen ist in der Praxis ein schwieriger und mehrstufiger Prozess. Die Fragestellung, welcher Ansatz10 der geeignete zum Aufbau eines Kennzahlensystems ist, führt im Allgemeinen nicht zum Ziel. Es geht vielmehr darum, herauszufinden, wie verschiedene Komponenten der Best Practices als Puzzle zusammengefügt werden können, um das bestmögliche durchgängige Kennzahlensystem für die jeweilige Organisation aufzubauen. ITIL führt hierzu aus (Service Strategy [OGC, 2007a]): Ein wirkungsvolles IT Service Management entsteht durch die Nutzung von Best Practices (Standards) und deren Ausrichtung an den spezifischen Fähigkeiten der eigenen Organisation.
Kennzahlen (KGIs und KPIs) und der Aufbau eines Kennzahlensystems sind kein Selbstzweck. Die Kennzahlen sind nicht zu definieren und zu berichten, weil COBIT und ITIL entsprechende KPIs bzw. KGIs beinhalten. Es geht auch nicht darum diese Kennzahlen zu definieren, weil es die ISO 20000 verlangt. COBIT und ITIL empfehlen bzw. die ISO 20000 verlangt vielmehr die Definitionen von Kennzahlen für jeden IT Service Management-Prozess, weil die Kennzahlen unentbehrliche Informationen für das Management von Prozessen darstellen. Das Prozess-Management (Service Manager, Prozess Owner und Prozess Manager) und das gesamte IT-Management müssen diese Kennzahlen als Führungsinstrument verstehen und dieses Werkzeug aktiv nutzen. Ziel des Prozess-Managements ist es, die Prozesse so zu gestalten und zu steuern, dass die definierten Ziele erreicht werden. Die Kennzahlen liefern dem gesamten Management die notwendigen Informationen darüber, ob die zuvor definierten Prozess-Ziele erreicht werden. Demzufolge müssen sich die Kennzahlen an den Prozesszielen ausrichten. Voraussetzung für die Definition von Kennzahlen sind definierte Ziele für die jeweiligen IT Service Management-Prozesse.
Die beschriebenen Best Practices sind daher als Guidelines für mögliche Kennzahlen zu verstehen. Ihre Nutzung oder die gegebenenfalls notwendige Definition ergänzender und anderer Kennzahlen muss immer in Bezug auf die spezifischen Prozess-Ziele einer IT-Organisation erfolgen.
10
Beispielsweise ITIL oder COBIT, aber auch andere.
97
Kennzahlen sind für ein wirksames ProzessManagement unabdingbar.
2 IT Service Management Die in ITIL und COBIT spezifizierten KGIs und KPIs stellen kein unumstößliches Dogma dar. Sie sind Best Practice Empfehlungen und liefern einen Input für die Definition von Kennzahlen. Es empfiehlt sich, die in ITIL und COBIT dokumentierten KPIs und KGIs zu berücksichtigen. Sie sollten aber grundsätzlich hinsichtlich ihrer Anwendbarkeit für die jeweilige IT-Organisation bzw. für die Prozessziele kritisch hinterfragt und nicht ungeprüft übernommen werden. Bei Bedarf ist die Definition abweichender oder zusätzlicher Kennzahlen notwendig.
Bei der Definition von KGIs und KPIs ist auch zu prüfen, ob die notwendigen Informationen vorliegen, mit welchem Aufwand die Kennzahlen gewonnen bzw. generiert werden können und welche Datenqualität die Ausgangsinformationen haben. Werden COBIT, ITIL, ISO 20000 und die BSC gemäß ihres konzeptionellen Ansatzes als Best Practice verstanden und wird die große Überstimmung der IT Service Management-Prozesse zwischen COBIT und ITIL erkannt (vgl. [Kurth, 2006]), so können diese Ansätze hinsichtlich ihrer Vorteile und Nutzungsmöglichkeit unvoreingenommen bewertet werden. Die folgende Darstellung (auf Basis von [Kurth, 2006], nachfolgende Seite) zeigt, dass es nicht den besten Best Practice Ansatz gibt. Sie zeigt auch, dass die Balanced Scorecard als integratives Instrument in Bezug auf Kennzahlen eingesetzt werden kann, um Ansätze zu verbinden. Es gilt, die jeweiligen Stärken von ITIL und COBIT zu nutzen.
COBIT und ITIL haben aufgrund ihrer Entwicklungsgeschichte und Betrachtungsbereiche unterschiedliche Stärken und Schwächen. Es gilt, die jeweiligen Vorteile beider Best Practices zu nutzen. Eine Festlegung auf einen der Best Practice-Ansätze ignoriert die Stärken des anderen Ansatzes und ist nicht zielführend. Werden die IT-Ziele aus der BSC abgeleitet, so können die Prozessziele und die damit in Verbindung stehenden Kennzahlen in die BSC integriert werden. Damit erhält eine Organisation ein durchgängiges Kennzahlensystem. ITIL, ISO 20000 und COBIT sind als Bausteine für ein übergreifendes Steuerungssystem zu verstehen. Die jeweiligen Stärken der einzelnen Best Practices können so optimal für die eigene Organisation genutzt werden. In einem durchgängigen Managementsystem können die Prozess-Ziele aus der BSC abgeleitet und mit Best Practices KPIs/KGIs aus ITIL und COBIT hinterlegt werden.
98
2.10 Konsequenzen
Eine IT Balanced Scorecard kann verschiedene Ansätze integrieren.
ITIL
ISO 20000
COBIT
IT-BSC
Prozessbeschreibung
Detaillierte (generische) Prozessbeschreibungen
Enthält keine Prozessbeschreibungen, sondern Mindestanforderungen an die ITSM-Prozesse
Enthält keine detaillierten Prozessbeschreibungen
Enthält keine Prozessbeschreibungen
Bekanntheitsgrad
Seit Mitte der 80er Jahre nachhaltig steigende Bekanntheit und Beliebtheit
Erfährt zunehmende Bedeutung, insbesondere für IT Service Provider
Bekanntheitsgrad weiter steigend, insbesondere durch SOX
Bekanntheitsgrad weiter steigend
Anerkennung
ITIL Zertifizierung relevant bei Stellenbesetzung; noch verlangte „ITIL Konformität“ wird durch ISO 20000 abgelöst
Als internationaler Standard weltweit anerkannt, einzige Möglichkeit einer Zertifizierung
In den USA bei Wirtschaftsprüfern weit verbreitet und zunehmend auch in Europa
Weltweit anerkannter Managementansatz zur Strategieumsetzung
Templates
Enthält Best Practices für SLA, RFC, IncidentRecord etc.
Enthält Best Practices für SLA-Inhalte
Enthält Best Practices für IT-Prozesse
Enthält Best Practices für Kennzahlensysteme
Kennzahlen
Schwache generische Beschreibung der ProzessKennzahlen
Enthält Anforderungen an Vorhandensein von Kennzahlen, gibt keine vor
Kennzahlen (-systematik) auch in der Praxis effektiv
Integrationswerkzeug für Kennzahlen
99
3 IT Prozess-Management 3.1 Management Summary Die Best Practice-Ansätze von COBIT und ITIL sowie der ISO 20000 „IT Service Management“ sind Ansätze für ein prozessorientiertes Management. In diesem Kapitel nun werden die damit verbundenen Anforderungen und Voraussetzungen an das Prozess-Management beschrieben. Von wesentlicher Bedeutung ist dabei die Verankerung des Service Managements und der damit verbundenen IT Service Management-Prozesse in das IT-Management. Wirksame Prozessziele und die damit verbundenen Kennzahlen sowie deren Zielwerte können nur in einem top down-Ansatz definiert und verfolgt werden. In diesem Kapitel wird ein praxisbewährtes und konzeptionelles Vorgehen bei der Definition vorgestellt. Die Etablierung von Prozessen erfordert darüber hinaus das Commitment des Managements und die Festlegung der Verantwortlichkeiten. Hierzu werden die Rollen und Verantwortlichkeiten beim Management der IT Service Management-Prozesse beschrieben. Zum Schluss gehen wir auf das Reporting von Prozess-Kennzahlen ein und widmen uns der Frage, wie unterschiedliche Hierarchieebenen Berücksichtigung finden können.
3.2 PDCA-Zyklus ITIL Version 3 geht innerhalb der Publikation „Continual Service Improvement“ expliziert auf ein Regelsystem zur kontinuierlichen Verbesserung von Prozessen und Services ein. Normen, wie die ISO 20000 „IT Service Management“, die ISO 27001 „Information Security Management“ oder die ISO 9001 „Qualitäts-Management“ beinhalten die Anforderungen an ein integriertes Managementsystem. Die in diesen Normen und Best Practices beschriebenen Qualitäts-Managementsysteme gehen zurück auf die Managementlehren des amerikanischen Wissenschaftlers W. Edwards Deming1 zum PDCA-Zyklus (Plan, Do, Check, Act), der als Deming-Zyklus international bekannt geworden ist. Deming selbst wies jedoch darauf hin, dass Walter A. Shewhart2 diesen Zyklus als Erster beschrieben hatte.
1
William Edwards Deming, 1900 - 1993
2
Walter Andrew Shewhart, amerikanischer Wissenschaftler, 1891 - 1967
101
3 IT Prozess-Management Daher wird der PDCA-Zyklus gelegentlich auch als „Shewhart-Zyklus” bezeichnet (siehe Abbildung 33).
Act Verbessern
Plan Planen
Ständige Verbesserung Check Überprüfen
Abbildung 33:
Do Ausführen
PDCA-Zyklus
Der PDCA-Zyklus basiert auf einem prozessorientiertem Managementansatz, der aus den folgenden Phasen besteht (vgl. [ISO 20000-1, 2005]): – Plan (Planen): Die Phase dient der Einführung der Prozesse und der damit verbundenen Ziele, die notwendig sind, um Ergebnisse entsprechend den Kundenanforderungen und den geschäftspolitischen Zielen zu liefern. – Do (Ausführen): Innerhalb der zweiten Phase erfolgt die Durchführung (initial die Implementierung) der geplanten Prozesse. – Check (Überprüfen): Die dritte Phase dient der Überwachung und Messung der Prozesse und Services gegenüber den geschäftspolitischen Zielen und den
102
3.2 PDCA-Zyklus einzelnen Prozess-/Service-Zielen und Anforderungen, sowie zur Berichterstattung der Ergebnisse. – Act (Verbessern): Liegen Ergebnisse aus der Überprüfung vor, so sind diese zu analysieren und geeignete Maßnahmen zu ergreifen, um die Leistungsfähigkeit der Prozesse nachhaltig zu verbessern. Diese identifizierten Verbesserungen finden wiederum Eingang in „Plan“. Dadurch ist kontinuierliche Verbesserung sichergestellt. Prozess-Management ist eine fortgehende, nicht endende Managementaufgabe. Hierzu hat Deming bereits herausgestellt, dass es kein Optimum gibt und demzufolge immer Verbesserungen identifiziert werden können. Von besonderer Bedeutung ist beim PDCA-Zyklus, dass es ein System ist, welches nicht nur der Prozesseinführung dient, sondern als Managementsystem der kontinuierlichen Verbesserung und so mittel- und langfristig einen wesentlichen Beitrag zum Unternehmenserfolg liefert.
Diese Schritte werden ständig wiederholt, um eine kontinuierliche Prozessverbesserung zu erreichen. Daher wird der PDCA-Zyklus auch als Regelzyklus bezeichnet. Die Kennzahlen für IT Service Management-Prozesse stellen eine äußerst wichtige Informationsbasis für die Phase „Check“ dar. Ohne Kennzahlen kann eine Überprüfung der Ergebnisse und Ziele nicht erfolgen und ohne Überprüfung ist eine Verbesserung der Prozesse nicht möglich. Die Kennzahlen für IT Service Management-Prozesse sind für die stetige Prozess-Optimierung ein unerlässliches Werkzeug.
Die im Folgenden beschriebene Vorgehensweise mag zum Teil theoretisch klingen oder auch als selbstverständlich angesehen werden, sie hat aber grundlegende Bedeutung für den Erfolg von IT Service ManagementProzessen. Es muss zum Selbstverständnis des Service Managers, Prozess Owners und Prozess Managers werden, dass die Kennzahlen ein unverzichtbares Werkzeug im Rahmen des Prozess-Managements sind. Ohne Kennzahlen ist letztendlich keine Prozessoptimierung und letztendliche Leistungssteigerung möglich. Es ist ein Irrglaube, Kennzahlen aus bestehenden Best Practices bedenkenlos übernehmen zu können. Es geht um die Sicherstellung der Ziele der Organisation und ihrer Kunden. Kennzahlen müssen dementsprechend ausgerichtet und abgebildet werden.
103
3 IT Prozess-Management
3.3 Etablierung des Prozess-Managements Die Gewinnung von Kennzahlen für IT Service Management-Prozesse setzt die Etablierung einer entsprechenden Prozessstruktur voraus. Bevor die Prozessziele definiert und die daraus abgeleiteten Kennzahlen gewonnen werden können, sind die IT Service Management-Prozesse in der Organisation zu verankern. Dazu ist es nicht ausreichend, einzelne in den ITIL Best Practices dokumentierten Aktivitäten umzusetzen oder ausgewählte Control Objectives aus COBIT sicherzustellen. Vielmehr müssen die Prozesse mit einem Prozess-Management in der Organisation etabliert werden. Dazu sind die damit verbundenen Verantwortlichkeiten und Zuständigkeiten für die IT Service Management-Prozesse zu definieren. Dieser organisatorische Akt, der sich in der Praxis häufig als problematisch darstellt, ist für die Einführung der IT Service Management-Prozesse ein äußerst kritischer Erfolgsfaktor. Bestehende Strukturen in der IT orientieren sich an den eingesetzten Komponenten.
In der Regel sind die bestehenden IT-Organisationen hierarchisch strukturiert, wobei sich deren Struktur stark an den eingesetzten Hardware-Systemen bzw. an Software/Applikationen orientiert. So gibt es Organisationsbereiche, die das LAN, die Datenbanken, die Applikationen oder die Sicherheitskomponenten planen, implementieren und betreuen. Diese Struktur ist historisch gewachsen und hat sich durch die stetig steigende Komplexität der eingesetzten IT-Komponenten ergeben. Der Einsatz der ITKomponenten setzt entsprechendes Spezialwissen der IT-Mitarbeiter voraus. Zum wirkungsvollen Management dieser Spezialisten werden die ITMitarbeiter thematisch in der Organisationsstruktur zu entsprechenden Gruppen, Abteilungen und Bereichen zusammengefasst. Diese Struktur führt häufig dazu, dass die Mitarbeiter innerhalb der IT-Organisation auf den Betrieb „Ihrer Systeme“ ausgerichtet sind und ihr Handeln darauf konzentrieren. Die Kunden- und Servicesicht ist noch nicht in allen ITOrganisation etabliert. Wie im vorhergehenden Kapitel bereits ausgeführt, werden unter dem IT Service ein oder mehrere IT-Systeme verstanden, die einen Geschäftsprozess unterstützen. In der Regel sind damit die Leistungen von mehreren Abteilungen verbunden. Für die IT Services muss es eine Gesamtverantwortung geben, die die Einhaltung der Service Level Agreements sicherstellt. Der Ansatz führt dazu, dass es organisationsübergreifende Verantwortungen geben muss. Analog wie IT Services organisationsübergreifend sichergestellt werden müssen, verhält es sich mit den IT Service Management-Prozessen. Auch diese Prozesse können nur dann wirkungsvoll sein, wenn die Prozesse und damit verbundenen Verantwortlichkeit nicht an Abteilungsgrenzen enden.
104
3.3 Etablierung des Prozess-Managements Mit dem fortschreitenden Out-Tasking wird das notwendige Spezialwissen teilweise durch externe Lieferanten beigestellt. Die Einscheidung für ein Out-Tasking wird einerseits getroffen, wenn das notwendige Wissen innerhalb der eigenen IT-Organisation nicht vorhanden ist. Andererseits werden Entscheidungen für ein Out-Tasking häufig aus finanziellen Gründen getroffen. Bei der Integration von externen Lieferanten muss deren Einbindung in die bestehenden IT-Prozesse sichergestellt werden. Diese Festlegung muss vor dem Vertragsschluss erfolgen. In diese Struktur gilt es die IT Service Management-Prozesse nachhaltig zu etablieren.
3.3.1
Der Charakter von IT-Prozessen
Ein Prozess kann wie folgt definiert werden (vgl. „Service Design“, [OGC, 2007b]): Ein Prozess ist eine strukturierte Folge von Aktivitäten, die geplant werden, um ein bestimmtes Ziel zu erreichen. Ein Prozess benötigt ein oder mehrere definierte Inputs und transformiert diese Inputs zu definierten Outputs. Ein Prozess beinhaltet die notwendigen Rollen, die Verantwortlichkeiten, die Tools und die Management Controls, um den Output zu liefern. Ein Prozess definiert dazu die notwendigen Grundsätze (Policies), Standards, Richtlinien, Aktivitäten und Arbeitsanweisungen.
Am Beispiel des Incident Managements soll diese Begriffsdefinition veranschaulicht werden. Die Zielsetzung des Incident Managements besteht darin, „den normalen Service-Betrieb so schnell wie möglich wiederherzustellen und die nachteiligen Auswirkungen auf den Geschäftsbetrieb auf ein Minimum zu begrenzen“ (vgl. [OGC, 2005b]). Ein Input des Incident Managements ist die „detaillierte Störungsbeschreibung“. Um den Output „behobene Störung und abgeschlossene Störungsvorgänge“ zu erreichen, sind im Prozess des Incident Managements definierte Aktivitäten durchzuführen. Dazu zählen unter anderem die „Registrierung der Störung“ und deren „Untersuchung und Diagnose“. In einer bestehenden IT-Organisation werden einzelne Aktivitäten des Prozesses häufig in unterschiedlichen Organisationseinheiten, zum Teil auch in unterschiedlichen Organisationen durchgeführt. So wird die Störung im Service Desk registriert, während die notwendige Störbehebung durch den 2nd oder 3rd Level Support in einzelnen Fachgruppen mit Spezialwissen übernommen wird. Dies hat zur Konsequenz, dass die ITProzesse organisationsübergreifend durchgeführt werden.
105
3 IT Prozess-Management IT-Prozesse durchdringen die gesamte IT-Organisation, schließen gegebenenfalls externe Lieferanten ein und enden demzufolge nicht an bestehenden organisatorischen Grenzen.
Die mögliche Bearbeitung eines Incidents könnte wie folgt abgewickelt werden (Abbildung 34): Organisation und EDV
Incident Service Desk
Client Systeme
Daten und Systeme
Serversysteme
Netze und Kommunikation
Datenbanken
LAN
WAN
Externer Onsite Support
Abbildung 34:
Exemplarische Darstellung der Bearbeitung eines Incidents
In dem abgebildeten Beispiel wird der Incident dem „Service Desk“ gemeldet und dort registriert. Nach einer ersten Untersuchung leitet der Service Desk den Incident-Record zur weiteren Bearbeitung an die Gruppe „LAN“ weiter. In dieser Gruppe wird festgestellt, dass das LAN keine Störung aufweist und der Incident-Record wird an die Gruppe „Client Systeme“ weitergegeben. Dort wird festgestellt, dass der Desktop in einer Niederlassung ausgefallen ist und man beauftragt den zuständigen „externen Onsite Support“ mit deren Behebung. Nach der erfolgten Behebung wird der „Service Desk“ entsprechend informiert. Dieses Beispiel einer einfachen Bearbeitung im Incident Management verdeutlicht, dass die IT-Prozesse die gesamte IT-Ogranisation durchdringen und zum Teil externe Lieferanten sowie Kunden einbeziehen.
106
3.3 Etablierung des Prozess-Managements Die Aufgabe des Prozess-Managements ist es sicherzustellen, dass der Prozess die definierten Ziele erfüllt. Hierzu definiert ITIL die Prozesssteuerung wie folgt (vgl. „Best Practice Service Design“, [OGC, 2007b): Die Prozess-Steuerung ist die Aktivität, einen Prozess zu planen und zu regulieren, mit dem Ziel, den Prozess effektiv, effizient und in einer einheitlichen Art und Weise auszuführen.
Die damit verbundene Verantwortung der effektiven und effizienten Prozessdurchführung liegt beim Prozess-Management des jeweiligen Prozesses. Auf die einzelnen Rollen im Prozess-Management wird an späterer Stelle in diesem Kapitel eingegangen. Mit der konsequenten Umsetzung der ITIL und COBIT Best Practices wird innerhalb der IT-Organisation aber nicht nur ein Prozess etabliert, sondern eine Vielzahl von Prozessen. Die ISO 20000 definiert hierzu, abgesehen von den übergeordneten Management-Prozessen, insgesamt 13 unerlässliche Prozesse. Das führt dazu, dass die bestehende hierarchische IT-Organisation querschnittlich von IT-Prozessen durchdrungen wird (Abbildung 35). Organisation und EDV
Incident Management Problem Management
Service Desk
Daten und Systeme
Netze und Kommunikation
Change Management Release Management … Client Systeme
Service Level Management Capacity Management
Serversysteme
Datenbanken
LAN
Externer Onsite Support
Security Management
Abbildung 35:
IT-Prozesse und bestehende Aufbauorganisation
Damit ergibt sich letztendlich eine Matrixorganisation mit den bekannten strukturellen Problemen. Die Mitarbeiter sind einerseits einer Linienorga-
107
WAN
3 IT Prozess-Management nisation zugehörig und unterstellt, andererseits haben sie Aktivitäten innerhalb von einem oder mehreren IT Service Management-Prozessen durchzuführen, wofür jeweils ein Prozess Owner bzw. Prozess Manager verantwortlich ist. Diese doppelte Zugehörigkeit zur Linienorganisation und zu den jeweiligen IT Service Management-Prozessen stellt nicht nur die Mitarbeiter der IT-Organisation in ein Spannungsfeld, sondern auch das IT-Management. Ein IT Service Management mit den erforderlichen IT-Prozessen kann nur dann erfolgreich etabliert werden, wenn die Verantwortlichkeiten zwischen Linienorganisation und Prozess-Management festgelegt werden.
Die angestrebte Transparenz führt nicht nur zu Ängsten bei Mitarbeitern sondern auch bei der verantwortlichen Linienorganisation. Denn wer möchte schon transparent sein? Wenn eine IT-Organisation es nicht schafft diese Probleme zu lösen, zum Beispiel durch ein begleitendes Veränderungs-Management und die aktive Beteiligung der „Betroffenen“, so werden die IT Service Management-Prozesse nicht wirkungsvoll sein. Die notwendige und als Ziel gesetzte Transparenz hinsichtlich der Leistungsfähigkeit und des Optimierungspotenzials der Prozesse und der IT Services wird dann ggf. als Bedrohung empfunden und kann nicht erreicht werden. Fehlt die notwendige Unterstützung, so werden die ermittelten Kennzahlen unter Umständen ein fehlerhaftes Bild darstellen und letztendlich wenig zielführend sein. So wie ein Veränderungsmanagement und die Überzeugung notwendig sind, so muss aber andererseits auch sichergestellt werden, dass die festgelegten Prozesse und Aktivitäten auch einzuhalten sind. Wird festgestellt, dass diese Vorgaben nicht eingehalten werden, so müssen damit spürbar Konsequenzen verbunden sein. Auch die Durchsetzung dieser Konsequenzen gehört zur Managementverantwortung. Im Einzelfall kann es durchaus vorkommen, dass vom Prozess abweichend gehandelt werden musste. Dies wird bei der Implementierung neuer Prozesse durchaus vorkommen. Dann muss aber sichergestellt werden, dass die notwendige Abweichung kommuniziert wird und zum Input für eine Prozessanpassung wird (im Sinne des PDCA-Zyklus). Ein IT Service Management mit den erforderlichen IT-Prozessen verlangt das Commitment des gesamten Managements. Es liegt in der Verantwortung des gesamten Managements, zum Erfolg des IT Service Managements aktiv beizutragen. Dies erfolgt sowohl durch ein begleitendes Veränderungs-Management, als auch durch Konsequenzen bei der Nichteinhaltung von getroffenen Vorgaben.
Damit das IT Service Management erfolgreich innerhalb einer hierarchischen Organisationsstruktur betrieben werden kann, sind die Verantwort-
108
3.3 Etablierung des Prozess-Managements lichkeiten eindeutig zu definieren. Diese Definition betrifft einerseits die Abgrenzung zwischen der Linien- und Prozessverantwortung. Andererseits sind auch für das IT Service Management die Verantwortlichkeiten festzulegen. Dazu sind die wahrzunehmenden Rollen im ProzessManagement zu spezifizieren.
3.3.2
Rollen im Prozess-Management
Die hier verwendeten Begriffe sind in IT-Organisation zum Teil mit anderen Aufgaben und Verantwortlichkeiten hinterlegt. Es ist daher im Rahmen der Implementierung zu prüfen, ob für die folgenden Rollen bestehende Begriffsdefinitionen bzw. die hier dokumentierten Rollenbezeichnungen anzupassen sind. Analog zu den ITIL Best Practices stellen die folgenden Rollenschreibungen Empfehlungen dar, deren Umsetzung von der jeweiligen Situation abhängig ist. So wird eine kleine IT-Organisation nicht einen Prozess Manager und einen Prozess Owner etablieren, sondern diese Aufgaben zusammenführen. Die hier beschrieben Rollen entsprechen den ITIL Best Practices (vgl. [OGC, 2007b) bzw. der ISO 20000 (vgl. [ISO 20000-2, 2005):
3.3.2.1 Service Manager Obwohl es bereits seit vielen Jahren eine offizielle Ausbildung und eine international anerkannte Zertifizierung zum „ITIL Service Manager“ (vgl. [KESS, 2007a]) gibt, war diese Rolle in der ITIL Version 2, abgesehen von der Publikation „Business Perspective Volume 2“, nicht explizit beschrieben. In einigen Textpassagen wurde zwar auf einen Service Manager hingewiesen, aber eine Rollenbeschreibung hierfür lag nicht vor. In der ITIL Version 3 ist auch die Rolle des Service Managers beschrieben (vgl. [OGC, 2007e]): Der Service Manager ist eine wichtige Rolle für die Entwicklung, Implementierung, Evaluation und das fortlaufende Management neuer und existierender Produkte und Services. Seine Verantwortung umfasst die Entwicklung der Geschäfts-Strategie, Markt- und Kunden-Analyse, Lieferanten-Management, Inventarisierung, Kosten Management und insbesondere das Auslieferungs- und Lebenszyklus-Management von Produkten und Services.
Die ISO 20000 empfiehlt, dass ein Mitglied des oberen Managements („senior level”) die Verantwortung für den Service Management-Plan und dessen Umsetzung übernehmen sollte (vgl. [ISO 20000-2, 2005]). Innerhalb dieses Service Management-Plans wird die Zielsetzung und Ausgestaltung des IT Service Managements beschrieben.
109
3 IT Prozess-Management Daraus folgt, dass es eine den einzelnen Prozess Ownern und Prozess Managern vorgesetzte Instanz gibt und diese dem oberen Management angehört. Das IT Service Management und die damit verbundenen Prozesse dienen keinem Selbstzweck, sondern sind in die IT-Planung und -Strategie einzubinden. Letztendlich leiten sich die konkrete Ausrichtung der Prozesse und ihre Zielsetzung aus den Business-Anforderungen und der ITStrategie ab. Dabei kann sich die konkrete Ausprägung in Abhängigkeit von den aktuellen Business-Anforderungen und der IT-Strategie durchaus ändern. So besteht zum Beispiel die Zielsetzung des Capacity Managements gemäß ITIL darin, dass „... die aktuellen und zukünftigen geschäftlichen Anforderungen im Hinblick auf Kapazitäten und Performance auf wirtschaftliche Weise erfüllt werden ...“. Befindet sich eine Organisation in einer starken Wachstumsphase, so wird das Capacity Management auf die Bereitstellung der erforderlichen Kapazitäten fokussiert sein. Muss die Organisation dagegen primär Kosten einsparen, so gewinnt die Wirtschaftlichkeit der Bereitstellung in der Regel ein größeres Gewicht. Die grundsätzliche Zielsetzung an ein Capacity Management ändert sich zwar nicht, aber die konkrete Ausgestaltung der Ziele ist abhängig von den Geschäftsanforderungen. Daher benötigen die Prozess Owner und Prozess Manager entsprechende Vorgaben, die in die Prozessziele eingehen und letztendlich auch Auswirkungen auf das Kennzahlensystem haben. Diese Vorgaben werden vom oberen Management getroffen und liegen in der Verantwortung des Service Managers. Eine weitere Aufgabe des Service Managers besteht darin, eine Eskalationsebene für die Prozess Owner und Prozess Manager zu bieten, da die einzelnen IT Service Management-Prozesse durchaus konkurrierende Ziele verfolgen können. Der Service Manager kann mit einem Städteplaner verglichen werden, während die Prozess Owner und Prozess Manager die Architekten und die Bauaufsicht darstellen.
3.3.2.2 Prozess Owner Der Prozess Owner ist für die Zielerreichung des jeweiligen Prozesses verantwortlich. Der Prozess Owner hat demzufolge die Ergebnisverantwortung für den jeweiligen Prozess. Eine Möglichkeit, die Verantwortlichkeiten für Aktivitäten übersichtlich darzustellen, besteht mittels einer RACI-Matrix. Dabei leitet sich der Name aus den vier Verantwortlichkeiten „Responsible“, „Accountable“, „Con-
110
3.3 Etablierung des Prozess-Managements sulted“ und „Informed“ ab. Dabei wird Responsible als Verantwortung für die Durchführung verstanden. Accountable ist dagegen die Person, die die Gesamt- und letztendlich die Ergebnisverantwortung trägt. Bei der Darstellung in Form der RACI-Matrix werden in einer Matrix Rollen gegenüber Aktivitäten aufgetragen (Abbildung 36). Durch Eintragen der Buchstaben R, A, C und I werden die Aktivitäten den Rollen zugeordnet. Diese Form zur Darstellung der Prozessaktivitäten und Rollen (Funktionen innerhalb der Organisation) wird von ITIL und COBIT genutzt. Role Responisibility
Change
Change en-
Change
Change
sponsor,
abler, e.g.
agent, e.g.
target, e.g.
e.g. busi-
process own-
team leader
individual
ness and IT leaders
ers, service owners
instructing change
performing the change
Articulate a vision for the business and service change in their domain Recognize and handle resistance to change
A/R
A/R
C
I
A/R
A
A
C
A/R
A/R
C
C
A/R
A/R
C
C
Initiate change, understand the levers for change and the obstacles Manage change and input to change plan
Abbildung 36:
Ausschnitt der RACI-Matrix zum Change Management (vgl. [OGC, 2007c])
Die Definition der zu erreichenden Ziele wird mit dem Service Manager abgestimmt und entsprechend dokumentiert. In der ITIL Version 3 wird die Rolle des Prozess Owners wie folgt definiert (vgl. [OGC, 2007b): Der Prozess Owner ist dafür verantwortlich, dass ein Prozess zweckmäßig ist. Die Verantwortung des Prozess Owners schließt die Unterstützung, das Design, das Change Management und die beständige Verbesserung des Prozesses und der damit verbunden Messsysteme ein.
Auf Basis der definierten Ziele legt der Prozess Owner gemeinsam mit dem Prozess Manager die damit verbundenen Kennzahlen fest. Erst mithilfe dieser Kennzahlen kann gesichert festgestellt werden, ob der Prozess
111
Die Definition von Kennzahlen setzt definierte Prozessziele voraus
3 IT Prozess-Management die definierten Ziele hinsichtlich der erwarteten Effektivität und Effizienz erreicht. Die Kennzahlen (KGI, KPI) sind top down zu entwickeln. Aus den BusinessAnforderungen und der IT-Strategie ergeben sich die jeweiligen Prozessziele. Mittels der definierten Kennzahlen erfolgt dann das Management der Prozesse, um die geforderte Effektivität und Effizienz zu erreichen. Die Kennzahlen signalisieren dem Prozess Owner, ob die definierten Ziele erreicht werden.
Es hat sich bewährt, dass der Prozess Owner dem IT-Management angehört. So ist einerseits die Abstimmung mit den Business-Anforderungen sowie mit der IT-Strategie sichergestellt. Anderseits erfährt der Prozess die notwendige Managementunterstützung. Es kann durchaus vorgekommen, dass der Prozess Manager innerhalb der Organisation auftretende Widerstände überwinden muss. Hier kann ihm ein Prozess Owner aus dem ITManagement die notwendige Unterstützung bieten. Außerdem wird damit ein wichtiges Signal für alle Mitarbeiter gegeben: „IT Service Management wird von unserem Management“ aktiv gefördert. Dies setzt aber selbstverständlich voraus, dass das IT-Management die Prozesse aktiv vorlebt und sich selbst an diese Prozesse hält.
3.3.2.3 Prozess Manager Die Verantwortung des Prozess Managers besteht in der erfolgreichen Umsetzung des Prozesses auf Basis der definierten Ziele. Der Prozess Manager ist für die Durchführung des Prozesses verantwortlich. In der ITIL Version 3 wird die Rolle des Prozess Managers wie folgt definiert (vgl. [OGC, 2007b): Der Prozess Manager ist für das operationelle Management des Prozesses verantwortlich. Die Verantwortung des Prozess Managers umfasst die Planung und Koordinierung aller Aktivitäten, deren Monitoring und deren Berichterstattung. In größeren Organisationen kann es durchaus mehrere Prozess Manager für einen Prozess geben, wie zum Beispiel regionale Change Manager pro Niederlassung.
In kleineren IT-Organisationen erfolgt keine Unterteilung zwischen Prozess Owner und Prozess Manager. Die Ergebnis- und Durchführungsverantwortung wird dann gemeinsam wahrgenommen. Im Rahmen der Durchführungsverantwortung gestaltet der Prozess Manager den Prozess und definiert die durchführenden Aktivitäten. Er stellt sicher, dass der Prozess mit den notwendigen Ressourcen unterstützt wird. Der Prozess Manager hat dazu die kritischen Erfolgsfaktoren (CSF: Critical
112
3.3 Etablierung des Prozess-Managements Success Factors) zu identifizieren und durch geeignete Maßnahmen abzusichern (= „Plan“ im PDCA-Zyklus). Mögliche Schwachstellen im Prozess sind vom Prozess Manager zu analysieren und durch geeignete Verbesserungsmaßnahmen nachhaltig zu beseitigen (= „Act“ im PDCA-Zyklus). Angesichts der Komplexität der Prozesse und der verschiedenen Beteiligten in unterschiedlichen Organisationseinheiten benötigt der Prozess Manager hierzu eine gesicherte Informationsbasis, er benötigt Prozesskennzahlen (= „Check“ im PDCA-Zyklus). Die Prozess-Kennzahlen sind Indikatoren. Sie informieren über die Zielerreichung bzw. über das Verlassen eines Zielbereichs. Unter der weiteren Berücksichtigung von Trendinformationen kann so der Prozess Manager aktiv werden. Die Indikatoren zeigen an, dass etwas passiert. Ein Indikator kann zum Beispiel sein, dass die definierten Lösungszeiten für Incidents nicht eingehalten werden, oder dass die Implementierung von Changes zu Incidents führt. Ein Indikator zeigt aber nicht an, warum etwas passiert ist. Die Kennzahlen sind für den Prozess Manager ein äußerst wichtiges Management-Werkzeug. Sie signalisieren was im Prozess passiert und – in Verbindung mit Trenddaten – wie sich der Prozess entwickelt. Nur mit entsprechenden Kennzahlen kann der Prozess Manager seiner Verantwortung nachkommen.
Um feststellen zu können, warum etwas passiert ist, muss der Prozess Manager einzelne Kennzahlen in Zusammenhang bringen. Zum Beispiel könnte geprüft werden, ob neue Services eingeführt wurden und damit erklärbar wird, warum die Lösungszeiten den vorgegeben Wert nicht mehr erreichen. Der Prozess Manager muss hierzu die Einflussfaktoren identifizieren, Zusammenhänge zuordnen und letztendlich die eigentlichen Ursachen analysieren (= „Check“ im PDCA-Zyklus). Die IT Service Management-Prozesse sind gekennzeichnet durch wechselseitige Aktivitäten. Der Prozess Manager benötigt daher nicht nur das Know-how für seinen eigenen Prozess, sondern muss auch über Grundlagenwissen zu den anderen Prozessen verfügen. Ohne dieses Wissen kann der eigene Prozess nicht erfolgreich gestaltet und gesteuert werden. Hinzu kommt, dass Kennzahlen zum Teil aus Daten anderer Prozesse generiert werden. So ist eine wichtige Kennzahl im Change Management „Anzahl von Störungen, die auf Änderungen zurückgeführt wurden“. Die Generierung dieser Kennzahl benötigt demzufolge Informationen aus dem Incident Management. Hierzu muss der Prozess Manager um das beschriebene Grundlagenwissen zu allen IT Service Management-Prozessen verfügen. Andererseits muss er die Ermittlung bzw. Nutzung der benötigen Daten mit einem anderen Prozess Manager abstimmen.
113
Kennzahlen sind die Arbeitsinstrumente des Prozess Managers.
3 IT Prozess-Management Der Prozess Manager benötigt Grundlagenwissen zu allen IT Service Management-Prozessen. Bei der Gestaltung des Prozesses und der Definition der Kennzahlen ist eine enge Zusammenarbeit mit den anderen Prozess Managern von großer Bedeutung.
3.3.2.4 Prozess-Mitarbeiter Die Prozess-Mitarbeiter sind für bestimmte Aktivitäten in einem Prozess verantwortlich und berichten dem Prozess Manager. Sie führen die Aktivitäten im Prozess durch, die ihrer fachlichen Qualifikation entsprechen. Neben der entsprechenden theoretischen Schulung benötigen die Mitarbeiter auch das Wissen um die konkrete Zielsetzung des Prozesses. Hierzu empfiehlt es sich, zunächst auch die Prozess-Mitarbeiter in den ITIL Grundlagen zu schulen und anschließend die Prozessschulungen durchzuführen. Mit der Einführung von Prozessen ändern sich häufig bestehende Abläufe und durchzuführende Aktivitäten. Kennzahlen unterstützen hierbei das notwendige Veränderungsmanagement. Anhand von Kennzahlen kann den Prozess-Mitarbeitern dargestellt werden, wie wirksam der Prozess ist und wie ihre Leistungen sowie die veränderten Arbeitsweisen zum erzielten Erfolg beitragen. Nach Möglichkeit sollten die Kennzahlen nicht nur dem Management zur Verfügung stehen. Auch die IT-Mitarbeiter sollten hierauf Zugriff haben.
3.3.2.5 Betriebs- und Personalrat Abschließend muss an dieser Stelle auf den Betriebs- bzw. Personalrat eingegangen werden. Die Kennzahlen zu den einzelnen Prozessen werden häufig aus operativen Systemen, wie zum Beispiel den Daten eines IT Service Management-Tools, generiert. Damit greifen die Kennzahlensysteme auf Daten zurück, die die Möglichkeit zur Leistungsbeurteilung von Mitarbeitern eröffnen. Kennzahlen sind informations- und/ oder mitbestimmungspflichtig
Innerhalb Deutschlands ist für die Erfassung und Auswertung derartiger Daten die Zustimmung des Betriebs- bzw. Personalrats erforderlich. Die geplanten Kennzahlen zur Beurteilung der IT Service Management-Prozesse sollten frühzeitig mit dem Betriebs- bzw. Personalrat abgestimmt werden. Insbesondere sollte dem Betriebs- bzw. Personalrat dargelegt werden, dass das System der Beurteilung von Prozessen dient und nicht der Beurteilung von Mitarbeitern.
114
3.4 Definition der Prozessziele und -Kennzahlen
3.4 Definition der Prozessziele und -Kennzahlen 3.4.1
Definition der Prozessziele
Die hier dargestellte Vorgehensweise der Zieldefinition und die daraus abgeleiteten Kennzahlen basieren auf erfolgreich durchgeführten ISO 20000-Projekten. Im Rahmen dieser Projekte wurden mit dem im Folgenden beschriebenen Konzept die ISO 20000 Anforderungen an das übergeordnete Managementsystem sichergestellt, und so die Basis für eine erfolgreiche Zertifizierung gelegt. Ungeachtet einer ISO 20000 Zertifizierung empfiehlt es sich jedoch generell, diese Vorgehensweise bei der Einführung von IT Service Management-Prozessen zu nutzen. Diese Vorgehensweise entspricht auch der ITIL Version 3 mit dem beschriebenen Service Lifecycle und der „Service Strategy“ als Mittelpunkt bzw. Ausgangspunkt des Service Lifecycle. Die hier beschriebene Vorgehensweise stellt sicher, dass die IT Service Management-Prozesse den Geschäftsanforderungen entsprechen, in die IT-Strategie eingebunden sind und die definierten Ziele mit endlichen Ressourcen wirkungsvoll erreicht werden können.
Die Kennzahlen und deren Zielwerte sind unmittelbar mit den Prozesszielen verbunden. Daher können die Kennzahlen und deren Zielwerte erst dann definiert werden, wenn die konkreten Prozessziele spezifiziert sind. Mithilfe von COBIT und ITIL kann dann geprüft werden, welche Best Practice Kennzahlen sich hierfür anbieten. In Projekten mussten darüber hinaus aufgrund der Prozessziele zum Teil Kennzahlen definiert werden, die in COBIT und ITIL nicht spezifiziert sind. Mögliche KPI, KGI aus COBIT und ITIL auszuwählen, ohne die Prozessziele zuvor definiert zu haben, ist nicht zielführend. Gegebenenfalls sind Kennzahlen zu spezifizieren, die in COBIT und ITIL nicht dokumentiert sind.
Die Prozessziele und die damit verbundenen Kennzahlen sowie deren Zielwerte sind in dem bereits zuvor angesprochenen top down-Ansatz zu definieren. Ein wichtiger Ausgangspunkt bei der Definition von Prozesszielen sind die Anforderungen des Kunden bzw. dessen Geschäftsprozesse. Die Anforderungen aus den Geschäftsprozessen beziehen sich in erster Linie auf die bereitzustellenden IT Services. In der Regel liegen die damit verbundenen (internen) IT Service Management-Prozesse der IT nicht im Blickpunkt des Kunden. Der Kunde benötigt die IT Services zur Durchführung seiner Geschäftsprozesse und die IT hat dies gemäß den getroffenen Vereinbarungen sicherzustellen. Wie diese Bereitstellung bestmöglich erfolgt, über-
115
3 IT Prozess-Management lässt der Kunde der IT-Organisation, in deren Verantwortung die entsprechende Umsetzung grundsätzlich liegen sollte. Die Anforderungen an die IT Services werden mittels SLAs spezifiziert (siehe Abbildung 37). Daraus abgeleitet werden die OLAs sowie die UCs verhandelt und vereinbart. Anhand dieser Vereinbarungen sind die jeweiligen Service Level sowie die Kapazitätsanforderungen zu messen, zu berichten und regelmäßigen Reviews zu unterziehen. Business
Business-Anforderungen IT-Services
Messung Service Level (Ziele)
SLA (OLA/UC)
Kapazitäten
Abbildung 37:
Definition der IT Services
Werden Verbesserungsmaßnahmen identifiziert, sind diese gemäß ITIL und der ISO 20000 in einem Service Improvement Plan (SIP) zu dokumentieren. Betreffen diese Verbesserungsmaßnahmen die implementieren IT Service Management-Prozesse, so werden sie im Prozess Improvement Plan (PIP) des jeweiligen Prozesses dokumentiert (siehe Abbildung 38). In der ISO 20000 werden zwar Reviews in den Prozessen und deren Dokumentation gefordert, aber nicht näher spezifiziert, wo diese Dokumentation zu erfolgen hat. In der Projektpraxis hat sich herausgestellt, dass der SIP hierfür wenig geeignet ist, da hier eine Vermischung von Informationen erfolgt. Für die Dokumentation sind daher die PIPs zu definieren. Dieses Konzept wurde erstmalig erfolgreich bei der ISO 20000 Zertifizierung der badenIT umgesetzt und wird im Folgenden vorgestellt.
116
3.4 Definition der Prozessziele und -Kennzahlen Business
Business-Anforderungen IT-Services
Messung Service Level (Ziele)
SLA (OLA/UC)
Kapazitäten Service Improvement Plan (SIP) Verbesserungspotenzial
Abbildung 38:
Prozess Improvement Pläne (PIP)
Definition der IT Services – Service Improvement Plan
Bei Kunden-Anforderungen an neue IT Services und bei veränderten Anforderungen an bestehende IT Services (siehe Abbildung 39) ist zu prüfen, ob die etablierten IT Service Management-Prozesse diesen Anforderungen genügen oder unter Umständen die Prozessziele sowie die damit verbundenen Prozessaktivitäten anzupassen sind. Außer den Anforderungen an die IT Services gibt es weitere übergeordnete Kunden- und Geschäfts-Anforderungen an die IT-Organisation, die Auswirkungen auf die IT Service Management-Prozesse haben (siehe Abbildung 40). Zu den Geschäftsanforderungen des Business gehören zum Beispiel die Forderungen nach einem IT Qualitätsmanagement, nachgewiesen durch die ISO 20000 Zertifizierung. Als zweiter Block stehen die regulativen Anforderungen (Compliance Anforderungen) wie zum Beispiel SOX, Euro SOX, Basel II oder GXP für Unternehmen in der PharmaBranche. Diese Anforderungen haben Auswirkungen auf die IT Service Management-Prozesse, deren Zielsetzung und letztendlich auf die damit verbundenen Kennzahlen.
117
3 IT Prozess-Management Business
Business-Anforderungen IT-Services
Messung Service Level (Ziele)
Neue oder veränderte IT-Services
SLA (OLA/UC)
Kapazitäten Service Improvement Plan (SIP) Verbesserungspotenzial
Abbildung 39:
Prozess Improvement Pläne (PIP)
Definition der Prozessziele – Neue Services
Business
Business-Anforderungen IT-Services
Messung Service Level (Ziele)
SLA (OLA/UC)
Neue oder veränderte IT-Services
KundenAnforderungen
GeschäftsAnforderungen
Kapazitäten Service Improvement Plan (SIP) Verbesserungspotenzial
Abbildung 40:
118
Prozess Improvement Pläne (PIP)
Definition der Prozessziele – Kundenanforderungen
3.4 Definition der Prozessziele und -Kennzahlen Auf Basis der geschäftspolitischen Ziele des Unternehmens, die größtenteils bereits in den zuvor genannten Anforderungen beschrieben sind, wird die IT-Strategie entwickelt (siehe Abbildung 41). Im Rahmen der Entwicklung und Weiterentwicklung der IT Service Management-Prozesse sind diese strategischen Ziele ebenfalls zu berücksichtigen. Business
Business-Anforderungen IT-Services
Messung Service Level (Ziele)
SLA (OLA/UC)
Neue oder veränderte IT-Services
KundenAnforderungen
GeschäftsAnforderungen
ITStrategie
Kapazitäten Service Improvement Plan (SIP) Verbesserungspotenzial
Abbildung 41:
Prozess Improvement Pläne (PIP)
Definition der Prozessziele – IT-Strategie
Auch mögliche finanzpolitische Aspekte haben Auswirkungen auf die IT Service Management-Prozesse und deren Ziele. Dies wird in der ITIL Version dadurch zum Ausdruck gebracht, dass das Financial Management der „Service Strategy“ zugeordnet ist. Die Geschäftsanforderungen an das Service Management können im Rahmen einer übergeordneten Balanced Scorecard und einer daraus abgeleiteten IT Balanced Scorecard vorgegeben werden. Diese Durchgängigkeit von der Balanced Scorecard zu den Zielen des Service Managements und den Prozesszielen hat zum Beispiel die badenIT in Freiburg erfolgreich umgesetzt. Im Rahmen der ISO 20000 Zertifizierung wurde dieser Aspekt von den Prüfern besonders positiv hervorgehoben. Dem Kapitel 6 „Lessons learned“ ist ein weiteres Beispiel für die Ableitung der Service Management-Prozess-Ziele aus der IT-Strategie und der BSC zu entnehmen.
119
3 IT Prozess-Management Eine weitere Quelle für die Definition der Prozessziele der IT Service Management-Prozesse, damit deren Kennzahlen und Sollwerte, sind die Ergebnisse der „Prozess Improvement Pläne“ (PIPs). In diesen Plänen ist prozessbezogen der jeweils identifizierte Verbesserungsbedarf der IT Service Management-Prozesse dokumentiert (siehe Abbildung 42). Der Verbesserungsbedarf wird im Rahmen von Audits und Reviews sowie anhand der vorliegenden Prozess-Kennzahlen, deren Sollwerten und der nachfolgenden Analysen des Prozesses ermittelt. Business
Business-Anforderungen IT-Services
Messung Service Level (Ziele)
SLA (OLA/UC)
Neue oder veränderte IT-Services
KundenAnforderungen
GeschäftsAnforderungen
ITStrategie
Kapazitäten Service Improvement Plan (SIP) Verbesserungspotenzial
Prozess Improvement Pläne (PIP) Verbesserungspotenzial
IT Service ManagementProzesse
Abbildung 42:
Definition der Prozessziele – Prozess Improvement Plan
Diese Informationen sind der Input für die „Planung und Implementierung des IT Service Managements“ (siehe Abbildung 43). Im Rahmen der Planung und Implementierung des IT Service Managements wird die Ausgestaltung des gesamten Systems durchgeführt. Dazu zählt auch die Festlegung der Ziele für die einzelnen Service Management-Prozesse.
120
3.4 Definition der Prozessziele und -Kennzahlen Diese übergeordnete Management-Aufgabe ist nicht als einmaliger Vorgang zu verstehen, sondern sie ist eine fortlaufende Aktivität und entspricht dem kontinuierlichen Verbesserungsprozess gemäß PDCA-Zyklus. Die Planung und Implementierung des IT Service Managements ist kein Projekt, sondern ein übergeordneter Management-Prozess. Business
Business-Anforderungen IT-Services
Messung Service Level (Ziele)
SLA (OLA/UC)
Neue oder veränderte IT-Services
KundenAnforderungen
GeschäftsAnforderungen
ITStrategie
Kapazitäten Service Improvement Plan (SIP) Verbesserungspotenzial
Planung und Implementierung des IT Service Managements
Prozess Improvement Pläne (PIP) Verbesserungspotenzial
IT Service ManagementProzesse
Abbildung 43:
Definition der Prozessziele – Planung und Implementierung
Mit diesem übergeordneten Management-Prozess wird sichergestellt, dass die IT Service Management-Prozesse auf die Geschäftsziele und daraus abgeleitete IT-Strategie ausgerichtet sind. Durch die kontinuierliche Anpassung an eine sich ändernde Umgebung und durch die laufende Erfolgsüberprüfung wird die Nachhaltigkeit der implementierten Prozesse sichergestellt. Das Ergebnis der „Planung und Implementierung des IT Service Managements“ sind die Zielvorgaben für die einzelnen IT Service ManagementProzesse. Diese Vorgaben sind ein Teil des dokumentierten „Service Ma-
121
3 IT Prozess-Management nagement Plans“ (SMP). Während im Service Improvement Plan (SIP) die identifizierten Serviceverbesserungen definiert sind, enthält der Service Management Plan (SMP) die Dokumentation des aktuellen IT Service Management-Systems. Dieser SMP wird als Dokumentation von der ISO 20000 gefordert. Zusätzlich fließen die Ergebnisse aus „Planung und Implementierung des IT Service Managements“ in die Prozess-Management Pläne (PMPs) ein (siehe Abbildung 44). Durch die PMPs werden auf Prozessebene die übergeordneten Managementziele für den jeweiligen Prozess konkretisiert. Der PMP kann als Prozessdokumentation mit allen notwendigen Informationen wie Prozessbeschreibung, Kennzahlen und deren Zielwerte, etc. angesehen werden. Business
Business-Anforderungen IT-Services
Messung Service Level (Ziele)
SLA (OLA/UC)
Neue oder veränderte IT-Services
KundenAnforderungen
GeschäftsAnforderungen
ITStrategie
Kapazitäten Service Improvement Plan (SIP) Verbesserungspotenzial
Planung und Implementierung des IT Service Managements Anforderungen
Service Management Plan (SMP)
Abbildung 44:
122
Prozess Improvement Pläne (PIP) Verbesserungspotenzial
Anforderungen
IT Service ManagementProzesse
Prozess Management Pläne (PMP)
Definition der Prozessziele – Service Management Plan
3.4 Definition der Prozessziele und -Kennzahlen Der hier beschriebene Managementansatz mag zunächst komplex und administrativ erscheinen, aber er stellt letztendlich die wirksame Ausrichtung des IT Service Managements sicher und sorgt für einen zielgerichteten Einsatz der Ressourcen. Die Verantwortung für diesen übergeordneten Prozess liegt beim Top-Management der IT-Organisation in der Rolle des Service Managers. Der Service Manager führt diese Aufgaben durch und stellt das übergeordnete Management-System sicher.
Ein Prozess-Management führt mittel- und langfristig zu Erfolgen. Gegebenenfalls sind Quick-Wins – abhängig von der bestehenden Ist-Situation – zu erzielen, sie stehen aber nicht im Fokus eines Prozess-Managements. Der hier beschriebene konzeptionelle Management-Ansatz erfüllt die Anforderungen der ISO 20000. Dieser Management-Ansatz stellt sicher, dass die konkrete Zielsetzung der einzelnen IT Service Management-Prozesse aus den Geschäftsanforderungen stringent abgeleitet wird. Im nächsten Kapitel wird dargestellt, wie die Kennzahlen und Sollwerte auf Basis der Zielsetzung definiert werden. Damit wird letztendlich sichergestellt, dass die Kennzahlen unmittelbar oder mittelbar mit den Geschäftsanforderungen der Kunden korrespondieren.
Die ISO 20000 dokumentiert die Anforderungen an dieses ManagementSystem und kann zum Nachweis der Konformität herangezogen werden (siehe Abbildung 45). Die konkrete Umsetzung ist Projektaufgabe. Es können zwar dezentral einzelne Service Management-Prozesse implementiert werden und einzelne beschriebene Aktivitäten umgesetzt werden, aber die Etablierung eines IT Service Managements verlangt unabdingbar das Management-Commitment und eine Integration in die bestehenden Management-Prozesse sowie in die IT-Strategie.
123
3 IT Prozess-Management Business
Business-Anforderungen IT-Services
Messung Service Level (Ziele)
SLA (OLA/UC)
Neue oder veränderte IT-Services
KundenAnforderungen
GeschäftsAnforderungen
ITStrategie
Kapazitäten Service Improvement Plan (SIP) Verbesserungspotenzial
Konformität
ISO 20000 IT Service Management
Anforderungen
Service Management Plan (SMP)
Abbildung 45:
3.4.2 Die Prozessdokumentation stellt die Leitlinien dar.
Planung und Implementierung des IT Service Managements
Prozess Improvement Pläne (PIP) Verbesserungspotenzial
Anforderungen
IT Service ManagementProzesse
Prozess Management Pläne (PMP)
Konformität des Managementsystems
Definition der Prozess-Kennzahlen
Auf der Basis der definierten Ziele sind die Control Objectives zu spezifizieren, die Prozessaktivitäten zu definieren und die kritischen Erfolgsfaktoren zu ermitteln. Das Prozessdesign erfolgt letztendlich auf der Basis der zuvor festgelegten Prozessziele (siehe Abbildung 46). Der Umfang der zu erstellenden Prozessdokumentation ist abhängig von der jeweiligen Unternehmenskultur. Es ist ein Kompromiss zu finden zwischen der Dokumentation notwendiger Informationen und Vorgaben einerseits und einem ausreichenden Gestaltungsspielraum für die Mitarbeiter andererseits. Hier sollte nicht der Anspruch bestehen, dass der erste Entwurf alle Eventualitäten abdeckt und fehlerfrei ist. Erfahrungsgemäß ergibt sich im täglichen Betrieb ein Optimierungsbedarf. Diese Einstellung und Erwartungshaltung sollte auch gegenüber den Mitarbeitern kommuniziert werden.
124
3.4 Definition der Prozessziele und -Kennzahlen Die Mitarbeiter sollten aufgerufen werden, den notwendigen Verbesserungsbedarf zu identifizieren und an den Prozess Manager weiterzugeben. Es darf nicht an fehlerhaften Abläufen festgehalten werden. Allerdings sind notwendigen Abweichungen in die richtigen Bahnen zu lenken und Änderungen müssen Einzug in die Prozessdokumentation finden. Service Management Plan (SMP)
Prozess Management Plan (PMP)
IT Service ManagementProzesse
Wird sichergestellt durch
Aktivitäten Kritische Erfolgsfaktoren Control Objectives Abbildung 46:
Prozess-Management – Prozessdesign
Zeitgleich mit dem Prozessdesign und vor der Implementierung sind die Kriterien festzulegen, die die Überprüfung des Prozesses sicherstellen. Zunächst geht es darum zu überprüfen, ob die definierten Prozessziele erreicht werden. Das heißt, es wird die Effektivität des Prozesses überprüft. Darüber hinaus gilt es im Rahmen der Prozessdurchführung festzustellen, ob und wie die definierten Prozessaktivitäten durchgeführt werden und ob die Control Objectives und die kritischen Erfolgsfaktoren sichergestellt werden. Diese Überprüfungen können mit Kennzahlen und den zugehörigen Sollwerten, Reviews und Audits durchgeführt werden. Dabei gehen die Ergebnisse aus den durchgeführten Reviews und Audits wiederum in Kennzahlen ein (siehe Abbildung 47). Mit diesen Überprüfungen wird die Wirksamkeit des Prozesses, betrachtet in den Dimensionen Effektivität und Effizienz, sichergestellt. Die Kennzahlen stehen in einem unmittelbaren Bezug zu den Prozesszielen. Die Kennzahlen und die damit verbundenen Sollwerte werden aus den Prozesszielen abgeleitet.
125
3 IT Prozess-Management Service Management Plan (SMP)
IT Service ManagementProzesse
Prozess Management Plan (PMP) Wird sichergestellt durch Aktivitäten Kritische Erfolgsfaktoren Control Objectives
Überprüfen / Verbessern
Kennzahlen (KPI, KGI) Abbildung 47:
Reviews/ Audits
Prozess-Management – Überprüfung
Bei der Ausgestaltung (Prozessdesign) der Prozesse und der Definition der Kennzahlen (KGI, KPI), sowie bei den durchzuführenden Audits und Reviews unterstützten die Best Practices von COBIT und ITIL (siehe Abbildung 48). Diesen Publikationen können entsprechende praxiserprobte Empfehlungen entnommen werden. Unter Umständen können aber zu den definierten Prozesszielen keine entsprechenden Kennzahlen aus COBIT und ITIL entnommen werden. In diesem Falle müssen die entsprechenden Kennzahlen und deren Zielwerte im Rahmen des Prozessdesigns definiert werden. COBIT und ITIL enthalten dokumentierte Best Practices für Kennzahlen. Es ist aber ein Irrglaube, diese Kennzahlen einfach übernehmen zu können. Vielmehr sind zunächst die Prozessziele zu definieren. Aus den Prozesszielen werden Kennzahlen und Sollwerte abgeleitet. Dabei können die Best Practices entsprechend unterstützen und herangezogen werden.
126
3.4 Definition der Prozessziele und -Kennzahlen Service Management Plan (SMP)
IT Service ManagementProzesse
Prozess Management Plan (PMP) Wird sichergestellt durch Aktivitäten Kritische Erfolgsfaktoren Control Objectives
Überprüfen / Verbessern
Kennzahlen (KPI, KGI)
Reviews/ Audits
Best Practice
COBIT
Abbildung 48:
ITIL
Prozess-Management – Nutzung von COBIT und ITIL
Sind die Kennzahlen und Zielwerte definiert, so empfiehlt es sich, als Qualitätscheck zu prüfen, ob von der Kennzahl eine unmittelbare oder mittelbare Verbindung zu einem Geschäftsziel besteht.
Möchte die IT-Organisation die Konformität mit der ISO 20000 nachweisen, so können der ISO 20000-1 (vgl. [ISO 20000-1, 2005]) die Anforderungen entnommen werden, die vom jeweiligen Prozess sichergestellt und nachgewiesen werden müssen (siehe Abbildung 49).
127
3 IT Prozess-Management Service Management Plan (SMP)
IT Service ManagementProzesse
Prozess Management Plan (PMP) Wird sichergestellt durch Aktivitäten Kritische Erfolgsfaktoren Control Objectives
Überprüfen / Verbessern
Kennzahlen (KPI, KGI)
Reviews/ Audits
Best Practice Konformität ITIL
COBIT
Abbildung 49:
ISO 20000
Prozess-Management – Konformität
Die Kennzahlen und deren laufende Überprüfung stellen die Basis für die gegebenenfalls notwendigen Verbesserungen der Prozesse dar. Ohne ausreichende Messung kann letztendlich keine zielgerichtete Verbesserung erreicht werden. Die Ergebnisse dieser Verbesserungsphase finden Einzug in dem Prozess Improvement Plan PIP (siehe Abbildung 50).
128
3.4 Definition der Prozessziele und -Kennzahlen Service Management Plan (SMP)
Prozess Improvement Plan (PIP)
IT Service ManagementProzesse
Prozess Management Plan (PMP) Wird sichergestellt durch Aktivitäten Kritische Erfolgsfaktoren Control Objectives
Überprüfen / Verbessern
Kennzahlen (KPI, KGI)
Reviews/ Audits
Best Practice Konformität COBIT
Abbildung 50:
ITIL
ISO 20000
Prozess-Management – Prozess Improvement Plan
Der hier beschriebene Managementansatz entspricht der Methode, die in der ITIL Version 3 empfohlen wird und in Continual Service Improvement [OGC, 2007e] beschrieben ist. Aus der übergeordneten Vision werden die Ziele definiert und mittels Kennzahlen gemessen. Dies stellt die nachfolgende Abbildung 51 aus [OGC, 2007e] dar.
129
3 IT Prozess-Management Vision Mission Ziele Objectives
CSFs
KPIs
Metriken Messungen Abbildung 51:
3.4.3
Entwicklung von Kennzahlen
Dokumentation der Prozess-Kennzahlen
Für die Dokumentation empfiehlt es sich, die Kennzahl mit der entsprechenden Definition, der Messmethode und anderen relevanten Informationen zu dokumentieren. Dazu bietet sich die Dokumentation in Form eines Kennzahlen-Steckbriefes an.
130
3.4 Definition der Prozessziele und -Kennzahlen
Bestandteil des Steckbriefs
Beschreibung
Kennzahl
Bezeichnung der Kennzahl
IT Service Management-Prozess
Prozess, der diese Kennzahl nutzt
Beschreibung
Beschreibung der Kennzahl, ihrer Aussagekraft und des mit dieser Kennzahl zu überprüfenden Prozesszieles
Zielwert
Zielwert der Kennzahl, der sich aus der Zieldefinition für den Prozess ergibt
Beziehung zu anderen Prozessen
Prozesse, die diese Kennzahl beeinflussen
Datenquelle
Beschreibung der Quelle für die zugrunde liegenden Daten
Formel
Berechnungsmethode zahl
Erhebungsfrequenz
Festlegung, wann/wie oft die Kennzahl fortgeschrieben wird
Auditfrequenz
Festlegung, wann/wie oft die Kennzahl hinsichtlich ihres Nutzen und ihrer Verwendung überprüft wird
Anmerkungen
Zusatzinformationen
der
Kenn-
Bei Bedarf können weitere Informationen – wie zum Beispiel Empfänger der Kennzahl, Risiken, etc. – aufgenommen werden. Im Rahmen der Prozessdokumentation ist zu prüfen, wie der KennzahlenSteckbrief zu dokumentieren ist. Es empfiehlt sich, die Beschreibung der Kennzahlen in den Service Management-Plan (SMP) aufzunehmen.
3.4.4
Reporting der Prozess-Kennzahlen
An der Zieldefinition und der Ausrichtung der IT Service ManagementProzesse sind verschiedene Management-Ebenen beteiligt. In einem top down-Ansatz erstreckt sich dieser Prozess vom Top-Management bis zum Prozess Manager.
131
3 IT Prozess-Management Kennzahlen müssen ebenengerecht sein.
So unterschiedlich die beteiligten Managementebenen sind, so unterschiedlich ist auch deren Informationsbedarf hinsichtlich der etablierten IT Service Management-Prozesse und der erbrachten Services. Der Prozess Manager benötigt im Rahmen seiner Durchführungsverantwortung verschiedene Kennzahlen (KGI, KPI), die ihm detaillierte Informationen bezüglich der Erreichung der einzelnen Prozessziele und der planmäßigen Prozessdurchführung aufzeigen. Das Top-Management möchte dagegen auf einen Blick sehen, ob das IT Service Management erfolgreich ist, ohne selbst den Zusammenhang aus verschiedenen Kennzahlen herleiten zu müssen. Das Top-Management benötigt also eine Gesamtsicht auf die Prozesse und Services. Die Kennzahlen müssen ebenengerecht aufbereitet und präsentiert werden.
Diese Anforderung des ebenengerechten Reportings lässt sich für die Rollen des Prozess Managers und zum Teil des Prozess Owners leicht umsetzen. Die für diese Rollen benötigten Kennzahlen sind die, die im Rahmen des Prozessdesigns zur Überprüfung des Prozesses definiert wurden. Die Kennzahlen hierzu sind als KPIs bzw. KGIs in COBIT und ITIL dokumentiert. Anders verhält es sich, wenn eine Gesamtbewertung knapp und präzise erfolgen muss. Dies ist beispielsweise immer der Fall, wenn der Service Manager eine Übersicht benötigt bzw. an das Top (IT-) Management berichtet. Nehmen wir an, die Fragestellung würde lauten: „Hat der Prozess Change Management seine Zielsetzung erfüllt?“ Dann müssen die ProzessKennzahlen zu einer Kennzahl zusammengefasst werden. Hierfür sind die einzelnen Kennzahlen zu gewichten und zu aggregieren So ist es für die Beurteilung seitens des Service Managers zunächst wichtig, zu erkennen, ob alle Services und alle Prozesse die Zielsetzung erfüllen - ob sie „im grünen Bereich“ sind. Am Beispiel des Change Managements könnte sich eine zusammengesetzte Kennzahl zum Prozess durch die Gewichtung der einzelnen Ziele und der damit verbundenen Kennzahlen wie folgt ergeben (siehe Abbildung 52):
132
3.4 Definition der Prozessziele und -Kennzahlen Anteil fehlerfreier Changes Anteil termingerechter Changes
60%
20%
Effektivität Change Management
Anteil kostengerechter Changes
20%
Anteil zurückgewiesener Changes
40% Effektivität Change Management
Anteil der Notfall-Changes Abbildung 52:
70%
Zielerreichung Change Management
30%
60%
Zusammengesetzte Prozess-Kennzahlen
Es ist zu empfehlen, Gesamtzusammenhänge beispielsweise in Form einer „Ampel“ darzustellen. Dabei ist es in den meisten Fällen so, dass in die Ampelbewertung auch qualitative Dinge einfließen. So könnte sich zum Beispiel eine Gesamtübersicht der Zielerreichung aller SLAs sich wie folgt (Abbildung 53) darstellen:
Abbildung 53:
Darstellung der SLAs mit dem Q-Board von Q to be
Die operativen Systeme, wie zum Beispiel die Tool-Unterstützung für das Change Management, liefern die notwendigen Basis-Informationen, aus
133
3 IT Prozess-Management denen – durch entsprechende Datenselektionen und Aggregation – die Prozess-Kennzahlen gewonnen werden können. Durch weitere Aggregationen erhalten dann der Service Manager und das Mittlere sowie das Top Management die notwendigen Informationen. Dabei sind aber nicht nur Kennzahlen zu den IT Service ManagementProzessen zu kreieren, sondern auch die erfolgreiche Umsetzung der im Service Management Plan (SMP) und Service Improvement Plan (SIP) festgelegten Verbesserungsmaßnahmen zu belegen (siehe Abbildung 54).
Top Management
Prozess Management
gewichtete Kennzahlen
ProzessKennzahlen (KGI, KPI)
ITSM-Tool(s) …. weitere operative Systeme Basisdaten aus den jeweiligen Prozessen Abbildung 54:
Service Service Improvement Management Plan Plan
Das IT Service Management Kennzahlensystem
Generell empfiehlt es sich, auf allen Hierarchieebenen für das Reporting auf grafische Elemente zurückzugreifen und Kennzahlen in den Ampelfarben darzustellen, nach dem Motto „Ein Bild sagt mehr als tausend Worte“. Hierzu wird der dargestellte Wert in Abhängigkeit der Sollwerte entsprechend farbig dargestellt oder grafisch animiert. Dazu können zum Beispiel Ampelsymbole oder Tachoscheiben herangezogen werden.
134
3.4 Definition der Prozessziele und -Kennzahlen Werden zu den absoluten Werten noch die Sollwerte und ein Trend ausgewiesen, so können die Prozess-Kennzahlen kompakt und dennoch informativ dargestellt werden. Abbildung 55 und Abbildung 56 zeigen ein anonymisiertes Projektbeispiel zum Reporting von Prozess-Kennzahlen. Die erste Seite zeigt die Gesamtbetrachtung und den Trend des Prozesses, während auf der zweiten Seite die einzelnen Prozess-Kennzahlen, deren Sollwerte und Trends ausgewiesen werden.
Incident Management Berichtsmonat: 04/2007
Prozent 110 105 100 95 90 1
2
3
4
5
6
7
8
9
10
11
12
Monat/2007
Zielerreichung in Prozent Abbildung 55:
Exemplarischer Prozess-Bericht – Deckblatt zum Report
135
3 IT Prozess-Management
70
Erstlösungsquote in %
65 60
Soll
Erstlösung
Ist
60% 62%
55 50 1
2
3
4
5
6
7
8
9
10
11
12
Monat/2007 Anzahl Major Incidents
8 6 4
Major Incident
Soll
Ist
2
5
2
0 1
2
3
4
5
6
7
8
9
10
11
12
Monat/2007
Lösungszeit Soll Prio 1 2 Prio 2 4
15
Ist
1,9 4,1
Lösungszeit in Std.
10 5 0 1
2
3
4
5
6
7
8
9
10
11
12
Monat/2007
Abbildung 56:
Exemplarischer Prozess-Bericht – Darstellung der Kennzahlen
Die Hersteller von Tools haben den Bedarf für eine übersichtliche, abgestufte Darstellung erkannt und bieten hierzu so genannte „ManagementCockpits“ an. Ein Beispiel gibt die folgende Abbildung 57.
136
3.5 Von der Kennzahl zur Verbesserungsmaßnahme
Abbildung 57:
Darstellung des Management Cockpits von iET Solutions
3.5 Von der Kennzahl zur Verbesserungsmaßnahme Die definierten Kennzahlen mit ihren jeweiligen Zielwerten, beschrieben als KGI (Key Goal Indicator) oder KPI (Key Performance Indicator), sollen erkennbar machen, dass ein Zielwert bzw. Prozessziel nicht erreicht wird. In Verbindung mit Trenddaten soll aufgezeigt werden, dass die Erreichung eines Prozesszieles gefährdet ist. Dabei kann der Indikator lediglich etwas aufzeigen. Die eigentliche Ursache ist vom Prozess Manager festzustellen. So kann dem Prozess Manager zum Beispiel aufgezeigt werden, dass sich die Erstlösungsquote im Incident Management verschlechtert (siehe Abbildung 58).
137
3 IT Prozess-Management
Abbildung 58:
Beispiel für eine Trenddarstellung
Der Prozess Manager hat durch detaillierte Auswertung festzustellen, warum sich die Erstlösungsquote verschlechtert. Hierzu muss der Prozess Manager analytisch tätig werden, indem er versucht, verschiedene Einflussfaktoren zu untersuchen, die einen möglichen Einfluss auf die Erstlösungsquote haben. Angenommen, ein neuer IT Service wurde eingeführt, könnte die Betrachtung der „Erstlösungsquote in Abhängigkeit von dem durch die aufgetretene Störung betroffenen IT Service sein“ hilfreich sein (siehe Abbildung 59). Hierzu wird die vorherige Auswertung der Erstlösungsquote in Abhängigkeit vom betroffenen Service ausgewertet. In diesem Beispiel zeigt die Auswertung eine schlechter werdende Erstlösungsquote für die Services „eMail“ und „Kfz-Dialog“.
138
3.5 Von der Kennzahl zur Verbesserungsmaßnahme
Abbildung 59:
Beispiel 1 für eine Analyse möglicher Ursachen
In einem weiteren Analyseschritt könnte der Prozess Manager dann zum Beispiel auswerten, ob sich hierzu die zugrunde liegenden Fehlerursachen verändert haben (siehe Abbildung 60). Der Prozess Manager benötigt für diese weitergehenden Analysen nicht nur Prozess-Know-how sondern auch umfangreiche Erfahrungen im täglichen Betrieb und das Wissen um mögliche Abhängigkeiten. Die möglichen Ursachen sind nicht immer offensichtlich, sondern erfordern analytisches Vorgehen – Detektivarbeit. Dabei ist eine geeignete Toolunterstützung von großem Vorteil. Das eingesetzte Tool sollte über variable Drill-Down-Möglichkeiten verfügen, sodass Analysen und deren Richtung situativ durchgeführt werden können.
139
3 IT Prozess-Management
Abbildung 60:
Beispiel 2 für eine Analyse möglicher Ursachen
3.6 Kennzahlen müssen reifen So wie die IT Service Management-Prozesse sich entwickeln und reifen müssen, so müssen auch die Kennzahlen reifen. Werden noch keine Prozesse gemessen, so empfiehlt es sich zunächst, die wichtigsten Prozessziele mit Kennzahlen zu hinterlegen. Mit diesen Kennzahlen kann das Managementsystem aufgebaut werden und es können erste Erfahrungen gesammelt werden. Liegen noch keine gesicherten Informationen zu einem Prozess vor, so muss sich der Prozess Manager zunächst einen Eindruck über das zu bewältigende Volumen im Prozess verschaffen. Welche Inputs hat der Prozess zu bewältigen? Zum Beispiel: Wie viele Incidents sind zu bearbeiten oder wie viele Changes sind auszuführen? Werden diese Vorgänge für das Incident, Problem und Change Management in Kategorien und Prioritäten unterteilt, so liegen bereits erste wichtige Informationen vor.
140
3.7 Der Umgang mit Kennzahlen Die Informationen zum Umfang des Inputs sind auch für die späteren Auswertungen als Referenzgröße von großer Bedeutung. Mögliche Veränderungen in den ermittelten Kennzahlen lassen sich häufig auf einen veränderten Input zurückführen. Zunächst gilt es, das Volumen des Inputs (Durchsatz) zu messen. Die Größe ist auch für vergleichende Betrachtungen von großer Bedeutung.
Eine weitere wichtige Betrachtung für den Prozess Manager ist die zeitliche Entwicklung. Trendinformationen können frühzeitig Handlungsbedarf aufzeigen und ermöglichen es, Maßnahmen zu ergreifen, bevor die Sollwerte unter- bzw. überschritten werden. Damit Trends dargestellt werden können, ist eine Stabilität im Kennzahlensystem notwendig. Sobald Kennzahlen vorliegen, sollten Änderungen der Berechnungsmethoden sorgsam geprüft werden. Die Berechnungsgrundlagen der Kennzahlen sollten nur nach sorgsamer Prüfung verändert werden. Ansonsten können keine verlässlichen Trends ausgewertet werden.
Die Prozesse sind hinsichtlich ihrer Zielerreichung (Key Goal Indicator = Effektivität) und ihrer Leistungsfähigkeit (Key Performance Indicator = Effizienz) zu messen. Dabei steht die Zielerreichung, die Betrachtung des Outputs, im Vordergrund. Demzufolge gilt es, sich zunächst auf die Einführung dieser Kennzahlen zu konzentrieren. Im Anschluss können diese Kennzahlen um Kennzahlen für eine Betrachtung der Effizienz erweitert werden. Die Anzahl genutzter Kennzahlen sollte im eingeschwungenen Zustand pro Prozess bei maximal zwischen 10-15 Kennzahlen liegen.
3.7 Der Umgang mit Kennzahlen Die Kennzahlen dienen primär als Management-Werkzeug für den Prozess Manager und den Prozess Owner. Diese können anhand der Kennzahlen erkennen, ob die Prozessziele erreicht werden und ob der Prozess wirkungsvoll durchgeführt wird. Darüber hinaus unterstützen die Kennzahlen den Prozess Manager bei der Identifizierung eines möglichen Verbesserungspotenzials, bei der Darstellung komplexer Sachverhalte und bei der Begründung möglicher Veränderungsmaßnahmen. Durch die Definition einer Kennzahl stellt das Prozess-Management die Bedeutung der damit verbundenen Aktivitäten heraus.
141
3 IT Prozess-Management Die Organisation wird demzufolge ihr Handeln auf die Erreichung des festgelegten Sollwerts für die Kennzahl ausrichten. Dieses Ziel wird jedoch auch dann angestrebt werden, wenn sich dies für das Unternehmen nachteilig auswirken sollte! Wird beispielsweise für den Service Desk eine maximale Bearbeitungszeit von 5 Minuten pro Telefonat als Zielwert vorgegeben, so werden die Mitarbeiter sich an dieser Kennzahl orientieren. Die Telefonate werden innerhalb dieser Zeit abgeschlossen, auch wenn eine mögliche Störung innerhalb der nächsten 30 Sekunden gelöst werden könnte. Das Verhalten der Mitarbeiter wird sich an den festgelegten Kennzahlen orientieren.
Der Prozess Manager muss sich dieses Verhaltens bewusst sein. Eine Möglichkeit, dem zu begegnen besteht darin, mit einer anderen Kennzahl negativen Auswirkungen entgegen zu wirken. Viel wichtiger ist es aber, den Nutzen der Kennzahlen in der Organisation herauszustellen. Die Kennzahlen dürfen nicht als Bedrohung sondern müssen als Chance verstanden werden.
Werden dem Top-Management einzelne Kennzahlen berichtet, so muss das Top-Management auch die Prozessziele der damit verbundenen IT Service Management-Prozesse kennen und verstehen. Ansonsten besteht die große Gefahr, dass aus den übermittelten Kennzahlen falsche Schlüsse gezogen werden. Was an dieser Stelle als Selbstverständlichkeit verstanden werden kann, hat in einigen Organisationen zu erheblichen Schwierigkeiten geführt. Die Aufgabe des Problem Managements besteht zum Beispiel darin, Probleme zu identifizieren. Steigt die Kennzahl der identifizierten Probleme, so ist dies ein Indikator für einen gut funktionierenden Problem Management-Prozess. Es wäre dagegen fatal, wenn das Management die wachsende Zahl identifizierter Probleme falsch interpretiert und dem Problem Management negativ anlastet.
142
4 IT Kennzahlensysteme 4.1 Management Summary Die IT eines Unternehmens lässt sich nur dann erfolgreich steuern, wenn verlässliches Material über Zahlen und Fakten verfügbar ist. Zum einen müssen diese Informationen die Situation der IT-Organisation realitätstreu widerspiegeln, zum anderen müssen Sie Anreize für die Veränderungen schaffen. Dies ist die Aufgabe von Kennzahlensystemen. In der IT gibt es wahrscheinlich so viele Kennzahlen wie in keinem anderen Bereich. Ein nur durchschnittlich ausgeprägtes Monitoring der IT-Systeme über System Management-Werkzeuge stellt mit Leichtigkeit schon Hunderte von Kennzahlen bereit – und das regelmäßig, in vielen Fällen im Minutentakt. Wichtig ist es daher, zu hinterfragen, was eine einzelne Kennzahl bezüglich der Gesamtsituation aussagt. Im Allgemeinen benötigt man hierzu eine Kombination aus mehreren Einzelkennzahlen. Die Praxis zeigt, dass das Design, die Umsetzung und die Pflege von Kennzahlensystemen in der IT nicht zu unterschätzende Aufgaben darstellen. Durch Interessenkonflikte innerhalb von Unternehmen sowie die häufig asymmetrische Informationsverteilung zwischen den Beteiligten wird die benötigte Objektivität zur entscheidenden Herausforderung. Die Kunst liegt darin, ein IT-Kennzahlensystem zu konstruieren, das einen präzisen und zeitnahen Überblick liefert, das sich nicht manipulieren lässt und das möglichst geringe Kosten verursacht. Es gibt einige veröffentlichte IT-Kennzahlensysteme. Mögen diese auch noch so exzellent in ihrer Ausprägung, Tiefe und Methodik sein. Eins bleibt festzuhalten: Kein IT-Kennzahlensystem lässt sich Eins zu Eins von einer IT-Organisation auf eine zweite übertragen. Der Hauptgrund liegt darin, dass der „Betrieb“ eines Kennzahlensystems immer auch einen strategischen Effekt erzielt. Dies ist zwangsläufig so – unabhängig davon, ob es von Anfang an beabsichtigt war oder nicht. Die strategische Positionierung der IT hinsichtlich ihrer Außen- und Innenwirkung ist CIO-Sache. Kennzahlensysteme bilden hierfür eine entscheidende Basis, nicht nur als Steuerungs- sondern insbesondere als Kommunikationsinstrument.
143
4 IT Kennzahlensysteme
4.2 Ziele Für Unternehmen steht heute nicht mehr zur Diskussion, dass Effizienz und Effektivität ihrer Organisationseinheiten objektiv, präzise und zuverlässig ermittelt werden müssen. Dies gilt für IT-Organisationen im Besonderen. Das frühzeitige Erkennen von Problemen und Verbesserungspotenzialen ist eine wichtige Voraussetzung für den Erfolg der IT. An dieser Stelle setzen Kennzahlensysteme an. Sie ermöglichen einen Blick auf die Situation der IT-Organisation, ihre Teilbereiche und ihre Prozesse. Die Auswahl und Erfassung von geeigneten Kennzahlen stellt sich in der Praxis als überraschend schwierig heraus. Der Grund hierfür liegt darin, dass Kennzahlen, um effektiv zu sein, die folgenden Voraussetzungen erfüllen müssen: – Eine Kennzahl muss objektiv erfassbar sein, um eine zuverlässige und unverzerrte Darstellung der Situation zu ermöglichen. Die verwendeten Begriffe zur Beschreibung der Kennzahl müssen eindeutig und für alle Beteiligten verständlich sein und von diesen akzeptiert werden. – Der Aufwand zur Erfassung einer Kennzahl sollte gering sein, um eine möglichst häufige, schnelle und preiswerte Ermittlung zu ermöglichen. Auch sollte eine zeitnahe Erfassung möglich sein. Idealerweise wird die Kennzahl automatisch erfasst und gespeichert. – Kennzahlen müssen das Entstehen von Fehlanreizen verhindern: Durch Kennzahlen ausgelöste positive Entwicklungen müssen begünstigt und negative sanktioniert werden. Die Kennzahlen sollten nicht manipulierbar sein. – Kennzahlen, die in einem bestimmten Bereich oder Prozess erhoben werden, sollten effektiv von diesem Bereich oder Prozess kontrollierbar sein. Andernfalls liefern sie ein falsches Bild der tatsächlichen Leistung oder Kosten.
Beispiel: Anwenderzufriedenheit Viele Unternehmen evaluieren die Anwenderzufriedenheit mit der IT über Fragebögen1 oder CAPIs2. Aber mit welcher Fragestellung lässt sich die Anwenderzufriedenheit ermitteln?
1
Diese werden auch „User Quality Surveys“ genannt.
2
CAPI steht für „Computer Assisted Personal Interview“.
144
4.2 Ziele Eine direkte Frage nach der „Zufriedenheit mit der IT“ führt zu wenig brauchbaren Resultaten, da Anwender häufig keinen Überblick über die Gesamtleistung der IT haben. Stattdessen rücken ungewollte Aspekte in den Vordergrund. Die Anwenderzufriedenheit ist durch die IT-Organisation selbst oft schwer zu beeinflussen, da sie von nicht-kontrollierbaren Dingen abhängen kann, wie mangelnder Lernbereitschaft bestimmter Anwender. Auch kann eine restriktive Sicherheitspolitik der IT die Anwenderzufriedenheit negativ beeinflussen, wie das Verbot der Internet-Nutzung oder privater Email. Obwohl solche Dinge dem Unternehmen als Ganzes nützen und von der IT gegebenenfalls professionell umgesetzt werden, ziehen Sie die Bewertung der IT nach unten. Hinzu kommt, dass der Anwender häufig eine andere Erwartung an den IT Service hat als seine Vorgesetzten, die Vereinbarungen in Form von SLAs mit dem IT Service Provider abgeschlossen haben. Dem Anwender sind zum Teil diese SLAs mit den Service Level Targets gar nicht bekannt. Auch wenn der IT Service Provider diese Anforderungen vollständig erfüllt, kann es so vorkommen, dass die Anwenderzufriedenheit nicht gegeben ist. Der Versuch, die Anwenderzufriedenheit indirekt zu messen, ist ebenfalls nicht einfach. Legt man beispielsweise die Anzahl der Kontaktaufnahmen mit dem Service Desk zugrunde, so gibt es mindestens zwei Interpretationsmöglichkeiten. Ein Service Desk, der wenig kontaktiert wird, kann eine hohe Anwenderzufriedenheit im Sinne „Alles läuft reibungslos“ bedeuten, aber auch, dass die Anwender es „aufgegeben haben“, sich an die IT zu wenden, beispielsweise wegen Inkompetenz oder Arroganz des Service Personals. Das Beispiel zeigt, dass man zur Ermittlung der Anwenderzufriedenheit nicht mit einer Kennzahl auskommt. In einem Kennzahlensystem sollen sich sorgfältig ausgewählte Kennzahlen gegenseitig ergänzen, um ein möglichst ausgewogenes und präzises Gesamtbild zu liefern.
Genauso wie einzelne Kennzahlen sollte ein gutes Kennzahlensystem Anforderungen erfüllen: – Der Informationszugewinn, der aus einem Kennzahlensystem im Vergleich zu einzelnen Kennzahlen entsteht, hängt davon ab, wie sehr sich die Kennzahlen voneinander unterscheiden. – Auch die Größe des Kennzahlensystems ist entscheidend. Zunächst führt jede zusätzliche Kennzahl zu einem Informationsgewinn, sofern sie optimal eingesetzt wird. Dieser wird aber mit wachsenden
145
4 IT Kennzahlensysteme Systemen immer geringer. Es kommt also darauf an, das Kennzahlensystem mit optimaler Größe auszulegen.3
Beispiel: Anwenderzufriedenheit (Fortsetzung) Die beiden Kennzahlen „Befragung” und die „Kontakthäufigkeit”, die wir oben vorgeschlagen hatten, sind beide für sich genommen zur Bestimmung der Anwenderzufriedenheit mit der IT wenig geeignet. Sie sind entweder nicht präzise genug oder können negative Effekte bewirken. Durch die Kombination der beiden Kennzahlen erhält man aber ein präziseres Maß, das weniger fehler- und zufallsanfällig ist. Auch wird eine Manipulation der resultierenden Kennzahl deutlich schwieriger und aufwendiger. Durch weitere Kennzahlen ließe sich dieses Kennzahlensystem nun verbessern, bis der gewünschte Kompromiss aus Informationsgehalt und Kosten des Systems erreicht ist. Doch bei der Auswahl neuer Kennzahlen ist Vorsicht geboten. Zunächst liegt der Gedanke nahe, den Mitarbeitern weitere Fragen zu anderen Aspekten ihrer Zufriedenheit zu stellen. Während dies im Einzelfall nützlich sein kann, um Problembereiche zu identifizieren, liegt die Vermutung nahe, dass die Zufriedenheit mit einzelnen Aspekten stark mit der allgemeinen Zufriedenheit korreliert und somit bereits zum Teil im System enthalten ist. In diesem Fall steht dem zusätzlichen Aufwand kaum ein Informationsgewinn gegenüber. Als Erfolg versprechend könnte sich hingegen die Analyse des Anwenderverhaltens erweisen. Falls sich beispielsweise deren Produktivität im Umgang mit ihrer IT-Umgebung messen ließe, so könnte dies auf deren Zufriedenheit schließen lassen. Auch eine Aufschlüsselung der Kontakthäufigkeit mit dem Service Desk nach Ursache (Incident, Service Request, Request for Change usw.) könnte sich als wertvoll erweisen.
3
Wegen des Verhältnisses von Grenzkosten und Grenznutzen.
146
4.3 Überblick
4.3 Überblick In den letzten 30 Jahren sind einige Vorschläge für IT-Kennzahlensysteme entwickelt und veröffentlicht worden. Diese sind zum Teil generisch und zum Teil im Hinblick auf konkrete Unternehmen konzipiert. Im Folgenden stellen wir eine Auswahl von Kennzahlensystemen kurz vor. Wir erheben dabei keinen Anspruch auf Vollständigkeit, sondern verfolgen vielmehr das Ziel, dem Leser eine grobe Vorstellung über den Aufbau von Kennzahlensystemen zu geben. Jedes Kennzahlensystem folgt einer eigenen Philosophie und ist für spezifische Anwendungsszenarien besonders geeignet. Die Qualität und Eignung der vorgestellten Systeme hängt somit immer vom geplanten Einsatz ab, sodass eine allgemeine Bewertung von Kennzahlensystemen weder objektiv möglich noch in diesem Text beabsichtigt ist. Grob unterscheiden kann man zwischen praxisorientierten, konkreten Systemen, und eher als generisch zu verstehenden Systemen. Während erstere in der Regel aktualisiert und auf die bestehende IT-Infrastruktur eines Unternehmens abgestimmt werden müssen, erfordern letztere das Entwickeln eigener, geeigneter Kennzahlen. Da sich kaum eines dieser Kennzahlensysteme direkt und ohne Anpassungen einsetzen lässt, ist es wichtig, vorab einige Kriterien zu nennen, anhand derer sich der Aufwand einer Implementierung abschätzen lässt: – Stimmt die Zielsetzung des Kennzahlensystems mit den Anforderungen überein? Werden alle IT-Bereiche ausreichend abgedeckt? Werden die wesentlichen Fragen hinreichend beantwortet? Stimmt die Gewichtung der Kennzahlen mit der Relevanz überein? – Wie konkret ist das Kennzahlensystem? Lassen sich die genannten Kennzahlen einfach erheben? Müssen Kennzahlen noch weiter ausformuliert werden? – Wie aufwendig ist die Implementierung des Systems? Werden die verwendeten Kennzahlen bereits erhoben? Welcher Aufwand würde die Erhebung der nötigen Kennzahlen verursachen? Wie häufig wäre eine Erhebung möglich? Im Folgenden machen wir eine kleine Reise durch die Welt der Kennzahlensysteme. Unsere Stopps sind aber nur kurz. Für längere Aufenthalte empfehlen wir einen Blick in die Originalarbeiten oder das sehr empfehlenswerte Buch von Martin Kütz [Kütz, 2007].
147
4 IT Kennzahlensysteme
4.3.1 SVD 1980 Herkunft Quelle Idee
Struktur
Schweizerische Vereinigung für Datenverarbeitung EDV-Kennzahlen (1980), Bern/Stuttgart SVD 1980 ist ein kompaktes, relativ allgemein gehaltenes Kennzahlensystem, das 34 nach Adressaten gruppierte Kennzahlen enthält. Gruppierung nach Adressat und Art der Kennzahl. Insgesamt 34 Kennzahlen. Management
Anwender
IT-Entwicklung
IT-Betrieb
Kosten
2
2
7
4
Leistungen
-
-
2
7
Nutzen
3
2
-
-
Sonstige
-
-
3
2
Kennzahlen
Beispiele
Fazit
148
– IT-Produktivitätsindex (Management / Nutzen) – Nutzenpunkte (Anwender / Nutzen) – Anzahl IT-Mitarbeiter (IT-Entwicklung / Sonstige) – Mean Time to Repair (MTTR) (IT-Betrieb / Leistung) Einige Kennzahlen müssen für den konkreten Einsatz in der Praxis spezifiziert werden, z. B. was „Nutzenpunkte“ im Einzelnen sind.
4.3 Überblick
4.3.2 Diebold 1984 Herkunft
Diebold Deutschland GmbH
Quelle
Diebold Kennzahlensystem (1984), 3. Auflage, Frankfurt
Idee
Dieses von der Unternehmensberatung Diebold entwickelte Kennzahlensystem stellt eine hierarchische Struktur dar, in die konkrete Kennzahlen eingearbeitet werden können.
Struktur
Hierarchische Strukturierung mit insgesamt 19 Untergruppen – – – – –
1 Spitzenkennzahl 2 Kennzahlenbereiche (A, B) Kennzahlenunterbereiche (AA, AB, ...) Kennzahlengruppen (AAA, AAB, ...) Kennzahlenuntergruppen (AAAA, AAAB, ...)
Beispiele
– Anteil IT-Kosten bezogen auf Umsatz (Spitzenkennzahl) – Wirkung des Einsatzes der IT im Hinblick auf die Unternehmensleistung (A) – ... bezogen auf das Gesamtunternehmen (AA) – ... je Hauptfunktionsbereich (AB)
Fazit
Diebold stellt ein abstraktes Kennzahlensystem dar, das für eine praktische Nutzung stark konkretisiert und angepasst werden muss. Es stellt sich auch die Frage, wie sich (durchaus wichtige) Aspekte wie „Innovationsverhalten“ und „Zukunftsorientierung“ praktisch und objektiv messen lassen. Die hierarchische Struktur bietet Vorteile dadurch, dass eine an den jeweiligen Adressaten angepasste Informationstiefe erreicht werden kann. Zu klären ist dabei allerdings, auf welche Art und Weise die Kennzahlen einer Gruppe zur jeweils höheren Hierarchiestufe zusammengerechnet werden können.
149
4 IT Kennzahlensysteme
4.3.3 Kargl 1996 Herkunft Herbert Kargl Quelle Controlling im DV-Bereich (1996), München Idee Das von Kargl entwickelte Kennzahlensystem bietet eine große Fülle an einfach zu implementierenden Kennzahlen. Struktur 5 Koordinationsfelder mit insgesamt 163 Kennzahlen – – – – – Beispiele
Strategische IT-Planung (34) Planung / Durchführung von IT-Projekten (30) Wirtschaftlichkeit (24) Anwendungsbetrieb und IT-Infrastruktur (52) Verrechnung von Kosten und Leistungen (23)
– Betriebskosten der Anwendungen (Strategische Planung) – Projektfertigstellungsgrad (Plan / Durchführung) – Projektkostenstruktur (Wirtschaftlichkeit) – Risikofelder und Gefahrenpotenzial (Infrastruktur) – Zusammensetzung der Budgets (Verrechnung)
Fazit Die Strukturierung des Kennzahlensystems ist stimmig und erfasst sowohl wirtschaftliche als auch strategische Ziele. Die Kennzahlen sind größtenteils relativ konkret formuliert, sodass sie sich gut praktisch nutzen und einfach abwandeln lassen. Zudem sind einige Kennzahlen enthalten, die nützliche Hintergrundinformationen liefern, beispielsweise über die Struktur der Leistungserstellung.
150
4.3 Überblick
4.3.4 Van der Zee 1996 Herkunft
Han van der Zee
Quelle
In: Search of the Value of Information Technology (1996), Dissertation, Katholische Universität Brabant
Idee
Das von van der Zee entwickelte IT-Kennzahlensystem versucht die Idee der Balanced Scorecard auf den Bereich der IT zu übertragen. Ferner werden für jede Perspektive konkrete Ziele formuliert.
Struktur
Aufteilung in 5 Management-Bereiche und jeweils 4 Perspektiven mit insgesamt 200 Kennzahlen: Kennzahlen
Beispiele
Kundenperspekt.
Interne Persp.
Innovationspersp.
Finanzpersp.
Leistungsmgmt.
9
8
7
5
Entwicklungsm.
15
17
7
6
Infrastrukturm.
18
33
5
6
Kundenmgmt.
15
5
7
3
Anwendersupport
16
9
6
3
Leistungsmanagement, interne Perspektive Ziel: „Ein guter Arbeitgeber sein.“ – – – –
Fazit
Mitarbeiterzufriedenheit Fluktuationsrate Wettbewerbsfähigkeit der Gehälter ...
Der einseitige Fokus auf die Kosten- und Finanzperspektive kann zu kurzsichtigem Handeln verleiten. Die Kunden-, Innovations- und Prozessperspektiven sollen helfen, langfristig relevante Werte zu erfassen. Die Kennzahlen selbst sind zum großen Teil konkret formuliert. Der enorme Umfang des Systems erfordert allerdings eine sorgfältige Auswahl.
151
4 IT Kennzahlensysteme
4.4 Bewertung Die betrachteten Kennzahlensysteme zeigen, dass es verschiedene, gleichermaßen schlüssige und sinnvolle Ansätze gibt, die scheinbar schwer messbare Leistung der IT zu erfassen. Zunächst stellt sich die Frage nach der grundsätzlichen Struktur eines Kennzahlensystems. In dieser sollten alle Kernbereiche der IT wieder zu finden sein. Auch sollte die Abgrenzung mit der tatsächlichen Aufteilung von Aufgaben und Kompetenzen in etwa übereinstimmen. Matrizenförmige Strukturen erlauben das gleichzeitige Gliedern der Kennzahlen nach dem Bereich und einem zweiten Kriterium. Eine (zusätzliche) hierarchische Strukturierung der Kennzahlen ist möglich und dann sinnvoll, wenn das System ohne Probleme von mehreren unterschiedlich stark involvierten Managementstufen benutzt werden soll. Das Hinzufügen von Zielen oder die Unterteilung nach Prozessen verleiht dem Kennzahlensystem schließlich eine eigene „Philosophie“, was sowohl bei der Erstellung des Systems, als auch bei der Auswertung der späteren Resultate sinnvoll ist. Was die Anwendbarkeit der vorgestellten Systeme betrifft, so erfordert jedes die Anpassung an die konkrete IT-Organisation. Während dies bei relativ konkreten Systemen wie van der Zee 1996 einfach durch die geschickte Auswahl aus einem „Kennzahlenpool“ erfolgen kann 4 , dienen abstrakte Klassifizierungssysteme wie Diebold 1984 eher als Basis für das Zusammenstellen und Strukturieren eines eigenen Systems. Stellt man sich die spannende Frage „Welches IT-Kennzahlensystem soll man so, wie es ist, in der Praxis einsetzen?“, so lautet die enttäuschende Antwort: „Keines“5. In der Praxis zeigt sich: – Der Überdeckungsgrad der Kennzahlensysteme ist eher gering, jedes Kennzahlensystem liefert neue Aspekte. – Die Anforderung, dass Prozessmodelle des IT Service Managements zu berücksichtigen sind, liefert nicht weniger, sondern mehr Kennzahlen. Kein Kennzahlensystem ist ohne Modifikation in der Praxis einsetzbar: – Zu viele Kennzahlen werden genannt.
4
Dies gilt im Übrigen auch für COBIT (vgl. Kapitel 3.3).
5
Vielleicht etwas hoffnungsvoller, versöhnlicher (und diplomatischer): „Keines ohne Modifikation“.
152
4.5 Konsequenzen – Kennzahlen werden genannt, die aber im konkreten Unternehmen nicht reported / gemessen werden können oder sollen. – Kennzahlen werden zwar genannt, aber nicht definiert. – Es wird kaum Bezug zur IT-Strategie genommen. Der strategische Aspekt von Kennzahlensystemen bleibt unberücksichtigt. IT-Kennzahlensysteme sagen, was man messen könnte, aber nicht, was man messen sollte! Sie sind damit Guidelines – nicht mehr und nicht weniger!
IT-Kennzahlensysteme sind nicht Selbstzweck, sondern haben immer eine strategische Ausrichtung. Sie sind immer unternehmensspezifisch. Einsatzbereiche für IT-Kennzahlensysteme können beispielsweise sein: – Steuerung des IT-Bereichs oder – Darstellung des IT-Bereichs (z. B. um der Geschäftsführung zu zeigen, wie der IT-Bereich im Unternehmen dasteht: „Lagebericht der IT“). Hieraus lässt sich ein wichtiger Aspekt ableiten: IT-Kennzahlensysteme haben immer einen bestimmten Adressatenkreis: Top Management, CIO, Prozess Owner oder Kunden.
4.5 Konsequenzen Anmerkung: Dies ist das kürzeste und wichtigste Kapitel in unserem Buch. Beantworten Sie die folgenden Fragen: – Wer sind die Adressaten des IT-Kennzahlensystems? – Welche Ziele verfolgen Sie mit der Einführung des IT-Kennzahlensystems in Bezug auf die Adressaten? – Welche IT Service Management-Prozesse sollen gemessen werden? – Wie sollte das Kennzahlensystem strukturiert sein? – Welche Kennzahlen können bzw. können nicht gemessen werden? – Welchen Aufwand darf das Kennzahlensystem verursachen?
Entwickeln Sie Ihr eigenes IT-Kennzahlensystem!
153
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen 5.1 Management Summary In diesem Kapitel gehen wir darauf ein, wie ein praxistaugliches ITKennzahlensystem entwickelt werden kann. Es kommt uns darauf an, zu zeigen, welche IT-Kennzahlen sich in unseren Praxisprojekten als nützlich und sinnvoll erwiesen haben. In unseren Projekten haben wir die Erfahrung gemacht, dass das Hauptproblem bei der Entwicklung eines IT-Kennzahlensystems darin besteht, die Komplexität des Systems zu reduzieren. Daher widmen wir uns diesem Problem gleich am Anfang des Kapitels und zeigen auf, wie man Kennzahlen in Cluster unterteilen kann, damit ein „Mehr-EbenenKennzahlen-System“ ohne Überfrachtung und Überforderung der Führungsebene entsteht. Insbesondere sind Kennzahlen hinsichtlich ihres Einsatzes und der strategischen Bedeutung zu verdichten. Dies sollte den entsprechenden ITMitarbeitern übertragen werden. Dabei ist wichtig, dass eine Aggregation der Daten stattfindet und nicht eine Datenreduktion. Eine Lösung bieten hier Controls on Demand, die dann herangezogen werden, wenn sie benötigt werden. Für die Aufbewahrung ist der jeweilige IT-Mitarbeiter verantwortlich. Die IT-Leitung erhält nur die aggregierten Zahlen zur Steuerung und Kontrolle, kann aber die Detaildaten jederzeit anfordern.
5.2 Klassifikationsschema für IT-Kennzahlen In IT-Organisationen gibt es im Allgemeinen sehr viele Kennzahlen. In einem durchschnittlichen mittelständischen Unternehmen (Größe der ITOrganisation 10 Mitarbeiter) haben wir bei der Ist-Analyse mit Leichtigkeit 500 Kennzahlen ermittelt, die alle erhoben und an die IT-Leitung reported wurden. Es drängt sich nun der Verdacht auf, diese seien nicht alle notwendig und man könne auf einen Großteil verzichten. Dem ist nicht so, denn 95 % dieser Kennzahlen sind sinnvoll und wichtig. Allerdings nicht so wichtig, dass sie monatlich an den CIO reported werden müssen, geschweige denn an die Geschäftsführung.
155
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Die Frage „Erheben wir die richtigen Kennzahlen?“ sollte man etwas detaillieren und erweitern: „Erheben wir die richtigen Kennzahlen zum richtigen Zeitpunkt für die richtige Person?“ Was „richtig“ oder „nicht richtig“ ist, lässt sich aus den Zielen und der Strategie ableiten! Interessanterweise erhält man hierdurch ein Klassifikationsschema für Kennzahlen, das sich pragmatisch in der Praxis anwenden lässt und die Komplexität des Systems reduziert. In der folgenden Abbildung 61 ist dieses Modell zur Klassifikation von ITKennzahlen dargestellt.
Top Management Geschäftsführung Balanced Scorecard (KSFs)
Kennzahlen einer ITOrganisation
IT-Management CIO KPIs
CSIs
IT-Controls Controls on Demand
IT - Kunden SLAs Abbildung 61:
Schema zur Klassifikation von IT-Kennzahlen
Hierzu die 3 Kernideen des Modells: – Im Wesentlichen lassen sich die Kennzahlen einer IT-Organisationseinheit in drei größere Gruppen einteilen, die sich an den Adressaten der Kennzahlen orientieren: Top Management, IT-Management und IT-Kunden. – Die meisten Kennzahlen – in der Praxis einige hundert – fallen im Umfeld des CIOs an. Ein Teil – die IT-Controls – ist zur Steuerung der IT notwendig. Der größte Teil wird nur in bestimmten Situationen benötigt. Diese Kennzahlen sollten als „Kennzahlen auf Abruf“ (Controls on Demand) vorgehalten werden.
156
5.2 Klassifikationsschema für IT-Kennzahlen – Es gibt viele Alternativen, Kennzahlen darzustellen. Entscheidend für den Erfolg eines Kennzahlensystems ist gerade die Fähigkeit, Strategien zu kommunizieren. Wir halten daher mindestens für das Reporting an die Geschäftsführung die Balanced Scorecard für unabdingbar. Lassen Sie uns auf die wesentlichen Kernideen des Klassifikationsschemas genauer eingehen.
5.2.1
Key Success Factors
Über die Rolle der IT in Unternehmen ist viel diskutiert und geschrieben worden. Wir sind der Meinung, dass die IT einen wesentlichen Produktionsfaktor für Unternehmen darstellt. Sie ist wettbewerbsbestimmend, da sie nicht nur die Systeme „am Laufen hält“, sondern gleichzeitig eine bedeutende Innovationskraft für Unternehmen darstellt. Wodurch soll heute Wachstum entstehen, wenn nicht durch Innovation? Nach unserer Ansicht hat die IT heute 2 Aufgaben zu erfüllen: – Run the Business: Die IT ist der Motor für die Geschäftsprozesse. Sie hat die Aufgabe, die Kosten im Griff zu halten, marktgerecht zu agieren, zu standardisieren, Skaleneffekte auszunutzen und das Risiko zu minimieren. – Grow and Transform the Business: Die IT ist ein wesentlicher Teil der „Entwicklungsabteilung für Geschäftsprozesse“. Sie verändert und optimiert die Kernprozesse von Unternehmen, legt die Basis für neue Märkte und ist eine strategische Waffe im Wettbewerb. Die IT ist damit nicht Selbstzweck, sondern sie trägt messbar zum Business Value des Gesamtunternehmens bei. Eine wesentliche Aufgabe des CIO besteht darin, den IT-Erfolg dem Top Management und IT-Kunden darzustellen.
Vielen Unternehmen bereitet diese Sicht Schwierigkeiten und daher implementieren sie nur unzureichende Möglichkeiten zur Kommunikation. Dies ist schade, denn dadurch verpufft einerseits viel Innovationskraft und andererseits bauen sich leicht Konfliktsituationen auf, die für das Unternehmen und die IT schädlich sein können. Sehr zu empfehlen ist ein „Management Report zur Lage der IT im Unternehmen“. Wir haben diese Art des „Reportings“ in vielen Unternehmen verschiedener Größen und Branchen erfolgreich eingeführt. In den meisten Fällen wird dieser Report mit Interesse von der Geschäftsführung entgegengenommen.
157
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Der Report sollte jährlich erscheinen. Er beschreibt und bewertet die IT im Hinblick auf ihre Leistungsfähigkeit. Der IT Management Report richtet sich an das Top Management.
Wichtig dabei sind die folgenden Dinge: – Der Management Report muss auf einer mehrdimensionalen Bewertung der IT basieren. – Er muss die Entwicklungstendenzen darstellen. Kennzahlenverläufe sind für die letzten 3 bzw. 5 Jahre anzugeben. – Die Bewertung (und die Kennzahlen) müssen für das Top Management verständlich sein. – Der Management Report darf Marketingaspekte beinhalten und verfolgen. Er ist eine Selbstdarstellung und dient dem Erreichen strategischer Ziele. – Er muss einen Überblick über die durchgeführten Projekte enthalten. Dabei ist herauszustellen, inwiefern die Projekte zum Business Value beigetragen haben. 1 – Aus dem Management Report müssen die Ziele für das nächste Jahr abgeleitet werden. – Insgesamt muss der Business Value der IT erkennbar sein. In unseren Projekten verwenden wir als Instrument zum Reporting an das Top Management in den meisten Fällen die Balanced Scorecard. Sie ist nicht nur für Management Meetings hervorragend geeignet sondern auch zum Aufbau von Management Reports. Die Frage, die sich hier stellt ist, welche Zahlen und Ergebnisse interessieren das Top Management? Dies sind sicherlich nicht die technischen Details der IT, die man ja reichlich reporten könnte. Es geht im Grunde darum, mit Fakten aufzuzeigen, wie erfolgreich die IT ist. Diese Kennzahlen nennen wir Key Success Faktoren (KSF). Sie setzen sich im Allgemeinen aus anderen Kennzahlen zusammen und sind damit selbst mehrdimensional. Es bietet sich an, die Dimensionen einer Balanced Scorecard als Key Success Faktoren zu nehmen (vgl. Abbildung 62). Die Kennzahlen können Key Performance Indikatoren2 oder Customer Satisfaction Indices aus der Ebene des IT-Managements sein, die durch Aggregation entstehen. Im Folgenden geben wir einen Ausschnitt aus einem solchen Kennzahlensystem an:
1
ROI im Sinne „Return on IT“.
2
KPIs im Sinne einer betriebswirtschaftlichen Begriffsbestimmung (vgl. den Exkurs zum Begriff KPI in Kapitel 5.2.2.)
158
5.2 Klassifikationsschema für IT-Kennzahlen
KSF: Finanzperspektive – IT-Kosten nach Umsatz – IT-Kosten je Anwender
KSF: Potenzialperspektive – Aus- und Weiterbildungstage – Mitarbeiterzufriedenheit
KSF: Kundenperspektive – Verfügbarkeit der Systeme – Kundenzufriedenheit
IT Management Report 2006 Finanzperspektive ... Kundenperspektive Mitarbeiterperspektive Abbildung 62:
Key Success Faktoren im IT Management Report
Die auszuwählenden Key Success Faktoren sind nach unserer Erfahrung für IT-Organisationen unterschiedlich. Wir haben die Perspektiven einer Balanced Scorecard bisher nie eins zu eins von einem Unternehmen auf das andere übertragen können. Das liegt unter anderem daran, dass sich die Key Success Faktoren aus der IT-Strategie ableiten (vgl. Abbildung 63). Meistens benutzen wir zwischen 5 – 7 Perspektiven und damit auch 5 – 7 Key Success Faktoren, die die IT insgesamt darstellen. Nicht zu viel und nicht zu wenig – gerade geeignet, um die Lage der IT dem Top Management transparent zu machen. Jeder Key Success Faktor sollte mit einem kurzen Text versehen werden, der den Verlauf der Kennzahlen interpretiert und sich auf die aktuelle
159
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Situation des Unternehmens bezieht. Expandiert das Unternehmen beispielsweise in andere Länder, so kann dies der Grund für erhöhte ITAufwände sein. Hat man in den letzten Jahren die IT-Plattformen konsolidiert, so kann dies in den Folgejahren ein Grund für sinkende Investitionen sein. Key Key Success Success Factor Factor
ITStrategie
Key Key Success Success Factor Factor
KPI KPI
CSI CSI KPI KPI
KPI KPI KPI KPI KPI KPI KPI KPI KPI KPI
Key Key Success Success Factor Factor
CSI CSI
CSI CSI KPI KPI CSI CSI CSI CSI
Kennzahlen-
system Abbildung 63:
Key Success Faktoren zur Gruppierung von KPIs und CSIs
Hilfreich ist es auch, für Kennzahlen Benchmarks anzugeben, falls diese verfügbar sind. Dies ist in einigen Branchen der Fall. Oft gibt es auch allgemeine Benchmarks, die dem Management zeigen, ob die eigene IT „noch im grünen Bereich liegt“. Ein Beispiel ist die Kennzahl „IT-Kosten pro Umsatz“, die zwischen 2 und 3 % liegen sollte. Dies ist aber von Branche zu Branche verschieden und sollte auf die aktuelle Situation des Unternehmens bezogen werden.
5.2.2
Key Performance und Customer Satisfaction
Alle IT Service Management-Ansätze sehen IT-Organisationen als IT Service Provider, die Leistungen für ihre Kunden erbringen. Der Kunde ist in diesem Zusammenhang derjenige, der für Leistungen „bezahlt“. Kunden werden von Anwendern unterschieden, die „lediglich“ die IT-Infrastruktur nutzen.
160
5.2 Klassifikationsschema für IT-Kennzahlen In IT-Kennzahlensystemen sollte die Kundenfokussierung Berücksichtigung finden. Es ist daher nicht nur zu messen und zu bewerten, welche Leistungen die IT-Organisation an ihre Kunden ausliefert sondern auch, wie der Kunde diese Leistungen empfindet.
Im Marketing – und nicht nur da – findet man hierzu den Begriff Customer Satisfaction Index (CSI), der angibt, wie der Kunde einen entsprechenden Service empfindet. Es wird sozusagen die „gefühlte“ Qualität bewertet. Die CSIs sind von den üblichen Key Performance Indikatoren (KPI) zu unterscheiden, die die Leistungsfähigkeit von Prozessen aus eigener Sicht bewerten. In [Zeithaml et al., 1988] werden die Lücken zwischen Kunden- und Providersicht sehr treffend beschrieben. Die nachfolgende Abbildung 64 zeigt zum einen, wie kompliziert die Wahrnehmungsprozesse sind, und zum anderen, dass es viele Schnittstellen gibt, an denen die Kunden- und Providersicht unterschiedlich sein kann.
Customer Satisfaction Index
Customer Satisfaction Index Abbildung 64:
Beispiele für Lücken zwischen Kunden- und Providersicht
Wir haben in der Abbildung 64 drei Punkte herausgegriffen, an denen man CSIs messen kann: – Zwischen Leistungserwartung und Servicewahrnehmung kann es ein Gap geben. Dies ist in der Praxis oft der Fall, wenn ITMarketingaspekte zu kurz kommen. – Zwischen Leistungserwartung des Kunden und der durch den Provider wahrgenommenen Kundenerwartung kann ebenfalls eine Lü-
161
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen cke klaffen. Das ist in der Praxis der Fall, wenn das Service Level Management keine „Engagement“ Funktion hinsichtlich der Kunden wahrnimmt. – Sind die Leistungsspezifikationen schwach ausgeprägt, so ist dies ebenfalls ein Nährboden für Wahrnehmungsstörungen. Wir haben diesen Fall in der Praxis oft gesehen, wenn SLAs nicht hinreichend genau formuliert waren und zu große Interpretationsspielräume zuließen. In [OGC, 2007e] werden 16 Gaps identifiziert, die sich im Service Lifecycle in allen möglichen Phasen – Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement – wiederfinden. Das Service Management hat dafür Sorge zu tragen, dass diese Lücken geschlossen werden und muss gegebenenfalls ein entsprechendes Service Improvement Program (SIP) initiieren. Die untere Abbildung 65 ist angelehnt an „Continual Service Improvement“ [OGC, 2007e] und stellt diese Gaps dar. Interessant ist, dass sie beim Kunden, beim Provider und auch zwischen Kunde und Provider auftreten können. Gap 5 beschreibt beispielsweise ein Kommunikationsproblem bzw. eine falsche Erwartungshaltung, die auf Seiten des Kunden besteht. Für IT-Kennzahlensysteme bedeutet dies, dass CSIs auf der Ebene des ITManagements gemessen und reported werden müssen. Sie sind zur Steuerung der IT genau so wichtig wie die KPIs.
Die Messung der CSIs sollte an all den Stellen erfolgen, wo Kundenkontakte wahrgenommen werden. Der wichtigste Sensor liegt hier sicherlich beim CIO selbst, der wahrnehmen muss, wie die IT im Unternehmen da steht. Andere Quellen sind natürlich das Service Level Management, aber auch der Service Desk sowie das Projekt Management.
162
5.2 Klassifikationsschema für IT-Kennzahlen Externe u. interne Kommunikation, Einflüsse und Treiber
GAP 1 GAP 3
Was wollen wir?
Was brauchen wir?
GAP 2
Erfahrung Vergangenheit
GAP 16 GAP 4
Was bekommen wir? Erwarteter Service GAP 5
Service Operation
GAP 14
GAP 13
GAP 9 Service Transition
GAP 6
Kommunikation zum Kunden
Was bekamen wir? Erhaltener Service
GAP 15
GAP 12
GAP 8 Service Design
GAP 11
GAP 7 Service Strategy Abbildung 65:
GAP 10
Gaps nach OGC (aus [OGC, 2007e])
Exkurs: Zum Begriff „Key Performance Indicator (KPI)“ Es sei an dieser Stelle angemerkt, dass der Begriff Key Performance Indicator (KPI) in vielen Zusammenhängen verwendet wird. Betriebswirtschaft / Management (vgl. [Wikipedia, 2007]): „Key Performance Indicators (KPI) are financial and non-financial metrics used to quantify objectives to reflect strategic performance of an organization. KPIs are used in Business Intelligence to assess the present state of the business and to prescribe a course of action. … KPIs are typically tied to an organization's strategy (as exemplified through techniques such as the Balanced Scorecard). The KPIs differ depending on the nature of the organization and the organization's strategy.” COBIT (vgl. [COBIT, 2005]): Hier werden die wesentlichen Leistungsindikatoren als Key Goal Indicators (Effektivität) bezeichnet, während KPIs „lediglich“ die Effizienz beschreiben.
163
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen ITIL definiert KPIs als (vgl. [OGC, 2007c]): A Metric that is used to help manage a Process, IT Service or Activity. Many Metrics may be measured, but only the most important of these are defined as KPIs and used to actively manage and report on the Process, IT Service or Activity. KPIs should be selected to ensure that Efficiency, Effectiveness, and Cost Effectiveness are all managed.
Wenn wir in unserem Klassifikationsschema in diesem Abschnitt von KPIs reden, verstehen wir darunter KPIs im Sinne der betriebswirtschaftlichen Definition. Diese Begriffsbestimmung ist allgemeiner, hat sich auch im ITControlling durchgesetzt und kann auch im Zusammenhang mit nichtCOBIT-basierten Frameworks eingesetzt werden. KPIs sind eben auch wesentlich für die Umsetzung der IT-Strategie – ja, entstehen geradezu aus dieser – und müssen losgelöst von Frameworks für jedes Unternehmen individuell zusammengestellt werden. Auf der ITManagementEbene sind KPIs und CSIs zu reporten.
KPIs müssen – die Prozessperformance widerspiegeln. Leistungsgrößen sind besser als Aufwandsgrößen. – Prozesse darstellen und möglichst Kundenbezug haben. – Steuerungsinstrumente des Process Owners und Prozess Managers sein. – mit den Customer Satisfaction Indicators CSIs verknüpft werden können. Beispiele für KPIs sind die „Erstlösungsrate im Service Desk“ und „ITProjekte in time und in budget“. Beispiele für CSIs sind die „empfundene“ Kompetenz der Service Desk Mitarbeiter und die Kundenzufriedenheit mit der IT.
5.2.3
IT-Controls und Controls on Demand
Durch die Vielzahl eingesetzter Monitoring Tools stehen in ITOrganisationen zeitnah immense Datenmengen zur Verfügung, die prinzipiell als Kennzahlen nutzbar sind. Es macht auf keiner Ebene des Kennzahlensystems – weder auf der Geschäftsführungs- noch auf der IT Management Ebene – Sinn, eine unüberschaubare Menge von Kennzahlen in ein monatliches Reporting einzubeziehen. Wir unterscheiden daher IT-Controls und Controls on Demand. IT-Controls sind Kennzahlen, die kontinuierlich reported werden. Controls on Demand sind Kennzahlen, die nur in speziellen Situationen aussagekräftig sind.
164
5.2 Klassifikationsschema für IT-Kennzahlen Beispiele für IT-Controls sind: – – – – – – – –
Personalaufwand monatlich Abschreibungen auf Sachanlagen Kapazitätsplan Fehlzeiten Anzahl von Systemstillständen 3 Auswertung der Service-Aufträge Erstlösungsrate (Incident Management)4 Anteil fehlerhafter Changes (Change Management)5
Wie die IT-Controls strukturiert werden, hängt vom Typ und von der Größe der IT-Organisation ab. Es bieten sich verschiedene Werkzeuge an, unter anderem die Balanced Scorecard. Im Gegensatz zum Fall des Reportings an die Geschäftsleitungsebene haben wir hier in unseren Projekten eine stärkere Ähnlichkeit der Kennzahlensysteme untereinander erkennen können. Die Idee, Cockpits einzusetzen, die diese Kennzahlen automatisch aus den operativen Systemen generieren, setzt sich immer mehr durch. Die Steuerung der IT über ein Cockpit kann vor allen Dingen zeitnah erfolgen und bedarf nicht der aufwendigen Sammlung und Auswertung von Daten zu einem bestimmten Zeitpunkt. Controls on Demand werden auf Anforderung reported. Sie müssen zwar generell zur Verfügung stehen, werden aber nur situationsbedingt eingesetzt, da sie von Ereignissen (oder Projekten) getriggert werden: – Nach einem Angriff muss reported werden, wer auf welche Server zugegriffen hat. – Nach Ausfall des Web-Servers muss die Trafic-Situation reported werden. Beispiele für Controls on Demand sind:
Betrieb der IT-Infrastruktur – – – –
Auslastung Datenbanken Verfügbarkeit spezieller Server Web-Server-Statistik Virenbefall-Statistik
3
Dies ist eine Standard-Kennzahl für das Prozessmanagement, die wir im folgenden Kapitel behandeln.
4
Dito.
5
Dito.
165
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen
Anwendungen – Datensicherungsprotokolle – Anzahl Datensätze in SAP BW
ITIL Prozesse (Prozess Owner Kennzahlen) – Größe und Kapazität der DSL (Release Management) – Dokumentationsqualität der CIs (Configuration Management) Das Beispiel zeigt, dass wir den Bereich der Controls on Demand absolut inhaltlich ausrichten. Es gibt keine Meta-Ebene, die sich beispielsweise an der IT-Strategie orientiert. Bei Controls on Demand geht es bei der Klassifizierung in Gruppen nur um eins: Die betreffenden Statistiken zu den Kennzahlen müssen „im Ernstfall“ schnell gefunden werden können.
5.3 Prozess-Kennzahlen Im Folgenden beschreiben wir ausgewählte Prozess-Kennzahlen, die sich in unseren Projekten und auf der Basis unserer Managementerfahrungen bewährt haben. Sie basieren zum Teil auf ITIL und COBIT, beinhalten aber darüber hinausgehende Betrachtungen. Die Struktur der dargestellten Kennzahlen bildet die in der ITIL Version 3 beschriebenen Prozesse und Managementaufgaben. Zusätzlich wurde der Service Desk als Anforderung an die Aufbauorganisation aufgenommen. Bedingt durch die zusammenfassende Darstellung aus den verschiedenen Best Practices, ist vor der Nutzung der ausgewiesenen Kennzahlen zu prüfen, ob sie in Verbindung mit den spezifizierten Prozesszielen der IT-Organisation stehen.
Zu den ausgewiesenen Kennzahlen wird deren jeweilige Definition, Messung und Relevanz spezifiziert. Bei der Messung von Kennzahlen ist zu beachten, dass hierfür keine Standards existieren. So ist zum Beispiel die Kennzahl „Erstlösungsquote“ weit verbreitet, aber deren Messung weicht zwischen den einzelnen IT-Organisationen voneinander ab. Daher muss bei einem Vergleich von Kennzahlen zwischen Organisationen immer deren spezifische Messung in die Betrachtung einbezogen werden. Im Rahmen von Benchmarks soll eine gemeinsame Vergleichsbasis sichergestellt werden.
Die im Folgenden angegebenen Messwerte stammen aus unserer Projekterfahrung. Sie können von Fall zu Fall von den implementierten Methoden in IT-Organisation abweichen.
166
5.3 Prozess-Kennzahlen Wie bereits im Kapitel Prozess-Management ausgeführt, stehen die Ziele Ihrer IT-Prozesse im Vordergrund. Daher sind auch die hier aufgeführten Prozesse hinsichtlich deren Relevanz kritisch zu prüfen.
Damit die aufgeführten Kennzahlen die notwendigen Informationen liefern können, müssen sie jeweils als Trend, in Bezug zum Sollwert und in Relation zu anderen Kennzahlen dargestellt werden. So ist zum Beispiel die Information einer schlechter werdenden Erstlösungsquote erst dann hilfreich, wenn gleichzeitig die Anzahl der eingehenden Störungsmeldungen dargestellt wird.
Kennzahlen sind als Trend und Relation darzustellen.
Durch die Darstellung von Trends für die im Anschluss beschriebenen Kennzahlen steigt der Informationsgehalt. Bei der Trenddarstellung sind die Sollwerte als Bezugslinien auszuweisen.
Die Kennzahlen sind nach dem Motto „Keep It Simple Stupid (KISS)“ - oder „In der Kürze liegt die Würze“ - zu definieren. Einerseits sollten die Kennzahlen möglichst einfach verständlich zu sein. Andererseits gilt es auch den Aufwand zu betrachten, der zur Generierung einer Kennzahl notwendig ist. Hier muss jeweils der Aufwand zur Generierung mit der Steuerungsrelevanz der Kennzahl und des möglichen Verbesserungspotenzials bewertet werden. Um Zusatzaufwendungen zu vermeiden, sollten die Kennzahlen möglichst ohne zusätzlichen Erfassungsaufwand aus den operativen IT-Systemen gewonnen werden. Speziell die Kennzahlen für die Prozesse Incident Management, Request Fulfilment, Problem Management, Access Management, Service Asset and Configuration Management, Change Management und Release and Deployment Management generieren sich weitestgehend aus dem eingesetzten IT Service Management-Tool. Kennzahlen werden zum Teil durch die Verknüpfungen von Daten aus verschiedenen Prozessen gewonnen. Dies erfordert eine hohe Integrität der zugrunde liegenden Datenbasis über verschiedene Prozesse hinweg. Auch aus der Betrachtung der Kennzahlengenerierung sollte das eingesetzte Tool nach Möglichkeit von einem Hersteller stammen.
Es muss sichergestellt werden, dass die automatisch generierten Kennzahlen fehlerfrei sind. Zum Teil werden Daten aus einem anderen Prozess zur Generierung von Kennzahlen herangezogen. Zum Beispiel lautet eine Kennzahl zum Change Management „Anteil fehlerhafter Changes“. Um diese Kennzahl zu ermitteln, müssen Daten aus dem Incident Management ermittelt werden. Bei zukünftigen Änderungen in Prozessen und der eingesetzten Toolumgebung ist sicherzustellen, dass diese Änderungen keine Auswirkungen auf die daraus generierten Kennzahlen haben.
167
Kennzahlen sind möglichst aus operativen Systemen zu generieren.
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Änderungen im Tool sind Changes und als solche zu behandeln
Änderungen im IT Service Management-Tool sind auf mögliche Auswirkungen hinsichtlich der Kennzahlengenerierung zu bewerten. Daher sollten auch Änderungen am IT Service Management-Tool über das Change Management gesteuert werden.
Die Tool-Unterstützung in den einzelnen IT-Organisationen ist sehr vielfältig. Zum Teil existiert zumindest für einen Teil der Prozesse des „Service Design“ (früher Service Delivery) und „Service Transition“ (früher Service Support) und „Service Operations“ (früher Service Support) ein einheitliches Tool mit einer zentralen gemeinsamen Datenbank. Bei anderen IT-Organisationen werden die Service Management-Prozesse von unterschiedlichen Tools und Datenbaken unterstützt. Daher wird in den folgenden Kapiteln der Prozessname als Synonym für das Tool bzw. den „View“ in der Datenbank genannt. Die IT Service Management-Prozesse und die Generierung von Kennzahlen bedingen eine adäquate Tool-Unterstützung. Die Kennzahlen werden zum Teil prozessübergreifend gewonnen. Es empfiehlt sich, die eingesetzten Produkte von einer geringen Anzahl von Herstellern zu beziehen. Datenqualität im Prozess kritisch bewerten und ggf. eine andere Messung wählen
Eine wichtige Datenbasis für die Messung von Kennzahlen stellt der Prozess des Incident Managements mit den dokumentierten Incident Records dar. So kann zum Beispiel die Effektivität des Change Managements, das heißt die fehlerfreie Implementierung von Changes, an der Anzahl von Incidents aufgrund des implementierten Changes gemessen werden. Dies setzt voraus, dass die Incident Records die notwendige Datenqualität aufweisen. Dazu müssen die Mitarbeiter über ein ausreichendes Know-how, aber insbesondere über ausreichende Zeit und Motivation (Einsicht) für die korrekte Erfassung des Incident Records verfügen. Ist diese Datenqualität nicht gegeben, leidet der Informationsgehalt von Kennzahlen in anderen IT Service Management-Prozessen. Kann hier keine ausreichende Datenqualität sichergestellt werden, so muss über eine alternative Messmethode nachgedacht werden. Zum Beispiel, in dem Probleme anstatt der Incidents ausgewertet werden. Kennzeichnend für das IT Service Management sind Prozesse mit wechselseitigen Aktivitäten und Schnittstellen. Daher werden häufig Daten aus anderen Prozessen zur Generierung von Kennzahlen genutzt. Eine schlechte Datenqualität, wie zum Beispiel von Incident Records, hat Auswirkung auf die Aussagekraft von Kennzahlen in anderen Prozessen.
168
5.3 Prozess-Kennzahlen
5.3.1
Service Strategy
5.3.1.1 Financial Management Der Prozess und die Funktionen des Financial Management sind verantwortlich für das Management der Budgetierung, des Accounting und des Charging beim IT Service Provider. Name der Kennzahl
Kundenzufriedenheit Financial Management
Definition
Ergebnis der Kundenzufriedenheit mit dem Financial Management für IT Services.
Relevanz
Die Kundenzufriedenheit zeigt, wie das Kostenmodell und die Preise empfunden werden.
Messwert
Abfrage in der Kundenzufriedenheitsumfrage
Bemerkung
Hier sollten die Fragen auf bestimmte Aspekte, wie „Verständlichkeit des Kostenmodells“ oder „Fairer Service-Preis“ detailliert werden.
Name der Kennzahl
Budgetplanung
Definition
Übereinstimmung des geplanten Budgets mit den tatsächlichen Ausgaben.
Relevanz
Eine gute Budgetplanung reduziert die finanziellen Risiken.
Messwert
Gegenüberstellung der Plan-Kosten zu den tatsächlichen Kosten. Diese sind in der Regel im ERP-System hinterlegt.
Name der Kennzahl
Ermittlung Service-Kosten
Definition
Ermittlung der vollständigen Kosten für den IT Service
Relevanz
Mittels des IT Service werden die Geschäftsprozesse sichergestellt. Hierzu werden servicebezogene IT-Kosten bzw. Preise benötigt.
Messwert
Auswertung der Kosten im Service Katalog.
169
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl
Bemängelte Leistungsverrechnung
Definition
Anteil der verrechneten Leistungen, die vom Kunden hinterfragt bzw. reklamiert werden.
Relevanz
Die Leistungsverrechnung muss für den Kunden nachvollziehbar und widerspruchsfrei sein.
Messwert
Auswertung der durchgeführten und dokumentierten Reviews.
Bemerkung
Voraussetzung für die Messung ist, dass die Reviews auf diesen Aspekt eingehen.
Name der Kennzahl
Anteil kritischer Services mit BIA
Definition
Anteil der geschäftskritischen Services, für die eine Business Impact Analyse (BIA) vorliegt.
Relevanz
Mithilfe der BIA können die Auswirkungen von Serviceausfällen auf die Geschäftsprozesse bewertet werden und sind Basis für Forderungen an die sicherzustellende Qualität des Service Managements.
Messwert
Identifizierung kritischer Services aus dem Service Katalog und Überprüfung auf vorhandene BIA.
Name der Kennzahl
IT-Kosten am Umsatz
Definition
Anteil der IT-Kosten am Umsatz des Unternehmens.
Relevanz
Dies ist die klassische Kennzahl zur Bewertung der IT aus Top Management Sicht.
Messwert
Die Messwerte sind nach Branche verschieden. Ein Benchmark ist das Intervall 1,5 bis 3,00 %.
Bemerkung
Die Kennzahl beschreibt, wie effizient die IT arbeitet (Kostenaspekt).
170
5.3 Prozess-Kennzahlen
5.3.2.1 Service Portfolio Management Dieser Prozess ist für das Management des Service Portfolios verantwortlich. Er berücksichtigt die Services in Bezug auf den für das Business gelieferten Wert. Name der Kennzahl
Anzahl Services im Portfolio
Definition
Anzahl der definierten Services im Portfolio
Relevanz
Ist einerseits als Referenzwert notwendig, andererseits zeigt die Kennzahl den Umfang des Servicespektrums auf.
Messwert
Auswertung der Services im Service Portfolios
Name der Kennzahl
Anteil gelieferter Services
Definition
Anteil der im Service Portfolio definierten Services, die von Kunden genutzt werden.
Relevanz
Diese Kennzahl zeigt die Nachfrage der angebotenen Services auf.
Messwert
Auswertung der Services im Service Katalog und im Service Portfolio.
Name der Kennzahl
Anteil Relationen IT Services zu Geschäftsprozessen
Definition
Anteil der abgebildeten Relationen zu den übergeordneten Geschäftsprozessen. Die IT Services dienen der Unterstützung der Geschäftsprozesse. Vorfälle und Maßnahmen innerhalb der IT können so direkt einem Geschäftsprozess zugeordnet werden.
Messwert
Auswertung des Service Portfolios.
Name der Kennzahl
Anteil Veränderungen im Service Portfolio
Definition
Anteil der im Service Portfolio vorgenommenen Veränderungen an den enthaltenen Services.
Relevanz
Die Kennzahl ist ein Kennzeichen für die Dynamik der geplanten und angebotenen Services.
Messwert
Auswertung des Service Portfolios.
171
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl
Status der Services im Service Portfolio
Definition
Status der Services im Service Portfolio
Relevanz
Die Kennzahl zeigt den Anteil der produktiven Services in Relation zu den in Entwicklung/ Überführung sowie den in Aussonderung befindlichen Services.
Messwert
Auswertung des Service Portfolios und Gruppierung anhand des Status.
Bemerkung
Die Services können den folgenden Status annehmen „Service Katalog“, „Service Pipeline“ (Service noch nicht produktiv) und „Retired Services“
5.3.1.3 Demand Management Das Demand Management hat die Kundenanforderungen an die IT Services aufzunehmen und zu beeinflussen, sodass die notwendigen Kapazitäten bereitgestellt werden können, die diesen Forderungen entsprechen. Name der Kennzahl
Anzahl der Kundenneuprojekte
Definition
Anzahl der vom Kunden gewünschten Neuprojekte in einer speziellen Applikationsdomain, einem Applikationsbereich etc.
Relevanz
Festlegung der Priorität in der Umsetzung von Applikationsprojekten. Festlegung der IT Ressourcenauslastung mit dem Kunden.
Messwert
Anzahl der IT Projektanmeldungen pro Applikationsbereich und Zeitraum
Bemerkung
Transparenz zwischen Kunde und IT bzgl. der IT Ressourcenauslastung.
Name der Kennzahl
Anzahl kurzfristiger Kapazitätsanpassungen
Definition
Anzahl kurzfristiger Anpassungen der bereitzustellenden Kapazitäten
Relevanz
Kurzfristige Anpassungen der Kapazitäten führen zu Zusatzkosten. Entweder entstehen ungenutzt Überkapazitäten oder Zusatzkapazitäten sind kurzfristig – daher in der Regel – teuer zu beschaffen. Häufig auftretende Anpassungen
172
5.3 Prozess-Kennzahlen sind ein Indiz für Probleme beim Demand Management. Messwert
5.3.2
Ergebnisse aus dem Review des Capacity Managements
Service Design
5.3.2.1 Service Catalogue Management Das Service Catalogue Management soll sicherstellen, dass ein Servicekatalog entwickelt und gewartet wird, der genaue Information über alle aktuellen und geplanten operationellen Services enthält. Name der Kennzahl
Service aus dem Service Katalog
Definition
Anzahl und Anteil der im Betrieb befindlichen Services, die im Service Katalog beschrieben sind.
Relevanz
Der Service Katalog soll alle im Betrieb befindlichen Services enthalten. Diese Kennzahl zeigt die Qualität und Aktualität des Service Katalogs auf.
Messwert
Vergleich der SLAs mit dem Service Katalog.
Bemerkung
Bei der Messung wird vorausgesetzt, dass für alle im Betrieb befindlichen Services SLAs existieren.
Name der Kennzahl
Inhaltliche Abweichungen zum Service Katalog
Definition
Anteil der inhaltlichen Abweichungen der im Betrieb befindlichen Services gegenüber den Spezifikationen im Service Katalog.
Relevanz
Der Service Katalog dient auch der Standardisierung von Services. Weichen die tatsächlichen Services von den Beschreibungen im Service Katalog ab, so wird diese Standardisierung nicht erreicht.
Messwert
Vergleich der SLAs mit dem Service Katalog.
Bemerkung
Bei der Messung wird vorausgesetzt, dass für alle im Betrieb befindlichen Services SLAs existieren.
173
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen
5.3.2.2 Service Level Management Der Prozess Service Level Management (SLM) ist für das Verhandeln von Service Level Agreements verantwortlich und hat sicherzustellen, dass diese SLAs eingehalten werden. Das SLM hat sicherzustellen, dass alle IT Service Management-Prozesse, Operational Level Agreements (OLAs) and Underpinning Contracts (UCs) den vereinbarten Service Level Zielen (Service Level Targets) entsprechen. Das SLM führt hierzu ein Monitoring und Reporting der Service Level sowie regelmäßige Reviews mit den Kunden durch. Name der Kennzahl
Kundenzufriedenheit Service Level Management
Definition
Ergebnis der Kundenzufriedenheit mit dem Service Level Management.
Relevanz
Die Kundenzufriedenheit mit dem Service Level Management ist mehr als die (messtechnische) Einhaltung der SLAs. Dazu gehört unter anderem auch die Flexibilität des IT Service Providers.
Messwert
Abfrage in der Kundenzufriedenheitsumfrage.
Bemerkung
Zusätzlich kann dieser Aspekt auch innerhalb einer Anwenderzufriedenheitsumfrage abgefragt werden.
Name der Kennzahl
Einhaltung der SLAs
Definition
Anteil der SLAs, deren Vereinbarungen eingehalten werden.
Relevanz
Die Einhaltung von SLAs stellt die vereinbarte IT-Unterstützung der Geschäftsprozesse sicher. Im externen Kunden-Lieferanten-Verhältnis sind mit der Einhaltung Preis-Regelungen verbunden.
Messwert
Hier sollte auf ein professionelles SLM-Tool zurückgegriffen werden, mit dessen Hilfe die einzelnen SLAs gemessen und die Ergebnisse berichtet werden können.
Bemerkung
Hierzu muss definiert werden, wann ein SLA als „eingehalten“ zählt. Zum Beispiel, wenn alle
174
5.3 Prozess-Kennzahlen einzelnen Service Level eines SLAs eingehalten werden. Name der Kennzahl
Anzahl der SLA-Reviews
Definition
Anteil der durchgeführten SLA-Reviews.
Relevanz
Die Reviews unterstützten eine bessere Zusammenarbeit zwischen Kunde und IT Service Provider. Im Rahmen von Reviews werden u. a. notwendige Service-Verbesserungen diskutiert.
Messwert
Auswertung der dokumentierten Reviews.
Bemerkung
Die Anzahl der Reviews können auch im SLA vereinbart werden.
Name der Kennzahl
Kundenerlöspriorität im Unternehmen
Definition
Welche Erlöse werden mit welchem Kunden, welchem Fachbereich, welcher Unternehmenseinheit getätigt.
Relevanz
Fokussierung auf die wichtigsten Kunden der IT.
Messwert
Erlös-Summe aller SLAs für einen bestimmten Kunden.
Bemerkung
Eine für die IT relevante Kennzahl, um im Sinne der ABC Technik festzulegen, wie intensiv ein Kunde betreut wird. Kunden mit hohen IT Erlösen werden bevorzugt betreut. Diese Kennzahl ist auch im Sinne des Gesamtunternehmens von hoher Bedeutung, da sie auf die Unternehmensbereiche mit hohen IT Erlösen fokussiert.
Name der Kennzahl
Anteil SLA Verletzungen durch UCs
Definition
Anteil der SLA-Verletzungen, die aufgrund nicht eingehaltener UCs entstanden sind.
Relevanz
Können SLAs nicht eingehalten werden, weil der Lieferant seine Zusagen nicht einhält, so müssen entsprechende Folgeaktivitäten eingeleitet werden.
Messwert
Hier sollte auf ein professionelles SLM-Tool
175
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen zurückgegriffen werden, mit dessen Hilfe die einzelnen SLAs und UCs gemessen und die Ergebnisse berichtet werden können. Name der Kennzahl
Anteil SLA Verletzungen durch OLAs
Definition
Anteil der SLA-Verletzungen, die aufgrund nicht eingehaltener OLAs entstanden sind.
Relevanz
Können SLAs nicht eingehalten werden, weil interne Einheiten ihre Zusagen nicht einhalten, so müssen entsprechende Folgeaktivitäten eingeleitet werden.
Messwert
Hier sollte auf ein professionelles SLM-Tool zurückgegriffen werden, mit dessen Hilfe die einzelnen SLAs und OLAs gemessen und die Ergebnisse berichtet werden können.
Name der Kennzahl
Anzahl ausstehender Maßnahmen im SIP
Definition
Anzahl der im Service Improvement Plan (SIP) enthaltenen Maßnahmen, die nicht wie geplant umgesetzt wurden.
Relevanz
Der SIP enthält notwendige Verbesserungsmaßnahmen für die IT Services. Diese Kennzahl zeigt, ob die identifizierten Maßnahmen planmäßig umgesetzt wurden.
Messwert
Auswertung der offenen Maßnahmen im SIP, deren Umsetzungstermin überschritten ist.
Name der Kennzahl
Anzahl Maßnahmen im SIP
Definition
Anzahl der im Service Improvement Plan (SIP) enthaltenen Maßnahmen.
Relevanz
Der SIP enthält notwendige Verbesserungsmaßnahmen für IT Services. Diese Kennzahl zeigt den Umfang der noch offenen Maßnahmen bzw. der umgesetzten Maßnahmen.
Messwert
Auswertung der offenen Maßnahmen im SIP.
Bemerkung
Die Maßnahmen sollten im Plan mit einem Status versehen werden. Dadurch können offene
176
5.3 Prozess-Kennzahlen Maßnahmen, in der Umsetzung befindliche oder bereits umgesetzte Maßnahmen dargestellt werden.
5.3.2.3 Capacity Management Das Capacity Management stellt sicher, dass die bereitgestellten Kapazitäten für die IT Services und die IT Infrastruktur gemäß den vereinbarten Service Level Zielen kostengünstig und rechtzeitig bereitgestellt werden. Das Capacity Management berücksichtigt alle geforderten Ressourcen zur Bereitstellung des IT Service und plant auf Basis der kurz-, mittel- und langfristigen Geschäftsanforderungen. Name der Kennzahl
Anzahl SLA-Verletzungen aufgrund fehlender Kapazitäten
Definition
Anzahl der Verletzungen von SLAs aufgrund der nicht sichergestellten Kapazitäten.
Relevanz
Werden die vereinbarten Kapazitäten nicht bereitgestellt, so führt dies in der Regel zu Geschäftsausfällen.
Messwert
Die Ist-Kapazitäten werden in der Regel aus dem System-Management oder mit Robotern (Antwortzeiten) ermittelt und den Soll-Werten gegenübergestellt.
Bemerkung
Die SLA-Verletzungen sind pro SLA auszuweisen.
Name der Kennzahl
Lastspitzen und Gesamtauslastungsrate
Definition
Darstellung der Lastspitzen und Gesamtauslastung pro SLA.
Relevanz
Zielsetzung des Capacity Managements ist die Einhaltung der Service Level, aber auch der Wirtschaftlichkeit. Daher sollte sich die Auslastung - in Abhängigkeit der IT-Strategie - dem Soll-Wert annähern. Lastspitzen können ggf. Zusatzbedarf oder die Notwendigkeit von Verlagerungen aufzeigen
Messwert
Die Auslastungen werden in der Regel aus dem System-Management oder zum Beispiel mit Robotern (Antwortzeiten) ermittelt.
177
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl
Prozentsatz unzureichender Antwortzeiten
Definition
Prozentsatz der Antwortzeiten, die dem SLA nicht entsprechen.
Relevanz
Schlechte Antwortzeiten führen dazu, dass der Service als nicht verfügbar angesehen und nicht mehr genutzt wird. Geschäftsausfälle und Kundenunzufriedenheit sind die Folge.
Messwert
Die Antwortzeiten werden in der Regel aus dem System-Management oder zum Beispiel mit Robotern ermittelt.
Name der Kennzahl
Qualität des Capacity Plans
Definition
Übereinstimmung der im Capacity Plan dokumentierten Veränderungen gegenüber den tatsächlichen Veränderungen.
Relevanz
Eine gute Planung ist wichtig für das Financial Management. Eine gute Planung verhindert kurzfristige und in der Regel teurere Beschaffungsmaßnahmen.
Messwert
Gegenüberstellung der Planungsdaten gegenüber den Daten des Configuration Management Systems.
Bemerkung
Es können auch „Emergency Changes“ aus dem Capacity Managements ermittelt werden. Diese sind ein Indiz für einen kurzfristigen Handlungsbedarf.
Name der Kennzahl
Anzahl und Anteil überwachter Systeme
Definition
Anzahl und Anteil der zentralen Systeme, die mittels eines Monitoring überwacht werden.
Relevanz
Das Monitoring ist Voraussetzung für eine gute Planung und Überwachung der eingesetzten Systeme.
Messwert
Die Anzahl ist dem System Management zu entnehmen, ggf. auch dem Configuration Management. Die Anzahl der zentralen Systeme kann dem Configuration Management System entnommen werden.
178
5.3 Prozess-Kennzahlen Name der Kennzahl
Kosteneinsparung durch das Capacity Management pro Bereich oder Technologie
Definition
Einsparungssumme in Euro, die durch optimaleren Einsatz von Technik (z. B. Verdichtung von Applikationen durch Virtualisierung) eingespart werden kann.
Relevanz
Capacity wird in immer mehr Unternehmen nicht nur in der Prognose von Kapazitätswachstum gesehen, sondern auch zur effektiveren Nutzung der Ressourcen
Messwert
Kosteneinsparung durch optimalere Nutzung der Technologien in Euro; z. B. im Bereich der Security wurden 100.000 Euro Invest eingespart, indem Lizenzen aus dem Abbau von Clients im Bereich xyz wiederverwendet wurden.
Bemerkung
Vermeidung von Invest durch Technologieoptimierungen sichert die Möglichkeit, in innovative IT Bereiche zu investieren
Name der Kennzahl
Capacity Management pro Technologie zum Beispiel Anzahl der Mails In and Out pro Tag
Definition
Vergleich der eingehenden zu den ausgehenden Mails. Je nach Unternehmen ist diese Kennzahl unterschiedlich, liegt aber in der Regel bei ca. 1 zu 2 (ausgehend zu eingehend). Sollte der eingehende Wert stark ansteigen ist dies z. B. der Hinweis auf SPAM oder Mail-Attacken, dem unbedingt entgegen zu treten ist, um die Ressourcen weiterhin optimal zu nutzen.
Relevanz
Erkennen von „Ressourcenverschwendungen“ – Hinweis auf die Einführung neuer Technologien um einen Kostenanstieg dauerhaft zu vermeiden.
Messwert
Vergleich über mehrere Tage, Wochen, Monate der Anzahl der eingehenden zu den ausgehenden Mails.
179
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen
5.3.2.4 Availability Management Der Prozess ist verantwortlich für die Definition, Analyse, Planung, Messung und Verbesserung aller Aspekte der Verfügbarkeit für IT Services. Das Availability Management ist dafür verantwortlich, dass die gesamte IT Infrastruktur, Prozesse, Tools, Rollen usw. den vereinbarten Service Level Zielen bezüglich der Verfügbarkeit entsprechen. Name der Kennzahl
Verfügbarkeit des Service und Komponenten
Definition
Verfügbarkeit der Services und der Komponenten innerhalb des vereinbarten Zeitraums.
Relevanz
Die Verfügbarkeit ist als wichtigster Service Level anzusehen. Deren Kenntnis ist ein wichtiger Input für das Service Level Management.
Messwert
Die Definition der Messung ist abhängig von der geforderten Qualität und den damit verbundenen Kosten. Von der Auswertung von Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel über MessPCs.
Name der Kennzahl
Anzahl SLA-Verletzungen aufgrund fehlender Verfügbarkeit
Definition
Anzahl der Verletzungen von SLAs aufgrund der nicht sichergestellten Verfügbarkeit.
Relevanz
Wird die vereinbarte Verfügbarkeit nicht sichergestellt, so führt dies in der Regel zu Geschäftsausfällen.
Messwert
Auswertung der gemessenen Verfügbarkeit gegenüber dem Soll-Wert.
Bemerkung
Die SLA-Verletzungen sind pro SLA auszuweisen.
Name der Kennzahl
Nicht-Verfügbarkeit innerhalb kritischer Geschäftszeiten
Definition
Nicht-Verfügbarkeit innerhalb kritischer Geschäftszeiten für einen IT Service.
Relevanz
Wurden mit dem Kunden kritische Geschäfts-
180
5.3 Prozess-Kennzahlen zeiten vereinbart, so ist die Verfügbarkeit innerhalb dieser Zeit besonders herauszustellen. Messwert
Die Definition der Messung ist abhängig von der geforderten Qualität und den damit verbundenen Kosten. Von der Auswertung von Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel über MessPCs.
Name der Kennzahl
Kosten der Nicht-Verfügbarkeit
Definition
Kosten für das Business, wenn die vereinbarte Verfügbarkeit nicht erreicht wird.
Relevanz
Wird die Verfügbarkeit nicht erreicht, so führt dies in der Regel zu Geschäftsausfällen oder zumindest Zusatzkosten.
Messwert
Die Kosten sind zusammen mit dem Kunden zu definieren. In der einfachsten Form wird die Ausfallzeit pro Anwender ermittelt und mit der Anzahl der Anwender und deren Stundensatz multipliziert.
Name der Kennzahl
Mittlere Ausfallzeit pro Service
Definition
Mittlere Ausfallzeit pro IT Service, gemessen vom Ausfall des Service bis zum Zeitpunkt, zu dem der Service wieder vom Kunden (Anwender) genutzt werden kann.
Relevanz
Während die Verfügbarkeit ein statisches Maß ist, bestimmt die mittlere Ausfallzeit die jeweilige Dauer. Maximale Dauer kann zusammen mit der Verfügbarkeit als Service Level vereinbart werden.
Messwert
Die Definition der Messung ist abhängig von der geforderten Qualität und den damit verbundenen Kosten. Von der Auswertung von Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel über MessPCs.
Bemerkung
Zum Teil wird diese Zeit als MTTR - Mean Time to Restore - bezeichnet. Häufiger wird die Ab-
181
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen kürzung für Mean Time to Restore verwendet. Es ist daher stets zu prüfen, ob die Zeitspanne die Recovery-Zeit einschließt. Eine Drill-Down Funktion sollte eine detaillierte Analyse der einzelnen Zeitstrecke ermöglichen. Name der Kennzahl
Häufigkeit von Ausfällen pro Service
Definition
Anzahl der Unterbrechungen des vereinbarten Service.
Relevanz
Die Kennzahl dient als Indiz für die Zuverlässigkeit des IT Service.
Messwert
Die Definition der Messung ist abhängig von der geforderten Qualität und den damit verbundenen Kosten. Von der Auswertung von Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel über MessPCs.
Name der Kennzahl
Qualität des Availability Plans
Definition
Übereinstimmung der im Availability Plan dokumentierten Veränderungen gegenüber den tatsächlichen Veränderungen.
Relevanz
Eine gute Planung ist wichtig für das Financial Management. Eine gute Planung verhindert kurzfristige und in der Regel teurere Beschaffungsmaßnahmen.
Messwert
Gegenüberstellung der Planungsdaten gegenüber den Daten des Configuration Management Systems.
Bemerkung
Es können auch „Emergency Changes“ aus dem Availability Managements ermittelt werden. Diese sind ein Indiz für einen kurzfristigen Handlungsbedarf.
5.3.2.5 IT Service Continuity Management Der Prozess IT Service Continuity Management (ITSCM) ist verantwortlich für das Management der Risiken, die schwere Auswirkungen auf den IT Service haben. Das ITSCM stellt durch eine Risikoreduzierung auf eine
182
5.3 Prozess-Kennzahlen akzeptable Ebene und die Planung des Recovery von IT Services sicher, dass der IT Service Provider immer die minimal vereinbarten Service Level Ziele bereitstellen kann. Das ITSCM sollte zur Unterstützung des Business Continuity Managements entworfen werden. Name der Kennzahl
Anteil SLAs mit ITSC-Anforderungen
Definition
Anteil der SLAs, die Anforderungen an die IT Service Continuity enthalten.
Relevanz
Die ITSCM Pläne sind an die Geschäftsanforderungen und den jeweiligen Service-Anforderungen auszurichten. Innerhalb von SLAs sind diese zu dokumentieren.
Messwert
Überprüfung der vorhandenen SLAs.
Bemerkung
Hier wird davon ausgegangen, dass für sämtliche Services SLAs existieren. Alternativ ist zu prüfen, ob die ITSC-Pläne mit den IT Services korrespondieren.
Name der Kennzahl
Anzahl und Anteil erfolgreicher ITSCM Audits
Definition
Anzahl und Anteil der erfolgreich durchgeführten ITSCM Überprüfungen.
Relevanz
Es muss sichergestellt werden, dass die ITSCM Pläne im Notfall auch funktionieren. Daher sind sie regelmäßig zu überprüfen.
Messwert
Auswertung der durchgeführten Reviews und Audits.
Bemerkung
Ergänzend sollte das Datum des letzten Audits / Reviews ausgewiesen werden.
Name der Kennzahl
Anzahl und Anteil erfolgreicher ITSCM Tests
Definition
Anzahl und Anteil der erfolgreich durchgeführten ITSCM Tests.
Relevanz
Es muss sichergestellt werden, dass die ITSCM Pläne im Notfall auch funktionieren. Daher sind sie regelmäßig zu testen.
Messwert
Auswertung der durchgeführten Testprotokolle.
183
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Bemerkung
Die Tests sollten zumindest einmal jährlich zusammen mit den Geschäftsbereichen (Business Continuity Management) erfolgen.
Name der Kennzahl
Schulungsstunden und Maßnahmen ITSCM
Definition
Anzahl der durchgeführten Schulungsstunden und Schulungsmaßnahmen für das ITSCM.
Relevanz
Schulung der Mitarbeiter stellt sicher, dass die Mitarbeiter mit den Maßnahmen vertraut sind und die Notwendigkeit einsehen.
Messwert
Auswertung der durchgeführten Schulungsmaßnahmen.
Name der Kennzahl
Zeitdauer für Aktualisierung der ITSC-Pläne
Definition
Zeitdauer für Aktualisierung der ITSC-Pläne aufgrund eines identifizierten Änderungsbedarfs.
Relevanz
Änderungen können sich aufgrund geänderter Kundenanforderungen oder durchgeführter Changes ergeben. Dann ist sicherzustellen, dass die notwendigen Änderungen zeitnah umgesetzt werden.
Messwert
ITSC-Pläne sind CIs. Im Rahmen der Versionsverfolgung kann aus dem Configuration Management System die Zeitspanne ermittelt werden.
5.3.2.6 Information Security Management Der Prozess Information Security Management stellt die Vertraulichkeit, Integrität und Verfügbarkeit von den Vermögenswerten (Assets) einer Organisation, deren Information, Daten und IT Services sicher. Das Information Security Management ist normalerweise ein Teil des organisatorischen Ansatzes zum Security Management, das einen breiteren Scope gegenüber dem IT Service Provider hat und die Handhabung von Schriftstücken, Gebäudezugängen, Telefonanrufe usw. für die gesamte Organisation beinhaltet.
184
5.3 Prozess-Kennzahlen Name der Kennzahl
Anzahl und Auswirkungen Security Incidents
Definition
Anzahl und Auswirkungen der festgestellten Security Incidents.
Relevanz
Aufgabe des Security Managements ist die Analyse mögliche Bedrohungen und deren präventive Reduktion. Diese Kennzahl zeigt die Qualität der Prävention auf und ist Indikator für mögliche Verbesserungen.
Messwert
Auswertung der Incident Records mit der Kategorie „Security“ und der Codierung „Auswirkung“ (Impact).
Bemerkung
Voraussetzung ist, dass die Security Incidents entsprechend erkannt und dokumentiert werden.
Name der Kennzahl
Anteil SLAs mit Sicherheits-Klauseln
Definition
Anteil des SLAs, die Klauseln zu den Sicherheits-Anforderungen enthalten.
Relevanz
Die notwendigen Sicherheitsmaßnahmen sind auf die Geschäftsanforderungen abzustimmen. Innerhalb werden die Anforderungen mit dem Kunden vereinbart und dokumentiert.
Messwert
Auswertung der SLAs.
Bemerkung
Werden Leistungen an Dritte vergeben, so sind die UCs entsprechend zu verfolgen.
Name der Kennzahl
Anzahl festgestellter Sicherheitsverletzungen
Definition
Anzahl der festgestellten Nicht-Konformität der IT Service Management-Prozesse und Systeme mit den definierten Sicherheitsanforderungen (Security Policy und Prozess).
Relevanz
Die Kennzahl zeigt die zunehmende Akzeptanz und Wahrnehmung von Sicherheitsbelangen.
Messwert
Auswertung durchgeführter Audits und Revisionen.
Bemerkung
Festgestellte Verletzungen von ComplianceAnforderungen sind besonders herauszustellen.
185
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl
Anzahl vergeblicher Login-Versuche
Definition
Anzahl der festgestellten vergeblichen LoginVersuche.
Relevanz
Eine hohe Anzahl vergeblicher Login-Versuche zeigt mögliche illegale Versuche der Informationsbeschaffung auf.
Messwert
Auswertung der Protokolldatei entsprechender Identifizierungssysteme.
Bemerkung
Hierzu sind „auffällige“ User-IDs zur Prävention herzustellen.
Name der Kennzahl
Anzahl Verbesserungsvorschläge zur Security
Definition
Anzahl der eingereichten Verbesserungsvorschläge und Verbesserungsmaßnahmen im Bereich des Security Managements.
Relevanz
Die Kennzahl zeigt die zunehmende Akzeptanz und Wahrnehmung von Sicherheitsbelangen.
Messwert
Auswertung der Service und Prozess Improvement Pläne (SIP und PIP).
Name der Kennzahl
Aufwand für Security pro Jahr und pro Bereich.
Definition
Höhe der Investition pro Security-Bereich und Jahr z. B. in Virenschutz, Firewalls etc. und damit z. B. in äußere und innere Sicherheit.
Relevanz
Abstimmung, Umsetzung und Monitoring der Investitionen in die Security eines Unternehmens
Messwert
Investitionen pro Jahr aufgeteilt in interne und externe Security oder z. B. Virenschutz, Firewalls, Sniffer etc..
5.3.2.7 Supplier Management Der Prozess Supplier Management ist dafür verantwortlich, sicherzustellen, dass alle Verträge mit Lieferanten die Geschäftsanforderungen unterstützen und dass alle Lieferanten ihren vertraglichen Verpflichtungen nachkommen.
186
5.3 Prozess-Kennzahlen Name der Kennzahl
Anteil eingehaltener UCs
Definition
Anteil der Lieferanten, die die im Underpinning Contract (UC) vereinbarten Anforderungen erfüllen.
Relevanz
Die Enthaltung der SLAs ist abhängig von der Einhaltung der UCs. Halten die Lieferanten die Vereinbarungen nicht ein, so hat dies einen unmittelbaren Einfluss auf die Unterstützung der Geschäftsprozesse.
Messwert
Wird dem Tool für das Monitoring der Service Level entnommen.
Name der Kennzahl
Anzahl Kundenbeschwerden zum Service
Definition
Anzahl der Kundenbeschwerden, die auf Nichteinhaltung von UCs zurückzuführen sein.
Relevanz
Die Nichteinhaltung von UCs führt in der Regel zu Service Level-Verletzungen und zu Kundenunzufriedenheit. Über ein Monitoring sind nicht sämtliche Aspekte zu messen.
Messwert
Auswertung von Reviews.
Name der Kennzahl
Anzahl der Streitfälle mit Lieferanten
Definition
Anzahl der formellen Streitfälle mit den beauftragten Lieferanten.
Relevanz
Formelle Streitfälle mit Lieferanten sind ein Indiz für nicht eindeutige Vereinbarungen innerhalb der UCs.
Messwert
Die Streitfälle sind vom Supplier Manager in einem System zu speichern.
Bemerkung
Bei Bedarf kann hier im Rahmen einer DrillDown Funktion noch nach dem Anlass unterschieden werden, wie zum Beispiel bemängelte Rechnungen oder Verletzungen von Compliance-Anforderungen.
Name der Kennzahl
Anzahl der Reviews mit Lieferanten
Definition
Anzahl der mit Lieferanten zum Service und
187
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen UC durchgeführten Reviews. Relevanz
Reviews dienen der besseren Abstimmung mit dem Lieferanten und führen zu einer Steigerung der Service-Qualität.
Messwert
Die Anzahl der durchgeführten Reviews sind vom Supplier Manager in einem System zu speichern.
Name der Kennzahl
Anzahl von Lieferanten, die faktisch der ITSteuerung unterliegen.
Definition
Anzahl der Lieferanten, die einem Supplierund Vertrags-Manager zugeordnet sind.
Relevanz
Die Supplier sind hinsichtlich der vereinbarten Leistungen und vertraglichen Aspekte durch verantwortliche Manager zu steuern.
Messwert
Die UCs sind zusammen mit den zugeordneten Managern im SLM-Tool gespeichert. Die zugeordnete Anzahl kann diesem System entnommen werden.
Bemerkung
Ergänzend kann zur Anzahl auch der Anteil der zugeordneten Lieferanten dargestellt werden.
Name der Kennzahl
Zufriedenheit mit dem Lieferanten
Definition
Zufriedenheit in der Zusammenarbeit und Kommunikation mit dem Lieferanten.
Relevanz
Eine gute Kommunikation und Zusammenarbeit zeigt sich auch außerhalb der festgelegten Service Level.
Messwert
Zufriedenheitsbefragung der innerhalb der IT mit dem Lieferanten zusammenarbeitenden Bereiche.
Bemerkung
Es kann auch der Lieferant zur Zufriedenheit befragt werden.
188
5.3 Prozess-Kennzahlen
5.3.3
Service Transition
5.3.3.1 Transition Planning and Support Der Prozess „Transition Planning und Support“ ist verantwortlich für die Planung der gesamten Service Transition Prozesse und Koordination der erforderlichen Ressourcen. Diese Prozesse sind „Change Management“, „Service Asset and Configuration Management “, „Release and Deployment Management“, „Service Validation and Testing“, „Evaluation“ und „Knowledge Management“. Name der Kennzahl
Anteil eingehaltener Release-Vereinbarungen
Definition
Anteil der Releases, die die zuvor vereinbarten Kriterien hinsichtlich Kosten, Qualität, Umfang und Terminplanung einhalten.
Relevanz
Für den Kunden ist nicht nur die Einhaltung der Qualität und die geplanten Termine für Releases von Relevanz, sondern auch, dass der implementierte Inhalt der Planung und Vereinbarung entspricht. Die Auswirkung der Einhaltung der Kostenplanung ist abhängig von der Leistungsverrechnung.
Messwert
Hierzu sind in den Release-Records die Planungsinformationen hinsichtlich Kosten, Termine und geplante Inhalte (Changes) zu speichern und mit dem Auslieferungsumfang, Termin und ermittelten Kosten zu vergleichen. Die Qualität wird über ggf. auftretende Incidents gemessen.
Bemerkung
In dieser Kennzahl werden mehrere Aspekte gemeinsam betrachtet. Dazu ist ggf. eine Gewichtung dieser Aspekte notwendig. Es ist auch möglich, aus den einzelnen Aspekten (Kosten, Termine, etc.) einzelne Kennzahlen zu definieren.
Name der Kennzahl
Kundenzufriedenheit Service Transition Pläne
Definition
Ergebnis der Kundenzufriedenheit bezüglich der Service Transition Pläne.
189
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Relevanz
Abweichungen des geplanten Release haben Auswirkungen auf die Kunden- (und Anwender) -zufriedenheit.
Messwert
Abfrage in der Kundenzufriedenheitsumfrage
Bemerkung
Hier ist zusätzlich auch eine Abfrage der Anwender möglich.
Name der Kennzahl
Zufriedenheit Service Team
Definition
Zufriedenheit in den Projekt- und ServiceTeams mit den in der Phase Service Transition definierten Verfahren.
Relevanz
Die korrekte Nutzung der beschrieben Verfahren hängt von der Praktikabilität und von Akzeptanz innerhalb der Service Teams und der beteiligten Projekt-Teams ab.
Messwert
Hierzu sind interne Feedbacks einzuholen und auszuwerten.
190
5.3 Prozess-Kennzahlen
5.3.3.2 Change Management Der Prozess Change Management ist für das Controlling des gesamten Lifecycle aller Changes verantwortlich. Das primäre Ziel des Change Managements besteht darin, die Durchführung vorteilhafter Changes zu ermöglichen, mit minimalen Störungen der IT Services. Name der Kennzahl
Anzahl Changes
Definition
Die Kennzahl stellt die Anzahl der bearbeiteten Changes im Betrachtungszeitraum dar. Betrachtet werden alle RFCs, die vom Change Management bearbeitet wurden, das heißt auch zurückgewiesene RFCs.
Relevanz
Die Kennzahl ist wichtig als Referenzwert. Darüber hinaus zeigt die Anzahl der Changes die Flexibilität der IT-Organisation, auf Kundenanforderungen schnell zu reagieren.
Messwert
Aus der Change-DB werden sämtliche RFCs im Betrachtungszeitraum ermittelt.
Bemerkung
Die Darstellung der Gesamtzahl allein ist wenig informativ. Daher ist eine Aufschlüsselung in IT Services, betroffene CIs (Infrastruktur, Applikation, etc.) notwendig. Eine weitere Aufschlüsselung besteht in der Darstellung der Prioritäten, wobei die „Emergency Changes“ besonders herausgehoben werden sollten. Weiterhin sollte eine Aufgliederung darstellen, ob es sich um Kunden- oder IT-getriebene Changes handelt.
Name der Kennzahl
Anteil fehlerfreier Changes
Definition
Darstellung des Verhältnisses fehlerfreier Changes – das heißt Implementierung des Changes ohne anschließende Incidents im Betrieb – in Bezug zur Anzahl der Changes
Relevanz
Diese Kennzahl ist die wichtigste Kennzahl für die Effektivität des Change Managements. Ein hoher Anteil nicht fehlerfreier Changes ist ein
191
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Indiz für eine unzureichende Auswirkungsanalyse der RFCs. Fehlerhafte Changes führen zu Geschäftsausfällen, dadurch sinkt die Kundenzufriedenheit. Weiterhin führen fehlerhafte Changes innerhalb der IT zu Zusatzaufwendungen, das heißt die IT-Kosten steigen. Messwert
Im Idealfall werden im Betrachtungszeitraum die implementierten Changes aus der ChangeDB ermittelt und geprüft, ob hierfür Incident Records existieren (im Incident Record ist die Nummer des Changes als Grund für den Incident vermerkt).
Bemerkung
Für die Aussagekraft dieser Kennzahl sind die Datenqualität und das Know-how im Incident Management entscheidend. Wird ein fehlerhafter Change nicht als Grund der Störung erkannt und eingetragen, so hat dies erheblichen Einfluss auf die Qualität dieser Kennzahl. Hier wäre dann zu überlegen, ob alternativ die Probleme aufgrund von Changes auszuwerten sind, da im Problem Management von einer besseren Datenqualität auszugehen ist.
Name der Kennzahl
Anteil termingerechter Changes
Definition
Darstellung des Verhältnisses termingerechter Changes - das heißt Implementierung bis zum vereinbarten Termin - in Bezug zur Anzahl der Changes
Relevanz
Diese Kennzahl ist eine Kennzahl für die Effektivität des Change Managements. Ein hoher Anteil nicht termingerechter Changes ist ein Indiz für eine unzureichende Planung. Werden die zugesagten Termine nicht eingehalten, sinkt die Kundenzufriedenheit und unter Umständen entstehen Auswirkungen auf das Business.
Messwert
In der Change-DB werden die Datenfelder der „geplante Implementierung“ mit der „tatsächlichen“ Implementierung verglichen.
Bemerkung
Bei Bedarf können weitere Aspekte hinsichtlich der Qualität der Terminplanung verfolgt wer-
192
5.3 Prozess-Kennzahlen den, wie zum Beispiel den Beginn der geplanten Tests, etc. Name der Kennzahl
Anteil kostengerechter Changes
Definition
Darstellung des Verhältnisses kostengerechter Changes - das heißt Changes, die die vereinbarten Kosten nicht überschreiten - in Bezug zur Anzahl der Changes
Relevanz
Die Relevanz dieser Kennzahl ist abhängig von der Leistungsverrechnung. Werden die Kosten für Changes vom Kunden getragen, so haben Mehrkosten Auswirkungen auf die Kundenzufriedenheit. Muss die IT für die Kosten aufkommen, so führen Changes mit höheren Durchführungskosten zu einer nicht eingeplanten Kostensteigerung innerhalb der IT. Die Kennzahl zeigt die Qualität der Planung und Analyse von Changes hinsichtlich der Aufwendungen auf.
Messwert
Zum Change sind die damit verbundenen Aufwendungen (Personal, Material) zu erfassen. Aus der Change-DB werden diese Aufwendungen ermittelt und den geplanten Kosten gegenübergestellt.
Name der Kennzahl
Anteil erfolgreicher Back-Out-Planungen
Definition
Die Kennzahl stellt die Anzahl der erfolgreichen Back-Out-Maßnahmen im Verhältnis zu den durchgeführten Back-Out-Maßnahmen dar.
Relevanz
Nicht alle Changes können störungsfrei implementiert werden. Dann ist es wichtig, dass die Möglichkeit besteht, in den gesicherten Ausgangszustand zurückzukehren. Hierzu ist im Change Management eine Back-Out-Planung notwendig. Diese Kennzahl misst die Qualität dieser Planung.
Messwert
Aus der Change-DB werden die Changes ermittelt, die zurückgenommen werden mussten und die Changes, deren Back-Out-Plan erfolgreich
193
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen war. Bemerkung
Existieren hierfür keine Datenfelder, so können zur Generierung auch die Ergebnisse aus dem Review herangezogen werden.
Name der Kennzahl
Anzahl offener RFCs
Definition
Die Kennzahl zeigt an, wie viele RFCs noch nicht bearbeitet wurden.
Relevanz
Eine hohe Anzahl offener RFCs zeigt einen Bearbeitungsstau im Prozess an. Als Folge wird die Akzeptanz für das Change Management sinken, unter Umständen das Change Management umgangen und sinnvolle RFCs nicht mehr eingereicht.
Messwert
Ermittelt werden aus der Change-DB die Anzahl der RFCs für die Aktivität „Asses and evaluate the Change“ noch nicht durchgeführt wurde.
Name der Kennzahl
Anzahl nicht genehmigter Changes
Definition
Diese Kennzahl identifiziert die festgestellten Changes, die unter Umgehung des Change Managements durchgeführt wurden.
Relevanz
Die Anzahl deutet auf einen nicht wirksamen Change Management-Prozess hin. Häufig ist er zu administrativ, sodass der Prozess umgangen wird. Insbesondere für Unternehmen, die Compliance-Anforderungen wie SOX erfüllen müssen, ist diese Kennzahl von besonderer Bedeutung.
Messwert
Es werden die Ergebnisse des „Verification and Audit“ im Prozess „Service Asset und Configuration Management“ ausgewertet.
Name der Kennzahl
Anteil zurückgewiesener RFCs
Definition
Die Kennzahl zeigt an, wie viele der eingereichten RFCs vom Change Management zurückgewiesen wurden.
194
5.3 Prozess-Kennzahlen Relevanz
RFCs können zurückgewiesen werden, wenn sie zum Beispiel unvollständig sind. Ein hoher Anteil zurückgewiesener RFCs führt zu einem ineffizienten Prozess.
Messwert
Ermittelt werden aus der Change-DB, die Anzahl der RFCs, die den Status „zurückgewiesen“ aufweisen.
5.3.3.3 Service Asset and Configuration Management Dieser Prozess gliedert sich in die Sub-Prozesse „Asset Management“ und „Configuration Management“. Das Asset Management ist für die Verfolgung und das Reporting der Werte und Ownership sämtlicher finanzieller Assets während des gesamten Lebenszyklus verantwortlich. Das Configuration Management ist für die Pflege der Information über Configuration Items (CIs) und deren Beziehungen verantwortlich, die für die Bereitstellung der IT Services benötigt werden. Diese Informationen sind über den gesamten Lebenszyklus der CIs zu verwalten. Name der Kennzahl
Anzahl der CIs
Definition
Anzahl der Service Assets und der Configuration Items (CIs).
Relevanz
Die Anzahl der CIs dient für weitere Betrachtungen als Referenzwert.
Messwert
Ermittlung der CIs aus dem Configuration Management System (CMS)
Bemerkung
Hierfür sollte eine Drill-Down Funktion existieren, um die CIs aufgliedern zu können (zum Beispiel CIs, die zu einem IT Service gehören, Applikationen, etc.)
Name der Kennzahl
Anzahl abweichender CIs
Definition
Anzahl der festgestellten Abweichungen an CIs zwischen dem CMS und dem tatsächlichen Bestand.
Relevanz
Die Informationen des CMS dienen unterschiedlichen Prozessen und Aktivitäten als Planungsgrundlage. Fehlerhafte Informationen haben eine negative Auswirkung auf die Qualität des
195
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen IT Service. In Verbindung mit Compliance-Anforderungen, wie zum Beispiel SOX oder Versicherungsbestimmungen, können geschäftliche Schäden bzw. Kosten entstehen. Messwert
CI-Abweichungen zwischen Soll- und Ist-Bestand sind im CMS beim betroffenen CI zu dokumentieren. Ausgewertet werden die Ergebnisse dieser Audits.
Bemerkung
Eine Gruppierung der CIs nach IT Services oder relevante Compliance-Anforderungen ist zweckmäßig.
Name der Kennzahl
Anteil nicht genutzter Lizenzen
Definition
Anteil der erworbenen und nicht genutzten Software-Lizenzen.
Relevanz
Nicht genutzte Software-Lizenzen führen zu unnötigen Kosten für die IT und die IT Services.
Messwert
Abgleich zwischen den erworbenen und in Nutzung befindlichen Software-Lizenzen. Hierzu müssen die CIs mit einem entsprechenden Status „in Nutzung“ und Codierung für „Software“ ausgewiesen werden.
Bemerkung
Diese Kennzahl kann auch genutzt werden, um eine Unterlizenzierung darzustellen.
Name der Kennzahl
Zunahme an und Wert der CIs
Definition
Zunahme der CIs und finanzieller Wert der CIs.
Relevanz
Zeigt das Wachstum innerhalb der IT auf.
Messwert
Auswertung des Configuration Management Systems.
Bemerkung
Hierfür sollte eine Drill-Down Funktion existieren, um die CIs aufgliedern zu können (ITZuordnung zum Service oder CI-Typen, wie Applikationen etc.).
196
5.3 Prozess-Kennzahlen Name der Kennzahl
Auswirkungen fehlerhafter CIs
Definition
Anzahl der fehlerhaften Changes, deren Ursachen auf fehlerhafte CIs und CI-Informationen zurückzuführen sind.
Relevanz
Das CMS liefert eine wichtige Informationsbasis für die Analyse der Auswirkungen von Changes. Fehlerhafte Informationen können zu Ausfällen von IT Services und für das Business führen, wenn hierdurch Changes fehlerhaft sind.
Messwert
Zur Generierung dieser Kennzahl sind die Ergebnisse der Reviews im Change Management auszuwerten.
Bemerkung
In der Literatur wird als Kennzahl auch „Incidents oder Probleme aufgrund fehlerhafter CIs“ beschrieben. Hier ist kritisch zu prüfen, ob eine eindeutige und verlässliche Unterscheidung im operativen Betrieb möglich ist.
Name der Kennzahl
Zeitspanne Korrektur fehlerhafter CIs
Definition
Zeitspanne zwischen der Feststellung eines fehlerhaften CIs und dessen Korrektur.
Relevanz
Diese Zeitspanne ist ein Indiz für die Effizienz des Configuration Managements.
Messwert
Hierzu sind die Audits zum jeweiligen CI auszuwerten. Mittels Codierung sind festgestellte Abweichungen und deren Korrektur zu dokumentieren.
5.3.3.4 Release and Deployment Management Der Prozess ist verantwortlich für das Release und Deployment Management. Dabei ist das Release Management für die Planung, Terminplanung und Steuerung der Überführung von Releases in die Test- und Live-Umgebung verantwortlich Das primäre Ziel des Release Managements besteht im Schutz der Live-Umgebung und der Herausgabe der richtigen Komponenten. Das Deployment Management ist verantwortlich für die Überführung von neuer oder geänderter Hardware, Software, Dokumentation, Prozesse usw. in die Live-Umgebung.
197
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl
Anzahl durchgeführter Releases
Definition
Anzahl der durchgeführten Releases pro IT Service.
Relevanz
Die Anzahl der CIs dient für weitere Betrachtungen als Referenzwert.
Messwert
Ermittlung der durchgeführten Releases aus der Release-DB.
Bemerkung
Hierfür sollte eine Drill-Down Funktion existieren, um die Releases aufgliedern zu können (zum Beispiel in Major Release, Minor Release und Emergency fix Release).
Name der Kennzahl
Anzahl Incidents aufgrund von Releases
Definition
Anzahl der Incidents, die aufgrund durchgeführter Releases auftreten.
Relevanz
Treten nach einem Release Incidents auf, so führt dies zu Geschäftsbeeinträchtigungen und einer Kundenunzufriedenheit. Außerdem treten mit der notwendigen Behebung Zusatzkosten für die IT-Organisation auf.
Messwert
Auswertung der Incidents im Betrachtungszeitraum, die auf einen Release referenzieren.
Bemerkung
Hier sollte eine Drill-Down Funktion auf betroffene IT Services bestehen. Kann das Incident Management die notwendigen Informationen und Datenqualität nicht sicherstellen, so sind statt der Incidents die Problems auszuwerten.
Name der Kennzahl
Kundenzufriedenheit durchgeführter Releases
Definition
Kundenzufriedenheit mit der Durchführung von Releases.
Relevanz
Die Kennzahl ist ein Maß für die subjektive Einschätzung des Kunden.
Messwert
Abfrage in der Kundenzufriedenheitsumfrage
198
5.3 Prozess-Kennzahlen Name der Kennzahl
Fehlerhafte CMS
Definition
Anzahl der durch das Release Management verursachten Abweichungen zwischen dem CMS und dem Ist-Bestand.
Relevanz
Mittels Releases durchgeführte Veränderungen sind im CMS zu dokumentieren. Diese Kennzahl dient der Messung, ob die notwendigen Daten dem Configuration Management zur Verfügung gestellt werden.
Messwert
Auswertung der CIs hinsichtlich festgestellter Abweichung und der Ursache „Release Management“
Bemerkung
Hierzu sind nicht nur festgestellte Abweichungen im Audit zum CI zu dokumentieren, sondern auch der Verursacher.
Name der Kennzahl
Vollständigkeit DML
Definition
Anzahl der fehlenden Medien im Bestand der Definitive Media Library (DML).
Relevanz
Sobald eine neue Software produktiv gesetzt wird, sind die Medien in die DML aufzunehmen und das CMS zu aktualisieren.
Messwert
Ermittlung auf Basis durchgeführter Verifikationen und Audits.
5.3.3.5 Evaluation Der Prozess ist verantwortlich für die Beurteilung neuer oder geänderter IT Services, um sicherzustellen, dass die Risiken gemanagt werden und hilft so bei der Festlegung, ob der Change fortgesetzt wird. Der Prozess wird ebenfalls genutzt, um zu beurteilen, ob die tatsächlichen Ergebnisse den angestrebten Ergebnissen entsprechen oder zum Vergleich einer Alternative mit einer anderen. Name der Kennzahl
Anzahl Abweichungen in der Service Performance
Definition
Anzahl der festgestellten Abweichungen zwischen der bereitgestellten und der benötigten Service Performance.
199
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Relevanz
Zur Unterstützung der Geschäftsprozesse muss der Service die benötigte Performance sicherstellen. Eine unzureichende Performance kann zu Geschäftsausfällen führen.
Messwert
Auswertung der Testergebnisse.
Name der Kennzahl
Anzahl Incidents zum Service
Definition
Anzahl der zum Service gemeldeten Incidents
Relevanz
Eine höhere Anzahl führt zur Einschränkung des Geschäftsbetriebs und Kundenunzufriedenheit.
Messwert
Auswertung der Incident Records, die zu einem Service erfasst sind. Zusätzlich sind die Termine für durchgeführte Deployments darzustellen.
Bemerkung
Hierzu muss eine Zuordnung des Incident Records zum Service möglich sein. Eine Drill-Down Funktion sollte die dazugehörigen Kategorien der Incidents aufzeigen.
Name der Kennzahl
Durchlaufzeit Auswertung
Definition
Durchlaufzeit, um die Auswertung der Tests durchzuführen.
Relevanz
Eine geringe Durchlaufzeit bzw. deren Reduzierung ist ein Zeichen für die verbesserte Effizienz.
Messwert
Auswertung der im Textbericht protokollierten Zeiten.
5.3.3.6 Knowledge Management Der Prozess ist dafür verantwortlich das Wissen und die Informationen innerhalb einer Organisation zu sammeln, zu analysieren, zu speichern und gemeinsam zu nutzen. Der Hauptzweck des Knowledge Managements ist es, durch das Reduzieren der Notwendigkeit das Wissen wieder zu entdecken, die Effizienz zu verbessern.
200
5.3 Prozess-Kennzahlen Name der Kennzahl
Anzahl Incident „fehlendes Anwender-Wissen“
Definition
Anzahl der Incidents mit der Kategorisierung „fehlendes Anwender-Wissen“.
Relevanz
Das fehlende Anwender-Wissen führt nicht nur zu Geschäftsausfällen, sondern auch zu Zusatzressourcen und Kosten innerhalb der ITOrganisation.
Messwert
Auswertung der Incident Records mit der Kategorie „fehlendes Anwender-Wissen“.
Bemerkung
Hierzu können auch die damit verbunden Bearbeitungszeiten und resultierenden Kosten dargestellt werden.
Name der Kennzahl
Durchschnittliche Diagnosezeit
Definition
Durchschnittliche Diagnose- und Behebungszeit für die Lösung von Fehlern.
Relevanz
Eine schnelle Diagnose- und Behebungszeit ist ein Indiz für ein gutes Service Knowledge Management System (SKMS).
Messwert
Auswertung der Diagnosezeiten der Incident Records.
Name der Kennzahl
Zugriffe SKMS
Definition
Anzahl der Zugriffe auf das SKMS.
Relevanz
Die Nutzung des SKMS führt in der Regel nicht nur zu schnelleren Lösungen, sondern sichert auch ein konsistentes Vorgehen.
Messwert
Auswertung der Zugriffe aus dem SKMS.
Bemerkung
In Verbindung mit der Anzahl der Incidents kann festgestellt werden, in wie vielen Fällen (Anteil in Prozent) nach einer Lösung im SKMS gesucht wurde.
Name der Kennzahl
Nutzungsgrad SKMS
Definition
Nutzungsgrad des SKMS zur Behebung von Incidents.
201
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Relevanz
Die Nutzung des SKMS führt in der Regel nicht nur zu schnelleren Lösungen, sondern sichert auch ein konsistentes Vorgehen.
Messwert
Auswertung der Incident Records, die mit Known Errors oder Workarounds verknüpft sind.
Bemerkung
In Verbindung mit den Zugriffen auf das SKMS kann festgestellt werden, in wie vielen Fällen eine Lösung in dem SKMS gefunden werden konnte.
Name der Kennzahl
Anwenderzufriedenheit SKMS
Definition
Anwenderzufriedenheit mit den zur Verfügung gestellten Informationen, wie zum Beispiel Newsletter, Einweisungen, Web-Informationen, etc.
Relevanz
Gute Informationen des Anwenders führen zu einer besseren Nutzung des Service und reduzieren Support-Kosten.
Messwert
Erhebung und Auswertung im Rahmen einer Anwenderzufriedenheitsbefragung.
5.3.4
Service Operation
5.3.4.1 Event Management Der Prozess ist verantwortlich für das Management von Events während des gesamten Lifecycle. Das Event Management ist eine der Hauptaktivitäten von IT Operation. Bisher wurden in ITIL und der ISO 20000 die Events im Incident Management aufgenommen und als Incidents gespeichert. Bis eine Erweiterung der bestehenden Prozesse durch die Tool-Hersteller auf ITIL V 3 erfolgt, sind die im Folgenden beschriebenen Events aus der Incident-DB anhand einer Codierung zu ermitteln. Name der Kennzahl
Anzahl der Events
Definition
Anzahl der Events im Betrachtungszeitraum.
Relevanz
Die Anzahl der Events dient für weitere Betrachtungen als Referenzwert. Sie kann zusam-
202
5.3 Prozess-Kennzahlen men mit einer Trend-Darstellung auch als Indiz für die Qualität des Events Managements genutzt werden. Messwert
Ermittlung der Records aus der Event-DB.
Bemerkung
Hierfür sollte eine Drill-Down Funktion existieren, um die betroffenen Cis (Applikationen, Plattformen, etc.) darstellen zu können.
Name der Kennzahl
Anteil der Events
Definition
Prozentualer Anteil und Anzahl der Events pro Art (Incident, Problem, Change) im Betrachtungszeitraum.
Relevanz
Die Anzahl der Events dient für weitere Betrachtungen als Referenzwert. Sie kann zusammen mit einer Trend-Darstellung auch als Indiz für die Qualität des Events Managements genutzt werden. Eine steigende Anzahl zeigt, dass die Ereignisse besser erkannt werden, bevor sie sich zum Beispiel als Störung beim Anwender äußern.
Messwert
Ermittlung der Records aus der Event-DB.
Bemerkung
Hierfür sollte ein Drill-Down möglich sein um die betroffenen Cis (Applikationen, Plattformen, etc.) darstellen zu können.
Name der Kennzahl
Events zu Incidents (Problems)
Definition
Prozentualer Anteil der per Events erkannten Incidents (Problems) zu den von Anwendern gemeldeten Incidents (Problems).
Relevanz
Ein hoher Anteil der Events zeigt, dass die Ereignisse vom System erkannt werden, bevor sie sich zum Beispiel als Störung beim Anwender äußern. Dies führt zu einer höheren Verfügbarkeit und größeren Kundenzufriedenheit.
Messwert
Ermittlung der Records aus der Event-DB und Incident-DB bzw. Problem-DB.
203
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl
Events pro Signifikanz
Definition
Anzahl und Anteil der Events pro Signifikanz.
Relevanz
Zielsetzung für das Event Management ist die Erkennung von signifikanten Incidents oder Problemen. Diese Kennzahl zeigt an, ob dieses Ziel erreicht wird.
Messwert
Ermittlung der Records aus der Event-DB und Incident-DB bzw. Problem-DB.
Name der Kennzahl
Events mit Verfügbarkeits-Belangen
Definition
Anzahl und Anteil der Events mit möglichen Belangen für die Verfügbarkeit.
Relevanz
Die Verfügbarkeit ist einer der wichtigsten Service Level. Eine Nicht-Verfügbarkeit wirkt sich unmittelbar auf die Geschäftsprozesse aus. Diese Kennzahl zeigt an, wie gut diese Incidents / Probleme erkannt werden.
Messwert
Ermittlung der Records aus der Event-DB und Incident-DB bzw. Problem-DB.
5.3.4.2 Incident Management Der Prozess ist verantwortlich für das Management der Incidents während des Lifecycle. Das primäre Ziel ist es, den IT Service für den Anwender so schnell wie möglich wieder herzustellen. Mit der Herausgabe von ITIL Version 3 werden Service Requests in einem gesonderten Prozess behandelt. Daher ist hier keine Filterung der erfassten Vorgänge notwendig. Innerhalb von ITIL Version 2 und der ISO 20000 werden im Incident Management Störungen und Service Requests behandelt. Für Auswertungszwecke ist hier eine Eingrenzung der erfassten Vorgänge auf Störungen notwendig. Name der Kennzahl
Anzahl der Incidents
Definition
Anzahl der Incidents im Betrachtungszeitraum.
Relevanz
Die Anzahl der Incidents dient für weitere Betrachtungen als Referenzwert. Sie kann zusammen mit einer Trend-Darstellung auch als Indiz für die Qualität des Problem Managements genutzt werden. Eine steigende Anzahl wirkt
204
5.3 Prozess-Kennzahlen sich darüber hinaus auf die Kundenzufriedenheit aus. Bei einer steigenden Anzahl führt deren Behebung zu steigenden Prozess- und ITKosten. Messwert
Ermittlung der Incident Records aus der Incident-DB.
Bemerkung
Die Gesamtanzahl ist allein wenig aussagekräftig. Die Anzahl der Incidents ist aufzugliedern in die betroffenen IT Services und pro Priorität darzustellen. Hier ist eine Drill-Down Funktion zur weiteren Analyse unbedingt notwendig.
Name der Kennzahl
Anzahl und Anteil der Major Incidents
Definition
Anzahl und Anteil der Major Incidents im Betrachtungszeitraum.
Relevanz
Major Incident führen i. d. R. zu größeren Ausfällen des IT Service und so der relevanten Geschäftsprozesse.
Messwert
Ermittlung der Incident Records anhand der Codierung aus der Incident-DB.
Name der Kennzahl
Erstlösungsquote
Definition
Die Erstlösungsquote definiert, wie viel Prozent der eingehenden Incidents im Erstkontakt zwischen den Anwendern und dem Service Desk gelöst werden konnten.
Relevanz
Eine gute Erstlösungsquote steigert die Anwenderzufriedenheit und reduziert die Ausfallzeit für das Business. Zusätzlich trägt eine gute Erstlösungsquote dazu bei, dass der 2nd Level Support entlastet wird. In der Regel führt dies auch zu einer Reduzierung der Kosten für die Behebung von Incidents.
Messwert
Ausgewertet werden alle Incidents, die mittels Telefon beim Service Desk eingegangen sind. Als Erstlösungsquote wird der Prozentwert dieser Incidents dargestellt, bei denen die Mitar-
205
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen beiter im Service Desk den Incident direkt lösen konnten und der Incident nicht weitergeleitet wurde. Bemerkung
Die Erstlösungsquote kann auch als Service Level in SLAs vereinbart werden. Dann ist die Erstlösungsquote in Bezug auf den jeweiligen IT Service darzustellen. Diese Kennzahl kann auch für die Bewertung des Service Desk herangezogen werden.
Name der Kennzahl
Durchschnittliche Reaktionszeit
Definition
Die Reaktionszeit bestimmt die Dauer zwischen der Weiterleitung vom Service Desk und der Aufnahme der Tätigkeit in der zugewiesenen Support-Einheit.
Relevanz
Hohe Reaktionszeiten können auf eine zu hohe Arbeitslast für die betroffene Support-Einheit hinweisen.
Messwert
Aus den Incident Records wird die Zeitdauer zwischen der Weiterleitung vom Service Desk und der Beginn der Bearbeitung in der zugewiesenen Support-Einheit ermittelt.
Bemerkung
Hier ist zu definieren, was unter Reaktion bzw. Reaktionszeit zu verstehen ist. Man könnte den Begriff „Reaktion“ z. B. als „Kontaktaufnahme mit dem Anwender“ definieren.
Name der Kennzahl
Einhaltung Reaktionszeit
Definition
Anteil der Incidents, die in Abhängigkeit der Priorität innerhalb der vereinbarten Reaktionszeit bearbeitet wurden.
Relevanz
Die Bedeutung ist abhängig von den vereinbarten Service Level. Ist die Reaktionszeit als Service Level vereinbart, so ist deren Einhaltung wichtig für die Kundenzufriedenheit. Innerhalb der IT ist die Reaktionszeit ein wichtiges Maß für die Bearbeitung von weitergeleiteten Störungen. Hohe Reaktionszeiten können auf eine zu hohe Arbeitslast für die betroffene
206
5.3 Prozess-Kennzahlen Support-Einheit hinweisen. Messwert
Mit der Festlegung der Priorität zu einem Incident wird die vereinbarte Reaktionszeit ermittelt. Die Kennzahl wird durch Auswertung der Incident Records und dem Vergleich zwischen der geplanten Reaktionszeit und der tatsächlichen Reaktionszeit ermittelt.
Bemerkung
Die Reaktionszeit kann auch als Service Level in SLAs, OLAs oder UCs vereinbart werden. Dann ist die Reaktionszeit in Bezug auf den jeweiligen IT Service zu berechnen.
Name der Kennzahl
Lösungszeit
Definition
Die Lösungszeit ist die Dauer zwischen der Aufnahme des Incidents und dessen Abschluss.
Relevanz
Die durchschnittlichen Lösungszeiten in Abhängigkeit von IT Service und Priorität (SLA) müssen den vereinbarten Service Level entsprechen.
Messwert
Mit der Zuweisung der Priorität liegt für den Incident Record die vereinbarte Lösungszeit vor. Anhand der dokumentierten Lösungszeit wird die tatsächliche Lösungszeit ermittelt.
Bemerkung
Siehe auch „Einhaltung Lösungszeit“.
Name der Kennzahl
Einhaltung Lösungszeit
Definition
Anteil der Incidents, die in Abhängigkeit der Priorität innerhalb der vereinbarten Lösungszeit behoben wurden.
Relevanz
Die Einhaltung der Lösungszeiten ist eine wichtige Kennzahl für die Effektivität des Prozesses. Durch deren Einhaltung wird die Anwenderund Kundenzufriedenheit beeinflusst.
Messwert
Mit der Zuweisung der Priorität liegt für den Incident Record die vereinbarte Lösungszeit vor. Anhand der dokumentierten Lösungszeit wird ermittelt, in welchem Maß (Prozent) diese Zeit eingehalten wurde.
Bemerkung
Die Lösungszeit kann auch als Service Level in
207
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen SLAs, OLAs oder UCs vereinbart werden. Dann ist die Lösungszeit in Bezug auf den jeweiligen IT Service zu berechnen. Entscheidend für die Lösung ist, dass der Anwender wieder arbeiten kann. Es ist mit dem Kunden festzulegen, wann ein Incident als abgeschlossen gewertet werden kann. Name der Kennzahl
Anteil Remote-Lösungen
Definition
Anteil der bearbeiteten Störungen, die Remote - das heißt ohne Vor-Ort-Service - gelöst werden konnten.
Relevanz
Der Vor-Ort-Service ist gegenüber einer Remote Lösung mit mehr Aufwand (Arbeitszeit und Kosten) verbunden. Hinzu kommt, dass die Lösungszeiten dadurch höher sind. Diese Kennzahl ist ein Indikator für die Effizienz des Prozesses.
Messwert
Ausgewertet wird der Anteil der Incidents, bei denen keine „Vor-Ort Support-Einheit“ in die Behebung eingebunden waren.
Name der Kennzahl
Kosten Incidents
Definition
Die Kennzahl weist die Kosten für die Aufnahme und Behebung von Incidents aus.
Relevanz
Eine Reduzierung der Kosten ist ein Nachweis für eine Steigerung der Effizienz.
Messwert
Die durchgeführten Aktivitäten sind hinsichtlich ihrer Aufwendungen (Material, Arbeitszeit, etc.) zu dokumentieren. Ausgewertet werden die damit verbunden Kosten.
Bemerkung
Die Aufwendungen sind häufig abhängig von den betroffenen IT Services, CIs und Kategorie. Eine Drill-Down-Funktion ist hierfür notwendig.
Name der Kennzahl
Anteil fehlerhaft zugewiesener Incidents
Definition
Die Kennzahl weist die Kosten für die Auf-
208
5.3 Prozess-Kennzahlen nahme und Behebung von Incidents aus. Relevanz
Werden Incidents einer fehlerhaften SupportGruppe zugewiesen, so entstehen zusätzliche Bearbeitungskosten (Effizienz) und die Bearbeitungszeit verlängert sich (Effektivität).
Messwert
Hierzu muss im Incident Record bei einer Weiterleitung deren Grund eingepflegt werden.
Bemerkung
Diese Kennzahl kann auch als Kennzahl für den Service Desk herangezogen werden.
Name der Kennzahl
Anteil fehlerhafter Incident Kategorien
Definition
Die Kennzahl weist den Anteil der bei der Aufnahme eines Incidents fehlerhaft zugewiesener Kategorien aus.
Relevanz
Die Kategorisierung unterstützt die Suche von Known Errors, Workarounds sowie die Weiterleitung von Incidents. Fehlerhafte Kategorien wirken sich negativ auf die Effizienz und Effektivität aus.
Messwert
Hierzu wird im Incident Record geprüft, ob beim Abschluss gegenüber der Eröffnung eine andere Kategorie zugewiesen wurde.
Bemerkung
Diese Kennzahl kann auch als Kennzahl für den Service Desk herangezogen werden.
Name der Kennzahl
Anteil wiedereröffneter Incidents
Definition
Die Kennzahl weißt den Anteil der Incidents aus, bei denen die aufgetretene Störung wieder auftritt.
Relevanz
Die Kennzahl zeigt an, ob Incidents fehlerhaft als gelöst abgeschlossen wurden.
Messwert
Hierzu muss im Incident Record eine „Reopen“ Aktivität dokumentiert werden. Die Anzahl der Incidents mit dieser Aktivität wird ausgewertet.
Bemerkung
Häufig werden Incidents nicht wiedereröffnet, sondern als neue Incidents aufgenommen.
209
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen
5.3.4.3 R eq u est F u lfilment Der Prozess ist für das Management des Lifecycle sämtlicher Service Requests verantwortlich. Bisher wurden in ITIL und der ISO 20000 die Service Requests im Incident Management aufgenommen. Daher werden die Service Requests bei vielen IT-Organisationen in der Incident-DB gespeichert. Statt der im Folgenden beschriebenen Request-DB sind in diesen Fällen die Service Requests aus der Incident-DB anhand einer Codierung zu ermitteln. Name der Kennzahl
Anzahl Service Requests
Definition
Anzahl der Service Requests im Betrachtungszeitraum.
Relevanz
Die Anzahl der Service Requests dient für weitere Betrachtungen als Referenzwert.
Messwert
Ermittlung der Service Requests Records aus der Request-DB.
Name der Kennzahl
Bearbeitungszeit Service Requests
Definition
Darstellung der mittleren Bearbeitungszeit "Service Requests" und Art der "Service Requests" (z. B. Passwort-Reset, Umzug etc.).
Relevanz
Die Kennzahl zeigt die Zeitdauer für den Workflow und ist Basis für die Berechnung möglicher Service Level.
Messwert
Ermittlung der Service Requests Records aus der Request-DB.
Name der Kennzahl
Einhaltung der Service Request-Zeiten
Definition
Anteil der Service Requests, die in Abhängigkeit von der Art innerhalb der vereinbarten Bearbeitungszeit abgeschlossen wurden.
Relevanz
Die Einhaltung der vereinbarten Service Request-Zeiten ist eine wichtige Kennzahl für die Effektivität des Prozesses. Durch deren Einhaltung wird die Anwender- und Kundenzufriedenheit beeinflusst.
210
5.3 Prozess-Kennzahlen Messwert
Dem Service Request muss ein Workflow mit einer geplanten Bearbeitungszeit hinterlegt sein. Auf dieser Basis kann die Einhaltung überwacht werden.
Bemerkung
Diese Kennzahl kann als Service Level in Service-Berichte einfließen. Bei einem Aufbruch in die einzelnen Aktivitäten und der Planwerte können die Werte auch für die Bewertung von OLAs und UCs herangezogen werden.
Name der Kennzahl
Service Request-Kosten
Definition
Kosten für die Durchführung für die verschiedenen Arten von Service Requests (zum Beispiel Passwort-Reset, Umzug, etc.).
Relevanz
Die Kosten werden für die Kalkulation des Service benötigt. Darüber hinaus zeigt die Kennzahl als Trenddarstellung die Effizienz auf.
Messwert
Zur Ermittlung müssen zu den einzelnen Aktivitäten die benötigten Arbeitsstunden erfasst werden.
Name der Kennzahl
Kundenzufriedenheit Service Request
Definition
Grad der Kundenzufriedenheit mit der Durchführung von Service Requests.
Relevanz
Die Kennzahl zeigt die Ausrichtung des Prozesses auf die Geschäftsanforderungen auf.
Messwert
Abfrage in der Kundenzufriedenheitsumfrage
Bemerkung
Hier ist zusätzlich auch eine Befragung der Anwender möglich.
211
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen
5.3.4.4 Problem Management Der Prozess ist für das Management des Lifecycle sämtlicher Probleme verantwortlich. Das primäre Ziel des Problem Managements besteht in der Verhinderung von Incidents und der Reduzierung der Auswirkung von Incidents, die nicht verhindert werden können. Die Relevanz von Problemen hinsichtlich der SLAs ist kritisch zu prüfen und zu hinterfragen. Wenn der Kunden nicht die Terminologie von ITIL nutzt, so ist häufig mit „Problemen“ eigentlich „Incidents“ mit deren Service Level gemeint. Name der Kennzahl
Anzahl der Probleme
Definition
Anzahl der Probleme im Betrachtungszeitraum.
Relevanz
Die Anzahl der Probleme dient für weitere Betrachtungen als Referenzwert.
Messwert
Ermittlung der Problem-Records aus der Problem-DB.
Bemerkung
Die Gesamtanzahl ist wenig aussagekräftig. Hier sollte eine Drill-Down Funktion auf betroffene IT Services, CIs, etc. möglich sein.
Name der Kennzahl
Anzahl offener Probleme
Definition
Anzahl der Probleme, die noch nicht gelöst wurden.
Relevanz
Die Kennzahl zeigt, wie viele Probleme zurzeit vom Problem Management zu bearbeiten sind bzw. die mittels eines Change zu implementieren sind.
Messwert
Auswertung der Probleme, die noch nicht abgeschlossen sind
Bemerkung
Die Gesamtzahl ist wenig aussagekräftig. Hier sollte die Gesamtzahl aufgebrochen werden in „Problemursache unbekannt“, „Known Error“, „RFC gestellt“
212
5.3 Prozess-Kennzahlen Name der Kennzahl
Durchschnittliche Problem-Lösungszeit
Definition
Durchschnittliche Zeitdauer für die Lösung von Problemen im Betrachtungszeitraum.
Relevanz
Eine lange Lösungsdauer kann dazu führen, dass innerhalb dieser Zeit weiterhin Incidents auftreten und so zu Aufwendungen (Kosten) im Support führen. Außerdem wird die Kundenzufriedenheit beeinträchtigt, wenn Incidents weiterhin auftreten oder nur unzureichende Workarounds existieren.
Messwert
Ermittlung der durchschnittlichen Zeitdauer zwischen der Eröffnung eines Problems und dessen Abschluss, das heißt, bis ein Change erfolgreich durchgeführt wurde.
Bemerkung
Zeitdauer über alle Services, CIs ist wenig aussagekräftig. Hier sollte ein Drill-Down auf betroffene IT Services, CIs, etc. möglich sein.
Name der Kennzahl
RFCs aufgrund von Problemen
Definition
Anzahl der vom Problem Management initiierten RFCs.
Relevanz
Eine hohe Anzahl vom Problem Management eingereichter RFCs kann ein Indiz für die Effektivität des Problem Managements sein.
Messwert
Auswertung der RFCs im Betrachtungszeitraum mit einer Verknüpfung zu Problemen.
Name der Kennzahl
Nutzungsgrad Known Errors
Definition
Anteil der Incidents, die mithilfe der Known Errors gelöst wurden.
Relevanz
Das Problem Management erstellt und pflegt die Known Errors. Mit deren Hilfe sollen Incidents besser und schneller behoben werden. Ein hoher Nutzungsgrad zeigt, dass das Incident Management diese Informationen verwenden kann.
Messwert
Auswertung der Incidents hinsichtlich einer Verknüpfung mit Known Errors.
213
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen
5.3.4.5 Access Management Der Prozess ist dafür verantwortlich, es den Anwendern zu ermöglichen, IT Services, Daten oder andere Assets zu benutzen. Das Access Management hilft, die Vertraulichkeit, Integrität und Verfügbarkeit von Assets dadurch zu schützen, dass nur autorisierte Anwender in der Lage sind, auf die Assets zuzugreifen oder diese zu modifizieren. Das Access Management wird teilweise als Rechteverwaltung oder Identity Management bezeichnet. Bisher wurden in ITIL und der ISO 20000 die Service Requests im Incident Management aufgenommen. Daher werden die Service Requests bei vielen IT-Organisationen innerhalb der Incident-DB gespeichert. Statt der im Folgenden beschriebenen „Access-DB“ sind in diesen Fällen die Service Requests mit dem Typ „Zugriffsrechte“ aus der Incident-DB anhand einer Codierung zu ermitteln. Name der Kennzahl
Anzahl der Zugriffs-Anforderungen
Definition
Anzahl der Anforderungen auf Zugriffsberechtigungen im Betrachtungszeitraum.
Relevanz
Die Anzahl der Anforderungen dient für weitere Betrachtungen als Referenzwert.
Messwert
Ermittlung der Access-Records aus der AccessDB.
Bemerkung
Die Gesamtanzahl ist wenig aussagekräftig. Hier sollte eine Drill-Down Funktion auf betroffene IT Services, Abteilungen, etc. möglich sein.
Name der Kennzahl
Incidents aufgrund fehlerhafter Zugriffsrechte
Definition
Anzahl der Incidents aufgrund fehlerhaft vergebener Zugriffsrechte.
Relevanz
Die Anzahl der auftretenden Incidents ist ein Maß für die Effektivität des Prozesses.
Messwert
Ermittlung der Incident-Records mit Kategorie „Zugriffsrechte“
Name der Kennzahl
Anzahl Bearbeitungsinstanzen
Definition
Anzahl Bearbeitungsinstanzen für die Generierung der Zugriffsrechte.
214
5.3 Prozess-Kennzahlen Relevanz
Die Anzahl der Bearbeitungsinstanzen ist ein Maß für die Effizienz des Prozesses.
Messwert
Ermittlung der Access-Records aus der AccessDB und der beteiligten Bearbeiter von der Aufnahme bis zum Abschluss.
Name der Kennzahl
Kosten für Zugriffsberechtigungen
Definition
Kosten für die Generierungen der Zugriffsberechtigungen.
Relevanz
Die Kosten für die Generierungen der Zugriffsberechtigungen sind ein Maß für die Effizienz des Prozesses und sind unter anderem bei der Kalkulation der SLAs zu berücksichtigen.
Messwert
Ermittlung der Arbeitsstunden pro Access-Records aus der Access-DB.
Bemerkung
Die Gesamtkosten sind wenig aussagekräftig. Hier ist eine Unterscheidung zwischen den IT Services notwendig.
5.3.4.6 Service Desk Der Service Desk dient als Single Point of Contact (SPOC) zwischen dem IT Service Provider und den Anwendern. Ein typischer Service Desk verwaltet die Incident und Service Requests und wickelt auch die Kommunikation mit den Anwendern ab. Der Service Desk beschreibt die funktionalen Anforderungen an eine Organisation und ist kein Service Management-Prozess. Der Service Desk ist in verschiedene Prozesse eingebunden, mit dem Schwerpunkt in den Prozessen Incident Management und Request Fulfilment. In diesem Kapitel werden die Kennzahlen ausgewiesen, die nicht zu den bereits ausgewiesenen Prozess-Kennzahlen, wie zum Beispiel der Erstlösungsquote, gehören. Name der Kennzahl
Anzahl Lost-Calls
Definition
Anzahl der Lost-Calls (verlorene Anrufe) im Betrachtungszeitraum.
Relevanz
Die Lost-Calls definieren die Anrufer, die aufgrund eines zu langen Wartezeitraums den Anruf beenden, ohne mit einem Mitarbeiter des Service Desk gesprochen zu haben. Diese Kenn-
215
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen zahl ist ein wichtiges Maß für die Anwenderund Kundenzufriedenheit. Messwert
Die Lost-Calls sind der Telefonanlage (ACD) zu entnehmen.
Bemerkung
Diese Kennzahl kann Bestandteil eines SLAs sein.
Name der Kennzahl
Dauer Telefonannahme
Definition
Durchschnittliche Dauer, bis ein Telefonanruf entgegengenommen wird.
Relevanz
Die durchschnittliche Dauer, bis ein Telefonanruf entgegengenommen wird, ist ein wichtiges Maß für die Anwender- und Kundenzufriedenheit.
Messwert
Die durchschnittliche Dauer, bis ein Telefonanruf entgegengenommen wird, ist der Telefonanlage (ACD) zu entnehmen.
Bemerkung
Diese Kennzahl kann Bestandteil eines SLAs sein.
Name der Kennzahl
Gesprächsdauer
Definition
Durchschnittliche Dauer pro Gespräch (Telefonkontakt) mit dem Anwender.
Relevanz
Das Ziel des Service Desk besteht in der Erreichbarkeit durch den Anwender. Zu lange Gespräche gefährden die Erreichbarkeit für andere Anwender. Daher kann eine maximale Gesprächsdauer festgelegt werden. Diese Kennzahl zeigt, ob diese Vorgabe erreicht wird.
Messwert
Die durchschnittliche Dauer, bis ein Telefonanruf entgegengenommen wird, ist der Telefonanlage (ACD) zu entnehmen.
Bemerkung
Diese Kennzahl kann Bestandteil eines OLAs sein.
216
5.3 Prozess-Kennzahlen
5.3.5
Continual Service Improvement
5.3.5.1 The 7 Step Improvement Process Für das Continual Service Improvement (CSI) ist das Konzept der Messung von grundlegender Bedeutung. Das CSI beschreibt hierzu den „7 Step Improvement Prozess“. Ausgehend von „Definition was sie wollen“ werden durchzuführende Aktivitäten bis zur „Implementierung korrigierende Aktionen” beschrieben. Name der Kennzahl
Anzahl Eingaben in SIP
Definition
Anzahl der identifizierten Maßnahmen zur Verbesserung der Services, als Eingabe in den Service Improvement Plan (SIP).
Relevanz
Identifizierte Verbesserungsmaßnahmen für die Services sind im SIP zu dokumentieren.
Messwert
Auswertung des SIP.
Name der Kennzahl
Anzahl Eingaben in PIP
Definition
Anzahl der identifizierten Maßnahmen zur Verbesserung der Prozesse, als Eingabe in den Prozess Improvement Plan (PIP).
Relevanz
Identifizierte Verbesserungsmaßnahmen für die Prozesse sind im PIP zu dokumentieren.
Messwert
Auswertung des PIP.
Name der Kennzahl
Anzahl identifizierter Probleme
Definition
Anzahl der im proaktiven Problem Management identifizierten Probleme.
Relevanz
Ein proaktives Problem Management steigert die Service-Qualität und reduziert die Aufwendungen für reaktive Maßnahmen.
Messwert
Auswertung der Problem-DB.
Bemerkung
In der ITIL Version 3 gehört das proaktive Problem Management nicht mehr zu den Aktivitäten des Problem Managements im Service Operation.
217
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen
5.3.5.2 Service Reporting Der Prozess ist für die Erstellung und Lieferung von Berichten über Leistung und Trends gegenüber den Service Level verantwortlich. Das Service Reporting sollte das Format, den Inhalt und die Häufigkeit von Berichten mit den Kunden vereinbaren. Name der Kennzahl
Kundenzufriedenheit Service Reporting
Definition
Ergebnis der Kundenzufriedenheit mit dem Service Reporting.
Relevanz
Das Service Reporting und die enthaltenen sowie dargestellten Informationen müssen den Geschäfts- bzw. Kundenanforderungen entsprechen.
Messwert
Abfrage in der Kundenzufriedenheitsumfrage
Name der Kennzahl
Termintreue für Service Reports
Definition
Einhaltung der vereinbarten Erstellungstermine für die Service Reports.
Relevanz
Service Reports stellen intern und extern eine wichtige Informationsquelle dar. Im externen Verhältnis sind die Berichtstermine zum Teil Bestandteil des SLAs. Daher sind die Berichte termingerecht zu veröffentlichen.
Messwert
Auswertung der Erstellungsdaten im Vergleich zu den definierten Terminen.
Name der Kennzahl
Anzahl fehlerhafter Service Reports
Definition
Anzahl der Service Reports, in denen fehlerhafte oder inkonsistente Informationen enthalten sind.
Relevanz
Fehlerhafte Service Reports führen zur Kundenunzufriedenheit.
Messwert
Auswertung von Prozess Reviews.
218
5.3 Prozess-Kennzahlen
5.3.5.3 Service Measurement Aufgabe des Service Measurement ist die Messung der IT Services. Hierzu betont ITIL, dass es nicht mehr genügt, die Leistung einer einzelnen Komponente, wie einen Server oder eine Applikation zu messen und zu berichten. Die IT muss in der Lage sein, end-to-end Service zu messen und zu berichten. Hierzu gibt es mit der Verfügbarkeit, Zuverlässigkeit und Performance drei Grundmessungen, von denen die meisten Organisationen Gebrauch machen. Name der Kennzahl
Anteil SLAs mit „end to end“ Messung
Definition
Anteil der SLAs, deren Service Level und die Erreichung der Service Level Ziele auf Basis einer „end to end“ Messung gemessen werden.
Relevanz
Eine „end to end“ Messung stellt die Sicht des Business auf den Service dar und ermöglicht eine Bewertung, in welchem Maße die Kunden den vereinbarten Service nutzen konnten.
Messwert
Bewertung der implementierten Messverfahren.
Bemerkung
Hierbei sind die damit verbundenen Kosten zu bewerten. Unter Umständen kann aus Kostengründen diese Messung lediglich für geschäftskritische Services angewandt werden.
5.3.5.4 Return on Investment (ROI) for CSI Im Rahmen des Return on Investments (ROI) für das Continual Service Improvement (CSI) sind die Kosten für die Durchführung dieser Phase des Service Lifecycle zu ermitteln und zu bewerten, welche geschäftlichen Vorteile durch das Continual Service Improvement erzielt werden. Name der Kennzahl
Kosten für das Continual Service Improvement
Definition
Kosten für die Durchführung des Continual Service Improvement
Relevanz
Hier werden die Kosten für das CSI dargestellt. Im Vergleich mit den Kennzahlen „erzielte Einsparungen (IT / Business)“ und „Mehrwert Business“ kann so der ROI bewertet werden.
Messwert
Vorrangig Betrachtung der Prozesskosten und Kosten für Tools
219
5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl
Erzielte Einsparungen (IT / Business)
Definition
Erzielte Einsparungen für die IT und / oder das Business
Relevanz
Primär geht es um die Einsparungen für das Business; aber auch Einsparungen innerhalb der IT kommen dem Business zugute.
Messwert
Informationen aus dem Financial Management
Name der Kennzahl
Mehrwert Business
Definition
Mehrwert der durchführten Verbesserungsmaßnahme für das Business
Relevanz
Wenn das Business einen Mehrwert hat, liegt die Rechtfertigung von Investitionen vor
Messwert
Bewertung durch das Business
5.3.5.5 The Business Questions for CSI Das Business muss in die Entscheidungsfindung im CSI eingebunden werden, um zu beurteilen, welche Verbesserungsmaßnahmen sinnvoll sind und dem Business den größten Nutzen bringen. Name der Kennzahl
Kundenzufriedenheit men
Definition
Ergebnis der Kundenzufriedenheit mit den identifizierten und umgesetzten Verbesserungsmaßnahmen.
Relevanz
Die Kennzahl identifiziert die Einbeziehung des Business in das Continual Service Improvement.
Messwert
Abfrage in der Kundenzufriedenheitsumfrage.
Verbesserungsmaßnah-
5.3.5.6 Service Level Management Die Kennzahlen zum Service Level Management sind zusammengefasst im Kapitel 5.3.2.2 (Prozess „Service Level Management“ innerhalb von Service Design) beschrieben. Speziell die Service Improvement Programme (SIP) und die damit verbundenen Kennzahlen betreffen die Maßnahmen innerhalb des Continual Service Improvements.
220
6 Lessons learned: Empfehlungen und Ratschläge 6.1 Management Summary Wir haben viele ITIL-Projekte durchgeführt, geleitet oder wenigstens begleitet. Die Einführung von ITIL in Unternehmen ist oft kein einfaches Projekt. Im Folgenden stellen wir unsere Erfahrungen dar und versuchen herauszustellen, was man tun sollte und woran man scheitern kann. Insbesondere möchten wir die Notwendigkeit vorbereitender Überlegungen und Maßnahmen verdeutlichen, mit denen eine erfolgreiche Adaption der ITIL Best Practices in IT-Organisationen abgesichert werden kann. Die wesentlichen Kernaussagen und Empfehlungen sind: – Die Nutzung der ITIL Best Practices für die Implementierung und Verbesserung des IT Service setzt voraus, dass Sie die unternehmensspezifischen IT Service Management-Prozesse definieren und designen. Hierzu kann ITIL einen wichtigen Beitrag leisten, darf dabei aber nicht zum Selbstzweck werden. Ziel ist es nicht, „ITIL zu implementieren“, sondern ITIL als Medium zu nutzen, um die IT Service Management-Prozesse zu etablieren und stetig zu verbessern. – Faktisch etabliert die Einführung von durchgängigen IT Service Management-Prozessen eine Matrixorganisation. Zu der bestehenden Linienorganisation existieren dann bereichsübergreifende IT Service Management-Prozesse mit entsprechenden Verantwortlichkeiten und Zielvorgaben unter Einbeziehung möglicher Supplier oder Lieferanten. Sie müssen sicherstellen, dass die organisatorische Verankerung dieser Prozesse erfolgt und die Akzeptanz der Prozesse und Prozessverantwortlichkeiten in allen Hierarchieebenen erreicht wird. – Die damit verbundenen Implementierungsaufgaben dürfen nicht unterschätzt werden. Ohne ein geeignetes Veränderungsmanagement werden die an das Projekt bzw. an die späteren Prozesse gerichteten Erwartungen nicht erfüllt. Ein fehlendes Veränderungsmanagement wird Zeitverschiebungen und Zusatzaufwendungen hervorrufen. Im schlimmsten Fall kann es zum Scheitern des gesamten Vorhabens führen.
221
6 Lessons learned: Empfehlungen und Ratschläge
6.2 ITIL-Einführung 6.2.1 Berücksichtigung bestehender Prozesse
Analyse der bestehenden Prozesse
Auf den ersten Blick mag es kurios erscheinen, aber jede – auch Ihre – ITOrganisation betreibt bereits IT Service Management-Prozesse. Zielsetzung und Aktivitäten dieser Prozesse entsprechen aber in der Regel nur zum Teil den ITIL Best Practices. Sie sollten daher zunächst Ihre bestehenden Prozesse analysieren und mit den ITIL Best Practices vergleichen. Damit stehen Sie aber in der Praxis vor dem Dilemma, etwas bewerten zu müssen, was Sie und Ihre Mitarbeiter ggf. noch nicht ausreichend kennen. Eine Lösungsmöglichkeit für Sie und die im Vorhaben involvierten Mitarbeiter besteht darin, sich kurzfristig ITIL-Know-how anzueignen. Hilfreich ist hier der Erwerb eines Foundation Certificate in IT Service Management und/oder das Studium der ITIL-Fachliteratur. Alternativ können Sie auf einen erfahrenen, zertifizierten Berater zurückgreifen. Berater bieten i. d. R. zusätzlich den Vorteil, nicht nur über das theoretische Grundwissen, sondern auch über Erfahrungen in vergleichbaren Projekten zu verfügen. Besonders wichtig bei diesem Ansatz: Sie müssen sicherstellen, dass der Berater nicht selbstständig – allein – die Maßnahmen durchführt. Die wesentliche Aufgabe des Beraters besteht vielmehr darin, Sie zu begleiten. Sie benötigen einen Coach, der den Wissenstransfer sicherstellt. Fungiert Ihr Berater nicht als Coach, so kann sowohl die Implementierungsanalyse, als auch die spätere Erweiterung und/oder Umsetzung schwierig werden. Ohne Akzeptanz des Beraters als Coach in Ihrer Organisation verlieren Sie Zeit und nutzen Ressourcen nicht optimal. Die Motivation zur Etablierung der Prozesse wird sinken.
Auf der Basis von ITIL sollten Sie analysieren und vergleichen, welche der dort beschriebenen IT Service Management-Prozesse und Aktivitäten bereits (zumindest vermeintlich) in Ihrer IT-Organisation etabliert sind. Dabei ist zunächst eine generische Betrachtung der Prozesse ausreichend. Als Hilfestellung hierbei bietet sich eine tabellarische Darstellung an: Tragen Sie als Zeilen (-überschriften) die IT Service Management-Prozesse ein, wie zum Beispiel Incident Management, Change Management, Service Level Management. Auf der vertikalen Achse erfolgt eine Einstufung der bestehenden Situation hinsichtlich Konzeption, Prozesse, Verfahren, Methoden und Nutzungsgrad. Diese ITIL-Prozesslandkarte ist eine erste, einfache Darstellung des bestehenden Reifegrades.
222
6.2 ITIL-Einführung Die ITIL-Prozesslandkarte soll aus der IT-Organisation heraus entwickelt werden, ggf. unter Beteiligung eines Coaches. Dadurch lernen Sie und Ihre Mitarbeiter die ITIL Best Practices erheblich besser kennen.
Für die Einstufung der Prozesse ist ausreichendes internes oder externes Know-how von großer Wichtigkeit. Speziell im Bereich des Incident und Problem Managements bedarf es einer entsprechenden Erfahrung, um eine Abgrenzung der Prozessaktivitäten vornehmen zu können. Sie müssen bei der Ist-Aufnahme unterstreichen, dass die Zielsetzung in der neutralen Aufnahme der bestehenden Prozesse besteht. Nur so ist eine echte Standortbestimmung möglich. Bei der Ist-Aufnahme ggf. festgestellte Fehler sowie Abweichungen von bestehenden Richtlinien, festgelegten Abläufen oder Standards dürfen keine negativen Auswirkungen auf die betroffenen Personen haben. Sie benötigen eine objektive Feststellung der IstSituation und keine geschönte Darstellung. Eröffnen Sie Ihren Mitarbeitern die Chance zur Offenheit und verzichten Sie auf Rügen für „Fehlverhalten“. Geben Sie ihren Mitarbeitern die notwendige Sicherheit für eine ungeschönte Darstellung der Ist-Situation. Liegt die ITIL-Prozesslandkarte vor, so sollten Sie spätestens jetzt eine Abstimmung mit einem externen Berater anstreben. Nur zusammen mit einem externen Berater können Sie die bestehende Situation wirklich bewerten und mit anderen IT-Organisationen vergleichen. Die Nutzung der ITIL Best Practices zur Optimierung der IT Service Management-Prozesse kann von verschiedenen Gruppen initiiert werden. Der Kreis der Betroffenen kann grob wie folgt gruppiert werden: – – – –
Top-Management, mittleres Management, Mitarbeiter, Kunde / Markt
Speziell wenn die Implementierung vom Top-Management ausgeht, werden häufig externe Berater frühzeitig mit den Durchführungsleistungen beauftragt. Die Gefahr bei diesem Szenario liegt in den auftretenden Akzeptanzproblemen: Das mittlere Management und die Mitarbeiter können das Gefühl entwickeln, die externen Berater – und damit ITIL – würden ihnen von oben „übergestülpt“. Folge hiervon sind die mangelnde Akzeptanz der geplanten Maßnahmen und die damit verbundene Verzögerung bei der Umsetzung. Konsequenz hieraus: Der eigenen Organisation muss die Chance gegeben werden, sich weiterzuentwickeln und ITIL zu adaptieren.
223
Initiierung der geplanten Maßnahmen
6 Lessons learned: Empfehlungen und Ratschläge Stellen Sie sicher, dass für das Management und die Mitarbeiter im Vorfeld eine Chance besteht, sich mit den ITIL Best Practices auseinander zu setzen. Damit können Sie einer Abwehrhaltung innerhalb Ihrer IT-Organisation erfolgreich begegnen.
Geht die Initiierung von der Mitarbeiterschaft aus, so muss zunächst das mittlere Management von den Vorteilen der ITIL Best Practices überzeugt werden: Die Nutzung von ITIL verlangt immer die Unterstützung des Managements. Aufgabe des mittleren Managements ist es, das Top-Management für die Implementierung der IT Service Management-Prozesse auf Basis von ITIL zu gewinnen. Dazu müssen Sie die Vorteile für Ihre Organisation deutlich herausstellen. Fehlt es hierzu an Kennzahlen, da noch keine messbaren Prozesse existieren, sollten Sie auf möglichst prägnante Ereignisse in der Vergangenheit verweisen, beispielsweise einen fehlgeschlagenen Change mit großen Auswirkungen auf die IT-Organisation und auf die Geschäftsprozesse Ihres Kunden. Nutzen Sie solche Beispiele und stellen Sie heraus, welche Vorteile Ihnen ein IT Service Management nach ITIL hierbei geboten hätte. Sie können auch den Weg über Konferenzen nutzen – wie zum Beispiel das ITIL Forum – und von den Erfahrungen anderer ITOrganisationen profitieren bzw. auf deren positive Erfahrungen verweisen. Als Grund für die Einführung von ITIL werden häufig die damit erreichbare höhere Servicequalität und die bessere Ausrichtung auf die Geschäftsprozesse angeführt. Sie können das Top-Management von ITIL aber nur dann überzeugen, wenn es Ihnen gelingt, die erkannten Defizite und deren Auswirkungen mit finanziellen Beträgen zu hinterlegen. Von Vorteil ist es, finanzielle Vorteile für die IT-Organisation aufzeigen zu können. Noch überzeugender ist die (glaubhafte) Aussicht auf finanzielle Vorteile für das Kerngeschäft. Stellen Sie gegenüber dem Top-Management heraus, dass sich die mit der Einführung von ITIL verbundenen Investitionen amortisieren.
Ganz gleichgültig, ob die Nutzung der ITIL Best Practices vom Management oder aus dem Mitarbeiterkreis initiiert wurde: Es muss sichergestellt werden, dass das gesamte Management hinter dem geplanten Vorhaben steht und die damit verbundenen Veränderungen aktiv unterstützt. Nutzen Sie die Kundenanforderungen, um die Notwendigkeit der geplanten Maßnahmen in Ihrer Organisation herauszustellen. – Nach dem Motto: „Wir implementieren IT Service Management, nicht weil es uns Spaß macht, sondern weil es ein im Markt anerkannter Standard für die optimale Zusammenarbeit zwischen IT und Kunde ist.“
224
6.2 ITIL-Einführung Eine besondere Rolle bei der geplanten Implementierung fällt Ihren Kunden bzw. dem Markt zu. Häufig verlangen Ihre Kunden in Angebotsaufforderungen oder bei Ausschreibungen, dass die anbietende ITOrganisation (IT Service Provider) ITIL-konforme Prozesse bzw. eine ISO 20000 (vormals BS 15000) Zertifizierung nachweist. Diese Situation stellt eine große Chance für Ihr geplantes Projekt dar: Mit diesem Außendruck kann die Notwendigkeit einer ITIL Implementierung in der IT-Organisation leichter vermittelt werden. Das Implementierungsprojekt wird unter diesen Voraussetzungen in der Regel mit einem höheren Nachdruck verfolgt werden. Nutzen Sie die Kundenanforderungen, um die Notwendigkeit der geplanten Maßnahmen in Ihrer Organisation herauszustellen. – Nach dem Motto: „Wir implementieren IT Service Management, nicht weil es uns Spaß macht, sondern weil es vom Markt verlangt wird.“
Hat sich Ihre Organisation entschieden, die IT Service Management-Prozesse zu etablieren, so müssen Sie Ihren Mitarbeitern die damit verbundenen Ziele vermitteln. Mit der Einführung von Prozessen soll eine Messbarkeit des IT Service Managements und eine Identifizierung von Schwachstellen sichergestellt werden. Die damit verbundene Transparenz ruft aber unter Umständen bei den Betroffenen Ängste hervor. Eine aus dem Kreis der Mitarbeiter häufig geäußerte Sorge ist: „Heute muss ich meine Tätigkeiten und mein Wissen transparent dokumentieren und morgen wird mit dem dokumentierten Wissen meine Leistung outgesourced“. Versuchen Sie diesen Ängsten mit Gegenbeispielen aus anderen ITOrganisationen zu begegnen. Erklären Sie Ihren Mitarbeitern, dass Outsourcing in der Regel keinen Sinn macht, wenn die Prozesse in der IT-Organisation gut funktionieren, transparente Services und Leistungen erbracht und die gesetzten Ziele erreicht werden. Stellen Sie den mit IT Service Management angestrebten Nachweis der eigenen Leistungsfähigkeit als möglichen Schutz vor Outsourcing heraus. Informieren Sie Ihre Mitarbeiter frühzeitig über die geplanten Maßnahmen und die damit verfolgten Ziele. Motivieren Sie die Mitarbeiter und begegnen Sie den Ängsten Ihrer Mitarbeiter.
Für eine erfolgreiche Etablierung der geplanten IT Service ManagementProzesse ist die Akzeptanz seitens Ihrer Mitarbeiter eine unabdingbare Voraussetzung.
225
Wertschätzung des Bestehenden
6 Lessons learned: Empfehlungen und Ratschläge Bei der Analyse der ITIL-Prozesslandkarte werden Sie wahrscheinlich feststellen, dass die bestehenden Prozesse die Anforderungen der ITIL Best Practices nicht vollständig erfüllen. Beispiel: Es existiert bereits ein Change Management, aber dieses Change Management bietet gegenüber ITIL Verbesserungspotenzial. Trotzdem hat dieser Prozess bisher Erfolge gezeigt, und Ihre Mitarbeiter haben sich in diesem bestehenden Prozess engagiert. Sie sollten die bisher bestehenden Abläufe und Leistungen nicht gering schätzen, sondern als Basis für eine Verbesserung würdigen. Zeigen Sie Ihre Wertschätzung für die bestehenden Abläufe und für die damit erzielten Erfolge. Stellen Sie ITIL als Chance für eine Verbesserung dar.
Nutzen Sie die bestehenden Prozesse und zeigen Sie die positiven Möglichkeiten der ITIL Best Practices auf, um diese Prozesse weiter zu verbessern. Ihre Mitarbeiter sollten ITIL als Angebot verstehen, auf das darin dokumentierte Wissen zurückzugreifen. Dafür muss ITIL als Chance gesehen werden, nicht als Damoklesschwert, das Bestehendes entwertet. Ihre Mitarbeiter und Manager sollen ITIL als Chance verstehen, von anderen zu lernen und sich dadurch weiterzuentwickeln.
Ihr Ziel muss es sein, ein Verständnis von ITIL als Chance für eine ganzheitliche Betrachtung der IT in Ihrer Organisation zu verankern.
6.2.2 Selbst erarbeiten statt fertig kaufen
Prozess-Einführungen
Sie müssen mit Widerständen bei der Implementierung der geplanten Prozesse rechnen. Sehr hilfreich ist es hier, wenn die IT Service Management-Prozesse aus Ihrer IT-Organisation heraus, von Ihren Mitarbeitern entwickelt werden. Ihre Mitarbeiter können dabei Ihre praktischen Erfahrungen einbringen und so sicherstellen, dass die geplanten Prozesse auf die Geschäftsprozesse Ihres Kunden ausgerichtet sind sowie den Anforderungen der IT-Organisation entsprechen. Ihre IT Service Management-Prozesse auf Basis von ITIL können Sie nicht extern einkaufen, sondern sie müssen unbedingt von Ihren Mitarbeitern erarbeitet werden.
Externe Berater können – und sollten – Ihnen hierbei helfen. Der Berater soll Ihre Mitarbeiter ansprechen können und als Coach tätig sein. Dazu muss der Berater nicht nur über die erforderlichen ITIL (und ISO 20000) Zertifizierungen verfügen, sondern auch Erfahrungen aus vergleichbaren Projekten und vergleichbaren Organisationen mitbringen. Nicht zuletzt ist
226
6.2 ITIL-Einführung die Sozialkompetenz des Beraters dabei ein weiterer wichtiger Erfolgsfaktor: „Die Chemie muss stimmen“. Das beauftragte Unternehmen muss sicherstellen können, dass es über eine ausreichende Anzahl von Beratern verfügt um ggf. mehrere gleichzeitig anstehende Projektaktivitäten in Ihrer IT-Organisation qualitativ zu unterstützen. Der Berater muss in der Lage sein, mit ggf. anderen im Ihrem Hause tätigen Beratern zusammenarbeiten zu können. Hierbei kann es sich unter Umständen um Berater handeln, die im Rahmen des IT Governance tätig sind oder den Veränderungsprozess einer Organisation unterstützen. Beauftragen Sie keine Zertifizierungsorganisation mit der Beratung: Ist eine spätere Zertifizierung der IT Service Management-Prozesse geplant, muss Unabhängigkeit zwischen Berater und Zertifizierer gewährleistet sein. Zertifizierungsorganisationen konzentrieren sich außerdem häufig auf die formalen Anforderungen des Standards, während ein Berater praxisorientiert vorgehen wird. Der Betriebsrat sollte von Ihnen bzw. vom Top-Management frühzeitig über die geplanten Maßnahmen informiert werden. Mit der Einführung von Prozessen auf Basis der ITIL Best Practices ist das Ziel verbunden, die Wirksamkeit der Prozesse zu messen und ggf. den Bedarf an notwendigen Optimierungsmaßnahmen zu identifizieren. In vielen Fällen führt dies dazu, dass die Prozess-Aktivitäten der Mitarbeiter erfasst und aggregiert werden. Zum Beispiel wird die Kennzahl „Einhaltung der Lösungszeiten in Abhängigkeiten der SLAs“ oder „Dauer der Liegezeiten“ aus den dokumentierten Maßnahmen in Tickets gewonnen. Nach deutschem Recht ist der Betriebsrat zumindest über diese Maßnahmen zu informieren; in Teilbereichen wird möglicherweise die Zustimmung des Betriebsrates erforderlich sein. Informieren und beteiligen Sie den Betriebsrat frühzeitig. Unterstreichen Sie, dass Prozesse ausgewertet werden sollen und nicht die Leistung einzelner Mitarbeiter. Machen Sie klar, dass die geplanten Maßnahmen der internen Optimierung und damit auch dem Schutz von Arbeitsplätzen dienen.
Zur Information und Abstimmung mit dem Betriebsrat hat sich folgendes Vorgehen bewährt: – Das Top-Management hat den Betriebsrat frühzeitig über die Ziele der geplanten Prozesseinführung und das Erreichen von Meilensteinen informiert. Es wurde mit dem Betriebsrat vereinbart, dass die Prozesse gemessen werden und keine Auswertung auf Mitarbeiterebene erfolgt.
227
Einbeziehung des Betriebsrats
6 Lessons learned: Empfehlungen und Ratschläge – In Abhängigkeit der Größe Ihrer IT-Organisation ist zu entscheiden, ob die Prozess Manager eine Full-time Tätigkeit übernehmen. In vielen Unternehmen ist dies der Fall. Dann sollte der Betriebsrat bei der Ausschreibung und Besetzung der Positionen der Prozess Manager beteiligt werden. – Eine detaillierte Absprache der geplanten und erhobenen Kennzahlen mit dem Betriebsrat liegt in der Verantwortung der eingesetzten Prozess Manager. Qualität vor Geschwindig keit
Vielfach bedeutet die Einführung der IT Service Management-Prozesse auf Basis der ITIL Best Practices eine veränderte Betrachtungsweise in der ITOrganisation: Weg von der Systemorientierung, hin zu einer Service- und Prozessorientierung. Das bedeutet auch und gerade eine Veränderung in der Denkweise und im Verhalten der Mitarbeiter in Ihrer IT-Organisation. Wie bei allen Veränderungsmaßnahmen wird hierzu eine ausreichende Zeit benötigt. Die Mitarbeiter müssen die Veränderungen adaptieren und verinnerlichen. Eine Veränderung über Nacht ist nicht zu erzwingen. Ebenso ist es nicht ratsam, zu große Veränderungen auf einmal durchzuführen. Sie sollten unbedingt stufenweise vorgehen. Dies gilt sowohl für die Gesamtheit aller IT Service Management-Prozesse, als auch innerhalb der einzelnen Prozesse. Es ist wenig ratsam, sämtliche IT Service Management-Prozesse gleichzeitig zu implementieren. In der Regel beginnt man mit der Implementierung des Service Level Managements, gefolgt von Incident, Configuration, Change und Problem Management. Die konkrete Reihenfolge der Einführung hängt aber von Ihrer Ist-Situation und den Anforderungen an Ihre IT-Organisation ab, also von Ihrer „Pain“. Ebenso sollte der Reifegrad, die Qualität der einzelnen Prozesse schrittweise gesteigert werden. Die Veränderungen müssen von den Mitarbeitern und der gesamten IT-Organisation verkraftet werden. Planen Sie daher Projektpausen ein, in denen sich die Mitarbeiter und die IT-Organisation zunächst mit den durchgeführten Veränderungen vertraut machen können und Sicherheit zurückgewinnen. Die Implementierung von IT Service Management-Prozessen bedingt eine Veränderung der IT-Organisation und der Mitarbeiter. Stellen Sie eine schrittweise Veränderung mit entsprechenden Projektpausen sicher.
228
6.2 ITIL-Einführung
6.2.3
Die Organisation gewinnen
Innerhalb Ihrer IT-Organisation existieren verschiedene Interessengruppen. Sie müssen die Motivation der einzelnen Interessengruppen identifizieren und sie anschließend auf Basis der identifizierten Motivationsgründe für ITIL gewinnen. Eine wichtige Motivation zur Nutzung von ITIL besteht in der bereits beschriebenen Chance, die IT-Organisation und sich persönlich weiterzuentwickeln. Das Qualitätsmanagement können Sie leicht für die ITIL Best Practices gewinnen, wobei unter Qualitätsmanagement hier nicht eine Abteilung, sondern der Gedanke der Qualitätsverbesserung zu verstehen ist. Ein wichtiges Kriterium für Qualität ist Nachhaltigkeit. ITIL stellt eine höhere Nachhaltigkeit in der IT sicher. So werden beispielsweise mit dem Incident Management nicht nur akute Störungen behoben, sondern darüber hinaus wird mit dem Problem Management eine nachhaltige Untersuchung etabliert, die zu einer Qualitätsverbesserung in der IT führt. Mitarbeiter mit einem starken Kundenfokus gewinnen Sie für ITIL, indem Sie die Serviceorientierung und die Ausrichtung der IT Service Management-Prozesse auf die Geschäftsprozesse des Kunden herausstellen. Die Motivation des Top-Managements wird wahrscheinlich primär durch die Qualitätsverbesserung geprägt sein. Durch Hinweise auf Kostenbetrachtungen und einen häufig gegebenen Wachstums- oder Konsolidierungsdruck können Sie weitere Motivation für die ITIL Best Practices generieren. Das mittlere Management gewinnen Sie für ITIL mit den zu erwartenden Verbesserungen in der abteilungsübergreifenden Zusammenarbeit oder der Mess- und Nachweisbarkeit von Qualitätsverbesserung gegenüber dem Top-Management. Den Mitarbeitern bietet ITIL u. a. eine stärkere Absicherung der durchgeführten Aktivitäten durch klare Rollen- und Prozessdefinitionen. Die jeweilige Motivation für IT Service Management wird auch von der Größe der IT-Organisation beeinflusst. In kleineren IT-Organisationen steht häufig allein die Kundenorientierung im Mittelpunkt. Kommunikationsprobleme innerhalb der IT-Organisation und die Vernetzung der einzelnen IT-Organisationen spielen hier kaum eine Rolle. Mit wachsender Größe der IT-Organisation nehmen diese Probleme aber exponentiell zu und ITIL wird als Chance erkannt, diese Probleme zu lösen. Zur Identifizierung der verschiedenen Motivationsgründe ist es hilfreich, über einen externen Berater mit entsprechenden Erfahrungen zu verfügen.
229
6 Lessons learned: Empfehlungen und Ratschläge Verdeutlichen Sie den durch IT Service Management erzielbaren Gewinn für die IT-Organisation, indem Sie die Sicht des Kunden einnehmen: Der Gewinn für die Organisation
Die IT wird in der Regel vom Kunden nur dann (negativ) wahrgenommen, wenn zugesagte Vereinbarungen nicht eingehalten werden oder größere IT-Störungen auftreten. Durch ein regelmäßiges, kundenorientiertes Reporting können Sie dieses Erscheinungsbild zum Positiven verändern. Reporten Sie Ihren Kunden aber nicht nur die einzelnen Bestandteile der SLAs, sondern stellen Sie ihnen aussagekräftige Qualitätsinformationen aus den IT Service Management-Prozessen zur Verfügung. So wird im Hause des IT Rechenzentrums dem Kunden unter anderem berichtet, welche Probleme identifiziert wurden und welche Maßnahmen ergriffen werden, um die identifizierten Probleme zu beheben. Für interne IT-Organisationen ist es ideal, über erreichte Kosteneinsparungen berichten zu können. Im beschriebenen Unternehmen konnte zum Beispiel mit Hilfe des Prozesses Capacity Management dargestellt werden, welche Kosteneinsparungen durch die Konsolidierung der IT Infrastruktur erzielt wurden.
6.2.4 Die Rollen gemäß der ITIL Best Practices
Rollenbeschreibungen
Innerhalb der ITIL Best Practices bis Version 2 finden Sie Rollenbeschreibungen zu den einzelnen Prozess Managern der IT Service ManagementProzesse. Schauen Sie sich hierzu [OGC, 2005b], [OGC, 2006b] und [OGC, 2006a] an: – OGC Best Practice for Service Support, – OGC Best Practice for Service Delivery und – Best Practice für Security Management. Generelle Rollenbeschreibungen für den Prozess Manager und den Prozess Owner sind der Originalliteratur zur ITIL Version 2 nicht zu entnehmen. Hier liefert aber entsprechende Sekundärliteratur Empfehlungen (vgl. [OGC, 2005a]). Die ITIL Version 3 greift diesen leichten Mangel aus Version 2 auf und gibt Handlungsempfehlungen für die Etablierung der organisatorischen Rollen Prozess Owner und Prozess Manager. Diese generischen Rollenbeschreibungen sind im Rahmen der Umsetzung entsprechend der jeweiligen Organisation zu operationalisieren. Diesen Empfehlungen gemäß ist der Prozessinhaber (Prozess Owner) für die Prozessergebnisse verantwortlich, während der Prozess Manager für die Durchführung und die Einrichtung des Prozesses verantwortlich ist. Der Prozess Owner dient dem Prozess Manager primär als Coach.
230
6.2 ITIL-Einführung Innerhalb des Unternehmens wurden für die Rollen der Prozess Owner und Prozess Managern abweichende Verantwortlichkeiten festgelegt. Der Prozess Manager hat die Verantwortung für das Funktionieren seines Prozesses und steuert die notwendigen Optimierungen. Der Prozess Manager muss demzufolge mit den notwendigen Weisungsrechten innerhalb seines Prozesses ausgestattet sein.
Die Rolle des Prozess Managers
Die Prozess-Ziele werden nicht nur primär vom Prozess Owner vorgegeben, sondern auch durch ihn aus der IT-Strategie und der Balanced Scorecard abgeleitet. Aus diesen Anforderungen heraus definiert der Prozess Manager die notwendigen Prozess-Ziele und die damit verbundenen Kennzahlen. Es muss sichergestellt werden, dass die Prozess Manager ein Grundverständnis aller IT Service Management-Prozesse haben. Dadurch wird einerseits erreicht, dass der eigene Prozess hinsichtlich seiner Schnittstellen, Abhängigkeiten und Verzahnungen besser gemanagt werden kann. Andererseits motivieren diese Kenntnisse und die damit verbundenen Aufstiegsmöglichkeiten den Prozess Manager zum Lernen. In der ITIL-Literatur bis Version 2 wird die Rolle des Service Managers nur stellenweise angesprochen, aber nicht übergreifend beschrieben. Trotzdem kommt dieser Rolle in der praktischen Umsetzung der ITIL Best Practices eine sehr wichtige Aufgabe zu. Die ITIL Version 3 präzisiert diese wichtige Rolle wie folgt: „Einzelne Prozess-Ziele können partiell miteinander konkurrieren, Umsetzungsmaßnahmen aus unterschiedlichen Prozessen sind zu priorisieren und es können Abstimmungsprobleme zwischen Prozessorganisation und hierarchischer Organisationsstruktur auftreten. – In diesen Fällen ist der Service Manager die Eskalationsinstanz für die Prozess Manager.“ Letztendlich liegt die Gesamtverantwortung für das Service Management in der Rolle des Service Managers (vgl. Continual Service Improvement, [OGC, 2007e] Seine Verantwortung umfasst die Entwicklung der Geschäfts-Strategie, Marktund Kunden-Analyse, Lieferanten-Management, Inventarisierung, Kosten Management und insbesondere das Auslieferungs- und Lebenszyklus-Management von Produkten und Services.
Für die Einführung der IT Service Management-Prozesse und der identifizierten Optimierungsmaßnahmen ist der Service Manager richtungsweisend, er erstellt den „Bebauungsplan“.
231
Die Rolle des Service Managers
6 Lessons learned: Empfehlungen und Ratschläge Die Rolle des Service Managers muss mit einem erfahrenen Manager besetzt werden. Die Rolle des TopManagements
Aufgabe des Top-Managements ist es, den zu etablierenden IT Service Management-Prozessen den Rücken zu stärken und ihre Ziele nach außen zu vertreten. Das Top-Management ist der Sponsor der IT Service Management-Prozesse. Mit der Implementierung der neuen IT Service Management-Prozesse kann vorübergehend eine Phase der Instabilität entstehen. Mit den bisherigen Abläufen waren die Mitarbeiter vertraut, mit den neu implementierten Prozessen sind sie es noch nicht. Erworbene Kompetenzen, gehen unter Umständen verloren, es beginnt eine unsichere Lernphase („Tal der Tränen“). Hier muss das Top-Management unterstützend einwirken und die Sicherheit geben, dass Anfangsfehler toleriert werden. Das Top-Management muss Anfangsfehler tolerieren und so dazu beitragen, dass kein Rückfall in alte Zustände eintritt.
Die Rolle des mittleren Managements
Das mittlere Management setzt einerseits die Vorgaben des Top-Managements im täglichen Betrieb aktiv um. Andererseits muss es die Prozess Manager unterstützen und ihnen den erforderlichen Freiraum verschaffen. Die Einführung von durchgängigen Prozessen mit dezidierter Prozessverantwortung führt häufig zu Widerständen im mittleren Management. Diese Widerstände sind mit der Angst vor der geplanten Transparenz und einem möglichen Machtverlust verbunden. Manchmal kann diesen Widerständen erfolgreich entgegen gewirkt werden, wenn die Rollen der Prozess Owner mit Personen aus dem mittleren Management besetzt werden. Dem mittleren Management kommt eine wichtige Rolle in der Unterstützung des Wandels zu.
Die Rolle der Mitarbeiter
Mit der Einführung von IT Service Management-Prozessen kann sich die Rolle von Mitarbeitern im IT Service aus deren Sicht verkomplizieren. Waren sie vorher ausschließlich einem Vorgesetzten verantwortlich (und dort der Ergebniserbringung), wird Ihre Tätigkeit nun in verschiedenen Prozessen überwacht und die Weisungen unterschiedlicher Prozess Manager steuern auf Qualitätsebene die operative Arbeit der Mitarbeiter. Stellen Sie sicher, dass Ihre Mitarbeiter sich in dieser Situation nicht verloren vorkommen. Die Hierarchie, insbesondere das mittlere Management, muss die Prozesse aktiv unterstützen, um damit die Ziele der ITIL Einführung nachhaltig zu unterstützten.
232
6.3 Kontinuierlicher Verbesserungsprozess Die Prozess Manager geben den Mitarbeitern „Leitplanken“ (Prozessleitlinien) vor, innerhalb derer sie sich sicher bewegen können. Durch diese Konzentration auf klare Prozesse geben sie ihren Mitarbeitern ein Gefühl der Sicherheit. Transparente Ziele und veröffentlichte Kennzahlen als Erfolgsnachweis der eigenen Arbeit steigern die Zufriedenheit der Mitarbeiter im Unternehmen. Beziehen Sie Ihre Mitarbeiter und deren Know-how bei der Entwicklung der neuen IT Service Management-Prozesse mit ein und gewinnen Sie dadurch weitere Akzeptanz. Damit die ITIL Best Practices erfolgreich zur Gestaltung und Implementierung Ihrer IT Service Management-Prozesse genutzt werden können, müssen Sie einen Veränderungsprozess in Ihrer IT-Organisation initiieren. Ohne flankierende Maßnahmen führt das „Einführen“ von ITIL zu Akzeptanzproblemen und scheitert nicht selten. Die ITIL Best Practices sind eine Methode, aber nicht das Ziel. Sie nutzen „lediglich“ die Best Practice-Erfahrungen, um von Ihnen bei der Definition Ihrer IT Service Management-Prozesse zu profitieren. Die angepassten IT Service Management-Prozesse müssen innerhalb Ihrer ITOrganisation gelebt werden. Dazu müssen Ihre Mitarbeiter die Prozesse verstehen, mitgestalten und insbesondere die Erfolge erfahren.
6.3 Kontinuierlicher Verbesserungsprozess Eine wichtige Komponente der ITIL Best Practices ist das im konzeptionalen Ansatz enthaltene Qualitätsmanagement. Hierzu verweisen die ITIL Best Practices auf verschiedene Methoden wie zum Beispiel auf „Six Sigma“ oder auf den „Deming-Zyklus“ (vgl. [OGC, 2005b]), dargestellt in Abbildung 66. Von wesentlicher Bedeutung für die Qualität der IT Services und der Prozesse ist, dass Sie eine fortlaufende Überprüfung, ein Monitoring sämtlicher implementierten IT Service Management-Prozesse durchführen. Auf die dazu notwendige Ermittlung von Kennzahlen wird im nächsten Kapitel eingegangen. In der Publikation „Best Practice für Service Support“ vgl. [OGC, 2005b]) heißt es hierzu: „Dieser Ansatz bedingt, dass ein Unternehmen nach definierten Prozessen agiert, seine Aktivitäten in Bezug auf die Zielerreichung misst, sowie die aus den Prozessdurchläufen folgenden Outputs im Hinblick auf mögliche Prozessverbesserungen überprüft.“
233
6 Lessons learned: Empfehlungen und Ratschläge
Abbildung 66:
Deming (oder PDCA) Zyklus
Die Norm ISO 20000, der (einzige) internationale Standard für das IT Service Management, konkretisiert diesen Ansatz der ITIL Best Practices weiter. So fordert die ISO 20000 einen übergeordneten Prozess „Planung und Implementierung“. Dieser Prozess stellt unter anderem die Etablierung eines übergreifenden kontinuierlichen Verbesserungsprozesses für das IT Service Management sicher. Darüber hinaus sind gemäß der ISO 20000 in den einzelnen IT Service Management-Prozessen notwendige Verbesserungsmaßnahmen zu identifizieren und aufzuzeigen. Mit der Messung und dem Review der IT Services und der IT Service Management-Prozesse erhalten Sie hierzu die notwendigen Voraussetzungen. Eine Kurzbeschreibung zur ISO 20000 finden Sie im Download-Bereich der KESS DV-Beratung (vgl. [KESS, 2006b]). Darüber hinausgehende Informationen können Sie den im Quellenverzeichnis aufgeführten Publikationen zu ISO 20000 entnehmen. Ein professionelles IT Service Management bedingt unabdingbar die stetige Messung der Prozesse und die Identifikation von möglichen Verbesserungsmaßnahmen (KVP: Kontinuierlicher Verbesserungs-Prozess).
6.3.1
KVP der bestehenden Prozesse
Ausgangspunkt ist die oben beschriebene Analyse der bereits innerhalb der IT-Organisation bestehenden IT Service Management-Prozesse. Prozess Manager von bereits bestehenden IT Service Management-Prozessen befinden sich dabei in einer vermeintlich komfortablen Ausgangsposition: Während andere Prozesse noch zu definieren und zu entwickeln sind, bestehen deren Prozesse bereits.
234
6.3 Kontinuierlicher Verbesserungsprozess In diesem Zusammenhang mag es zunächst paradox erscheinen, aber speziell die Prozess Manager von bestehenden Prozessen benötigen die intensivste Unterstützung durch eine externe Begleitung. Sie müssen die IT Service Management-Prozesse, die am weitesten entwickelt sind (mit der höchsten Prozessreife), besonders eng begleiten.
Ansonsten besteht die große Gefahr, dass sich der betroffene Prozess Manager aufgrund der durchgeführten Ist-Aufnahme (ITIL-Prozesslandkarte) in seiner bestehenden Handlungsweise bestätigt fühlt und keine notwendigen Handlungsmaßnahmen für „seinen“ Prozess identifiziert. Auch bei guten (Einzel-) Ergebnissen der durchgeführten Ist-Aufnahme (Prozessreife) muss aber zumindest davon ausgegangen werden, dass die Vernetzung der IT Service Management-Prozesse noch nicht ausreichend gegeben ist. Das heißt, es besteht immer ein Handlungsbedarf, den Prozess mit den anderen IT Service Management-Prozessen zu vernetzen. Die (externe) Begleitung des Prozess Managers soll sicherstellen, dass die erforderliche Vernetzung erkannt und aktiv betrieben wird. Die Rolle des externen Begleiters ist es, als Coach den Prozess Manager „einzufangen“. Durch die Forcierung der Vernetzung vermeiden Sie eine isolierte Optimierung einzelner IT Service Management-Prozesse, die ansonsten den anderen Prozessen davoneilen würden. Die isolierte Optimierung einzelner Prozesse kann zu Mehraufwendungen führen, wenn später die notwendigen Schnittstellen und unter Umständen damit verbundene Aktivitäten angepasst werden müssen. Es ist für Ihre IT-Organisation von großem Vorteil, wenn eine gleichmäßige vertikale Entfaltung der geplanten IT Service Management-Prozesse betrieben wird.
Diese Forderung bedeutet nicht, dass Sie alle IT Service Management-Prozesse gleichzeitig einführen sollen. Es ist vielmehr pro Projekt- bzw. Implementierungsphase eine synchrone Entwicklung der einzelnen Prozesse sicherzustellen. Dem Prozess Manager mit dem bereits am weitesten entwickelten Prozess kommt hierbei eine besondere Rolle zu. Er muss auf die anderen Prozess Manager zugehen, die Vernetzung der einzelnen Prozesse aktiv vorantreiben und sicherstellen. Planen Sie zum Beispiel die Etablierung des Incident, Problem und Change Managements und ist der Prozess des Incident Managements am weitesten fortgeschritten, so muss der Prozess Manager des Incident Managements die führende Rolle bei der erforderlichen Vernetzung der drei Prozesse einnehmen.
235
6 Lessons learned: Empfehlungen und Ratschläge Bei den bestehenden Prozessen zeichnet sich der KVP dadurch aus, dass die Prozesse gleichmäßig (vertikal) entwickelt werden und keine Prozesse die Entwicklung isoliert vorantreiben. Nicht zu früh beginnen
6.3.2
KVP der neuen Prozesse
Mit dem Start des kontinuierlichen Verbesserungsprozesses darf bei neuen Prozessen nicht zu früh begonnen werden. Stellen Sie zunächst sicher, dass der Prozess bereits komplett eingeführt ist. Am Bild einer Treppe verdeutlicht: Sie sollten die Stufen stetig, mit ruhigen Schritten emporsteigen. Nehmen Sie nicht mehrere Stufen auf einmal, überspringen Sie keine Stufen. Um das Ziel sicher zu erreichen, sollten Sie auf jeder Stufe erst einmal verharren und Kraft tanken, um dann erholt die nächste Stufe zu erklimmen. Ihre Organisation muss die Prozesse angenommen haben und damit verbundene (Ver-) Änderungen müssen verkraftet sein. Die Einführung von IT Service Management-Prozessen auf Basis der ITIL Best Practices ist eine Maßnahme der Organisationsentwicklung und bedarf eines Veränderungs-Managements. Der Soziologe Kurt Lewin gilt als Wegbereiter der Organisationsentwicklung. Aufbauend auf seiner Grundannahme, dass sich eine Organisation ändert, wenn sich ihre Akteure ändern, entwickelte er sein Phasenmodell (vgl. Abbildung 67) zum Veränderungs-Management (vgl. [Lewin, 1958]).
Neue Welt
Alte Welt
Einfrieren
Auftauen
Bewegen Abbildung 67:
236
3-Phasen-Modell nach Lewin
6.3 Kontinuierlicher Verbesserungsprozess Im Ausgangszustand befindet sich eine Organisation im Gleichgewicht. Die bestehenden Abläufe und Prozesse werden in Frage gestellt. Hierzu kann auf die ITIL Best Practices und die damit in anderen IT-Organisationen erzielten Erfolge verwiesen werden. Die bestehende IT-Organisation wird „aufgetaut“. Ist das Auftauen der IT-Organisation (und der Mitarbeiter) erreicht, werden in der Phase der „Bewegung“ neue Prozesse implementiert und die Mitarbeiter in deren Handhabung ausgebildet und eingewiesen. Es ist dann von großer Bedeutung, dass dieser Zustand zunächst „eingefroren“ wird. Mit den alten Abläufen waren Ihre Mitarbeiter vertraut. Die Implementierung der neuen IT Service Management-Prozesse führt zu einer Instabilität. Die Mitarbeiter sind mit in den neuen Prozessabläufen und den damit verbundenen Abläufen noch nicht vertraut. Sie fühlen sich unsicher. Ihre Aufgabe besteht jetzt darin, den Mitarbeitern die notwendige Sicherheit zu vermitteln. Das heißt, Sie müssen den Mitarbeitern die Chance geben, sich mit den neuen Prozessen auseinander zu setzen und deren Handhabung im täglichen Betrieb einzuüben. Die Mitarbeiter Ihrer IT-Organisation müssen die Veränderungen bewältigen. Geben Sie ihrer Organisation die Chance, sich mit neuen Abläufen vertraut zu machen und planen Sie Phasen des „Einfrierens“ ein.
Erst wenn die Mitarbeiter mit den neuen Prozessaktivitäten vertraut sind, sollten Sie eine weitere Verbesserung und Erweiterung des Prozesses angehen. Zusätzlich ist die Phase des „Einfrierens“ für die Motivation Ihrer ITOrganisation von großer Bedeutung. Die Einführung von IT Service Management-Prozessen auf Basis der ITIL Best Practices führt zu veränderten Abläufen und ggf. zu anderen Aktivitäten, die die Mitarbeiter durchzuführen haben. Von nachhaltigem Erfolg sind diese Maßnahmen nur dann, wenn Sie akzeptiert werden. Akzeptiert werden die Maßnahmen in der Regel, wenn Sie den Erfolg – wenn möglich für den Einzelnen – nachweisen. Haben Sie zum Beispiel ein Configuration Management eingeführt, so sollten Sie die Erfolge des Prozesses für Ihre IT-Organisation und Ihre Mitarbeiter erfahrbar machen. Die Mitarbeiter sollen erleben, welche Vorteile dieser Prozess in der täglichen Arbeit bietet. Damit stellen Sie die Motivation der Mitarbeiter für weitere Veränderungsmaßnahmen sicher.
237
6 Lessons learned: Empfehlungen und Ratschläge Beginnen Sie zu früh mit den nächsten Verbesserungsmaßnahmen, so nehmen Sie ihrer IT-Organisation und Ihren Mitarbeiter die Chance, die bisher erzielten Vorteile zu erleben. Das Service Improvement Programm
Innerhalb der ITIL Best Practices wird lediglich im Rahmen des Service Level Management-Prozesses auf ein Service Improvement Programm (SIP) eingegangen. Die ISO 20000 „IT Service Management“ ist hier konsequenter. Dort wird zu den jeweiligen Prozess-Reviews gefordert, dass ein erkanntes Verbesserungspotenzial zu Prozessen oder Services der Input für das SIP ist. Durch die Dokumentation im SIP stellen Sie die Nachhaltigkeit der Umsetzung von identifizierten Verbesserungsmaßnahmen sicher. Häufig wird innerhalb der IT-Organisation die Feststellung getroffen „Darum müsste man sich einmal kümmern …“. Dann jedoch diktiert wieder das Tagesgeschäft das Geschehen. Bis zum nächsten akuten Auftreten eines Problems gerät die identifizierte Schwachstelle samt Optimierungsbedarf wieder in Vergessenheit. Ein Service Improvement Programm und die Möglichkeit, dass jeder Mitarbeiter hierzu einen Input liefern kann, hilft Ihnen nachhaltig, die Qualität der Prozesse und des IT Service zu verbessern. Ihre Mitarbeiter haben mit dem Service Improvement Programm die Chance sich einzubringen und zu erleben, wie sie persönlich zum Erfolg der IT-Organisation beitragen.
Damit entsteht letztendlich eine Kombination aus formellen Reviews zur Service- und Prozessoptimierung und einem betrieblichen Vorschlagswesen. In Ihrer Organisation existiert damit ein Verbesserungsprozess, der Input für neue und eingeführte IT Service Management-Prozesse aus der IT-Organisation (Reviews) und von den Mitarbeitern bezieht. ITIL Einführung erfordert ein Release
Aufgabe des Prozess Managers ist die Bewertung des Inputs für den Service Improvement Plan und die Erstellung einer Umsetzungsplanung. Die Einführung und der Ausbau der IT Service Management-Prozesse sollten in Stufen und mit Stabilisierungsphasen (Projektpausen) erfolgen. Dazu muss der Prozess Manager die zuvor geplanten Projektphasen sowie den Input aus dem SIP bewerten, die mit den Maßnahmen verbundenen Vorteile identifizieren und die Umsetzung planen. Diese Tätigkeit ist mit dem IT Service Management-Prozess des Release Management vergleichbar. Es ist nicht zweckmäßig eine Reihe von Änderungen jeweils einzeln und nacheinander zu implementieren. Sie sollten vielmehr die Einzelmaßnahmen bündeln und als Aufgabenpaket (Release) durchführen.
238
6.3 Kontinuierlicher Verbesserungsprozess Bündeln Sie die einzelnen Verbesserungs- und Erweiterungsmaßnahmen zu einem Aufgabenpaket (Release).
Dem Prozess Owner kommt hierbei als Coach eine qualitätssichernde Aufgabe zu. Zum Beispiel hat der Prozess Owner beim Prozess Manager kritisch zu hinterfragen, ob die nächste Umsetzungsmaßnahme sowohl inhaltlich als auch vom Zeitpunkt her die IT-Organisation nicht überfrachtet. Sobald diese Abstimmung erfolgt ist, muss der Prozess Manager die geplanten Verbesserungen und Erweiterungen in der IT-Organisation gegenüber dem Management und den Mitarbeitern kommunizieren. Kommunizieren Sie als Prozess Manager Ihre geplanten Maßnahmen (SIP für Ihre IT Service Management-Prozesse) in der IT-Organisation.
Die Initiierung zur Entfaltung weiterer IT Service Management-Prozesse muss vom IT-Management erfolgen. Haben Sie zum Beispiel bereits Incident, Problem, Configuration und Change Management implementiert, so muss eine Erweiterung um das Release Management vom IT-Management initiiert werden. Die Verantwortung für die Prozessentfaltung – die Erweiterung der bestehenden IT Service Management-Prozesse – liegt beim Service Manager und dem prozessverantwortlichen Prozess Manager. Diese stimmen die mit der Prozesseinführung verbundenen Maßnahmen mit dem Prozess Owner ab. Die Verantwortung für die Prozessentfaltung – die Erweiterung der bestehenden IT Service Management-Prozesse – liegt beim Service Manager. Dieser stimmt zunächst die damit verbundenen Maßnahmen mit dem Prozess Owner ab. Sobald der Prozess Manager für den neuen IT Service Management-Prozess etabliert ist, stimmen sich dann der Prozess Owner und der Prozess Manager ab. Es ist hilfreich, wenn die Prozess Owner für alle IT Service ManagementProzesse zu Beginn benannt werden, auch wenn die Prozesse noch nicht implementiert wurden. Die Prozess Manager können mit der Entscheidung des Managements über die Einführung eines Prozesses benannt werden. Wichtig ist, nicht nur die implementierten Prozesse hinsichtlich ihrer Zielerreichung zu messen, sondern auch die Einführung von Prozessen zu messen und zu überwachen.
239
Der Entfaltungsprozess
6 Lessons learned: Empfehlungen und Ratschläge Der Service Manager hat hierzu ein prozessorientiertes Führungssystem aufgebaut, in dem pro Prozess die folgenden Stufen vom Service Manager gemessen und berichtet werden: – – – –
1. Stufe „Prozess verstanden“ 2. Stufe „Prozessnutzung initiert“ 3. Stufe „Prozess implementiert“ 4. Stufe „Prozess wird kontinuierlich verbessert (KVP)“
Damit die Implementierung der Prozesse vom Management besser verfolgt werden kann, könnten die obigen Stufen der IT Service ManagementProzesse mit einem Ampelsystem dargestellt werden. Für die Gestaltung des Ampelsystems empfiehlt es sich, auf der vertikalen Achse die unternehmenswichtigen Prozesse (z. B. Incident, Problem, Change aufzuführen (etc.) und auf der horizontalen Achse die involvierten Gruppen, Abteilungen, Hauptabteilungen etc. darzustellen. Die Matrix kann dann anschließend in der Stufigkeit 1 – 4 befüllt werden. Wir haben sehr gute Erfahrung mit einer einfachen Einstufung der Skala 1 – 4 gemacht: Stufe 1: die Mitarbeiter sind geschult, die Mitarbeiter haben die richtigen Informationen über die Umsetzung der Prozesse; Stufe 2: die Mitarbeiter leben die Prozesse in den ersten Anfängen, nutzen die neuen Tools, Portale etc.; Stufe 3: die Prozesse werden vollumfänglich genutzt (es kommen Vorschläge zur Verbesserung), die Prozesstools werden ausgereizt; Stufe 4: die Organisation denkt darüber nach, Erweiterungen und Verbesserungen umfänglich einzuführen. Mit diesem Ampelsystem verfügt der Service Manager – und damit das gesamte Management – über ein gutes Führungssystem zur Überwachung der geplanten Maßnahmen und der erzielten Prozessreife. Sie benötigen nicht nur ein System zur Messung der Effizienz und Effektivität der Prozesse, sondern auch ein Messsystem für die Prozessimplementierung. Mit einem Ampelsystem können Sie die Einhaltung der Prozesse und deren Wirksamkeit in der Linie überprüfen.
240
6.3 Kontinuierlicher Verbesserungsprozess
6.3.3
Wettbewerb der Prozesseinführung
Für die Einführung der IT Service Management-Prozesse werden so genannte „Quick-Wins“ benötigt. In unserer schnelllebigen Zeit akzeptiert kein Management mehr Projekte, deren erste Erfolge nach 9 Monaten eintreten. Daher müssen die Prozess Manager bei der Prozesseinführung die QuickWins identifizieren und darstellen. Damit kann nicht nur gegenüber dem Management ein erster ROI demonstriert werden, sondern Sie können auch die Anerkennung des Prozesses in der IT-Organisation erleichtern. Selbst mit der besten Einführungsplanung und einem optimalen VeränderungsManagement werden Sie nicht alle Mitarbeiter von den geplanten Maßnahmen überzeugen können. Mit den Quick-Wins können Sie erste Erfolge nachweisen, die die Richtigkeit des Vorhabens demonstrieren. Die Einführung wird anschließend durch eine größere Akzeptanz beschleunigt.
Die ITIL Einführung benötigt eine durchgängige Kommunikationsplattform. Hier berichten die Prozess Manager dem Service Manager und dem Prozess Owner über die bereits erzielten Erfolge. Diese Erfolge können aus einer Verbesserung der Prozessreife – und der damit verbundenen Änderung der Ampelfarbe – bestehen, wie zum Beispiel der erreichten Dokumentation eines Prozesses. Ein Erfolg kann aber beispielsweise auch darin bestehen, dass Probleme erfolgreich behoben wurden und dadurch die Anzahl der Störungen gesenkt werden konnte. Mit der Zeit lernen die Prozess Manager, wie sie der Organisation die Wirksamkeit ihrer Prozesse darstellen können. Zum Beispiel kann der Prozess Manager Configuration Management dem Produktionsleiter demonstrieren, wie mithilfe des Configuration Managements sehr viel schneller wichtige Informationen abgerufen werden können. Dadurch, dass die Prozess Manager erste Erfolge aufzeigen, entsteht innerhalb der IT-Organisation ein Wettbewerb der Prozesseinführung. Andere Prozess Manager haben ein Interesse daran, ebenfalls Erfolge aufzuzeigen. Es entsteht eine Sogwirkung. Durch die gemeinsame Kommunikationsplattform ist die notwendige Transparenz gegeben. Zusammen mit dem kontinuierlichen Verbesserungsprozess und der damit verbundenen Planung entsteht so auch ein internes Benchmarking.
241
6 Lessons learned: Empfehlungen und Ratschläge
6.3.4
Reifegradanalyse der Prozesse im laufenden Betrieb
Die oben angegebenen Maßnahmen zur Bestimmung des Reifegrads dürfen nicht zu einer Behinderung des Betriebs innerhalb Ihrer IT-Organisation führen. Eine Überprüfung der IT Service Management-Prozesse, die zu früh durchgeführt wird oder zu lange dauert, führt zu einer Verunsicherung der Mitarbeiter. Wird eine Überprüfung zu früh durchgeführt, so fühlen sich Ihre Mitarbeiter in eine Position der Rechtfertigung gedrängt. Es entsteht eine Vorwurfshaltung, bis hin zu Neid und Missgunst. Es geht dann nicht mehr um die Identifizierung von Verbesserungspotenzial, sondern es werden Schuldige gesucht. Eine zu frühe bzw. zu lange Analyse hinterlässt i. d. R. verbrannte Erde. Eine Analyse der bestehenden Prozesse hat schnell und kurzfristig zu erfolgen. Sie sollten besser mit einer gewissen Ungenauigkeit leben, als mehr Genauigkeit zu fordern und damit Ihre IT-Organisation zu belasten und zu verunsichern.
Speziell die Überprüfung durch eine externe Organisation vor der Einführungsphase kann zu diesen Problemen führen. In der Regel werden große Defizite zu den ITIL Best Practices identifiziert und die Mitarbeiter verbinden dies mit einer Disqualifikation ihrer Leistungen und ihres Know-how. Der Berater muss daher unbedingt als Coach auftreten. Erfahrene Berater sind in der Lage sich durch eine kurze Bestandsaufnahme einen Eindruck zu verschaffen, der für eine Planung der notwendigen Maßnahmen völlig ausreichend ist, ohne die Mitarbeiter zu verunsichern. Dies soll keinesfalls heißen, dass Sie Ihre Prozesse nicht extern überprüfen und zertifizieren lassen sollten. Achten Sie lediglich darauf, dass die Überprüfung erst dann erfolgt, wenn eine reelle Chance besteht, dass die Anforderungen erfüllt werden können. Mit einer externen Zertifizierung können Sie Ihre Mitarbeiter weiter motivieren und in Ihrer IT-Organisation den Erfolg der vollzogenen Veränderungsmaßnahmen nachweisen. Die Zertifizierung nach der ISO 20000 belegt, dass auch eine externe, neutrale Organisation den Erfolg Ihrer IT Service Management-Prozesse anerkennt. Achten Sie darauf, dass der externe Berater nicht nur Unterschiede und "Nicht 100% ITIL konform" feststellt, sondern in der Lage ist, Ihren Mitarbeitern Wertschätzung zu geben und das bisher Erreichte positiv unterstreichen zu können.
Die Abstimmung des IT Service Management auf die Business-Strategie sollte frühestmöglich erfolgen. Klären Sie zunächst innerhalb der ITOrganisation, welche IT Services, welche Service Level und welche Messungen realistisch zugesichert werden können. Sie vermeiden dadurch
242
6.4 Kennzahlen eine falsche Erwartungshaltung bei Ihrem Kunden. Holen Sie dann unbedingt Ihren Kunden ab, erläutern Sie ihm die jetzige Situation, gehen Sie ggf. auf die Kostensituation ein und binden Sie ihn in die weitere Entwicklung ein. „Think big, start small“ – getreu diesem Motto sollte die Entwicklung von Kennzahlen erfolgen. Starten Sie zunächst die Messung Ihrer IT Service Management-Prozesse mit wenigen charakteristischen Kennzahlen und entwickeln Sie die Kennzahlen im Rahmen des KVP weiter. Verhindern Sie, dass die Prozesse nach einer gewissen Zeit einschlafen.
Die Zielsetzung für das IT Service Management und die dazu gehörigen Prozesse muss aus der IT-Organisation heraus entwickelt werden. Sie ergibt sich aus der Umsetzung der IT-Strategie und der Strategie Ihres Kunden. Beachten Sie stets, dass die ITIL Best Practices nur eine Methode sind. Definieren Sie keine isolierten ITIL Ziele. Ihre Mitarbeiter müssen die IT Service Management-Prozesse verstehen, dafür benötigen sie theoretische und praktische Schulungen. Wichtig ist die Hinführung der Mitarbeiter von der ITIL-Theorie zu den für sie relevanten Prozessen in Ihrer IT-Organisation. Das Management sollte regelmäßig z. B. Kongresse als Informationsquelle nutzen, um Ihre IT-Organisation mit anderen Unternehmen vergleichen zu können und um weiteres Optimierungspotenzial zu identifizieren.
6.4 Kennzahlen Die IT Service Management-Prozesse auf der Basis der ITIL Best Practices sind fortlaufend kritisch hinsichtlich ihrer Zielerreichung und ihrer Ausrichtung auf die Geschäftsprozesse Ihres Unternehmens zu überprüfen. In diesem Kapitel stellen wir Ihnen vor, wie Sie Ihre IT Service Management-Prozesse bezüglich der Zielerreichung und der Ausrichtung auf die Geschäftsprozesse überprüfen können. Anschließend gehen wir darauf ein, wie Sie die IT Service Management-Prozesse auf Ihre IT-Strategie und Ihre Geschäftsanforderungen ausrichten können. Zum Schluss dieses Kapitels erläutern wir, warum auch nach der Einführung der Prozesse ein Transition Management weiterhin notwendig bleibt.
243
6 Lessons learned: Empfehlungen und Ratschläge
6.4.1
IT-Prozesse am Tagesgeschäft ausrichten
Die ITIL Best Practices und die ISO 20000 sehen Reviews zu den Prozessen und den IT Services vor und betonen die Sicherstellung der Messbarkeit von IT Service Management-Prozessen und IT Services. Dadurch soll gewährleistet werden, dass die IT Service Management-Prozesse die jeweils definierten Ziele erfüllen. Die Publikation „Best Practice für Service Support“ hierzu (vgl. [OGC, 2005b]): „Um ermitteln zu können, ob Ihre Aktivitäten einen optimalen Beitrag der vom Prozess verfolgten geschäftlichen Zielsetzung leisten, sollten Sie regelmäßig ihre Effektivität messen. Die Durchführung von Messungen ermöglicht Ihnen, das tatsächlich Erreichte mit dem Geplanten zu vergleichen sowie eine eventuell erforderliche Verbesserung zu erwägen bzw. einzuleiten.“ Angesichts der Komplexität und der großen Zahl von durchgeführten Aktivitäten innerhalb einer IT-Organisation kann in der Praxis nur über Kennzahlen verfolgt werden, ob die IT Service Management-Prozesse die definierten Ziele erreichen bzw. welche Entwicklungen sich in den IT Service Management-Prozessen abzeichnen. Die Prozesssteuerung von IT Service Management-Prozessen ist ohne Kennzahlen unmöglich. Sie benötigen Kennzahlen für jeden einzelnen IT Service Management-Prozess.
Die Kennzahlen werden dabei zum Teil aus den operativen Systemen gewonnen, wie zum Beispiel aus den in einem Tool für das Incident Management dokumentierten Aktivitäten. Die gespeicherten Informationen werden dabei zu aussagekräftigen Kennzahlen verdichtet, mit denen die Effektivität und Effizienz der jeweiligen IT Service Management-Prozesse gemessen werden kann. Wenn Sie zum ersten Mal Ihre IT Service Management-Prozesse messen, also erste Kennzahlen gewinnen, können die Ergebnisse für das Management sehr ernüchternd sein. Einzelwerte können sogar erschreckend sein. Sehen Sie diesen ersten Eindruck als Chance für das Management. Sie können die Prozesse messen und haben dadurch die Basis für ein erfolgreiches Management der Prozesse geschaffen.
Ein Nutznießer der Kennzahlen ist Ihr IT-Management, z. B. Gruppenoder Abteilungsleiter. Anhand weniger signifikanter Kennzahlen kann sich das IT-Management einen Überblick über die aktuelle Situation verschaffen.
244
6.4 Kennzahlen Folgende Kennzahlen können von Interesse sein: – Incidents pro Monat und Gruppe – Probleme pro Monat und Gruppe – Changes pro Monat und Gruppe Die Anzahl der Changes zeigt die Änderungsdynamik im Unternehmen auf und dient außerdem als Indikator für die Arbeitsbelastung der Mitarbeiter. Ein sprunghaftes Ansteigen von Incidents kann auf eine Flächenstörung hinweisen. Das Management sollte jeweils die Gründe hinterfragen und ggf. die notwendigen organisatorischen Maßnahmen veranlassen. Stellen Sie in Ihrer IT-Organisation heraus, dass die Ermittlung und Auswertung von Kennzahlen für das Management der IT Service Management-Prozesse unbedingt notwendig sind. Betonen Sie, dass die Kennzahlen nicht zur Messung und Beurteilung Ihrer Mitarbeiter dienen und auch nicht dazu genutzt werden.
Wenn Sie noch über keine Messwerte zu einem Prozess verfügen, sollten Sie sich zunächst auf die wichtigsten Kennzahlen konzentrieren. Denken Sie bei der Definition der Kennzahlen an die 80/20-Regel (Pareto-Regel): Der Aufwand und das Ergebnis stehen oft in einem nicht-linearen Verhältnis. 80 % der Arbeit lässt sich mit 20 % Aufwand erledigen. Die restlichen 20% erfordern dagegen 80 % Aufwand.
Bei der 80/20-Regel geht es nicht nur um den Aufwand zur Definition der Kennzahl, sondern insbesondere um den Aufwand der Datengenerierung. Ihre IT-Organisation muss zunächst Erfahrungen mit dem Management von und mit Kennzahlen gewinnen. Daher sollten Sie anfangs mit einfachen Kennzahlen beginnen. Komplexere Kennzahlen – z. B. „wie viele Incidents werden auf Probleme referenziert?“ – sollten erst in einer zweiten oder dritten Stufe des kontinuierlichen Verbesserungsprozesses (KVP) angewandt werden. Für das Incident Management ist es zunächst ausreichend, wenn Sie feststellen, wie viele Incidents überhaupt gemeldet und bearbeitet werden. Die Verfolgung des Trends der Incidents und die Identifizierung signifikanter Abweichungen sind für erste Analysen ausreichend. Mit den ersten Kennzahlen erhalten Sie eine Art Fieberthermometer für Ihre IT Service Management-Prozesse. Auch bei der Definition von Kennzahlen bewahrheitet sich die Erkenntnis „Weniger ist oft mehr“. Wenn noch keine Messwerte vorliegen, sollten Sie sich zunächst auf wenige signifikante Kennzahlen konzentrieren.
245
Wenige, der IT-Organisation nutzbringende, Kennzahlen
6 Lessons learned: Empfehlungen und Ratschläge Die Anforderungen hinsichtlich der Messbarkeit von Prozessen werden von Prozess Managern oft überinterpretiert. Der Konzeptphase folgt dann häufig ein Erschrecken über den Umfang der definierten Kennzahlen und als (vermeintliche) Lösung der Ruf nach einer Tool-Unterstützung. Werden die definierten Kennzahlen schließlich mit Daten hinterlegt, wird oft klar, dass lediglich 10% der Kennzahlen nutzbringend sind. Dieses Vorgehen rührt z. T. auch aus einer unkritischen Nutzung von Publikationen. In den ITIL Best Practices finden Sie zwar beispielhaft einige Kennzahlen. Aber Sie sollten die dargestellten Kennzahlen nicht komplett und ungeprüft übernehmen. Um Ihre Kennzahlen zu definieren, müssen Sie sich fragen, welche Kennzahlen sich aus Ihrer IT-Strategie ableiten und welche Kennzahlen von Ihrer Linienorganisation benötigt werden. Das heißt, welche Kennzahlen unterstützen Ihr Tagesgeschäft? Eine große Hilfestellung bei der Definition von Kennzahlen für die Linienorganisation kann der Prozess Owner geben. Aufgrund der Anforderungen und seinen Erfahrungen aus dem Tagesgeschäft ist der Prozess Owner der ideale Partner, um die notwendigen Kennzahlen zu diskutieren und zu definieren. Interessante Kennzahlen für den Beginn eines Kennzahlenmonitorings können sein: – Anzahl der ausgefertigten und abgeschlossenen SLAs mit Ihren Kunden in Bezug auf den Servicelevelprozess – Anzahl der Notfall / BCM Übungen pro Jahr in Bezug auf das IT Service Continuity Management – Anzahl der vorhandenen Assets pro Gruppe (Windows, Unix, Host etc.) in Bezug auf das Configuration Management. – Anzahl der Ausfälle > 120 min pro Applikation und Monat in Bezug auf das Availability Management Verwendete Kennzahlen müssen für das Management prägnant und beeinflussbar sein. Kann ein Linien-Manager die Kennzahlen nicht sinnvoll nutzen, so findet ITIL beim Management keine Anerkennung! Schrittweise Erweiterung der Kennzahlen
Im Rahmen der schrittweisen Weiterentwicklung Ihrer IT Service Management-Prozesse können Sie ggf. auf einzelne Kennzahlen verzichten oder Kennzahlen ergänzen. Haben Sie zum Beispiel im Incident Management mit der Kennzahl „Anzahl Incidents insgesamt“ begonnen, so können Sie dann die Incidents auf einzelne Kunden, IT Services oder IT-Systeme gruppieren.
246
6.4 Kennzahlen Im Rahmen dieser schrittweisen Erweiterung können Sie dann auch auf Best Practices wie ITIL oder COBIT zurückgreifen. Prüfen Sie die dort dokumentierten Kennzahlen auf sinnvolle Nutzung in Ihrer IT-Organisation, und übernehmen Sie sie nur bei einer positiven Bewertung. Wollen Sie eine Revision Ihrer IT Service Management-Prozesse auf der Basis von COBIT sicherzustellen, so sollten Sie die Umsetzung dieser Anforderung als Stufe Ihres KVP planen und nicht zu Beginn des Prozesses integrieren. Im weiteren Reifegrad der ITIL Einführung können folgende Kennzahlen signifikanter werden: – Anzahl der Changes mit Auswirkungen auf die Availability, somit die Referenz von Changes zu Incidents. – Anzahl der Incidents die auf ein Problem referenzieren, somit die Übersicht darüber, wie viele Maßnahmen im Problem Management aktuell betrachtet werden. – Anzahl der Service Level Agreements in verschiedenen monetären Volumen (z. B. < 100.000 Euro; < 500.000 Euro) und damit eine Gruppierung nach A,B,C Kunden.
6.4.2
ITIL abgestimmt auf die Business- und IT-Strategie
Charakteristisch für IT Service Management-Prozesse auf der Basis der ITIL Best Practices ist ihre Ausrichtung auf die Geschäftsprozesse Ihres (internen oder externen) Kunden. Hierzu heißt es in „Best Practice für Service Support“ (vgl. [OGC, 2005b]): „ITIL richtet den Fokus auf die Bereitstellung qualitativ hochwertiger Services und unterstreicht insbesondere die Bedeutung von Kundenbeziehungen. Dies bedeutet, dass die IT-Organisation bereitstellen sollte, was immer mit dem Kunden vereinbart wurde, was wiederum eine enge Beziehung zwischen der IT-Organisation und deren Kunden und Partnern voraussetzt.“ Planen Sie die Einführung von „kundennahen“ IT Service ManagementProzessen (z. B. Service Level Management oder Financial Management for IT Services), sollten Sie vorab die Erwartungshaltung des Kunden in Erfahrung bringen. Sie müssen die Erwartungshaltung Ihres Kunden verstehen, um auf dieser Basis die Machbarkeit innerhalb der IT-Organisation zu prüfen und mit den möglichen Anforderungen abzugleichen. Im Idealfall sollten Sie in der Lage sein, sämtliche Kundenanforderungen an einen IT Service dort zu messen, wo der Kunde bzw. Anwender den IT
247
Den Kunden rechtzeitig einbinden.
6 Lessons learned: Empfehlungen und Ratschläge Service wahrnimmt. Dies ist in der Regel der Arbeitsplatz, und dieser Ansatz führt damit zu einer „end-to-end“ Messung des IT Service. Diese end-to-end Messungen können jedoch zurzeit in vielen Unternehmen noch nicht durchgeführt werden, da die notwendigen Werkzeuge fehlen. Die Implementierung dieser Werkzeuge ist in der Regel – in Abhängigkeit von den betrachteten IT Services und der genutzten IT-Infrastruktur – mit nicht unerheblichen Investitionen verbunden. Eine kunden- bzw. serviceorientierte Messung und ein entsprechendes Reporting, die Realisierung einer end-to-end Messung, sollte zumindest mittel- bis langfristig Ihr Ziel sein. Da dieses Ziel häufig nicht kurzfristig erreichbar ist, sollten Sie gemeinsam mit dem Kunden machbare Lösungen definieren.
Prüfen Sie zunächst, was zurzeit an Messungen und damit an verbindlichen Vereinbarungen überhaupt technisch darstellbar ist, statt im Vorfeld die Anforderungen des Kunden unstrukturiert einzufordern. Erst dann sollten Sie konkrete Vereinbarungen mit dem Kunden treffen. Der Prozess Manager sollte dies gemeinsam mit dem für den Kunden verantwortlichen Personenkreis durchführen. Je nach IT-Organisation kann dies mit dem Relationship Management, dem Key-Account-Manager oder dem KundenService Manager erfolgen. Oft wird diese Vorprüfung möglicher Service Level gemeinsam mit dem Kundenservicemanager und dem RelationshipManager, der den Kunden strategisch verantwortet, vorgenommen. Die innerhalb Ihrer IT-Organisation bestehenden Möglichkeiten zur Definition von Service Level und deren Messung sollten Sie dann gemeinsam Ihrem Kunden erläutern. Es besteht ansonsten die Gefahr, dass der Kunde einige von Ihnen nicht umsetzbare Anforderungen definiert, was in der Folge zu (vermeidbarer) Unzufriedenheit und Enttäuschung bei Ihrem Kunden führen würde. Gehen Sie daher mit einem ersten Vorschlag – was zurzeit technisch machbar ist – auf den Kunden zu. Ist dieser Vorschlag dem Kunden nicht ausreichend, so seien Sie offen für die Anforderungen Ihres Kunden. Zeigen Sie dem Kunden aber auch die damit für ihn ggf. verbundenen finanziellen Auswirkungen auf. In unserem Beispiel konnte durch die so erfolgte Abstimmung zwischen notwendigen Anforderungen aus Kundensicht und der technischen Machbarkeit innerhalb der IT-Organisation ein sinnvoller Kompromiss gefunden werden. Bei diesem Abstimmungsprozess muss der Prozess Manager selbstverständlich über die notwendige Verantwortung und Kompetenz für seinen Prozess verfügen. Er benötigt aber auch die Unterstützung des gesamten Managements, wie zum Beispiel des Key-Account-Managements.
248
6.4 Kennzahlen Sie sollten die IT Service Management-Prozesse schrittweise einführen. Dies betrifft sowohl die Anzahl der einzuführenden Prozesse, als auch den stufenweisen Ausbau (KVP). Dieses schrittweise Vorgehen bedingt eine Priorisierung der Einführung durch das Management. Ein Aspekt ist dabei der so genannte „Pain-Faktor“. Gibt es innerhalb Ihrer IT-Organisation in bestimmten Bereichen besonderen Handlungsdruck, so empfiehlt sich eine Priorisierung derjenigen IT Service Management-Prozesse, die hier Abhilfe schaffen können. Stellen Sie zum Beispiel fest, dass durchgeführte Änderungen häufig zu Betriebsstörungen geführt haben, so sollte der Change Management-Prozess priorisiert eingeführt werden. Ein weiterer wichtiger Aspekt für die Priorisierung von IT Service Management-Prozessen ist das Wissen um die Geschäftsstrategie Ihres Kunden. Sie müssen diese Strategie verstehen, um zu entscheiden, wie Sie ihre Prozessentfaltung vorantreiben, wie Sie die stufenweise Einführung und den Ausbau der IT Service Management-Prozesse planen. Befindet sich Ihr Unternehmen bzw. Ihr Kunde in einer Wachstumsphase, so würde sich die Priorisierung der Planungsprozesse (Service Delivery) und des Release Managements empfehlen. Denn damit stellen Sie sicher, dass die notwendigen Kapazitäten rechtzeitig bereitgestellt werden können und die Geschäftsprozesse nicht durch fehlende IT-Kapazitäten in Mitleidenschaft gezogen werden. Betreibt Ihr Unternehmen dagegen eine Kostendämpfungsstrategie, so bietet sich eine Konzentration auf das Problem und Change Management an. Durch das Problem Management identifizieren Sie die Ursachen von Störungen und können die Qualität der IT Services steigern. Die Anzahl von Störungen und Geschäftsausfällen wird abnehmen und Sie leisten einen Beitrag zur Kosteneinsparung. Betrachten Sie die Gründe für ITStörungen, so werden Sie unter Umständen feststellen, dass die Ursachen häufig in fehlerhaften Änderungen (Changes) liegen. Durch einen Change Management-Prozess steigern Sie nicht nur die Qualität, sondern reduzieren Aufwände für Folge-Maßnahmen und tragen so mit dem Change Management zu einer weiteren Kosteneinsparung bei. So wie die Geschäftsstrategie Ihres Kunden in die IT-Strategie einfließt, so beeinflusst die Geschäftsstrategie auch die Einführungsplanung Ihrer IT Service Management-Prozesse.
Auch wenn Sie über erste Kennziffern verfügen, sollten Sie ihrem Kunden keine technischen Kennziffern berichten.
249
Die Strategie des Kunden verstehen
6 Lessons learned: Empfehlungen und Ratschläge Das Reporting der Kennzahlen muss kundenorientiert erfolgen
Grundsätzlich besteht Ihre Verantwortung darin, Ihrem Kunden die vereinbarten Service Level zu berichten. Manchmal bewährt sich die Maxime, dieses Reporting in einer Sprache und Darstellung vorzunehmen, die der Kunde versteht, also in der Sprache des Kunden, nicht in der Sprache des Technikers. Statt zum Beispiel dem Kunden über die Anzahl von Incidents zu berichten, wird dargestellt, was für Folgen die wichtigsten Störungen hatten, welche Konsequenzen zum Beispiel ein Ausfall einzelner Standorte hatte und welche Verbesserungsmaßnahmen innerhalb der IT ergriffen wurden, um diese Ausfälle in Zukunft zu vermeiden. Speziell die Darstellung eingeleiteter Verbesserungsmaßnahmen ist für den Kunden von großer Bedeutung. Der Kunde ist zwar auch an der Historie interessiert, aber viel wichtiger ist ihm, dass die IT Verbesserungsmaßnahmen ergreift und die Ausfälle in Zukunft vermieden werden können. Als signifikanter Report reicht aus, dem Kunden einmal im Monat eine kleinere Powerpoint-Präsentation zur Verfügung zu stellen, die vor allem auf die Availability- und Performancekennzahlen eingeht – also das, was der Kunde direkt über die IT wahrnimmt. Zum Beispiel könnte der Report folgende Informationen enthalten: Im Monat März hatten wir am 12.3.2006 eine Störung in der Anwendung (xyz). Diese Störung wurde hervorgerufen durch einen Netzwerk-Change, der im Wechsel einer technischen Komponente zu einem Ausfall von 6.00 Uhr – 7.30 Uhr führte. Um dies zukünftig zu vermeiden, haben wir unseren Servicepartner angewiesen, eine weitere redundante Komponente im Falle eines Hardwarewechsels vor Ort verfügbar zu haben, um damit schneller eine Reparatur zu ermöglichen. Berichte zu den geleisteten IT Services und den Kennzahlen aus den IT Service Management-Prozessen müssen aus der Sicht und in der Sprache des Kunden erfolgen.
6.4.3
ITIL Refresh oder wie geht es weiter?
Nachdem Sie auf Basis der ITIL Best Practices Ihre IT Service Management-Prozesse gestaltet und eingeführt haben, bedarf es eines regelmäßigen Refresh. Dieser Refresh betrifft alle Beteiligten Ihrer IT-Organisation mit unterschiedlichen Ausprägungen und Inhalten. In diesem Abschnitt stellen wir die wichtigsten Aspekte gruppiert nach den beteiligten Bereichen vor.
250
6.4 Kennzahlen Falls Sie eine Zertifizierung Ihrer IT Service Management-Prozesse durchführen, wird von der Zertifizierungsorganisation auch geprüft, ob eine Aus- und Weiterbildungsplanung existiert und mögliche Defizite werden aufgezeigt. Das Top-Management, der Service Manager, die Prozess Owner und die Prozess Manager sollen beobachten, wie sich die Umsetzung der ITIL Best Practices im Unternehmen weiterentwickelt. Hierbei ist auch relevant, wie sich vergleichbare andere IT-Organisationen weiter entwickeln und wie sich diese Weiterentwicklung in Bezug auf Ihre Organisation darstellt.
Das Management hat die Weiterentwicklung zur Aufgabe
Die dokumentierten ITIL Best Practices unterliegen zwar einer stetigen Weiterentwicklung, aber diese geht erst mit einem Zeitverzug in die offiziellen Publikationen ein. Auf Kongressen, wie dem ITIL Forum oder dem Jahreskongress der itSMF Deutschland e.V., wird aktuell über Erfahrungen mit der Umsetzung der ITIL Best Practices und über in Unternehmen vollzogene Ausgestaltungen und Erweiterungen berichtet. Auf diesen Kongressen können Sie nicht nur aufnehmen, wo Ihre ITOrganisation in Bezug auf andere IT-Organisationen steht. Sie können Ideen aufnehmen und prüfen, ob diese Ideen auch für Ihre IT-Organisation eine Innovation darstellen und einen Mehrwert generieren können. Insbesondere für den Service Manager, den Prozess Owner und den Prozess Manager stellt dieser Informationsprozess eine wichtige Aufgabe dar. Es ist sehr wichtig, dass Sie sich mit den erreichten Maßnahmen nicht zufrieden geben. Sie müssen die Weiterentwicklung von ITIL und von anderen ITOrganisationen beobachten, andere Ansätze prüfen und mehrwertschaffendeKonzepte adaptieren.
In der Ebene der Mitarbeiter ist es von großer Bedeutung, dass neue Mitarbeiter über ITIL Know-how verfügen bzw. entsprechend geschult werden. Diese Schulung sollte in drei Teilen erfolgen: – Die Mitarbeiter benötigen zunächst einen Gesamtüberblick über die Ziele des IT Service Managements sowie aller Prozesse. Ansonsten werden die Mitarbeiter den Nutzen von ITIL nicht verstehen. Es empfiehlt sich diese Schulungen extern wahrnehmen zu lassen. Gegebenenfalls könnte dies auch von einem Service Manager mit entsprechender Schulungserfahrung übernommen werden. – Sind die theoretischen Aspekte bekannt, so sollten die Prozess Manager die Mitarbeiter in denjenigen Prozessen schulen, in denen diese eingebunden sind. Hierbei wird insbesondere geschult, wie die jeweiligen Prozesse innerhalb der jeweiligen Organisation des Unternehmens ihre Anwendung finden (von der Theorie zur Praxis).
251
Mitarbeiter müssen geschult werden
6 Lessons learned: Empfehlungen und Ratschläge – Sind die IT Service Management-Prozesse auf Basis der ITIL Best Practices eingeführt, so ist unbedingt darauf zu achten, dass es regelmäßige Nachschulungen für die geschulten Mitarbeiter gibt (Wissen erhalten und erweitern) und neue Mitarbeiter ebenfalls die Stufen des aufgesetzten ITIL Schulungsprozesses durchlaufen. Ein erfolgreiches IT Service Management bedingt, dass Ihre Mitarbeiter die Prozesse kennen und verstehen. Sie müssen sicherstellen, dass dieses Verständnis auch bei neuen Mitarbeitern ausreichend gegeben ist.
Sie werden wahrscheinlich feststellen müssen, dass die Prozesse nach der Implementierung und längerem Betrieb auf Mitarbeiter-Ebene „einschlafen“. Der bei der Einführung vorhandene Elan geht im Laufe der Zeit verloren. Die Aktivitäten erstarren in Routine. Dem Prozess Manager kommt hier eine weitere wichtige Aufgabe zu. Der Prozess Manager sorgt dafür, dass Prozesse gelebt werden
Der Prozess Manager muss Maßnahmen entwickeln, die ein Einschleifen der Prozesse verhindern. Hierzu können bestimmte Prozesse, wie das Change Management, angepasst werden. Der Prozess Manager muss einen Prozess aktiv halten und das Einschlafen verhindern. Besondere Aufmerksamkeit benötigen bereits länger eingeführte Prozesse.
Zerschlagen Sie nicht unnötig erfolgreiche Prozesse. Drücken Sie vielmehr ihre Wertschätzung aus und motivieren Sie ihre Mitarbeiter, diese Prozesse in Richtung der ITIL Best Practices weiter zu entwickeln. Nutzen Sie so die vorhandene Erfahrung. Stellen Sie sicher, dass die Prozesse innerhalb der Phasen gleichmäßig entwickelt werden (vertikale gleichmäßige Entfaltung) und dass sie vernetzt werden. Vermeiden Sie ein unkontrolliertes Davoneilen einzelner Prozesse. Diese Entwicklungen zu kontrollieren und zu steuern ist Aufgabe des Service Managers. Zeigen Sie die Erfolge der eingeführten Prozesse unbedingt auf. Lassen Sie Ihre Mitarbeiter die erzielten Verbesserungen im täglichen Betrieb spüren. Damit erhalten und steigern Sie die Motivation. Um dies möglich zu machen, sollten Sie Ruhe- und Stabilitätsphasen in der Entwicklung der Prozesse einplanen. Ansonsten können in einem permanenten Veränderungsprozess die Erfolge nicht mehr spürbar gemacht werden. Darüber hinaus fördert das Aufzeigen von Erfolgen in einem Prozess den Wettbewerb unter den Prozess Managern. Der Service Manager benötigt ein System zur Messung und Verfolgung der Prozess-Fortschritte. Im Beispiel hat sich hierzu ein Ampelsystem be-
252
6.4 Kennzahlen währt. Damit werden auch für die Prozess Manager die erzielten Erfolge sichtbar. Die IT Service Management-Prozesse haben eine eindeutige Ausrichtung auf die Geschäftsprozesse Ihres Kunden und müssen daher Bestandteil Ihrer IT-Strategie sein. Diese Anforderung bedeutet nicht nur, dass die IT Service ManagementProzesse aufgrund Ihrer IT-Strategie eingeführt werden, sondern auch, dass sich deren Ziele stets aus der IT-Strategie ableiten. Logische Konsequenz hieraus ist, dass sich auch die Kennzahlen und deren Soll-Werte aus der IT-Strategie ergeben. Um alle Bereiche auf die IT-Strategie auszurichten, sollten sie anfänglich eine einfache Balanced Scorecard (BSC) nutzen. Dazu werden aus den übergeordneten strategischen Betrachtungen konkrete Maßnahmen und Leistungen in den IT Service Management-Prozessen identifiziert und mit entsprechenden Kennzahlen hinterlegt. Die Ziele und Zielwerte (Soll-Werte) der IT Service Management-Prozesse leiten sich aus der IT-Strategie ab. Durch die Verknüpfung der Balanced Scorecard mit den Kennzahlen der jeweiligen IT Service ManagementProzesse etablieren Sie ein durchgängiges Controlling-System. Vermeiden Sie den Aufbau eines zweiten, isolierten Kennzahlensystems für Ihre IT Service Management-Prozesse.
Service Manager, Prozess Manager und Prozess Owner In den vorhergehenden Kapiteln wurde bereits auf die Rolle des Service Managers, des Prozess Managers und des Prozess Owners eingegangen. An dieser Stelle sei angemerkt, dass die Aufgabenzuordnungen zu den Rollen des Prozess Owners und des Prozess Managers von den Rollenbeschreibungen in der Literatur abweichen können. Oft können Prozess Owner und Prozess Manager organisatorisch über Kreuz besetzt werden – dass heißt, der Prozess Owner kommt aus einem anderen Bereich als der Prozess Manager – und so kann die Vernetzung innerhalb der IT-Organisation gestärkt werden. Bestehende Abteilungsgrenzen können erfolgreich überbrückt werden. Voraussetzung hierfür ist die Stärkung der Rolle des Prozess Managers, ansonsten dominiert der Prozess Owner allein aufgrund der hierarchischen Stellung den Prozess Manager.
253
Die Balanced Scorecard ermöglicht die Ausrichtung auf die ITStrategie
6 Lessons learned: Empfehlungen und Ratschläge
Service Manager In den ITIL Best Practices finden sich zwar an einigen Stellen Hinweise zum Service Manager, aber eine durchgängige Beschreibung dieser Rolle ist in ITIL nicht zu finden. Dabei ist diese Rolle für ein IT Service Management von existenzieller Bedeutung und damit auch die organisatorische Verankerung dieser Rolle. Die IT Service Management-Prozesse sollen sicherstellen, dass die IT Services auf die Geschäftsprozesse des Kunden ausgerichtet sind und deren Anforderungen optimal unterstützen. Daher bieten sich zwei Bereiche an, denen die Rolle des Service Manager organisatorisch zugeordnet werden kann. Zunächst wäre die Kundenschnittstelle der IT-Organisation zu nennen. Damit wird sichergestellt, dass die geforderte Ausrichtung der IT Service Management-Prozesse auf die Kundenanforderungen gewährleistet ist. Alternativ bietet sich eine Stabstelle zur IT-Geschäftsführung an. Hierfür sprechen die dann kurzen Wege zur Geschäftsführung und die enge Verknüpfung mit der IT-Strategie. Sie müssen für Ihre IT-Organisation entscheiden, welche Zuordnung für Ihren Bereich zweckmäßig ist. Der Service Manager muss unbedingt über eine langjährige Erfahrung im Bereich des IT Service Managements und mit dem Management von ITOrganisationen verfügen. Häufig ist der Service Manager im Bereich der Kundenschnittstelle angesiedelt und stimmt seine Planungen und Maßnahmen mit dem „Board der Prozess Owner“ ab.
Prozess Manager Der Prozess Manager sollte aus der Linienfunktion besetzt werden, in der wesentliche Prozessaktivitäten durchgeführt werden. Der Prozess Manager sollte weiterhin in der Linienorganisation angesiedelt bleiben und nicht herausgelöst werden, da ansonsten der Tagesbezug verloren geht. So ist zum Beispiel der Change Manager des Rechenzentrums innerhalb der Produktion angesiedelt. So ist sichergestellt, dass der Change Manager unmittelbar erfährt, wie erfolgreich die Implementierungen von Changes sind bzw. welche Auswirkungen auftreten. Damit ergibt sich auch die Anforderung, dass der Prozess Manager aus dem Bereich besetzt werden sollte, der über die meisten Erfahrungen mit dem jeweiligen Prozess verfügt.
254
6.4 Kennzahlen
Prozess Owner Innerhalb des RZs hat es sich als vorteilhaft erwiesen, die Rolle des Prozess Owners rotieren zu lassen. Durch die wechselnden Prozess Owner wird der Blickwinkel des Prozess Managers im Laufe der Zeit erweitert. Wenn möglich, wird die Rolle des Prozess Owners aus dem Bereich besetzt, der die größten Auswirkungen des Prozesses erfährt. So kommt zum Beispiel der Prozess Owner für das Change Management nicht aus der Produktion, sondern aus dem Kunden-Management, da dort die Auswirkungen der Changes unmittelbar zu spüren sind. Die Prozess Owner werden aus einer Hierarchieebene besetzt, die gegenüber der IT-Organisation weisungsbefugt ist. Innerhalb des Rechenzentrums unseres Beispiels sind die Prozess Owner Bereichs- und Abteilungsleiter, die direkt der Geschäftsführung berichten.
IT im Wandel und wie unterstützt ITIL Ein ständiger Abgleich Ihrer IT Service Management-Prozesse mit der Business- und der IT-Strategie ist unumgänglich. Sie müssen diese Strategien nicht nur während der Einführung berücksichtigen, sondern auch während der gesamten Prozessphase. Wurden die IT Service Management-Prozesse beispielsweise während einer Wachstumsphase eingeführt, dürfte die spezifische Ausrichtung des Capacity Managements darin bestehen, zukünftige Erweiterungen der ITInfrastruktur rechtzeitig einzuplanen, um das Wachstum der Organisation zu unterstützen. In einer Schrumpfungsphase wird das Hauptaugenmerk des Prozess Managers Capacity Management dagegen auf einer möglichst großen Auslastung bestehender Systeme bzw. auf der Reduzierung bestehender Systeme liegen, um so die notwendige Kostenreduzierung sicherzustellen. Die grundsätzlichen Ziele der IT Service Management-Prozesse bleiben bestehen, aber die konkrete Ausgestaltung und die Schwerpunkte sind stets aus der Business- und IT-Strategie abzuleiten. Die in den ITIL Best Practices dokumentierten Aktivitäten sind Empfehlungen, die Sie in Ihre IT-Organisation sinnvoll übertragen müssen. Damit sind diese Aktivitäten aber nicht für alle Zukunft festgeschrieben. Mit einer veränderten Business- und IT-Strategie können sich die Schwerpunkte und damit die Aktivitäten innerhalb der IT Service ManagementProzesse ändern. Ihre IT Service Management-Prozesse unterliegen damit einem stetigen Wandel. Beispiel: Hat ein Change Manager eine Vorlaufzeit von fünf Tagen für den RFC festgelegt, so muss dieser Ansatz unter Umständen modifiziert wer-
255
6 Lessons learned: Empfehlungen und Ratschläge den, wenn sich die Organisation in einer sehr starken Wachstumsphase befindet. Logische Konsequenz ist, dass die Business- und IT-Strategie einen Input für den kontinuierlichen Verbesserungsprozess der IT Service Management-Prozesse sind. Der Prozess Owner ist die Person, die diesen Input sicherstellt. Der Prozess Owner erfährt aufgrund seiner hierarchischen Stellung frühzeitig von Veränderungen in der Business- oder IT-Strategie. Er muss als Coach unter Einbeziehung des Service Managers den Prozess Manager auf die veränderten Rahmenbedingungen aufmerksam machen. Aufgabe des Prozess Managers ist es dann, notwendige Maßnahmen abzuleiten, sie mit dem Prozess Owner und dem Service Manager abzustimmen und schließlich im Prozess umzusetzen. Für die organisatorische Einbindung der IT Service Management-Prozesse ist die Besetzung des Prozess Managers von großer Bedeutung. Der Prozess Manager sollte aus der Linien-Organisation stammen und auch dort verbleiben. Als Bereich ist die Organisationseinheit zu wählen, in der die wesentlichen Aktivitäten des Prozesses stattfinden. Das Überkreuzen von Prozess Manager und Prozess Owner hat sich sehr bewährt. Dadurch konnte unter anderem eine bessere Vernetzung in der IT-Organisation erzielt werden. Ein wichtiger Nebeneffekt ist, dass der Prozess nicht durch Bereichsdenken geprägt wird. Diese Gefahr besteht, wenn Prozess Owner und Prozess Manager aus dem gleichen Bereich kommen. Die Rotation der Prozess Owner erweitert den Horizont der Prozess Manager. Sehr oft kommt dem Prozess Owner die Rolle eines Coaches zu.
256
7 Praxisbeispiel: ALTANA Pharma AG IT Service Management im regulierten Umfeld am Beispiel der ALTANA Pharma AG
Dr. Jan Hadenfeld IT Change und Configuration Manager ALTANA Pharma AG, ein Unternehmen der Nycomed Gruppe www.nycomed.com
Firmenportrait Nycomed ist ein internationales pharmazeutisches Unternehmen, das Arzneimittel für Krankenhäuser, Fachärzte und Allgemeinmediziner anbietet. Darüber hinaus versorgt das Unternehmen Patienten in ausgewählten Märkten mit OTC-Medikamenten. Nycomed arbeitet in einer Reihe von Therapiegebieten wie Kardiologie, Gastroenterologie, Osteoporose, Atemwegserkrankungen, Schmerztherapie und Gewebemanagement. Neue Produkte entstehen sowohl in der eigenen Forschung als auch in der Zusammenarbeit mit externen Partnern. Nycomed ist in etwa 50 Märkten weltweit präsent und engagiert sich in ganz Europa sowie in wachstumsstarken Märkten wie Lateinamerika, Russland/GUS und der asiatisch-pazifischen Region. Der im Privatbesitz befindliche Konzern verzeichnete 2006 einen Jahresumsatz von ca. 3,4 Milliarden € sowie ein bereinigtes EBITDA von 933,4 Millionen €. Weitere Informationen finden Sie unter www.nycomed.com
Ausgangslage Die IT der ALTANA Pharma hatte sich 2004 das Ziel gesetzt, sich vom IT Service Provider zum innovativen Business Enabler zu wandeln. Um dieses Ziel zu unterstützen und die angebotenen Services und Lösungen an den sich ändernden Geschäftsanforderungen und der globalen IT-Strategie des Unternehmens auszurichten, wurde das Betriebsmodell der IT an IS Lite von Gartner ausgerichtet.
257
7 Praxisbeispiel: ALTANA Pharma AG Gartner hat 1999 folgende vier Trends ausgemacht, die zu signifikanten Änderungen in der IT führen werden: – – – –
Trend 1: Prozessbasierendes Arbeiten Trend 2: Outsourcing Trend 3: Spezialisierung in Kompetenzzentren Trend 4: Einbeziehung der Applikationsentwicklung im Business
IS Lite, als Ergebnis dieser Trends, stellt eine flexible und erweiterbare Organisation zur Verfügung, um die unterschiedlichen Geschäftsanforderungen beherrschen zu können. Bei ALTANA Pharma waren hierzu strukturelle Änderungen in der ITOrganisation notwendig. Es wurde unter anderem das Global CIO Office aufgebaut und Abteilungen wie Project Management, Business Process Management, Architektur, Account Management und IT Service & Vendor Management dort etabliert.
IT Service Management im regulierten Umfeld Sauber definierte IT Service-Prozesse stellen einen professionellen ITBetrieb sicher. Ein professionelles Vendor Management ist Voraussetzung für eine erfolgreiche Beschaffung von IT Services, intern wie extern. Die Zielsetzungen des IT Service Management bei ALTANA Pharma, – Einführung einheitlicher, standardisierter IT Serviceprozesse, um die Qualität und Quantität der IT Services für den Kunden zu steuern, zu überwachen und sicherzustellen, sowie die – Ausrichtung der IT Services auf die Bedürfnisse der Kunden in den Fachbereichen und Standorten, haben ausdrücklich den Kunden und seine Zufriedenheit mit den erbrachten Dienstleistungen im Focus. Die Anforderungen der Kunden an einen IT Service sind oft zusätzlich durch Compliance-Vorgaben beschrieben. In dem sehr stark regulierten Bereich der Pharmaindustrie gibt es nationale und internationale Vorgaben, an die sich auch die ALTANA Pharma halten muss. Dazu zählen die Good x Practices (GxP) (x steht für Laboratory, Clinical oder Manufacturing), die 1978 von der amerikanischen Gesundheitsbehörde FDA (Food and Drug Administration) aufgestellt wurden, um die Sicherheit und Produktqualität von Medikamenten sicher zu stellen. Auch der Sarbanes-Oxley Act (SOX) mit seiner Sektion 404 stellt seit 2002 an die IT der ALTANA Pharma hohe Anforderungen, die von an USBörsen notierten Firmen erfüllt werden müssen.
258
7 Praxisbeispiel: ALTANA Pharma AG Hier haben sich sogenannte „Best Practices“ wie – Good Automated Manufacturing Practice (GAMP) – Control objectives for information and related technology (CobiT) – IT Infrastructure Library (ITIL) bewährt, um die IT bei der Erfüllung der genannten regulatorischen Vorgaben zu unterstützen. Auch wenn diese drei einen unterschiedlichen Focus haben, so sind doch viele Basisaktivitäten gleich. Um das IT Service & Vendor Management der ALTANA Pharma zu optimieren wurde das Projekt SMILE (Service Management ImpLEmentation) 2004 initiiert. Im Vordergrund stand dabei die Ausrichtung der IT-Prozesse nach ITIL. Damit verbunden war die Optimierung und Stabilisierung bestehender Prozesse, auch um größere Transparenz zu schaffen und eine Grundlage für die Messung von Kennzahlen zu ermöglichen. Das Projekt hatte Initial den Fokus auf die IT Service Support Prozesse und verfolgte die folgende Zielsetzung: – Erstellung eines ALTANA Pharma spezifischen Konzepts zum IT Service Management nach ITIL (bzgl. der betrachteten Disziplinen) – Aufbau eines Account Managements für interne Kunden der IT – Aufbau eines Service Level Management-Prozesses, insbesondere Einführung eines Leistungs- und Service Katalogs – Überarbeitung der Incident- und Problem Management-Prozesse sowie deren inhaltliche Trennung – Finetuning des Change Management-Prozesses sowie die Erstellung der Grobstruktur für eine Konfigurationsdatenbank – Definition eines Release Management-Prozesses Die Einführung der Prozesse nach ITIL wurde unterstützt, indem nahezu alle IT-Mitarbeiter und weitere wichtige Ansprechpartner aus den Fachbereichen von der Firma KESS DV-Beratung GmbH in ITIL geschult worden sind und erfolgreich mit dem Foundation Certificate in IT Service Management abschlossen. Neben dem Verständnis für die ITIL-Prozesse wurde so auch ein einheitlicher Sprachgebrauch gefördert. Um eine spätere Akzeptanz der Prozesse zu erzielen, wurden für jeden Prozess mit abteilungsübergreifenden Teams Workshops veranstaltet. Die Ergebnisse wurden, wie in einem Pharma-Unternehmen üblich, in Standard Operating Procedures (SOPs) festgehalten. Diese SOPs dienen auch als Schulungsunterlagen. Logische Konsequenz dieser Vorbereitungen war die Unterstützung der IT Service Management-Prozesse mit einem integrierten System, auch um Messungen der Prozessperformance zu ermöglichen. Bis auf das Incident
259
7 Praxisbeispiel: ALTANA Pharma AG Management war dies durch die teilweise papierbasierende Vorgehensweise nicht oder nur schlecht möglich. Das Folgeprojekt eSmile wurde initiiert.
eSmile: Einführung einer integrierten Systemunterstützung Die Zielsetzung des Projektes eSmile lässt sich in den folgenden Punkten zusammenfassen: – Integration aller betrachteten IT Service Management-Prozesse – Durchgängiger Informationsfluss und Transparenz – Etablierung der Configuration Management Database (CMDB) als zentrale Datenbank für alle Configuration Items (CIs) – Elektronische Autorisierung von Change Requests über ein Self Service-Portal – Vorbereitung auf den Roll-out in anderen Niederlassungen weltweit – eSmile als Integrationsplattform für alle externen und internen Dienstleister Gerade der letzte Punkt, dass eSmile von fast allen externen Dienstleistern verwendet wird, hat verschiedene Vorteile. Bei Neuausschreibungen von Service-Verträgen wurde diese System-Vorgabe deswegen mit in die Angebotsaufforderungen aufgenommen. Dadurch wird auch sichergestellt, dass die Verantwortung für das Prozess-Management im Hause liegt und durch eine gemeinsame Datenbasis die Prozess-Verantwortlichen ohne Medienbrüche Informationen und Kennzahlen über den gesamten Prozess erhalten. Das System wurde nach dem V-Modell validiert eingeführt. Das V-Modell ist eine im Pharma-Umfeld gängige Vorgehensweise. Es beschreibt Aktivitäten und Ergebnisse, die bei der Einführung von IT Systemen durchzuführen bzw. zu erzielen sind, und Bereiche wie Anforderungen, Umsetzung und Tests zur Qualitätssicherung beinhaltet. Validierung eines computergestützten Systems ist der dokumentierte Nachweis, dass das System den GxP-Anforderungen genügt und so arbeitet und in Zukunft arbeiten wird, wie es dies laut Spezifikationen soll. Nach der Validierungsfreigabe im April 2006 wurde die Produktivschaltung des Systems zweiphasig umgesetzt. In der ersten Phase kamen die Prozesse Problem, Change und Configuration Management zum Einsatz. Hier hat man sich erhofft, durch die Ablösung des papierbasierenden Change Managements mit einem System, in dem weltweit über einen webbasierenden Self Service elektronisch unterschrieben werden kann, einen Quick-Win zu erhalten. Dies hat sich bestätigt, da trotz der Verdoppelung der eingegangenen RfCs die Bearbeitung im Change Management handhabbar geblieben ist.
260
7 Praxisbeispiel: ALTANA Pharma AG In der zweiten Phase wurde kurz darauf das Incident Management mit dem Service Level Management aktiviert. Nach einer Eingewöhnungsphase kamen dann schnell die notwendigen Daten zustande, um ein aussagekräftiges Management Reporting zu beginnen und mit Kennzahlen die unterstützten Prozesse zu bewerten.
Ansatz für Kennzahlen und KPIs In der IT der ALTANA Pharma haben sich mit der Einführung der IT Service Management-Prozesse auch unterschiedliche Gremien etabliert. In diesen Gremien werden Kennzahlen zur Steuerung benötigt. Hierzu zählt das Incident-, Problem- und Change-Meeting (IPC-Meeting), das die Prozesse mit den internen Support-Einheiten bespricht. Es dient einer Verbesserung der Organisation der IPC-Bearbeitung (Organisatorisches Meeting, keine Diskussionsplattform), der Vermittlung des Status Quo an die Teamleiter, Ableitung von erforderlichen Maßnahmen sowie Nachverfolgung der beschlossenen Maßnahmen. Das Change Advisory Board (CAB) wie auch das Betriebsmeeting haben eine Schnittstelle zu den externen Providern. Gerade hier sind Kennzahlen wichtig. Einmal um die getroffenen Vereinbarungen zu überprüfen, aber auch, um Probleme zu identifizieren und gemeinsam Verbesserungen zu erarbeiten. Die Kennzahlen werden je nach Anforderung wöchentlich, 14-tägig und monatlich erhoben und zur Verfügung gestellt.
Incident Management Im Incident Management beziehen sich die erstellten Berichte überwiegend auf die mit dem externen Service Provider vereinbarten Service Level. Hauptaugenmerk wird auf den dorthin vergebenen Service Desk gelegt. Neben allgemeinen mengenorientierten Kennzahlen werden die folgenden berichtet: – – – – – – – –
Erreichbarkeit Longest Wait Call Wartezeit Direktlösungsrate Lösungsrate Erfüllungsgrad Weiterleitung Reset / Aktivierung von Passwörtern Account Administration
Dabei werden die Erreichbarkeit, Wartezeit und Longest Wait Call durch Auswertungen der Telefonanlage berechnet, alle anderen auf Basis des IT Service Management Systems eSmile. Durch eine direkte Datenbankanbin-
261
7 Praxisbeispiel: ALTANA Pharma AG dung werden die monatlichen Reporte teilweise auch automatisiert erzeugt.
Change Management Aus den genannten Gremien heraus wurden immer wieder Informationen über den Change Management-Prozess benötigt. Die Kennzahlen wurden meistens nach der „Bottom-up“ Methode erstellt, dort wo der „Schuh am meisten drückte“. Dies sind mengenorientierte Kennzahlen wie – Anzahl RfCs pro Kalenderwoche / Monat (siehe Abbildung 68) / Jahr / Workgroup / Priorisierung / Service 32 28 24
# of RfCs
20 16 12 8 4
07
7
20 ai M
A
pr il
20
20 0
07
7 M
är
z
r2
Fe
br
ua
ar nu Ja
be em D
ez
00
07 20
00 r2
r2 em
ov N
6
6 00
06 be
er kt ob O
be S
ep
te
m
ug A
20
00
6
r2
00
6 us
li 2
t2
00
6 ni Ju
Ju
20 0
06 20 ai M
Abbildung 68:
6
0
Anzahl der RfCs pro Monat (Demo-Daten)
um eine Auslastung der Supporteinheiten darzustellen, aber auch Kennzahlen, welche die Prozessqualität beschreiben können wie – Status aller RfCs (siehe Abbildung 69) pro Workgroup / Priorisierung / Service – Durchlaufzeiten der einzelnen Phasen (Initiierung, Prüfung, Genehmigung, Test, Implementierung, Abschluss) – Anzahl RfCs ohne Planungsdatum / ohne CIs / mit mehrmaligem Routing – Anzahl nicht implementierter RfCs, bei dem das vorgegeben Datum des Änderungsanforderers überschritten ist – Anzahl RfCs mit verknüpften Incidents oder Problems
262
7 Praxisbeispiel: ALTANA Pharma AG Rejected
New Assessed Authorized Developm ent Com pleted Release to Production Technically Completed User Acceptance
New 4 2,2% Ass ess ed 1 0,6% Authorized 6 3,3% Developm ent C om pleted 1 0,6% Releas e to Production 6 3,3% Tec hnic ally Com pleted 3 1,7% Us er Ac ceptanc e 3 1,7% Finished 132 72,9% Rejected 25 13,8% Summ e: 181 100,0%
Finished
Abbildung 69:
Status aller RfCs (Demo-Daten)
Eine Darstellung für die Qualität der erbrachten Leistungen durch einen Change wird durch die – Auswertung des Post Implementation Review (PIR) ermöglicht, in dem neben der technischen Umsetzung auch die Zufriedenheit des Kunden abgefragt wird. Ein auch in der ITIL-Literatur beschriebenes Thema ist der Audit. Ähnlich werden Systeme und Verfahren auch im GxP- und SOX-Umfeld auditiert. Hier ist als Kennzahl die – Anzahl und Reduzierung der Findings pro Kategorie (Critical, Major, Minor) wichtig.
Ausblick Während der Erarbeitung der für ALTANA Pharma angepassten IT Service Management-Prozesse nach ITIL wurden für jeden Prozess auch die Prozessziele angegeben. Durch den Change Management-Prozess wird beispielsweise sichergestellt, dass alle Änderungen an den IT-Systemen – notwendig, begründet und getestet sind, – dokumentiert sind, – hinsichtlich Abhängigkeiten der betroffenen Schnittstellen überprüft sind, – auf Basis einer nachvollziehbaren Ressourcenplanung durchgeführt werden, – eine transparente Darstellung von Kosten zu Nutzen haben und – gegenüber den Anwendern, der Hotline und anderen betroffenen Funktionen kommuniziert werden.
263
7 Praxisbeispiel: ALTANA Pharma AG Durch die Etablierung des Change Management-Verfahrens wird den Validierungsanforderungen bezüglich der Änderungskontrolle nachgekommen. Ein nächster Schritt wird sein, diese Prozessziele als Ansatz zu nehmen und „Top-down“ die entsprechenden Kennzahlen und KPIs zu ermitteln und zuzuordnen. Hier werden Informationen wie der Forward Schedule of Changes (FSC) stärker betrachtet werden, da dies ein wichtiges Instrument ist, um eine Planungssicherheit zu haben und frühzeitig über Änderungen informieren zu können.
264
8 Praxisbeispiel: Autobahn Tank & Rast GmbH
IT Kennzahlensystem der Autobahn Tank & Rast GmbH
Gerhard Göttert Leiter Technologie- und Innovationsmanagement Autobahn Tank & Rast GmbH www.tank.rast.de
Dienstleister Nr. 1 auf deutschen Autobahnen Die Autobahn Tank & Rast ist der führende Anbieter von Services und Dienstleistungen entlang der Autobahn in Deutschland: Rund 500 Millionen Gäste besuchen jedes Jahr die Servicebetriebe der Tank & Rast. Mit seinen Pächtern betreibt das Unternehmen rund 340 Tankstellen und rund 370 Raststätten (einschließlich ca. 50 Hotels). Durchschnittlich alle 60 Autobahnkilometer finden Kunden eine Tank- und Raststätte des Unternehmens.
Autobahn Tank & Rast: Auftanken und Abschalten 1998 hervorgegangen aus einer bundeseigenen Gesellschaft, hat sich das Unternehmen mit seinen rund 720 Servicebetrieben zu einem Dienstleister entwickelt, der in Kundenbefragungen ein Höchstmaß an Anerkennung genießt. Tankstellen, Raststätten und zahlreiche Shops stehen den Autobahn-Reisenden sieben Tage die Woche rund um die Uhr zur Verfügung. Bestnoten vor allem in der Wertung Gastronomie und Service in europaweit durchgeführten Tests des ADAC bestätigen immer wieder die Leistungen der Tank & Rast.
Gründe für die Entwicklung eines IT Kennzahlensystems Die Entwicklung der T&R wird von einer Vielzahl technologischer Projekte begleitet. Wesentlichen Einfluss auf den Projekterfolg haben dabei die benötigten IT-Services. Die Herausforderungen für das IT-Management sind, die verfügbaren Ressourcen und Mittel effektiv und effizient einzusetzen. Dabei stehen Flexibilität, Innovationsstärke und Wirtschaft-
265
8 Praxisbeispiel: Autobahn Tank & Rast GmbH lichkeit im Focus der mittel- und langfristigen Ziele. Um dies zu gewährleisten wurde ein IT-Kennzahlensystem entwickelt, dass die Steuerung des IT-Bereichs nach den genannten Kriterien ermöglicht und gleichzeitig eine hohe Transparenz der Prozesse und der Leistungsfähigkeit sicherstellt.
Entwicklung eines eigenen IT Kennzahlensystems Die Entwicklung eines IT-Kennzahlensystems ist ein nicht unerhebliches Unterfangen. Dies war dem IT-Management bereits zum Start des Projekts bewusst. Neben der Nutzung des Kennzahlensystems als strategisches Instrument zur Steuerung und Entwicklung des IT-Bereichs, verfolgt das IT-Management auch den Ansatz, das Kennzahlensystem, zumindest teilweise, zur operativen Steuerung des IT-Bereichs zu nutzen. Um größtmöglichen Nutzen zu gewährleisten muss jedes IT-Kennzahlensystem auf die individuellen Anforderungen eines Unternehmens abgestimmt sein. Es ist deshalb nicht sinnvoll, Kennzahlensysteme wie z. B. das Diebold- oder das Brogli-Kennzahlensystem einfach eins zu eins in das Reporting eines Unternehmens zu übernehmen. In Zusammenarbeit mit der Victor GmbH, Bonn, hat Tank & Rast deshalb ein Kennzahlenkonzept entwickelt, dass explizit auf die Anforderungen des Unternehmens abgestimmt ist. Dieses Konzept wurde im weiteren Verlauf des Projekts gemeinsam mit der Victor GmbH erfolgreich umgesetzt und implementiert. Die Umsetzung des Projekts erfolgte in folgenden Schritten: – Im ersten Step wurden Interviews mit IT-Mitarbeitern aus ausgewählten IT-Serviceeinheiten geführt. In diesem Kreis erfolgte eine Bestandsaufnahme der vorhandenen IT-Kennzahlen und die Relevanz der einzelnen Kennzahlen für die jeweiligen IT-Serviceeinheiten wurde diskutiert. Dabei stellte die Victor GmbH Kennzahlen aus verschiedenen Kennzahlensystemen, teilweise aus den klassischen aber auch aus neueren Systemen (COBIT) zur Diskussion. – Im weiteren Verlauf erfolgten zwei Interviews mit der IT-Leitung. Ziel war die finale Festlegung des zuvor erarbeiteten IT Kennzahlen-Pools. Es wurde für jede Kennzahl geprüft, welchen Mehrwert sie isoliert oder im Verbund weiterer Dimensionen aufweist, für wen sie bestimmt ist, wer für sie verantwortlich ist und wie und wie oft sie gemessen wird. Zur Sicherstellung des strategischen Ziels des neuen Kennzahlensystems, wurde bereits zu diesem Zeitpunkt der Controlling-Bereich der Tank & Rast in das Projekt eingebunden.
266
8 Praxisbeispiel: Autobahn Tank & Rast GmbH – Das Ergebnis war eine Tabelle mit ca. 35 Kennzahlen, die für die IT der Tank & Rast strategisch und operativ relevant sind.
Strukturierung der Kennzahlen anhand der Balanced Scorecard Tank & Rast verfolgte bereits zu Begin des Projekts das Ziel, eine IT Balanced Scorecard zur Steuerung der IT einzusetzen. Eine Herausforderung bestand darin, festzulegen, welche Perspektiven diese BSC haben sollte. Die operative und strategische Nutzung des IT-Kennzahlensystems setzt eine vernünftige Clusterung in valide und zuverlässige Dimensionen des Systems voraus. Diese müssen mit einer sinnvollen Anzahl von Kennzahlen ausgebildet sein. Für das Kennzahlensystem der Tank & Rast wurden folgende Dimensionen auf der obersten Ebene erarbeitet: – – – –
Finanzdimension Kundendimension Technologie-/Innovationsdimension und die Mitarbeiterdimension.
Jede der Dimensionen beinhaltet 4 bis 6 Kennzahlen.
Erfahrungen und Ratschläge Mitte 2006 hat Tank & Rast damit begonnen, das IT-Kennzahlensystem zu entwickeln. Innerhalb weniger Monate konnten das notwendige Reporting aufgebaut und in das Berichtswesen der IT integriert werden. Die frühe Einbindung des Unternehmenscontrollings hat sich als sehr sinnvoll und zielführend herausgestellt. Durch die Mitarbeit fand eine Sensibilisierung der Mitarbeiter des Controllings für die IT-Besonderheiten statt. Zudem konnten die Projektbeteiligten beim Aufbau des strategischen Berichtswesens umfassend vom Know-how der Controlling-Mitarbeiter partizipieren. Die fachliche Unterstützung durch die Victor GmbH hat dazu geführt, das Projekt in kurzer Zeit umzusetzen. Die Auswahl der für Tank & Rast sinnvollen Kennzahlen aus den vielen möglichen Werten der bekannten Kennzahlensysteme war eine der wesentlichen Aufgaben der Victor GmbH. Dabei bildeten international anerkannte Kennzahlensysteme die Basis des Auswahlprozesses. Zusätzlich wurde Tank & Rast durch Victor GmbH bei der Einbindung der neuen IT-BSC in die bereits vorhandenen ITILProzesse, insbesondere den Prozess des Service-Level-Managements, unterstützt. Das IT Kennzahlensystem liefert heute verlässliche und zeitnahe Daten. Neben der effizienten Steuerung der IT mit der IT-BSC wurde die Basis geschaffen, die strategische Entwicklung des IT-Bereichs transparent darzustellen.
267
9 Praxisbeispiel: Flughafen München Service Management des Flughafens München
Michael Zaddach Leiter Servicebereich IT Flughafen München GmbH www.munich-airport.de
Zum Autor Michael Zaddach ist Leiter des Servicebereichs IT bei der Flughafen München GmbH. In seinen Verantwortungsbereich fallen die Servicefelder Projekte und Entwicklung, sowie Betrieb & Service und Field-Services für alle IT- und Kommunikationssysteme am Flughafen. Nach dem Abschluss des Studiums der Nachrichtentechnik war M. Zaddach bei Siemens, AEG und debis Systemhaus in verschiedenen Funktionen wie zum Beispiel Systementwicklung, Product-Line-Management, Projektmanagement und Consulting tätig. Bei debis Systemhaus leitete er von 1997 – 2000 eine Business Unit für IT Service Management. In dieser Funktion begleitete er auch viele Outsourcing-Vorhaben von debis Systemhaus. Im Jahr 2000 übernahm er die Leitung der Hauptabteilung Informatik und Kommunikation am Flughafen München.
Firmenportrait Am 22. Dezember 2006 hat der Flughafen München den 30-millionsten Passagier des Jahres 2006 begrüßt und damit den Grundstein für eine dauerhafte Präsenz Münchens unter den großen Luftverkehrsdrehscheiben Europas gelegt. Die Planung für das Jahr 2007 ist ebenso ambitioniert und geht von 32,5 Mio. Passagieren aus. Die Erfolgsstory des Münchner Flughafens, die den letzten Höhepunkt im Jahr 2003 mit der Eröffnung des neuen Terminal 2 hatte, geht damit in die nächste Runde. Die Planer arbeiten bereits wieder an neuen Infrastrukturprojekten und reagieren damit auf die weiterhin überproportionalen Steigerungsraten bei Passagieren, Flugbewegungen und beim Frachtaufkom-
269
9 Praxisbeispiel: Flughafen München men. Im Jahr 2007 beginnen die Arbeiten an einem neuen Speditionsgebäude und einem weiteren Hotel. Die Planungen zum Bau einer dritten Start- und Landebahn laufen seit 2005. Die Flughafen München GmbH rechnet mit der Inbetriebnahme im Jahr 2012. Im Eröffnungsjahr werden für den Flughafen München ca. 40 Millionen Passagiere prognostiziert. Der Münchner Flughafen verfügt dann über drei Bahnen mit jeweils 4000 Meter Länge und kann damit die aus dem weiteren Ausbau des Drehkreuzes erwarteten Verkehrssteigerungen bewältigen. Der Erfolg des Münchner Flughafens als Drehkreuz des Südens liegt nicht zuletzt in der starken Verzahnung der Flughafen-Kernprozesse mit unterstützenden IT-Lösungen. So kann dank effizientem IT-Einsatz im Terminal 2 eine kürzeste Umsteigezeit von nur 30 Minuten garantiert werden. Um diesen Wert einhalten zu können, werden Passagier- und Gepäckströme sowie die Umsteigebeziehungen der Passagiere und Crews laufend überwacht und gesteuert. Dazu wurde gemeinsam mit dem Home-Carrier Lufthansa eine interdisziplinäre und unternehmensübergreifende Kontrollzentrale, das HCC (Hub-Control-Center) eingerichtet. Dort laufen alle abfertigungsrelevanten Informationen zusammen und werden über individuelle prozessunterstützende Systeme angezeigt und verarbeitet. So kann frühzeitig auf Abweichungen in den Hub-Prozessen reagiert werden. Verspätungen im Flugzeugumlauf durch Probleme in der HubKoordination werden so auf ein Minimum reduziert. Neben dem Flugbetrieb spielt aber auch das so genannte Non-AviationBusiness eine immer größere Rolle. Mit der Vermietung, Verpachtung, Retail-Business, Gastronomie und dem Parken generiert der Airport heute bereits fast die Hälfte seines Gesamtumsatzes.
Der Servicebereich IT Der Servicebereich IT des Flughafens versteht sich nicht nur als ICT-Provider für die Flughafengesellschaft, sondern auch für die weiteren am Flughafen ansässigen Unternehmen. So zählen heute über 500 Firmen, wie zum Beispiel Airlines, Speditionen, Behörden und viele weitere Dienstleistungsunternehmen zu den Kunden des Servicebereichs. Die Forderungen nach Qualität und der professionellen Abwicklung der Leistungen bekommen dadurch nochmals einen höheren Stellenwert. Mit 180 Mitarbeitern erwirtschaftet der Servicebereich IT einen Gesamtumsatz von ca. 42 Millionen Euro. Ein Drittel dieser Leistung wird dabei mit Kunden außerhalb der Flughafengesellschaft generiert.
270
9 Praxisbeispiel: Flughafen München Der Servicebereich IT des Flughafens München stellt die IT Services auch für externe Kunden mit wachsendem Anteil bereit.
Die Organisation des Servicebereichs IT gliedert sich in drei Servicefelder und drei Unterstützungsbereiche, wie im folgenden Bild dargestellt. Servicebereich IT
Projekte und Entwicklung ITE
Operation & Service ITO
• ITEA - AS Aviation • ITEG - AS GroundHandling
• ITOS - Systems Management
• Schichtleiter 1
• ITOP - Plattforms
• Schichtleiter 3
• ITET - AS Technik
• ITOC - Communications
• ITEP - AS Personal
• ITOR - Rollout Management
• ITES - SAP-CCC und AS Rechnungsw.
Field Service ITF
Interne Services ITS
Controlling & Sales ITK
• Schichtleiter 2
• ITOI - Internal Services
• ITEV - AS Vertrieb • ITED - CC-Anwendungsentwicklung • ITEC - CC Basistools
Abbildung 70:
Organisationsstruktur Flughafen München, Servicebereich IT
Zu den Leistungen gehört neben dem Betrieb und dem Service für die eingesetzten Systeme auch die Entwicklung und Implementierung von flughafenspezifischen Applikationen. Die Mengenangaben zu den betriebenen Systemen sind der folgenden Aufstellung zu entnehmen. – – – – – – – –
Betriebene PCs Aktive LAN-Anschlüsse Telefone FIDS Displays CCTV-Kameras Zentrale Server Speicherkapazität (brutto) Applikationen
ca. 2.500 ca. 12.000 12.500 2.400 ca. 1.700 240 > 100 TB ca. 420
271
CIM ITC
9 Praxisbeispiel: Flughafen München Sämtliche Leistungen werden den internen, wie auch den externen Kunden als Full-Services verkauft.
Der Servicebereich steht dabei ständig unter dem Druck, die angebotenen Leistungen zu marktüblichen Preisen anzubieten und muss die Marktfähigkeit über entsprechende Benchmarks nachweisen. Andererseits haben die vereinbarten IT Services häufig hohe Auswirkungen auf die Geschäftsprozesse und die Services der internen und externen Kunden. Daher muss die Servicequalität auf einem sehr hohen Niveau sichergestellt und nachgewiesen werden. Speziell die reibungslose Abwicklung der "just in time" Abfertigungsprozesse am Flughafen verlangt diese hohe Qualität und Stabilität der Leistungen. "Eine hohe Servicequalität zu möglichst geringen Kosten zu erbringen ist die Zielsetzung des Servicebereichs IT.“
Implementierung des Service Managements Zielsetzung des Service Managements Damit der Flughafen München auch den zukünftigen Anforderungen gerecht werden kann und die erzielten Ergebnisse verbessert werden können, wurden ausgehend von den Unternehmenszielen und der Unternehmensstrategie des Flughafens München die IT-Ziele definiert und dementsprechende Umsetzungsmaßnahmen erarbeitet.
272
9 Praxisbeispiel: Flughafen München
Ergebnis
Frage
Zielsetzung FMG
Wie kann die FMG in Zukunft im Wettbewerb wirtschaftlich bestehen ?
Ideenfindung
Mit welchen Mitteln können wir das gesteckte Ziel erreichen ?
• Strategische FMG-weit 1000 Neuausrichtung Ideen aus • ErgebnisverWorkshops besserung • Neue Organisation
Abbildung 71:
Zielsetzung IT
Maßnahmen IT
Umsetzung
Welche Zielsetzung ergibt sich für den Bereich IT ?
Welche konkreten Maßnahmen sind zur Zielerreichung erforderlich ?
Wie erfolgt die Umsetzung ?
Effizienzsteigerung und Generierung zusätzlicher Erlöse zur nachhaltigen Senkung der ITKosten um 10% im Konzern
13 Umsetzungsmaßnahmen zur Senkung der
• Effizienzsteigerung in den ServiceProzessen • Verbesserung der Projektabwicklung • Systemkonsolidierung • Stärkung des Vertriebs
• Kapitalkosten • Fremdleistungen • Personalkosten und Erhöhung der Marktdurchdringung
Von den Unternehmenszielen zu der Umsetzung in der IT
Zur Effizienzsteigerung wurde ein umfangreiches Optimierungsprogramm durchgeführt, das unter anderem eine Reorganisation des IT-Bereichs und die Implementierung des Service Managements beinhaltete. Die Implementierung des IT Service Management war kein Selbstzweck, sondern ergab sich als Umsetzungsmaßnahme aus der Unternehmensstrategie des Flughafens München.
Um eine durchgängig hohe Servicequalität zu niedrigen Kosten anbieten zu können, hatte der Servicebereich IT in den letzten Jahren bereits umfangreiche Maßnahmen zur Optimierung der IT Serviceprozesse durchgeführt. Die Ziele waren dabei klar gesteckt. Steigerung der Effizienz in den Serviceprozessen und die Konsolidierung von Systemen auf gemeinsamen technischen Plattformen. In der Konsequenz bedeutete diese Optimierung auch für die Organisation und die Mitarbeiter des Servicebereichs eine gravierende Veränderung. So wurde die Organisation von der rein systemorientierten auf eine prozessorientierte Struktur umgestellt, ein 90Grad-Schwenk in der Organisation und in den Köpfen aller Beteiligten.
273
9 Praxisbeispiel: Flughafen München
Abbildung 72:
Prozessorientierte Sicht des Servicebereichs IT
Der Abschied von den Technik-Silos Die Organisationsänderung war dabei kein Selbstzweck, sondern die logische Folge der Konvergenz in der eingesetzten Systemtechnik. Früher gab es zum Beispiel für Anzeigesysteme, Videoüberwachung und die Datenkommunikation vollständig unterschiedliche und voneinander getrennte Systemlandschaften. Heute wachsen diese Welten technisch zusammen. Die Kommunikation der Systeme wird zukünftig einheitlich über das flughafenweite MPLS-Netz abgewickelt. Die Individualität der Systeme zeigt sich nur noch in den eingesetzten Endgeräten und in den verwendeten Applikationen auf Client- und Serversystemen. Eine sehr weit reichende Standardisierung der verwendeten Systemkomponenten ist möglich und wird konsequent durchgeführt. Dies führt zu erheblichen Kostensenkungen beim Einkauf der IT-Infrastruktur, die dann meist nur noch aus Standardkomponenten besteht. Spezialwissen für das Engineering, die Betreuung und den Betrieb von "Silo-Technik" ist in Zukunft immer weniger erforderlich. Die Verfolgung dieser Strategie der konsequenten Standardisierung und Konvergenz bedingt natürlich die Übernahme des Integrationsrisikos und erfordert die entsprechende Integrationskompetenz. Die beteiligten Mitarbeiter müssen sich also von Silo-Spezialisten zu Integrations-Spezialisten entwickeln. Das Wissen in der Breite und die guten Kenntnisse der Standards werden wichtiger als das extrem tiefe Spezialisten-Know-how für individuelle Systeme.
274
9 Praxisbeispiel: Flughafen München Die Abkehr von den Silo-Systemen bietet enorme Chancen in der effizienteren Gestaltung der Serviceprozesse. Während früher zum Beispiel die Bereiche Telekommunikation (TK), Anzeigesysteme (FIDS), Videoüberwachung, Office-Systeme und Netzwerk eine eigene Auftragsannahme und eigenes Störmanagement unterhielten, werden in der neuen Struktur alle Aufträge und Störungen vom zentralen Service Desk angenommen und durchgängig bearbeitet. Auch beim Betrieb und bei den Field-Services können erhebliche Synergien erschlossen werden. Die Konvergenz der Systeme und die Konzentration auf standardisierte Plattformen werden damit in der Organisationsstruktur nachvollzogen. Voraussetzung für einen reibungslosen und effizienten Ablauf in der neuen Organisation sind dokumentierte und kommunizierte Prozesse.
Und weiterhin erfordert dieser Transformationsprozess für eine zeitgerechte Umsetzung eine klare Definition des angestrebten Zielzustands und einen Endtermin, auf den alle Beteiligten gemeinsam hinarbeiten.
Das Prozessmodell und die Verantwortlichkeiten Die strategische Ausrichtung der Prozesse Die Prozessziele werden in regelmäßigen Planungsrunden aus der Strategie abgeleitet und definiert. Durch die Einhaltung der Prozesse ist sichergestellt, dass von der Führungs- bis zur Mitarbeiterebene die IT-Strategie einheitlich verstanden und deren Umsetzung unterstützt wird. Die Service Management-Prozesse verbinden die langfristige Ausrichtung des Servicebereichs IT mit der kurzfristigen Zieldefinition und -verfolgung.
275
9 Praxisbeispiel: Flughafen München Strategische Grundausrichtung Strategieklausur
langfristig (3 – 5 Jahre) Kunde
Prozess
Finanz
Mitarbeite r.
jährlich
Strategieelemente langfristig (3 – 5 Jahre) Kunde
Prozess
Kunde
P rozess
Finanz
Mitarbeite r.
Finanz
Mitarbeiter .
Strategische Initiativen
Ziele (Führungskräfte)
mittelfristig (1 - 3 Jahre)
Maßnahmenpläne
kurzfristig (1 Jahr) bezogen auf Meilensteine der Initiativen
Ziele (Mitarbeiter)
kurzfristig (1 Jahr)
Abbildung 73:
Quartalsreview
Projektmonitoring, Mitarbeitergespräche
kurzfristig (1 Jahr)
Ausrichtung der Prozesse an der IT-Strategie
Skill-Management und Soft Factors In einem Unternehmen mit einer etablierten IT und akzeptierter Qualität sind die Implementierung von ITIL-Prozessen und die Zertifizierung nach ISO 20000 nicht ohne weiteres einzusehen. Dies gilt sowohl für die Mitarbeiter des IT-Bereichs, als auch für die Kunden. Es werden immer wieder Fragen gestellt, wie zum Beispiel: "... was haben wir denn falsch gemacht, dass nun alles geändert wird?", oder "... wer soll denn die Zusatzkosten für diesen ganzen Overhead zahlen?". Die besondere Herausforderung liegt an dieser Stelle sicherlich darin, von Beginn der Planungen an die Mitarbeiter intensiv an dem Prozess zu beteiligen und immer wieder Erfordernisse, angestrebte Ziele und die Verbesserungspotenziale zu verdeutlichen. Aus diesem Grund wurde bereits zu Beginn des Projekts ein Team aus 15 Mitarbeitern – den späteren Prozess Ownern – eingesetzt. Gemeinsam wurden die Vorgaben und Rahmenbedingungen festgelegt und vom Groben ins Feine entwickelt. Schnittstellen wurden diskutiert und beleuchtet und in ihrem bürokratischen Aufwand reduziert. Die Mitarbeiter wurden dabei extern begleitet und unterstützt. Aber für die Entwicklung waren die Mitarbeiter des Servicebereichs IT verantwortlich, der externe Dienstleiter nahm die Rolle eines Coachs ein und war für den notwendigen Wissenstransfer verantwortlich. Der folgenden Abbildung können die im Servicebereich IT implementierten Service Management-Prozesse entnommen werden.
276
9 Praxisbeispiel: Flughafen München
Abbildung 74:
Die Prozesslandkarte des Servicebereichs IT
Für die Definition und Beschreibung der Prozesse wurde das folgende Vorgehen definiert: – – – – –
Prozesse werden generisch gestaltet Rollen und Verantwortlichkeiten werden festgelegt Verzahnung der Prozesse über Schnittstellen Über ein Kennzahlensystem erfolgt die Messung der Prozesse Die Ergebnisse der Prozesssteuerung fließen in einen kontinuierlichen Verbesserungsprozess ein
Die Vorgehensweise zur Inbetriebnahme der Prozesse erfolgte wie folgt: – Erarbeitung der Prozesse gemäß Vorgaben – Freigabe der Prozessdokumentation durch den IT-Qualitätsbeauftragten – Veröffentlichung der Prozesse im ITSM-Portal im Intranet – Ausbildung der Mitarbeiter – Leben der Prozesse – Internes Audit als Vorbereitung auf die Zertifizierung – Externes Audit mit der Zertifizierung gemäß ISO 20000
277
9 Praxisbeispiel: Flughafen München Die Prozesse wurden vom Projektteam so dokumentiert, dass sie die tägliche Arbeit der Mitarbeiter unterstützten, aber wann immer sinnvoll trotzdem eigenverantwortliche Handlungsspielräume zulassen und vor allem die Kompetenz der Mitarbeiter berücksichtigen. Die Grundsätze der Transparenz, Wirtschaftlichkeit und Zielstrebigkeit im Sinne des Kunden standen dabei immer im Mittelpunkt. Vorgabe der Prozessentwicklung war es, nicht in einen „ARIS Rausch“ zu verfallen, sondern einerseits so viel Prozessdokumentation wie nötig zu erstellen, andererseits aber so viel Eigenständigkeit und Serviceorientierung wie möglich zuzulassen. Die zu implementierenden Prozesse und deren Dokumentation sollten als Leitplanken verstanden werden, die den Mitarbeitern die notwendige Sicherheit und Entscheidungskompetenz geben, aber den Handlungsspielraum nicht unnötig einengen sollen. Der Servicebereich IT wird auch weiterhin von der Leistungsbereitschaft und Serviceorientierung der Mitarbeiter getragen.
Die Prozessdurchführung und der kontinuierliche Verbesserungsprozess Alle Mitarbeiter des Servicebereichs IT haben einen Zugriff auf das ITSMPortal und können über dieses Portal auf die Prozessdokumentation, Arbeitsanweisungen, Templates und weitere unterstützende Dokumentation zugreifen (siehe Abbildung 75). Den Mitarbeitern des Servicebereichs IT wurde im Rahmen der Trainings und Einweisungen verdeutlicht, dass sie - wenn nötig - auch vom vorgegebenen Prozess abweichen dürfen. Dann besteht allerdings die Verpflichtung zu erläutern, warum die abweichende Durchführung notwendig war und zu definieren, wie der Prozess zukünftig entsprechend anzupassen ist. Dieses Feedback aus der praktischen Prozessdurchführung ist ein wichtiger Input in den kontinuierlichen Verbesserungsprozess (Prozess Improvement Plan).
278
9 Praxisbeispiel: Flughafen München
Abbildung 75:
Das ITSM-Portal des Servicebereichs IT
Trainings Um die Mitarbeiter in die Lage zu versetzen, die ITIL Prozessanforderungen auf den Servicebereich IT zu adaptieren, galt es in einer ersten Trainingsphase den Prozess Ownern und deren Mitarbeiter die notwendigen ITIL Best Practices zu vermitteln. Prozesse können nur dann erfolgreich implementiert werden, wenn die beteiligten Mitarbeiter die Notwendigkeit dieser Prozesse, deren Aktivitä-
279
9 Praxisbeispiel: Flughafen München ten, Abhängigkeiten und Schnittstellen verstehen. In einer zweiten Phase wurden hierzu alle Mitarbeiter des Servicebereichs ausgebildet. Für die Durchführung dieser Trainings war es wichtig, dass die Dozenten nicht nur über das theoretische Know-how verfügten, sondern auch praktische Umsetzungsbeispiele vermitteln konnten. Das Trainingsprogramm für die Mitarbeiter des Servicebereichs IT hatte den folgenden Umfang: -
-
-
ITIL-Foundation Trainings für alle Mitarbeiter des Servicebereichs mit abschließender Prüfung, durchgeführt vom beratenden Unternehmen Prozesstrainings für alle Prozess Manager und die weiteren betroffenen Mitarbeiter mit dem Ziel, ein einheitliches Verständnis für die implementierten Prozesse zu erreichen, durchgeführt von den Prozess Ownern ITSM-Praxistrainings mit Fallbeispielen und Toolnutzung für die Prozesse Incident-, Problem- und Change-Management , durchgeführt von den Prozess Ownern und Prozess Managern
Die ISO 200000 „IT Service Management“ Obwohl die Zertifizierung nach der ISO 20000 des Servicebereichs IT zunächst nicht im Fokus der Zielsetzung stand, hat der klare Zieltermin und der klar definierte Umfang der Zertifizierung allen Beteiligten enorm geholfen. Bei einer solch umfassenden Neugestaltung der Prozesslandschaft besteht die Gefahr, dass man sich sonst in den Tiefen der Prozessgestaltung verliert. Die Zertifizierung hilft in diesem Zusammenhang zur Einhaltung einer pragmatischen „Flughöhe“ und zwingt zur rechtzeitigen Landung. Als Motivationsfaktoren für eine ISO 20000 Zertifizierung findet man in der Literatur häufig die folgenden Gründe: – Verbesserung der Qualität der Services und dadurch verbessertes Vertrauen der Kunden in die IT-Abteilung – Verbessertes Ansehen sowie Verbesserung der Stabilität und Zusammenarbeit – Transparente Darstellung der Leistungsfähigkeit Ihrer IT bestätigt durch einen unabhängigen Dritten (Zertifizierer) – Manager und Mitarbeiter erhalten ein besseres Verständnis für das Geschäft, die Rollen und die Verantwortlichkeiten Die genannten Gründe trafen für den Servicebereich IT des Flughafens München nur eingeschränkt zu. Der Hauptgrund lag in der gewünschten
280
9 Praxisbeispiel: Flughafen München Effizienzsteigerung des Servicebereichs IT und einer angestrebten Prozessorientierung der gesamten Organisation. Da der Servicebereich IT nicht nur intern Leistungen erbringt, wurde die Definition des Scopes der ISO 20000 Zertifizierung bereits zu Beginn der Planungen auf das gesamte Leistungs- und Kundenspektrum bezogen. Die Scope-Definition lautet daher: "The IT Service Management System that supports the provision of IT services to internal and external customers of Flughafen Muenchen GmbH"
Und wenn zum Zertifizierungsdatum noch nicht alles perfekt ist? Die Zertifizierung nach der ISO 20000 umfasst grundsätzlich immer die gesamte in der Norm definierte Prozesslandschaft mit den in der Norm definierten Mindestanforderungen an den jeweiligen Prozess. Dieser sehr große Umfang stellt für viele Organisationen eine große Hemmschwelle dar und die Frage liegt nahe: "Wie ist denn eine Vorbereitung auf diesen Umfang in passabler Zeit machbar und wie bringt man dann auch die Prozesse in diesem Umfang zum "Leben"?".
Prozess-Kennzahlen und Prozesssteuerung Eine wesentliche Komponente der Prozessdefinitionen und der Prozesssteuerung stellt die Festlegung von Kennzahlen (KPIs) und deren Controlling dar. Die Kennzahl soll Schlüsselindikator für die Leistungsfähigkeit des Prozesses sein und Messgrößen liefern, die anzeigen, wie schnell und zu welchem Grad störungsfrei ein Prozess abläuft. Besonders hier ist jedoch zu beachten, dass jede definierte Kennzahl erhoben werden muss und auch interpretiert werden will, um als Steuerungsinformation einen Nutzen zu liefern, entsprechende Messindikatoren sind zu implementieren. In der Euphorie der Prozessdefinition werden gerne Kennzahlen definiert, die beiden Kriterien nicht gerecht werden. In der Praxis hat sich im Servicebereich IT gezeigt, dass die Anzahl der ursprünglich definierten Kennzahlen nach einem Jahr um etwa 50 % reduziert wurde. Weiterhin ist nicht jede Kennzahl auf jeder Organisationsebene gefragt. So ist zum Beispiel „die Anzahl der geöffneten und geschlossenen ProblemRecords je Prioritätsklasse" für den Prozess Owner „Problem-Management“ und seinen Linienverantwortlichen von großem Interesse, jedoch weniger für die Geschäftsführung des Unternehmens. Die folgende Tabelle zeigt einen Auszug der ersten Ebene der ProzessKennzahlen:
281
9 Praxisbeispiel: Flughafen München
Abbildung 76:
Auszug der ersten Ebene der Kennzahlen des SB IT
Im Rahmen der jährlichen IT-Strategie werden konkreten Prozessziele und die Sollwerte für die einzelnen Kennzahlen mit dem Prozess Owner festgeschrieben.
Der Prozess Improvement Plan Im Laufe der Vorbereitung auf die Zertifizierung wird sehr schnell klar, dass es viele Prozessdetails gibt, die eine gewisse Reifezeit brauchen, bis sie in der Organisation wirklich umgesetzt sind und Wirkung zeigen. Zum Zeitpunkt der Zertifizierung wird in den meisten Unternehmen noch nicht alles absolut perfekt laufen. Diese Erfahrung hat auch der Servicebereich IT des Flughafens München gemacht. Um dennoch zertifizierungsfähig zu sein, ist zum Zeitpunkt der Zertifizierung eine klare Aussage zur Weiterentwicklung der Prozesse und
282
9 Praxisbeispiel: Flughafen München die Definition von angestrebten Zielzuständen erforderlich; der so genannte Prozess Improvement Plan (Schema siehe Bild). Prozess: Problem-Management
Datum: 27.04.2005
Freigabe (FK1 / FK2):
Definierte Einschränkungen: • Werden die Zielzeiten bei Incidents überschritten erfolgt noch nicht zwingend die Analyse mittels Problem-Management
Maßnahmen- und Zeitplan für die Erhöhung des Abdeckungsgrades und zur Verbesserung der inhaltlichen Ausgestaltung: Maßnahme
Ziel
Zieldatum
Verantwortlicher
Ausweitung der Problem-Management Verfahren auf den gesamten Bereich IT
Einbindung aller Mitarbeiter in den Prozess Problem-Management
01.08.2006
Prozess-Owner, Prozess-Manager
Schulungen aller IT-Mitarbeiter über die Inhalte und Arbeitsanweisungen zum Problem-Management
Einbindung aller Mitarbeiter in den Prozess Problem-Management
01.10.2006
Prozess-Owner, Prozess-Manager
Arbeitsanweisung zum ProblemManagement erweitern um Vor-gehen bei Zielzeitüberschreitungen von Incidents zu berücksichtigen
Sicherstellen daß Known Errors und Workarounds für die IncidentBearbeitung zur Verfügung gestellt werden
01.08.2006
Prozess-Owner, Prozess-Manager
Verbesserungen am ARS-Tool und ARSMasken
Vereinfachtes Bearbeiten und Erhöhung der Akzeptanz
01.12.2006
Prozess-Owner, Prozess-Manager
Abbildung 77:
Auszug aus dem Service Improvement Plan des SB IT
In diesem Plan sind für jeden Prozess, die zum Zertifizierungstermin getroffenen und bekannten Einschränkungen hinsichtlich der Prozess Implementierung zu beschreiben und der Plan für die Weiterentwicklung der Prozesse mit klaren Zielen, Terminen und Verantwortlichkeiten zu hinterlegen. Aber Vorsicht! Im Zuge der Vorbereitung auf die Zertifizierung arbeiten alle beteiligten Mitarbeiter mit einer sehr hohen Intensität und Euphorie an dem Thema. Dieser Aufwand ist in der späteren betrieblichen Praxis im Rahmen des kontinuierlichen Verbesserungsprozesses nicht zu halten. Bei der Definition des Prozess Improvement Plans besteht daher die potentielle Gefahr, dass die Messlatte für die angestrebten Ziele zu hoch gelegt wird und nach kurzer Zeit die Enttäuschung einsetzt, weil eine Zielerreichung aufgrund von Aufwandslimitierungen nicht möglich ist.
283
9 Praxisbeispiel: Flughafen München
Der ITSM-Maßnahmenkatalog Auch nach der Zertifizierung werden viele neue Erkenntnisse in Hinblick auf eine Verbesserung oder Abrundung der definierten Prozesse aufkommen. Um diese Informationen von Mitarbeitern und weiteren Prozessbeteiligten konsequent verfolgen zu können, ist ein strukturiertes Vorgehen erforderlich. Der Servicebereich IT hat dazu eine Datenbank realisiert, in der alle Probleme, Änderungs- und Erweiterungsanforderungen erfasst und überwacht werden. Das Qualitätsmanagement hat in diesem Kontext die Aufgabe des Moderators übernommen und hinterfragt die geforderten Aspekte, definiert gemeinsam mit den Linienverantwortlichen die Verantwortlichkeiten für die Maßnahmenbearbeitung, überprüft die Zielerfüllung und eskaliert ggf. bei Terminüberschreitungen. Ein Reporting über den Bearbeitungsstatus der Maßnahmen an das Bereichsmanagement erfolgt einmal im Quartal, an die direkten Linienverantwortlichen monatlich.
Erfolge Die Erfolge der konsequent verfolgten Strategie sprechen bereits jetzt für sich. In den letzten drei Jahren konnte der Faktor IT-Kosten zum Umsatz des Unternehmens um fast 1,4%-Punkte verbessert werden.
Sowohl die Kosten für die eingesetzten Systeme, als auch die Kosten für Fremdleistungen konnten bei gleich bleibender Personalkapazität erheblich reduziert werden. Die IT-Organisation der Flughafen München GmbH hat als fünftes deutsches Unternehmen und als erster Flughafen weltweit ein ISO 20000 Zertifikat erhalten und weist damit seine exzellente Servicequalität aus. Speziell für neue Kunden, die die Qualität und Leistungsfähigkeit des Servicebereichs IT noch nicht beurteilen können und den Zusicherungen vertrauen müssen, ist die Zertifizierung und damit Nachweis des Service Managements ein wichtiger Indikator für die Servicequalität. Der Anteil des externen Geschäfts konnte auch in 2006/2007 weiter gesteigert werden. Aus diesem Grund hat sich der Flughafen entschlossen, innerhalb des SB IT eine neue Business-Unit für externes Geschäft zu gründen, um Leistungen im Airport-Sektor, aber auch an andere Unternehmen mit Campus-Charakter anzubieten und den Anteil an externer Leistung weiter auszubauen. Dies ist eine gute Perspektive für weiteres wirtschaftliches Wachstum des Münchner Flughafens und für die Umsetzung neuer innovativer Ideen für den Airport der Zukunft.
284
10 Praxisbeispiel: VOSS Gruppe IT Management Report der VOSS Gruppe
Gottfried Weibler Leiter Informationstechnologie VOSS Automotive GmbH www.voss.de
Firmenportrait VOSS ist eine mittelständische Unternehmensgruppe mit Stammsitz in Wipperfürth. Unter dem Dach der VOSS Holding betreuen die organisatorisch eigenständigen Unternehmen VOSS Automotive und VOSS Fluid, unterstützt von zehn Auslandsgesellschaften, die internationalen Märkte von Fahrzeug- und Maschinenbau. Die VOSS Gruppe beschäftigt ca. 1.400 Mitarbeiter. VOSS ist einer der führenden Systempartner für Leitungs- und Verbindungstechnik im internationalen Fahrzeug- und Maschinenbau und versteht sich als kompetenter Entwicklungspartner seiner Kunden. Ergebnis der Entwicklungspartnerschaft sind maßgeschneiderte Lösungen der Leitungsauslegung, der Leitungsführung und der Verbindungstechnik. Dies gilt für Pneumatik, Hydraulik, Kraftstoff- und Klimasysteme, insbesondere auch für Anwendungen im Serienfahrzeug von morgen, wie etwa Brennstoffzellen oder CO2-Klimaanlagen. In der Automobilindustrie hat VOSS Automotive als technischer Dienstleister nachhaltig den Stand der Technik geprägt, z. B. in der Verbindungstechnik für die Druckluftbremse in Nutzfahrzeugen und für die Luftfederung in PKW. Als einer der führenden Anbieter hydraulischer Verbindungstechnik ist VOSS Fluid ein international gefragter Partner. Im engen Kundenkontakt optimiert VOSS Fluid die Verbindungsauslegung der Hydraulik und übernimmt damit wesentliche Aufgaben innerhalb der gesamten Hydrauliksysteme. Durch ein Komplettprogramm in der Rohrverschraubung wird unser Anspruch, den Kunden ein umfassendes Lieferprogramm zu bieten, erweitert. Darüber hinaus liefert die VOSS Fluid weitere Komponenten
285
10 Praxisbeispiel: VOSS Gruppe wie Messtechnik, Rohrschellen, Kugelhähne, einbaufertige Schlauchleitungen, Flanschverbindungen und komplette Kits. Die IT Abteilung ist organisatorisch in der VOSS Automotive GmbH angesiedelt und ist zentraler IT-Dienstleister für alle VOSS-Gesellschaften.
Herausforderungen an die VOSS IT Die VOSS Gruppe expandiert weltweit und das immer schneller. Dies ist eine enorme Herausforderung auch für die VOSS IT, die mit einer relativ kleinen Personaldecke sehr flexibel und „skalierbar“ sein muss. Schon sehr früh haben wir uns nach ITIL ausgerichtet und das Potenzial des IT Service Managements erkannt. Wir konnten die durch ITIL erreichten Verbesserungen in vielen Kontexten einsetzen, z. B. werden die turnusmäßigen Audits nach ISO/TS 16949 unserer IT, sowie kundenspezifische Audits unserer IT und IT – Überprüfung durch unsere Wirtschaftsprüfer durch den praktischen Einsatz von ITIL sehr viel einfacher.
ITIL und Kennzahlen Einen wesentlichen Erfolg haben wir im letzten Jahr durch die enge Verzahnung von IT-Kennzahlen und ITIL erreicht. – Das Service Desk liefert wesentliche IT-Kennzahlen. – Ein Cockpitsystem auf der Basis von NAGIOS, das sich in der letzten Phase des Aufbaus befindet, ermittelt die für den IT-Betrieb relevanten Kennzahlen automatisch und zeigt insbesondere Abweichungen auf. Dadurch ist eine schnelle Reaktion seitens der IT im Service Desk und im Problem Management möglich. – Das Reporting der VOSS IT an unsere Geschäftsführung ist enorm professionalisiert worden. Neben den Beiträgen in Management Meetings stellen wir unserem Top Management einen jährlichen Bericht, den IT Management Report, zur Verfügung, der in der Sprache der Geschäftsführung die Lage der IT in der VOSS Gruppe darstellt.
IT Management Report Ich möchte in dieser Kurzdarstellung nur auf den IT Management Report eingehen. Die Entwicklung dieses Reports, der die Situation der VOSS IT jährlich beleuchtet, war kein einfaches Projekt. Sehr viel Vorarbeit war dazu nötig, u. a. im Bereich IT-Controlling und die Recherche nach den für die VOSS Gruppe geeigneten Kategorien mit den wichtigsten Key Performance Indikatoren, die sich letztlich aus technischen und finanzwirtschaftlichen IT-Kennzahlen ableiten.
286
10 Praxisbeispiel: VOSS Gruppe Die Struktur unseres IT Management Reports haben wir in Form einer Balanced Scorecard entwickelt, allerdings haben wir diese auf unsere firmenspezifischen Bedürfnisse erweitert. Diese erfolgt bei uns in fünf Kategorien, die nicht nur die Finanzperspektive, sondern auch die Perspektivsichten auf Kunden, Leistung, Mitarbeiter und insbesondere die für die Weiterentwicklung der VOSS Gruppe wichtigen IT - Projekte und Innovationen abgeleitet aus der Geschäftsstrategie berücksichtigt. In jeder Perspektive benutzen wir maximal 5 Kennzahlen. Wichtig waren uns sowohl die Zeitreihen und Darstellung des Verlaufs der Kennzahlen als auch eine inhaltliche Interpretation der Situation. Bemüht man sich, diese Interpretation klar und verständlich in den Business-Zusammenhang einzuordnen, so fällt es leicht, aus dieser Darstellung die Ziele für das nächste Jahr abzuleiten. Der jährlich erscheinende IT Management Report soll einen umfassenden und prägnanten Eindruck über die IT in der VOSS Gruppe vermitteln. Daher wird besonderer Wert auf Knappheit und Transparenz der Darstellung gelegt. Die Kennzahlen, die wir verwenden, sind natürlich vertraulich. Wir haben kein „fertiges“ Kennzahlensystem eingesetzt, sondern unser eigenes entwickelt, das insbesondere unsere Geschäftsziele und firmenspezifischen Bedürfnisse berücksichtigt. Wegen des enormen weltweiten Wachstums der VOSS Gruppe waren uns Kennzahlen wichtig, die eventuell für andere weniger wichtig sind. Es kam uns beispielsweise darauf an, darzustellen, wie viele Lokationen an das weltweite VOSSNET angeschlossen sind und in wie weit eine CSCW Durchdringung bereits stattgefunden hat – auch im strategischen Sinne.
Erfahrungen Anfang 2007 haben wir den IT Management Report zum ersten Mal für das Jahr 2006 entwickelt. Unser Top Management hat diesem Report große Beachtung geschenkt. Insbesondere vermittelt der Report ein „geschlossenes Bild“ der IT. Es wird deutlich, wieso wir bestimmte Dinge, z. B. Virtualisierung und Serverkonsolidierungen zu einem bestimmten Zeitpunkt, durchgeführt haben, und wie sie sich auswirken. Wir sehen den IT Management Report als ideales Kommunikationsinstrument zur Darstellung der Leistungen unserer IT. Die Darstellung der aktuellen Situation der IT und die Zielformulierung werden anhand der Balanced Scorecard integriert und stehen nicht mehr isoliert nebeneinander wie in den Vorjahren. Wir werden den IT Management Report jährlich an die Geschäftsziele und davon abgeleitete IT-Strategie anpassen – denn diese ist natürlich im Fluss.
287
11 Anhang 11.1 Quellenverzeichnis [Baschin, 2001] Baschin, Anja Die Balanced Scorecard für Ihren IT-Bereich – Ein Leitfaden für Aufbau und Einführung Campus Verlag, Frankfurt, New York, 2001, ISBN 3 593 36715 7 [Bung, 2006] Bung, Jakob Entwicklung eines Kennzahlensystems für das IT-Service Management auf der Basis von ITIL, ISO 20000 und COBIT Masterarbeit im Studiengang Entrepreneurial Management der Fachhochschule für Wirtschaft Berlin, 2006 [BS 15000-1, 2002] BS 150000-1:2002 IT service management - Part 1: Specification BSI, London, 2002, ISBN 0 580 40470 6 [BS 15000-2, 2002] BS 150000-2:2002 IT service management - Part 2: Code of practice BSI, London, 2002, ISBN 0 580 41125 7 [COBIT, 2000] IT Governance Institute COBIT 3rd Edition - Management Guidelines www.isaca.org, Rolling Meadows, IL 60008 USA, 2000, ISBN 1-893209-12-1
289
11 Anhang [COBIT, 2004a] IT Governance Institute COBIT Mapping - Overview of International IT Guidance www.isaca.org, Rolling Meadows, IL 60008 USA, 2004, ISBN 1-893209-57-1 [COBIT, 2004b] IT Governance Institute COBIT Mapping - Mapping of ISO/IEC 17799:2000 With COBIT www.isaca.org, Rolling Meadows, IL 60008 USA, 2004, ISBN 1-893209-62-8 [COBIT, 2005] IT Governance Institute COBIT 4.0 - Control Objectives, Management Guidelines, Maturity Models www.isaca.org, Rolling Meadows, IL 60008 USA, 2005, ISBN 1-933284-37-4 [COBIT, 2006] IT Governance Institute IT Control Objectives for Sarbanes-Oxley, 2nd Edition The Role of IT in the Design and Implementation of Internal Control Over Financial Reporting www.isaca.org, Rolling Meadows, IL 60008 USA, 2006, ISBN 1-933284-76-5 [COBIT, 2007] IT Governance Institute Mapping of ITIL With COBIT 4.0 www.isaca.org, Rolling Meadows, IL 60008 USA, 2007, ISBN 1-933284-77-3
290
11.1 Quellenverzeichnis [Gartner, 2006] Gartner Research ISO/IEC 20000 Has an Important Role in Sourcing Management Gartner Research, 2006, ID Number: G00136652 [Harvard, 2004] Harvard Business Manager Balanced Scorecard – Unternehmen erfolgreich steuern Manager Magazin Verlagsgesellschaft, Hamburg, Auflage 1, März 2004, ISBN 3-935577-07-9 [ISO 20000-1, 2005] ISO/IEC 20000-1:2005-12 Information technology - Service management – Part 1: Specification Beuth Verlag, Berlin, 2005, ISBN 0 580 47529 8 [ISO 20000-2, 2005] ISO/IEC 20000-2:2005-12 Information technology - Service management - Part 2: Code of practice Beuth Verlag, Berlin, 2005, ISBN 0 580 47530 1 [ISO 17799, 2005] ISO/IEC 17799:2005 Information technology - Security techniques - Code of practice for information security management Beuth Verlag, Berlin, 2005, ISBN 0580467813
291
11 Anhang [itSMF, 2001] itSMF The IT Service Management Forum IT Service Management – Ein Begleitband zur IT INFRASTRUCTURE LIBRARY, Version 2.1.b itSMF Ltd., Winnersh, 2001, ISBN 0-9524706-2-4 [Kaplan et al., 1996] Kaplan, Robert S.; Norton, David P. The Balanced Scorecard. Translating Strategy Into Action Mcgraw-Hill Professional, 1996, ISBN 0875846513 [Kaplan et al., 1997] Kaplan, Robert S.; Norton, David P. Balanced Scorecard – Strategien erfolgreich umsetzen Schäffer-Poeschel Verlag, Stuttgart, 1997, ISBN 3-7910-1203-7 [KESS, 2006a] KESS DV-Beratung GmbH Erfolgreiche ISO 20000-Zertifizierung der ITOrganisation des Flughafens München Pressemitteilung http://www.kess-dv.de/Pressemitteilung ISO_20000_Flughafen__Munchen.pdf, 10.01.2007 [KESS, 2006b] KESS DV-Beratung GmbH Download-Bereich http://www.kess-dv.de/Wir-Ueber-Uns/Beschreibungenund-Downloads/beschreibungen-und-downloads.html, 10.03.2007
292
11.1 Quellenverzeichnis [KESS, 2007a] KESS DV-Beratung GmbH Beschreibung zum ITIL Service Manager Seminar http://www.kess-dv.de/Seminare/ServiceManager/service-manager.html, 17.03.2007 [KESS, 2007b] KESS DV-Beratung GmbH IT Service Management Simulationen http://www.kess-dv.de/Seminare/seminare.html, 16.06.2007 [KESS, 2007c] KESS DV-Beratung GmbH Workshop Unterlage „ITIL V3 - was ist neu” http://www.kess-dv.de/Seminare/seminare.html, 16.06.2007 [Kütz, 2007] Kütz, Martin Kennzahlen in der IT dpunkt Verlag, Heidelberg, 2. Auflage, 2007 [Kurth, 2006] Kurth, Sascha IT Service Management Prozesse mit Kennzahlen steuern Tagungsband zur dritten Fachtagung IT-Controlling Fachhochschule Bonn-Rhein-Sieg, Band 16, Sankt Augustin 2006
293
11 Anhang [Lewin, 1958] Lewin, Kurt Group decision and social change In: Maccoby, Newcomb, Hartley (Hrsg.): Readings in social Psychology, 3. Auflage, New York, 1958, S. 197-211. [OGC, 2005a] OGC Best Practice Einführung in ITIL The Stationery Office Books, London, 2005, ISBN 0 11 331035 8 [OGC, 2005b] OGC Best Practice für Service Support The Stationery Office Books, London, 2005, ISBN 0 11 330970 8 [OGC, 2006a] OGC Best Practice für Security-Management The Stationery Office Books, London, 2006, ISBN 0 11 330968 6 [OGC, 2006b] OGC Best Practice für Service Delivery The Stationery Office Books, London, 2006, ISBN 0 11 330056 2 [OGC, 2007a] OGC Service Strategy The Stationery Office Books, London, 2007, ISBN 97801133104560
294
11.1 Quellenverzeichnis [OGC, 2007b] OGC Service Design The Stationery Office Books, London, 2007, ISBN 9780113310470 [OGC, 2007c] OGC Service Transition The Stationery Office Books, London, 2007, ISBN 9780113310487 [OGC, 2007d] OGC Service Operation The Stationery Office Books, London, 2007, ISBN 9780113310463 [OGC, 2007e] OGC Continual Service Improvement The Stationery Office Books, London, 2007, ISBN 9780113310494 [OGC, 2007f] OGC The Official Introduction to Service Lifecycle The Stationery Office Books, London, 2007, ISBN 9780113310617 [Preißner, 2006] Preißner, Andreas Balanced Scorecard anwenden – Kennzahlengestützte Unternehmenssteuerung Hanser Wirtschaft, 2. Auflage, 2006, ISBN: 3446407383
295
11 Anhang [van Bon, 2006] van Bon, Jan ISO/IEC 20000 - Das Taschenbuch Van Haren Publishing, Zerwole (Niederlande), 2006, ISBN 90 77212 87 6 [Victor et al., 2005] Victor, Frank; Günther Holger Optimiertes IT Management mit ITIL Vieweg Verlag, Wiesbaden, 2005, ISBN 978-3528158941 [Victor GmbH, 2007] Victor GmbH ITIL Implementation Guide http://www.VictorGmbH.de 27.05.2007 [Wikipedia, 2007] Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Key_performance_indicators, 08.05.2007 [Zeithaml et al., 1988] Zeithaml, V. A.; Berry, L. L.; Parasuraman, A. Communication and control processes in the delivery of service quality Journal of Marketing, 52(1), 1988, S. 44
296
11.2 Abkürzungsverzeichnis
11.2 Abkürzungsverzeichnis ACD
Automatic Call Distribution
BCM
Business Continuity Management
BIA
Business Impact Analyse
BS
British Standard
BSC
Balanced Scorecard
CAB
Change Advisory Board
CAPI
Computer Assisted Personal Interview
CCTA
Central Computer and Telecommunications Agency
CI
Configuration Item
CMDB
Configuration Management Database
CMS
Configuration Management System
COBIT
Control Objectives for Information and related Technology
CSF
Critical Success Factor
CSI
Continual Service Improvement
CSI
Customer Satisfaction Index
DHS
Definitive Hardware Store
DML
Definitive Media Library
DSL
Definitive Software Library
EC
Emergency Committee
ISACA
Information Systems Audit and Control Association
ISACF
Information Systems Audit and Control Foundation
ISO
International Standardization Organization
ITGI
IT Governance Institute
ITIL
IT Infrastructure Library (Version 2), in Version 3 Synonym für Service Management
ITSC
IT Service Continuity
ITSCM
IT Service Continuity Management
ITSM
IT Service Management
itSMF
IT Service Management Forum
297
11 Anhang ISO
International Organization for Standardization
KGI
Key Goal Indicator
KPI
Key Performance Indicator
KSF
Key Success Factor
KVP
Kontinuierlicher Verbesserungsprozess
OGC
Office of Government Commerce
OLA
Operational Level Agreement
PDCA
Plan, Do, Check, Act
PIP
Prozess Improvement Plan
PMP
Prozess-Management Plan
RFC
Request for Change
ROI
Return of Investment
SCM
Service Catalogue Management
SIP
Service Improvement Program
SIP
Service Improvement Plan
SKMS
Service Knowledge Management System
SLA
Service Level Agreement
SLM
Service Level Management
SLR
Service Level Requirements
SMP
Service Management Plan
SPOC
Single Point of Contact
UC
Underpinning Contract
298
11.3 Abbildungsverzeichnis
11.3 Abbildungsverzeichnis Abbildung 1:
ITIL Rahmenstruktur ...............................................................8
Abbildung 2:
Die 10 ITIL-Prozesse und der Service Desk ..........................9
Abbildung 3:
Generisches ITIL-Prozessmodell ..........................................10
Abbildung 4:
Die Ausrichtung der Services auf das Business..................13
Abbildung 5:
Die 5 Phasen des Service Lifecycles nach ITIL V3..............15
Abbildung 6:
Verbindung zwischen IT Service und Business Service ....17
Abbildung 7:
Service Strategy Prozesse.......................................................18
Abbildung 8:
Service Design Prozesse.........................................................19
Abbildung 9:
Service Transition Prozesse ...................................................20
Abbildung 10: Service Operation Prozesse ...................................................22 Abbildung 11: Continual Service Improvement...........................................23 Abbildung 12: ITIL Version 3 Prozessmodell ...............................................25 Abbildung 13: Die 5 Phasen des Service Lifecycles und ihre Prozesse .....33 Abbildung 14: Service Strategy .......................................................................34 Abbildung 15: Service Design .........................................................................35 Abbildung 16: Service Transition ...................................................................39 Abbildung 17: Service Operation....................................................................42 Abbildung 18: Continual Service Improvement...........................................46 Abbildung 19: 7 Step Improvement Prozess .................................................47 Abbildung 20: IT Service Management-Prozesse der ISO 20000................54 Abbildung 21: PDCA-Methodik .....................................................................55 Abbildung 22: COBIT Prozess-Übersicht ......................................................58 Abbildung 23: Zusammenhang zwischen Control Objectives in COBIT.60 Abbildung 24: Ziele, Prozesse und Metriken in COBIT ..............................62 Abbildung 25: Prozess, Ziele und Kontrollebenen in COBIT .....................63 Abbildung 26: Mapping der Prozesse in ITIL Version 2 und COBIT........65 Abbildung 27: Wertschöpfungskette nach Porter ........................................75 Abbildung 28: Zusammenhang zwischen SLAs, OLAs und UCs..............79 Abbildung 29: Beispiel für mehrschichtige SLAs .........................................80 Abbildung 30: Allgemeine Balanced Scorecard............................................91
299
11 Anhang Abbildung 31: Ursache-Wirkungskette .........................................................93 Abbildung 32: Stellung der BSC im Unternehmensplanungsprozess .......93 Abbildung 33: PDCA-Zyklus ........................................................................102 Abbildung 34: Exemplarische Darstellung der Bearbeitung eines Incidents .................................................................................106 Abbildung 35: IT-Prozesse und bestehende Aufbauorganisation............107 Abbildung 36: Ausschnitt der RACI-Matrix zum Change Management (vgl. [OGC, 2007c])................................................................111 Abbildung 37: Definition der IT Services ....................................................116 Abbildung 38: Definition der IT Services – Service Improvement Plan ..117 Abbildung 39: Definition der Prozessziele – Neue Services .....................118 Abbildung 40: Definition der Prozessziele – Kundenanforderungen .....118 Abbildung 41: Definition der Prozessziele – IT-Strategie..........................119 Abbildung 42: Definition der Prozessziele – Prozess Improvement Plan .........................................................................................120 Abbildung 43: Definition der Prozessziele – Planung und Implementierung ..................................................................121 Abbildung 44: Definition der Prozessziele – Service Management Plan 122 Abbildung 45: Konformität des Managementsystems ..............................124 Abbildung 46: Prozess-Management – Prozessdesign ..............................125 Abbildung 47: Prozess-Management – Überprüfung ................................126 Abbildung 48: Prozess-Management – Nutzung von COBIT und ITIL ..127 Abbildung 49: Prozess-Management – Konformität..................................128 Abbildung 50: Prozess-Management – Prozess Improvement Plan ........129 Abbildung 51: Entwicklung von Kennzahlen .............................................130 Abbildung 52: Zusammengesetzte Prozess-Kennzahlen ..........................133 Abbildung 53: Darstellung der SLAs mit dem Q-Board von Q to be ......133 Abbildung 54: Das IT Service Management Kennzahlensystem..............134 Abbildung 55: Exemplarischer Prozess-Bericht – Deckblatt zum Report .....................................................................................135 Abbildung 56: Exemplarischer Prozess-Bericht – Darstellung der Kennzahlen ............................................................................136 Abbildung 57: Darstellung des Management Cockpits von iET Solutions.................................................................................137
300
11.3 Abbildungsverzeichnis Abbildung 58: Beispiel für eine Trenddarstellung .....................................138 Abbildung 59: Beispiel 1 für eine Analyse möglicher Ursachen ..............139 Abbildung 60: Beispiel 2 für eine Analyse möglicher Ursachen ..............140 Abbildung 61: Schema zur Klassifikation von IT-Kennzahlen.................156 Abbildung 62: Key Success Faktoren im IT Management Report............159 Abbildung 63: Key Success Faktoren zur Gruppierung von KPIs und CSIs .........................................................................................160 Abbildung 64: Beispiele für Lücken zwischen Kunden- und Providersicht .........................................................................161 Abbildung 65: Gaps nach OGC (aus [OGC, 2007e])...................................163 Abbildung 66: Deming (oder PDCA) Zyklus..............................................234 Abbildung 67: 3-Phasen-Modell nach Lewin..............................................236 Abbildung 68: Anzahl der RfCs pro Monat (Demo-Daten) ......................262 Abbildung 69: Status aller RfCs (Demo-Daten) ..........................................263 Abbildung 70: Organisationsstruktur Flughafen München, Servicebereich IT...................................................................271 Abbildung 71: Von den Unternehmenszielen zu der Umsetzung in der IT ......................................................................................273 Abbildung 72: Prozessorientierte Sicht des Servicebereichs IT ................274 Abbildung 73: Ausrichtung der Prozesse an der IT-Strategie ..................276 Abbildung 74: Die Prozesslandkarte des Servicebereichs IT ....................277 Abbildung 75: Das ITSM-Portal des Servicebereichs IT ............................279 Abbildung 76: Auszug der ersten Ebene der Kennzahlen des SB IT.......282 Abbildung 77: Auszug aus dem Service Improvement Plan des SB IT...283
301
11 Anhang
11.4 Sachwortverzeichnis —A—
—F—
Access Management 44, 214 Asset 34
Financial Management 30, 34, 169
Asset Management 40
—G—
Availability Management 8, 31, 37, 180
Governance 11, 56, 57
—B—
Improvement Prozess 46
Balanced Scorecard 3, 5, 88
Incident 28
Benchmark 160 Best Practice 1, 3
Incident Management 6, 27, 43, 105, 204
Business Continuity Management 31, 37
Information Security Management 38, 101, 185
—C—
ISO 20000 3, 4, 5, 50, 51, 53, 54, 81
Capacity Management 30, 36, 177 Change Management 26, 28, 29, 39, 191 COBIT 2, 5, 56 Configuration Management 29, 40 Continual Service Improvement 14, 22, 46, 217
—I—
IT Prozess-Management 101 IT Service 5, 13, 73 IT Service Continuity Management 31, 37, 183 IT Service Management 5, 27 IT Service Provider 13, 22, 77, 78, 86, 87 IT-Controls 164
Controls on Demand 164
ITIL 1, 2, 3, 5, 7, 11, 14, 23
Critical Success Factor 63, 113
ITIL Best Practice 83
—D—
ITIL Refresh 250
Definitive Media Library 199
—K—
Demand Management 24, 35, 172
Kennzahlen 1, 7, 11, 27, 32, 54, 88, 101, 115, 124, 130, 140, 141, 143, 155, 166, 243
—E—
Evaluation 41, 199 Event Management 42, 202
302
Kennzahlensystem 2, 5, 94, 143, 147, 155, 158, 161
11.4 Sachwortverzeichnis Key Performance Indikator 33, 61, 158, 161, 163
Request Fulfilment 43, 53, 167, 210
Knowledge Management 42, 189, 200
Return on Investment 49, 89, 219
Kontinuierlicher Verbesserungsprozess 233
—S—
—L—
Lifecycle 6, 14 —M—
Metriken 66 Monitoring 72 —O—
Risiko Management 14 Security Management 31, 65, 72 Service 12 Service Asset 40 Service Asset and Configuration Management 40, 167, 189, 195 Service Catalogue Management 35, 173
Operational Level Agreement 32, 77, 174
Service Design 14, 18, 35, 173
Outsourcing 225, 258 —P—
Service Improvement Plan 55, 116, 122, 134, 238
PDCA-Zyklus 101
Service Katalog 35, 81
Plan-Do-Check-Act 55
Service Level 14, 21, 36
Problem Management 28, 44, 64, 67, 73, 212
Service Level Agreement 13, 35, 43, 52, 77, 78, 82, 174
Prozess Manager 26, 97, 103, 108, 112
Service Level Management 8, 30, 36, 49, 77, 81, 174, 220
Prozess Owner 10, 26, 97, 103, 108, 110, 111
Service Level Requirement 77
Prozess-Kennzahlen 124, 130, 166
Service Management 1, 7
Prozess-Management 104 —R—
Service Desk 9, 28, 37, 44, 66, 215
Service Level Target 145, 174 Service Manager 109 Service Measurement 48, 219
Reifegrad 242
Service Operation 14, 21, 23, 42, 202
Release and Deployment Management 40, 189, 197
Service Portfolio 16, 34, 35, 171
Release Management 29, 197
Service Portfolio Management 24, 34, 35, 171
Reporting 72
Service Reporting 48, 218
Request for Change 28, 73
Service Request 32, 43, 44, 45, 49, 204, 210
303
11 Anhang Service Strategy 11, 15, 34, 53, 115, 169
Transition Planning and Support 39, 189
Service Transition 14, 19, 23, 39, 189
—U—
Service Validation and Testing 41, 189
Underpinning Contract 32, 77, 174 —V—
Single Point of Contact 215
Verification and Audit 194
Supplier Management 38, 187
—W—
System Management 143
Workaround 82
—T—
The 7 Step Improvement Process 217
304
