IT-Management mit ITIL® V3 3834805262, 9783834805263 [PDF]

Zitiervorschau

Ralf Buchsein | Frank Victor | Holger Günther | Volker Machmeier IT-Management mit ITIL® V3

Ralf Buchsein | Frank Victor | Holger Günther | Volker Machmeier

IT-Management ® mit ITIL V3 Strategien, Kennzahlen, Umsetzung 2., aktualisierte und erweiterte Auflage Mit 93 Abbildungen PRAXIS

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Das in diesem Werk enthaltene Programm-Material ist mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Der Autor übernimmt infolgedessen keine Verantwortung und wird keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programm-Materials oder Teilen davon entsteht. 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 2., aktualisierte und erweiterte Auflage 2008 Alle Rechte vorbehalten © Vieweg +Teubner |GWV Fachverlage GmbH, Wiesbaden 2008 Lektorat: Sybille Thelen | Andrea Broßler Vieweg+Teubner ist Teil der Fachverlagsgruppe Springer Science+Business Media. www.viewegteubner.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. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Druck und buchbinderische Verarbeitung: Wilhelm & Adam, Heusenstamm Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier. Printed in Germany ISBN 978-3-8348-0526-3

Vorwort zur 1. Auflage ITIL als Basis für eine neue Sicht auf die IT hat sich in den letzten Jahren in deutschen Unternehmen rasant verbreitet, und das mit anhaltendem Erfolg. Der Grund liegt darin, 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

Vorwort zur 2. Auflage Im September 2007 ist unser Buch „IT-Management mit ITIL V3“ in der ersten Auflage erschienen. Seitdem hat sich viel getan. Die itSMF Deutschland e.V. hat mittlerweile das deutsche Glossar zu ITIL V3 herausgegeben und wir haben im letzten halben Jahr viele hilfreiche Diskussionen mit unserer werten Leserschaft geführt, deren Anmerkungen aufgegriffen und umgesetzt. Die vorliegende zweite Auflage unseres Buches ist eine gründliche Überarbeitung der ersten. Wir haben die deutschen Fachbegriffe auf die des offiziellen ITIL V3-Glossars angepasst, und wir sind dem Wunsch vieler Leserinnen und Leser nachgekommen, die Inhalte zu ITIL V3 neu zu strukturieren und zu vertiefen. Die Zielsetzung ist dabei gleich geblieben: x

ITIL V3 steht im Mittelpunkt. Darum ranken sich eine Reihe von praxisrelevanten Themen, wie IT-Management-Strategien, Kennzahlensysteme, Zertifizierungen, Balanced Scorecards und Reporting.

x

ITIL V3 wird in einem Detaillierungslevel dargestellt, so dass die Kernideen und die Einordnung in die Gesamtzusammenhänge deutlich werden.

Das Buch wendet sich damit an Praktiker und IT-Entscheider und ist weniger als Lehrbuch zu ITIL V3 gedacht. Es geht um Grundlagen, Ideen, ITManagement, Umsetzung und Erfahrungen aus der Praxis für die Praxis. An dieser Stelle möchten wir uns – auch im Namen des Vieweg+Teubner Verlages – ganz herzlich bei Ihnen, den Leserinnen und Lesern der ersten Auflage, für die guten Hinweise bedanken, die wir hoffentlich geeignet umgesetzt haben. Mai 2008 Ralf Buchsein, Frank Victor, Holger Günther und Volker Machmeier

VII

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 ..................................................16

2.4.2

Service Strategy...........................................................................20

2.4.3

Service Design.............................................................................27

2.4.4

Service Transition .......................................................................32

2.4.5

Service Operation .......................................................................37

2.4.6

Continual Service Improvement...............................................42

2.4.7

Der prozessorientierte Ansatz von ITIL Version 3.................47

2.5 ITIL Kennzahlen für IT Service Management-Prozesse......................52 2.5.1

Ausgewählte Kennzahlen der ITIL Version 2.........................52

2.5.2

Prozesse und ausgewählte Kennzahlen der ITIL Version 3 .57

2.6 ISO 20000 ...................................................................................................97 2.6.1

Die Geschichte der ISO 20000 ...................................................99

2.6.2

Der Aufbau der ISO 20000.........................................................99

2.6.3

Die Inhalte der ISO 20000 ........................................................101

2.6.4

Die ISO 20000 und Kennzahlen ..............................................102

2.7 COBIT.......................................................................................................103 2.7.1

Entwicklung von COBIT .........................................................104

2.7.2

Struktur von COBIT .................................................................105

2.7.3

Prozess-Management gemäß COBIT .....................................106

2.7.4

COBIT und die IT Service Management-Prozesse ...............111

IX

Inhaltsverzeichnis 2.7.5

Metriken für IT Service Management-Prozesse ...................113

2.7.6

COBIT Metriken für IT Service Management-Prozesse ......114

2.8 Monitoring und Reporting von SLAs ..................................................119 2.8.1

Definition und Interpretation des Begriffs „IT Service“......121

2.8.2

Service Level Agreements .......................................................124

2.8.3

Das Zusammenwirken von SLAs, OLAs und UCs..............125

2.8.4

Der Aufbau von SLAs ..............................................................126

2.8.5

Die Inhalte von SLAs................................................................128

2.8.6

Monitoring und Reporting von SLAs, OLAs und UCs .......132

2.8.7

Abgrenzung der Kennzahlen..................................................135

2.9 Integrationsinstrument: Balanced Scorecard ......................................135 2.9.1

Kernideen...................................................................................136

2.9.2

Anwendung auf den IT-Bereich .............................................141

2.9.3

Ausprägungen der Balanced Scorecard ................................142

2.10 Konsequenzen.......................................................................................144 3 IT Prozess-Management..............................................................................147 3.1 Management Summary .........................................................................147 3.2 PDCA-Zyklus..........................................................................................147 3.3 Etablierung des Prozess-Managements...............................................150 3.3.1

Der Charakter von IT-Prozessen ............................................151

3.3.2

Rollen im Prozess-Management .............................................155

3.4 Definition der Prozessziele und -Kennzahlen ....................................161 3.4.1

Definition der Prozessziele......................................................161

3.4.2

Definition der Prozess-Kennzahlen .......................................171

3.4.3

Dokumentation der Prozess-Kennzahlen..............................178

3.4.4

Reporting der Prozess-Kennzahlen........................................179

3.5 Von der Kennzahl zur Verbesserungsmaßnahme .............................185 3.6 Kennzahlen müssen reifen ....................................................................188 3.7 Der Umgang mit Kennzahlen ...............................................................189 4 IT Kennzahlensysteme ................................................................................191 4.1 Management Summary .........................................................................191 4.2 Ziele ..........................................................................................................192

X

Inhaltsverzeichnis 4.3 Überblick .................................................................................................195 4.3.1 SVD 1980...........................................................................................196 4.3.2 Diebold 1984.....................................................................................197 4.3.3 Kargl 1996 .........................................................................................198 4.3.4 Van der Zee 1996 .............................................................................199 4.4 Bewertung ...............................................................................................200 4.5 Konsequenzen.........................................................................................201 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen....203 5.1 Management Summary .........................................................................203 5.2 Klassifikationsschema für IT-Kennzahlen ..........................................203 5.2.1

Key Success Factors..................................................................205

5.2.2

Key Performance und Customer Satisfaction.......................208

5.2.3

IT-Controls und Controls on Demand...................................212

5.3 Prozess-Kennzahlen ...............................................................................214 5.3.1

Service Strategy.........................................................................217

5.3.2

Service Design...........................................................................221

5.3.3

Service Transition .....................................................................237

5.3.4

Service Operation .....................................................................250

5.3.5

Continual Service Improvement.............................................265

6 Lessons learned: Empfehlungen und Ratschläge...................................269 6.1 Management Summary .........................................................................269 6.2 ITIL-Einführung .....................................................................................270 6.2.1

Analyse der bestehenden Prozesse ........................................270

6.2.2

Prozess-Einführungen..............................................................274

6.2.3

Die Organisation gewinnen ....................................................277

6.2.4

Rollenbeschreibungen..............................................................278

6.3 Kontinuierlicher Verbesserungsprozess..............................................281 6.3.1

KVP der bestehenden Prozesse ..............................................283

6.3.2

KVP der neuen Prozesse..........................................................284

6.3.3

Wettbewerb der Prozesseinführung ......................................289

6.3.4

Reifegradanalyse der Prozesse im laufenden Betrieb..........290

6.4 Kennzahlen..............................................................................................291

XI

Inhaltsverzeichnis 6.4.1

IT-Prozesse am Tagesgeschäft ausrichten .............................292

6.4.2

ITIL – abgestimmt auf Business- und IT-Strategie...............295

6.4.3

ITIL Refresh oder wie geht es weiter?....................................298

7 Praxisbeispiel: ALTANA Pharma AG ......................................................305 8 Praxisbeispiel: Autobahn Tank & Rast GmbH.......................................313 9 Praxisbeispiel: Flughafen München .........................................................317 10 Praxisbeispiel: VOSS Gruppe ..................................................................333 11 Anhang .........................................................................................................337 11.1 Quellenverzeichnis ...............................................................................337 11.2 Abkürzungsverzeichnis.......................................................................345 11.3 Abbildungsverzeichnis ........................................................................347 11.4 Glossar....................................................................................................351 11.5 Sachwortverzeichnis ............................................................................369

XII

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 downVerfahren 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 downAnsatz 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 upVerfahren 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 IT-Kennzahlen 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 ManagementProjekten 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“ und „Service Delivery“ hierzu insgesamt zehn erforderliche IT-Prozesse dokumentiert. Zusätzlich ist der Prozess „Security Management“ in einem eigenen Dokument beschrieben. 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ügbar-

8

2.3 Die Struktur gemäß ITIL Version 2 keit. Jeder IT Service Management-Prozess hat eine charakteristische Zielrichtung 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 folgendermaßen definiert: Prozessteuerung: “Der Prozess der Planung und Regelung; mit dem Ziel, einen Prozess in einer effektiven und effizienten Weise durchzuführen.”

9

2 IT Service Management Hierzu sind in einem generischen Prozessmodell die wichtigsten Aufgaben beschrieben (siehe Abbildung 3, aus „Best Practice Einführung in ITIL“, [OGC, 2005a]). Ziele des Prozesses

ProzessOwner Qualitätsparameter und KPIs Prozessmanagement

Aktivitäten und Subprozesse

Input

Output

Prozessausführung

Ressourcen

Rollen

Prozessbedingungen Abbildung 3: Der Process Owner gibt die Prozessziele vor und kann anhand der KPIs die Erreichung der Ziele feststellen.

Generisches ITIL-Prozessmodell

Auf Basis der vom Process 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.

10

2.4 Die Struktur gemäß ITIL Version 3 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). 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 Die in diesem Buch wiedergegebenen Definitionen stammen aus dem ITIL V3 Glossar des Arbeitskreises „Publikation, ITIL Version 3 Translation Projekt“ des itSMF Deutschland e. V. Dieses Glossar bildet die Basis für die Übersetzung der Originalliteratur.

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 Beitrag zur IT Go-

11

ITIL Kennzahlen sind lediglich Empfehlungen.

2 IT Service Management vernance geliefert. Im Rahmen der IT Governance soll sichergestellt werden, dass die IT-Organisation mit etablierten Strukturen und Prozessen die Unternehmensziele und -Strategie unterstützt. Wesentlicher Teil der IT Governance ist eine erfolgreiche Ausrichtung der IT an den Geschäftszielen des Unternehmens (Stichwort „Business-IT Alignment“). Mit der Version 3 gehen die ITIL Best Practices einen Schritt weiter. Die Zielsetzung von ITIL mit der Version 3 besteht in der “Business Integration”.

Mithilfe der ITIL Best Practice soll nicht nur eine bessere Ausrichtung der IT-Organisation an den Geschäftsprozessen und Anforderungen des Kunden ermöglicht werden, sondern es wird mit der ITIL V3 eine IT- / Business Integration angestrebt. In den meisten Organisationen ist inzwischen die Abwicklung eines Geschäftsprozesses ohne entsprechende IT-Unterstützung nicht mehr denkbar. In einigen Fällen findet die Durchführung eines Geschäftsprozesses inzwischen nur durch elektronische Systeme und ohne manuelle Bearbeitungsschritte statt. Als Beispiele hierfür können „Web-Shops“ oder das „Online Banking“ herangezogen werden. Die Qualität, Funktionalität und Leistungsfähigkeit dieser IT-Unterstützung prägt maßgeblich das Erscheinungsbild der gesamten Organisation nach außen zum Kunden. Gleichzeitig gehört die auf den Geschäftsprozess ausgerichtete IT-Unterstützung zu den strategischen Fähigkeiten und Ressourcen einer Organisation. Damit wird die notwendige und auf die jeweilige Organisation ausgerichtete ITUnterstützung zum elementaren Bestandteil des Geschäftserfolges. Diese Unterstützung eines Geschäftsprozesses wird in den ITIL Best Practices als Service bezeichnet. Den Service definiert ITIL (Version 3) als: Service: „Eine Möglichkeit, einen Mehrwert für Kunden zu erbringen, indem das Erreichen der von den Kunden angestrebten Ergebnisse erleichtert oder gefördert wird. Dabei müssen die Kunden selbst keine Verantwortung für bestimmte Kosten und Risiken tragen.“

In dieser neuen Definition des Service werden die Erbringung eines Mehrwertes für den Kunden und die angestrebten Ergebnisse herausgestellt. Damit unterstreicht die ITIL Version 3 die beabsichtigte Business Integration. Es wird nicht nur ein Service bereitgestellt, sondern er muss auch die angestrebten Ergebnisse erzielen und einen Mehrwert für das Business erbringen. ITIL Version 3 spricht hier von einer ergebnisbasierten Definition des IT Service: „Was ist das Ergebnis bzw. der Mehrwert des IT Service für den Geschäftsprozess?“.

12

2.4 Die Struktur gemäß ITIL Version 3 Damit verbunden ist auch die Erweiterung der Definition für den IT Service (aus „Service Strategy“, [OGC, 2007a]). Hier wird der allgemeine Begriff des Service auf den Bereich der IT konkretisiert: IT Service: „Ein Service, der für einen oder mehrere Kunden von einem IT Service Provider bereitgestellt wird. Ein IT Service basiert auf dem Einsatz der Informationstechnologie und unterstützt die Business-Prozesse des Kunden. Ein IT Service besteht aus einer Kombination von Personen, Prozessen und Technologie und sollte in einem Service Level Agreement definiert werden.”

Sinngemäß lässt sich der IT Service also wie folgt definieren: – IT Services werden von einem IT Service Provider für einen oder mehrere 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. – IT Services erbringen einen Mehrwert für Kunden. Ein IT Service ist demzufolge mehr als die Bereitstellung einer Technologie. Der IT Service Provider muss zur Bereitstellung des IT Service nicht nur die geeignete Technik, sondern auch über entsprechend qualifiziertes Personal und auf den IT Service ausgerichtete Prozesse verfügen. Innerhalb der Publikation „Service Strategy“ werden diese Grundlagen und der Bezug eines IT Service zu den Geschäftsprozessen des Business deutlich herausgestellt. Letztendlich stellen die IT Services die Geschäftsprozesse des Business sicher bzw. stellen den IT Service aus Sicht des Kunden dar (Abbildung 4, auf Basis „Service Strategy“, [OGC, 2007a]). Die Abbildung zeigt die Ausrichtung der IT Services auf das Business und die Business Prozesse. Der IT Service Provider verfügt über spezielle Ressourcen und Fähigkeiten. ITIL V3 bezeichnet diese Ressourcen und Fähigkeiten als Service Assets, die im nachfolgenden Kapitel „Service Strategy“ näher betrachtet werden. Mithilfe dieser Ressourcen und Fähigkeiten wird dem Business der notwendige IT Service bereitgestellt, der in die Business Prozesse integriert ist. Teilweise ist, wie zum Beispiel für WebShops, der IT Service mit dem Business Prozess gleichzusetzen (rechter mittlerer Teil der Abbildung). Letztendlich dienen die Business Prozesse dazu, dem Kunden der Organisation einen Service oder ein Produkt zu liefern. Hier wird die Leistungsfähigkeit der Organisation für den Kunden als Ganzes erlebbar.

13

2 IT Service Management Business Services (Produkte, Waren) Business Service

Business Service

Business Prozesse

IT Services IT Service

IT Service

IT Service

IT Service

Ressourcen und Fähigkeiten Internet

Abbildung 4:

Die Ausrichtung der IT Services auf das Business

IT Services bestehen in der Regel aus verschiedenen technischen Systemen, Applikationen 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]): Service Owner (Serviceverantwortlicher): “Eine Rolle, die für die Bereitstellung eines bestimmten IT Service verantwortlich ist.”

Demzufolge ist der Service Owner verantwortlich für einen spezifischen IT Service, unabhängig davon, wo innerhalb der Organisation die zugrunde liegenden Ressourcen und Fähigkeiten, wie zum Beispiel technologischen Komponenten oder Applikationen angesiedelt sind. In vielen IT-Organisationen hat sich diese Rolle bereits etabliert, wenn auch zum Teil unter ei-

14

2.4 Die Struktur gemäß ITIL Version 3 nem anderen Namen. Häufig wird diese Rolle als Service Manager bezeichnet. Da innerhalb der ITIL Best Practice mit der Version 3 auch die Rolle des Service Managers beschrieben wird, gilt es, innerhalb der jeweiligen IT-Organisation eindeutige Bezeichnungen und Rollendefinitionen zu finden. In der Vergangenheit führte die Bezeichnung „IT Infrastructure Library“ zu Missverständnissen. So wurde der Begriff „Infrastructure“ fälschlicherweise dahingehend interpretiert, dass die ITIL Best Practice lediglich auf den Bereich der Infrastruktur der IT-Organisationen anzuwenden sei und zum Beispiel die Applikationen nicht im Betrachtungsbereich von ITIL liegen. Mit der neuen Version ist ITIL nicht mehr die Abkürzung für “IT Infrastructure Library”, sondern ITIL ist nun ein Synonym für Service Management. Hierzu definiert die ITIL Version 3 den Begriff ITIL wie folgt: ITIL: “Ein Satz an Best Practice-Leitlinien für das IT Service Management. Inhaber von ITIL ist das OGC. ITIL umfasst eine Reihe von Publikationen, die Leitlinien zur Bereitstellung von qualitätsbasierten IT Services sowie zu den Prozessen und Einrichtungen bieten, die zur Unterstützung dieser Services erforderlich sind.”

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: „Das Service Management ist die Gesamtheit der spezialisierten organisatorischen Fähigkeiten, die zur Generierung eines Mehrwerts für Kunden in Form von Services verfügbar 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), die Ü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).

15

2 IT Service Management Hierzu werden nicht nur Service Management-Prozesse beschrieben, sondern zum Beispiel auch die strategische Ausrichtung der IT, bewährte 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

Innerhalb der Informationstechnologie haben sich traditionell die Phasen „Plan“ (Planung), „Build“ (Entwicklung, Erstellung) und „Run“ (Betrieb, Produktion) etabliert: – Die Phase „Plan“ beinhaltet dabei in der Regel den ganzheitlichen Blick auf die Informationstechnologie und die Ausrichtung an den Anforderungen des Unternehmens. – Innerhalb von „Build“ werden darauf aufbauend die notwendigen IT-Systeme konzipiert, entwickelt und beschafft. – Innerhalb von „Run“ werden die Systeme betrieben und die Leistungen für die Kunden zur Verfügung gestellt. Diese bewährte Struktur hat die ITIL V3 konzeptionell aufgegriffen und mit einem umfassenden kontinuierlichen Verbesserungsprozess als Service Lifecycle beschrieben. Ausgehend von der strategischen Ausrichtung und Definition des IT Service (Service Strategy) werden die IT Services entwickelt (Service Design) und in die Produktion bzw. in den Betrieb überführt (Service Transition). Anschließend werden die IT Services betrieben und den Geschäftsprozessen zur Verfügung gestellt (Service Operation). Diese Phasen werden umschlossen von einem kontinuierlichen Verbesserungsprozess (Continual Service Improvement), der über alle Phasen des Service Lifecycle mögliche Verbesserungen identifiziert. Die Beschreibung dieses Service Lifecycle mit den Best Practices für jede einzelne Phase wird als ITIL Core bezeichnet. Der ITIL Core besteht aus den 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])

Diese fünf Core-Publikationen bilden die Phasen eines iterativen und mehrdimensionalen Lifecycle 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.

16

2.4 Die Struktur gemäß ITIL Version 3 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:

Service Operation

Die 5 Phasen des Service Lifecycle nach ITIL V3.

Diese Phasen haben nicht nur spezielle Zielsetzungen und Aufgaben innerhalb des Service Lifecycle, sondern auch definierte Übergänge zwischen den einzelnen Phasen. Die folgende Abbildung 6 veranschaulicht die Hauptaktivitäten der einzelnen Phasen sowie ihre Übergänge bzw. Schnittstellen (vereinfachte Darstellung aus „The Official Introduction to Service Lifecycle“ ([OGC, 2007e]). In dieser Abbildung finden sich die einzelnen Phasen des Service Lifecycle als Ebenen wieder. Die dargestellten Aktivitäten bzw. Aufgabenstellungen pro Phase werden in den nachfolgenden Kapiteln erläutert. An dieser Stelle werden die Übergänge zwischen den einzelnen Phasen beschrieben.

17

18

Change Management

Service Tranistion

Abbildung 6:

CSI

Definition Metriken

Lösen & Wiederherstellen

Risiken optimieren

Verhandeln/ Vereinbaren

Definition des Marktes

Service Reporting

Incident Management

Service Asset Configuration Management

Service Level Management

Demand Management

Integrierter Ablauf der Lifecycle Elemente

Service Measurement

Request Fulfilment

Supplier Management

Service Design Package

Service Performance Reports

Strategie Generierung

Service Strategie

Analyse

Monitoring & Aktionen

Verifizieren

Entwicklung Angebote

Entwicklung Angebote

Improvement

Event Management

Release & Deployment Management

Service Portfolio Management

Service Portfolio Management

Service Operation

Early Life Support

Service Design

Service Level Package

2 IT Service Management

2.4 Die Struktur gemäß ITIL Version 3 Eine der wichtigsten Aufgaben der Service Strategy ist die Definition des Serviceportfolios. Mittels des so genannten „Service Level Package“ werden IT Services beschrieben, die den Kunden zur Verfügung gestellt werden und innerhalb von Service Design zu entwickeln sind. Die in Service Design entwickelten IT Services werden mittels so genannter „Service Design Packages“ dokumentiert und Service Transition übergeben. Mittels Service Transition wird der IT Service in den IT-Betrieb überführt. Service Transition endet nicht mit der Überführung des IT Service in den Betrieb, sondern beinhaltet den Support für eine bestimmte Zeitspanne nach seiner Freigabe (Early Life Support). Innerhalb von Service Operations wird der IT Service dem Kunden zur Verfügung gestellt. Aus der Phase des Service Operation werden dann Service Performance Reports generiert, die im Continual Service Improvement analysiert werden und Aufschluss über mögliche Verbesserungsmaßnahmen geben. Zu jeder dieser Phasen des Service Lifecycle beschreibt jeweils eine ITILPublikation die Best Practice und gibt so einen Leitfaden zur Ausgestaltung dieser Phase. Dabei sind nicht nur die relevanten IT Service Management-Prozesse beschrieben, sondern unter anderem auch die phasenbezogenen Prinzipien, Methoden und Aspekte der Implementierung. So wird zum Beispiel innerhalb von Service Design auf Aspekte wie der „Business Impact Analysis”, der „Risiko Analyse von Services und Prozessen“ sowie von „Sourcing Prinzipien“ eingegangen. Die IT Service Management-Prozesse werden jeweils innerhalb der relevanten Service Lifecycle-Phase beschrieben. Dadurch wird sichergestellt, dass die Prozesse grundsätzlich nur in einer Publikation beschrieben sind. Einzige Ausnahme bildet hier das Service Level Management. Beim Service Level Management werden die wesentlichen Aspekte innerhalb von Service Design beschrieben. Ergänzungen hierzu finden sich noch im Continual Service Improvement. Im Fall des Incidents Managements (Störungs-Management) ist die Zuordnung zu Service Operation offensichtlich. Die Zielsetzung des Incident Managements besteht in der schnellstmöglichen Wiederherstellung des IT Service für die Anwender. Da Service Operation das tägliche Management eines IT Service, eines Systems oder eines anderen Configuration Item beschreibt, ist der Incident Management-Prozess ein wichtiger Bestandteil dieser Phase des Service Lifecycle. Es gibt aber auch Prozesse, die phasenübergreifend Aktivitäten beschreiben und anzuwenden sind. Als Beispiel für die phasenübergreifende Anwendung von Prozessen dient der Prozess des Change Managements. Dieser Prozess ist für die Steuerung des Lebenszyklus aller Changes verantwortlich. Wichtigstes Ziel des Change Managements ist es, die Durchführung von lohnenden Changes bei einer minimalen Unterbrechung der

19

2 IT Service Management IT Services zu ermöglichen. Da damit die gesicherte Überführung von Changes in die Betriebsumgebung verbunden ist, findet sich dieser Prozess innerhalb von Service Transition wieder. Aber Changes finden auch in anderen Phasen statt. Wird zum Beispiel innerhalb von Service Strategy entschieden, einen neuen Service zu entwickeln, so handelt es sich dabei auch um einen Change. Daraus folgt, dass einzelne Prozesse auch phasenübergreifend ihre Anwendung finden. In der ITIL V3 werden die IT Service Management-Prozesse innerhalb einer Phase des Service Lifecycle beschrieben und dokumentiert. Diese Prozesse finden aber zum Teil phasenübergreifend ihre Anwendung.

Abbildung 7 veranschaulicht die Prozesse der einzelnen Phasen und ihren Wirkungsbereich (vereinfachte Darstellung aus „The Official Introduction to Service Lifecycle“ ([OGC, 2007e]). Dieser ITIL Core soll von der OGC sukzessive um weitere Komponenten ergänzt werden und in ihrer Summe die gesamte ITIL Library ausmachen: – 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. Ergänzt werden diese offiziellen Publikationen der OGC um eine allgemeine Einführung „The Official Introduction to Service Lifecycle“ ([OGC, 2007e]).

2.4.2

Service Strategy

Im Zentrum des dargestellten Service Lifecycle steht die Phase Service Strategy (vgl. [OGC, 2007a]). Hier werden die strategischen Entscheidungen getroffen. Es geht 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 strategische Fundament für die Phasen Service Design, Service Transition, Service Operation und den alles umfassenden permanenten Verbesserungskreislaufs des Continual Service Improvement.

20

2.4 Die Struktur gemäß ITIL Version 3

Service Lifecycle – Governance Prozesse Service Strategy

Operational Service Lifecycle Prozessezb

Continual Service Improvement

Service Design

Service Transition

Service Operation

IT Financial Management Service Portfolio Management

Service Measurement

Strategie Generierung

Service Reporting

Demand Management Service Catalogue Management Service Level Management Availability Management Capacity Management

Service Improvement

IT Service Continuity Management IT Security Management Supplier Management Transition Planning Change Management

Service Asset and Configuration Management Release and Deployment Management Service Validation and Testing Evaluation Knowledge Management Event Management Incident Management Request Fulfilment Problem Management Access Management Common Service Operation Activities Abbildung 7:

Service Lifecycle und Prozesse

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. Marktplätze sind nicht nur für IT Service Provider zu definieren, die ihre Leistungen auf dem Markt anbieten, sondern auch für interne IT-Bereiche. Hierzu gilt es, auch die Frage zu

21

2 IT Service Management beantworten: „Wie können wir uns von der Konkurrenz bzw. externen Dienstleistern abheben?“. Innerhalb der Service Strategy gilt es, auf Basis dieser Fragestellung geeignete Servicestrukturen zu entwickeln, die eigenen Stärken zu erkennen und kritisch zu prüfen, welche externen Leistungen einbezogen werden sollten. Heute kann keine IT-Organisation mehr alle Ressourcen und Fähigkeiten mit eigenen Ressourcen produzieren. Es gilt demzufolge, durch die Konzentration auf die Alleinstellungsmerkmale und die Einbeziehung geeigneter Lieferanten (Supplier) zweckmäßige Servicestrukturen zu konzipieren. Mit Unterstützung des IT Financial Managements werden ein Serviceportfolio definiert und die Entwicklung eines Servicekatalogs vorbereitet. Hierzu werden vom IT Financial Management Kostenmodelle entwickelt sowie Return on Investment und Return on Value-Berechnungen angestellt. Unter Berücksichtigung der Aktivitäten im IT Financial Management kann die zuvor auf Seite 18 dargestellte „Abbildung 6: Integrierter Ablauf der Lifecycle Elemente“ aus dem Kapitel „2.4.1 ITIL und der Service Lifecycle“ nun wie folgt detailliert werden (Auszug aus der Darstellung in „The Official Introduction to Service Lifecycle“ ([OGC, 2007e]):

Gelegenheiten und Grenzen

Kostenmodelle

Return on Investment

Return on Value

IT Financial Management Service Level Package

Service Strategie Strategie Generierung

Definition des Marktes

Demand Management

Entwicklung Angebote

Service Portfolio Management

Service Design

Abbildung 8:

Elemente Service Strategy

Mit der ITIL V3 nimmt das Serviceportfolio eine wichtige Funktion im Service Management ein. Innerhalb der Service Strategy wird definiert, welche IT Services zur Unterstützung der Geschäftsprozesse zu liefern bzw. zu entwickeln sind. Diese IT Services werden im Serviceportfolio dokumentiert. Dagegen enthält der bereits aus ITIL V2 bekannte Servicekatalog lediglich die IT Services, die sich in der Nutzung bzw. im Übergang in die Betriebsumgebung befinden.

22

2.4 Die Struktur gemäß ITIL Version 3 Innerhalb von Service Strategy gilt es, nicht nur zu entscheiden, welche IT Services zu liefern und zu entwickeln sind, sondern auch, welche IT Services außer Kraft gesetzt werden sollen. Auch diese IT Services sind dem Serviceportfolio zu entnehmen. Insbesondere die Entscheidung über und die Kennzeichnung der außer Kraft gesetzten IT Services sind für einen wirtschaftlichen IT-Betrieb wichtige Informationen, da die damit freigesetzten Ressourcen für andere IT Services zur Verfügung stehen und so ggf. zusätzliche Beschaffungen vermieden werden. Für das Serviceportfolio und die beschriebenen Phasen werden mit der ITIL V3 folgende Begriffe geprägt ([OGC, 2007a]): Serviceportfolio: Die Gesamtheit aller Services, die von einem Service Provider verwaltet werden. Das Serviceportfolio wird für das Management des gesamten Lebenszyklus aller Services genutzt. Es umfasst drei Kategorien: Servicepipeline (beantragt oder in der Entwicklung), Servicekatalog (Live oder bereit zum Deployment) und außer Kraft gesetzte Services. Servicepipeline: Eine Datenbank oder ein strukturiertes Dokument, in dem alle IT Services aufgelistet sind, die zur Diskussion stehen oder sich in der Entwicklung befinden und noch nicht für den Kunden verfügbar sind. Die Servicepipeline bietet einen Überblick über mögliche zukünftige IT Services und ist Teil des Serviceportfolios, das in der Regel nicht an die Kunden weitergegeben wird. Servicekatalog: Eine Datenbank oder ein strukturiertes Dokument mit Informationen zu allen Live IT Services, einschließlich der Services, die für das Deployment verfügbar sind. Der Servicekatalog ist der einzige Bestandteil des Serviceportfolios, der an die Kunden ausgehändigt wird. Er unterstützt den Vertrieb und die Bereitstellung von IT Services. Der Servicekatalog enthält Angaben zu Lieferergebnissen, Preisen, Bestellungen und Anfragen sowie Kontaktinformationen. Außerkraftsetzen: Die dauerhafte Entfernung eines IT Service oder eines anderen Configuration Items aus der Live-Umgebung. Das Außerkraftsetzen ist bei vielen Configuration Items Bestandteil des Lebenszyklus.

Letztendlich ist jeder IT Service mit einem Status verknüpft, über den eine eindeutige Zuordnung möglich wird. Die folgende Abbildung 9 aus [KESS, 2007d] veranschaulicht diesen Zusammenhang:

23

Service Status: ¬ Requirements ¬ Defined ¬ Analyzed ¬ Approved ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬

Chartered Designed Developed Built Test Released Operational Retired

Servicepipeline

Servicekatalog

Serviceportfolio

Service Lifecycle

2 IT Service Management

Außerkraftgesetzte Services

Abbildung 9:

Serviceportfolio und die einzelnen Stati

Die Definition des Serviceportfolios und dessen Integration in die aktuellen und zukünftigen Geschäftsprozesse ist eine der wichtigsten Aufgaben von Service Strategy.

Auch Themen wie Organisationsentwicklung sowie Kosten- und Risikobetrachtungen im Hinblick auf das Serviceportfolio 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, und tragen zum weiteren Ausbau von Geschäftsstrategien und -chancen bei. Das Fazit in einem kurzen Satz wäre wohl, die Service Strategy folgendermaßen zu formulieren: Erst das WAS, dann das WIE! Im gesamten Service Lifecycle wird eines sehr deutlich: die Ausrichtung der IT Services an den Anforderungen und am wirklichen Bedarf des Kunden und seines Geschäftes. Dieses Ziel wird stringent verfolgt. IT Services 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 10).

24

2.4 Die Struktur gemäß ITIL Version 3 Geschäftsprozess Nutzt den IT Service Nimmt Leistungen in Anspruch

Integration in Geschäftsprozess ermöglicht Wertbeitrag

IT Service IT Service Provider

Fähigkeiten und Ressourcen IT-Infrastruktur

Personen

Configuration Items

Organisation

Andere Elemente

Geld

IT Service

Prozesse

Abbildung 10:

Anwendungen

Verbindung zwischen IT Service und Business-Service

Business Service Management: „Ein Ansatz zur Verwaltung von IT Services, bei dem die unterstützten BusinessProzesse und der Geschäftswert berücksichtigt werden. Dieser Begriff bezeichnet darüber hinaus die Verwaltung von Business-Services, die für Business-Kunden bereitgestellt werden.“

Die mit der ITIL V3 verbundene Integration der IT Services in die Geschäftsprozesse des Kunden hat zu den bereits vorgestellten neuen Definitionen des Begriffs „Service“ bzw. „IT Service“ geführt. In diesen Definitionen wird zum Ausdruck gebracht, dass der IT Service einen Mehrwert für den Kunden erbringt. Die Service Level Agreements (SLAs) stellen hierzu einen wichtigen Beitrag dar; wobei sicherzustellen ist, dass diese SLAs einen IT Service aus Sicht des Geschäftsprozesses beschreiben und nicht die Bereitstellung eines technischen Systems wie den Betrieb eines SAP-Systems im Rechenzentrum. Aber damit wird der Mehrwert für den Geschäftsprozess und den Kunden noch nicht dokumentiert, und die Gefahr besteht, dass die IT weiterhin als Kostenfaktor gesehen und ihre Bedeutung für den Geschäftsbetrieb nicht ausreichend herausgestellt wird. Mit ITIL V3 soll der für den Kunden generierte Mehrwert betrachtet werden. Hierzu werden mit der „Warranty“ (Gewährleistung) und „Utility“ (Nutzen) zwei Dimensionen beschrieben.

25

2 IT Service Management Service Utility: Die Funktionalität eines IT Service aus der Perspektive des Kunden. Der Business-Wert eines IT Service setzt sich aus dem Service Utility („was“ der Service tut) und der Service Warranty („wie gut“ der Service das ausführt) zusammen. Service Warranty: Die Zusicherung, dass ein IT Service den vereinbarten Anforderungen gerecht wird. Dabei kann es sich sowohl um eine formale Vereinbarung wie ein Service Level Agreement oder einen Vertrag, als auch um eine Marketingbotschaft oder ein bestimmtes Markenimage handeln. Der Business-Wert eines IT Service setzt sich aus dem Service Utility („was“ der Service tut) und der Service Warranty („wie gut“ der Service das ausführt) zusammen.

Zweckmäßig?

Die Service Utility hilft dem Kunden in der Steigerung der Produktivität seiner Geschäftsprozesse, während die Service Warranty die notwendigen Voraussetzungen wie zum Beispiel Verfügbarkeit und Kapazität für den Betrieb spezifiziert. Der hier beschriebene Zusammenhang lässt sich wie folgt darstellen (Abbildung 11, aus [OGC, 2007a]):

Unterstützt Leistung?

Utility Zwecke erfüllt? ODER

Verschiebt Grenzen?

W/F

Warranty Anforderungen erfüllt ?

Wertschaffend?

UND

W/F

W/F

Verfügbar? Kontinuität? Kapazität?

UND

W/F = wahr / falsch betriebsfähig?

Sicherheit?

Abbildung 11:

Die Wertebetrachtung eines IT 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 Strategy die Basis bildet (siehe Abbildung 12, aus „Service Strategy“, [OGC, 2007a]).

26

2.4 Die Struktur gemäß ITIL Version 3

Strategie Implementierung

Messung und Bewertung

Service Design Service Design Anforderungen Service Strategy •Service Portfolio •Service Katalog

Service Transition Anforderungen

Service Transition

Service Operation Service Operation Anforderungen

Abbildung 12:

2.4.3

Continual Service Improvement

Messung und Bewertung

Service Strategy als Basis für den Service Lifecycle

Service Design

Dieses Buch (vgl. [OGC, 2007b]) trägt den Untertitel „Building structural service integrity“, was sehr prägnant die Zielsetzung dieser Phase des Service Lifecycle wiedergibt. Die Integrität des Service wird aber nicht nur von der eingesetzten Technologie gewährleistet, sondern auch von den damit in Verbindung stehenden Prozessen. Beim Service Design sind die folgenden fünf Aspekte zu betrachten: – Das Design der IT Services einschließlich aller funktionellen Erfordernisse, Ressourcen und Fähigkeiten – Das Design von Service Management Systemen und Tools, insbesondere des Serviceportfolios für das Management und die Steuerung der IT Services während des gesamten Lebenszyklus – Das Design der technologischen Architekturen und der Managementsysteme, die erforderlich sind, um den IT Service bereitzustellen – Das Design der Prozesse, die benötigt werden zum Design, Transition, Operation und Improvement der IT Services

27

2 IT Service Management – Das Design der Messsysteme und Metriken der IT Services, der Architekturen, ihrer verbundenen Komponenten und der Prozesse selbst. ITIL spricht hier von einem ereignisgesteuerten Ansatz, in dem für jeden der genannten Aspekte die gewünschten und geplanten Ergebnisse definiert werden, so dass der gelieferte IT Service den Erwartungen der Kunden und Benutzer entspricht. Ausgehend von den strategischen Zielen, die in der Phase Service Strategy definiert wurden, findet hier die Transformation zu einem Portfolio von IT 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 13 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. Service Level Package

Service Strategy

Supplier Management Service Design Package

Verhandeln/ Vereinbaren

Design ausgewogener Zuverlässigkeit Availability

Service Level Management

Anforderungen

Design Lösung

Messsysteme

Capacity

Servicekatalog Management

Architektur Security

Service Design

Compliance Continuity

Service Transition

Abbildung 13:

Service Design Aufgaben und Einbindung

Dies beinhaltet auch Änderungen und Verbesserungen, die notwendig werden, um sowohl den Wert der IT Services für den Kunden über den Lebenszyklus der IT Services hinweg zu erhalten, als auch die Kontinuität der IT Services, das Erreichen der Service-Qualität (Service Level-Ziele) und die Konformität zu Standards und Regeln.

28

2.4 Die Struktur gemäß ITIL Version 3 Die Aufgaben des Service Design und die Einbindung in den Service Lifecycle stellen sich wie in Abbildung 13 dar (Auszug aus der Darstellung in „The Official Introduction to Service Lifecycle“ ([OGC, 2007e]). Bevor ein neuer IT Service oder eine Änderung an einem bestehenden IT Service entwickelt wird, sind die damit verbundenen Kundenanforderungen aufzunehmen und zu analysieren. Eine damit verbundene Aufgabe ist die Analyse der bestehenden Fähigkeiten innerhalb der eigenen Organisation. Der Begriff der Fähigkeiten ist hier im Kontext zur Begriffsdefinition gemäß ITIL V3 zu verstehen: Fähigkeit (Capability): Die Fähigkeit einer Organisation, einer Person, eines Prozesses, einer Anwendung, eines Configuration Item oder eines IT Service zur Durchführung einer Aktivität. Fähigkeiten gehören zu den nicht greifbaren Assets einer Organisation.

Gibt es zwischen bestehenden Fähigkeiten und den notwendigen Fähigkeiten für den neuen bzw. zu ändernden IT Service Diskrepanzen, so sind geeignete Maßnahmen zu konzipieren. Dabei ist es nicht unbedingt erforderlich, die notwendigen Fähigkeiten innerhalb der eigenen IT-Organisation aufzubauen. Die zusätzlichen Fähigkeiten können auch extern bezogen werden. Innerhalb von Service Design werden hierzu „Delivery Model Options“ zur Integration von externen Lieferanten und Partnern beschrieben.

Serviceportfolio • Beschreibung • Wertbeitrag • Geschäftspläne (Business Cases) • Prioritäten • Risiken • Angebote und Einheiten • Kosten und Preisgestaltung

Abbildung 14:

Servicekatalog(e) • Services • Unterstützte Produkte • Richtlinien (Policies) • Bestellung und erforderliche Prozesse • Unterstützte Liefer- und Zahlungsbedingungen • Eingangspunkt und Eskalationen • Preisgestaltung und Verrechnung

Vom Serviceportfolio zum Servicekatalog

29

2 IT Service Management Das Serviceportfolio ist eine zentrale Informationsquelle innerhalb des Service Lifecycle. Dem Serviceportfolio können sämtliche IT Services und deren jeweiliger Status entnommen werden. Zusätzlich können weitere Details zum IT Service, dessen Schnittstellen und die Abhängigkeiten zu anderen IT Services hinterlegt werden. Eine Teilmenge des Serviceportfolios ist der Servicekatalog mit den Informationen zu sämtlichen in der Nutzung und der Überführung in die Betriebsumgebung befindlichen IT Services. Abbildung 14 beschreibt die Inhalte des Serviceportfolios und des Servicekatalogs (aus [KESS, 2007d]). Verbunden mit der Integration des IT Service in den Geschäftsprozess des Kunden entsteht die Notwendigkeit, diesen IT Service innerhalb der ITOrganisation zu strukturieren. Besteht der IT Service zum Beispiel in der Form eines „Personalverwaltungssystems“, so könnte dieser IT Service in den Betrieb eines Servers, eines LAN, einer Datenbank usw. verfeinert strukturiert werden. Zur besseren Abgrenzung bezeichnet ITIL V3 diesen IT Service als Business-Service: Business-Service: Ein IT Service, der einen Business-Prozess direkt unterstützt, im Gegensatz zu einem Infrastrukturservice, der intern vom IT Service Provider eingesetzt wird und der in der Regel nicht vom Business wahrgenommen wird. Der Begriff „Business-Service“ bezeichnet darüber hinaus einen Service, der von einem Geschäftsbereich für Business-Kunden erbracht wird. Dazu gehören beispielsweise die Bereitstellung von Finanzdienstleistungen für Kunden einer Bank oder die Lieferung von Waren an Kunden eines Einzelhandelsgeschäfts. Die erfolgreiche Bereitstellung von Business-Services hängt häufig von einem oder mehreren IT Services ab.

Es ist eine wesentliche Aufgabe innerhalb des Service Design, diese Business-Services so zu gestalten, dass sie die sich ändernden Anforderungen der Kunden und deren Geschäftsprozesse erfüllen. Hierzu sind die notwendigen unterstützenden IT Services zu bestimmen und auszugestalten. Der Prozess des Servicekatalog Managements hat zum Ziel, dass ein Servicekatalog erstellt und gepflegt wird, der diese Informationen über alle operationellen IT Services enthält, die für den operativen Betrieb vorbereitet werden. Hierzu werden zwei unterschiedliche Sichten zur Verfügung gestellt. Für den Kunden werden die Business-Services präsentiert, während innerhalb der IT die damit verbundenen (internen) IT Services in Verbindung gebracht werden (aus [OGC, 2007b]):

30

2.4 Die Struktur gemäß ITIL Version 3

Business Prozess 1

Business Prozess 2

Business Prozess 3

Business Servicekatalog

Service A

Service B

Service C

Service D

Service E

Applikationen

Daten

Technischer Servicekatalog

Support Services

Abbildung 15:

Hardware

Software

Die Inhalte und Sichten des Servicekatalogs

Liegt das Service Design vor, so ist es die Aufgabe des Service Level Managements, die entsprechenden Service Level Agreements (SLA) mit dem Kunden zu verhandeln, zu vereinbaren und sicherzustellen, dass die vereinbarten Service Level-Ziele eingehalten werden. Dazu zählt unter anderem die Sicherstellung der Zuverlässigkeits- und Compliance-Anforderungen. Dieser SLA wird mit dem Kunden auf der Ebene des Business-Service abgeschlossen werden (obere Ebene der Abbildung 15). Zur Absicherung des SLAs stellt das Service Level Management sicher, dass alle IT Service Management-Prozesse, Operational Level Agreements (OLAs) und Underpinning Contracts (UCs) für die vereinbarten Service Level-Ziele angemessen sind. Die Operational Level Agreements werden innerhalb der eigenen Organisation mit den beteiligten Einheiten, wie zum Beispiel Abteilungen abgeschlossen. Werden externe IT Services integriert, sind hierfür so genannte Underpinning Contracts zu verhandeln und zu vereinbaren. Dies erfolgt in Zusammenarbeit zwischen dem Service Level Management und Supplier Management. Sämtliche Prozesse des Service Design und deren Zielsetzung können dem Abschnitt „2.5.2.2 Service Design“ entnommen werden.

31

2 IT Service Management Ist der IT Service vollständig entwickelt, ist die Phase Service Transition verantwortlich für die Überführung des IT Service in den operativen Betrieb.

2.4.4

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. Hierzu werden die Anforderungen aus den Phasen Service Strategy und Service Design für ein effektives Service Operation realisiert. Hier findet das Management komplexer Changes 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. Die Aufgaben der Phase Service Transition sind Abbildung 16 zu entnehmen (Darstellung aus „The Official Introduction to Service Lifecycle“ ([OGC, 2007f]): Service Design

Service Design Package Qualitätssicherung

Service Abnahme

Planung & Support

Konformität

Utility und Warranty

Validierung & Testen

Entscheidung Fähigkeiten

Evaluierung

Knowledge

Service Transition Change Optimierung Riskien Management

Service Asset & Configuration Management

Verifizieren

Release & Deployment Management

Early Life Support

Service Operation

Abbildung 16:

Service Transition-Prozesse

Innerhalb von Service Transition haben die Prozesse „Change Management“, „Service Asset und Configuration Management“ und „Release und Deployment Management“ eine besondere Bedeutung. Sämtliche Prozesse

32

2.4 Die Struktur gemäß ITIL Version 3 von Service Transition können dem Abschnitt „2.5.2.3 Service on“ entnommen werden.

Transiti-

Jegliche Veränderung eines stabilen laufenden Systems ist mit Risiken verbunden. Das Change Management hat zum Ziel, die notwendigen Changes mit minimaler Unterbrechung der IT Services zu implementieren. Hierzu sind die einzelnen Changes zu bewerten, zu planen und so die damit verbundenen Risiken zu reduzieren. Die Verantwortung für die Autorisierung und Umsetzung von Changes liegt in der Rolle des Change Managers. Diese Bewertung kann bei umfassenden Changes nicht von einer Person allein mit einer ausreichenden Sicherheit durchgeführt werden. Daher hat sich die Unterstützung des Change Managers durch das so genannte Change Advisory Board (CAB) bewährt: Change Advisory Board (CAB) Eine Gruppe von Personen, die den Change Manager bei der Bewertung, Festlegung von Prioritäten und zeitlichen Planung in Bezug auf Changes beraten. Dieses Gremium setzt sich in der Regel aus Vertretern aller Bereiche des IT Service Providers, dem Business und den Drittparteien wie z. B Suppliern zusammen.

Damit mögliche Auswirkungen von Changes beurteilt werden können, benötigt das Change Management Informationen zu den betroffenen IT Services und den damit in Verbindung stehenden Komponenten. Die Pflege dieser Informationen zu den Komponenten liegt in der Verantwortung des „Configuration und Service Asset Managements“. In ITIL werden diese Komponenten als Configuration Items (CIs) bezeichnet: Configuration Item (CI): Alle Komponenten, die verwaltet werden müssen, um einen IT Service bereitstellen zu können. Informationen zu den einzelnen CIs werden in einem Configuration Record innerhalb des Configuration Management Systems erfasst und über den gesamten Lebenszyklus hinweg vom Configuration Management verwaltet. CIs unterstehen der Steuerung und Kontrolle des Change Management. CIs umfassen vor allem IT Services, Hardware, Software, Gebäude, Personen und formale Dokumentationen, beispielsweise zum Prozess und SLAs.

Die Definition stellt deutlich heraus, dass die Configuration Items nicht nur technische Komponenten wie Hardware, Software und Applikationen umfassen. Im Mittelpunkt der Definition steht, dass ein „IT Service“ bereitzustellen ist. Daher werden auch Informationen wie beispielsweise zu SLAs benötigt und als CIs hinterlegt. Aber auch Applikationen sind CIs.

33

Configuration Items sind mehr als Hard- und Software

2 IT Service Management Änderungen an Applikationen werden über das Change Management gesteuert. In der ITIL V2 wurde die Configuration Management Database (CMDB) noch als eine Datenbank beschrieben, die die relevanten Details zu jedem CI sowie Details der wichtigsten Beziehungen zwischen CIs enthält. Der Begriff „eine Datenbank“ wurde vielfach mit einer physischen Datenbank assoziiert, in der sämtliche Informationen zu hinterlegen waren. Diese Forderung war in der Praxis nicht zweckmäßig umzusetzen und aus Sicht der Autoren auch nicht die Intention von ITIL V2. In der Version 3 gibt es zwar noch den Begriff der CMDB, aber das Gesamtsystem zur Verwaltung der Informationen ist nunmehr das Configuration Management System (CMS): Configuration Management System: Ein Satz an Hilfsmitteln und Datenbanken, der für die Verwaltung der Configuration-Daten eines IT Service Providers verwendet wird. Das CMS enthält darüber hinaus Informationen zu Incidents, Problemen, Known Errors, Changes und Releases und kann auch Daten zu Mitarbeitern, Suppliern, Standorten, Geschäftsbereichen, Kunden und Anwendern beinhalten. Das CMS umfasst Hilfsmittel zum Sammeln, Speichern, Verwalten, Aktualisieren und Präsentieren von Daten zu allen Configuration Items und deren Beziehungen. Das CMS untersteht der Zuständigkeit des Configuration Management und wird von allen IT Service Management-Prozessen eingesetzt.

Die folgende Abbildung 17 (Auszug aus [OGC, 2007c]) verdeutlicht die möglichen Daten- und Informationsquellen sowie Tools für ein Configuration Management System:

Projekt Dokumentation

Definitive Media Library

Daten- und Strukturiert InformationsQuellen und Tools

Definitive Document Library 1

Projekt Software

Definitive Multimedia Library 1

Abbildung 17:

34

Physikalische CMDBs

Discovery, Software Enterprise Plattform Configuration Configuration Applikationen Asset Management Tools Management Access Management

CMDB1

CMDB2

wie Datenbank Netzwerk, Mainframe, Verteilte Desktop

Human Ressourcen Supply Chain Management Customer Relationship Management

Daten und Informationsquellen für ein CMS

und Audit Tools

2.4 Die Struktur gemäß ITIL Version 3 Innerhalb des „Release und Deployment Managements“ werden die Releases in den IT-Betrieb übergeleitet. Hierbei ist sicherzustellen, dass das Release effektiv in einen Einsatzbereich bzw. eine Zielumgebung ausgebracht (deployed) werden kann und die damit verbundenen Geschäftsanforderungen erfüllt werden. Die in Service Transition beschriebenen Prozesse lassen sich in die zwei Gruppen aufteilen: – Prozesse, die den gesamten Service Lifecycle unterstützen – Prozesse innerhalb des Service Transition Die Gruppe „Prozesse, die den Service Lifecycle unterstützen“ enthält einerseits wichtige Prozesse innerhalb von Service Transition, aber diese Prozesse unterstützen darüber hinaus alle Service Lifecycle-Phasen (siehe Abbildung 7). Diese Prozesse sind: – Service Asset und Configuration Management – Knowledge Management – Change Management Dagegen sind die folgenden Prozesse auf die Phase Service Transition fokussiert: – – – –

Transition Planning and Support Release and Deployment Management Service Testing and Validation Evaluation

Mit der Aufgabe, Informationen zu den Configuration Items zur Verfügung zu stellen, ist es offensichtlich, dass das „Service Asset und Configuration Management“ über alle Phasen des Service Lifecycle seine Anwendung findet. Denn diese Informationen können das Serviceportfolio innerhalb von Service Strategy betreffen, Informationen für das Service Design enthalten, die Auswirkungsanalyse von Changes innerhalb Service Transition unterstützen, bei Service Operation einen „Known Error“ für das Incident Management liefern und für die Phase Continual Service Improvement notwendige Daten zu einem SLA bereitstellen. Der Prozess „Knowledge Management“ ist mit der Version 3 erstmalig in den ITIL Best Practices dokumentiert. Seine Zielsetzung besteht in der Bereitstellung von Wissen und der damit verbundenen Effizienzsteigerung. Innerhalb der IT-Organisation fällt eine Unmenge von Daten an, die es gilt, für sämtliche Phasen des Service Lifecycle verfügbar zu machen. Hierzu sind aus den Daten Informationen und Wissen zu generieren, das dann für das Management als Entscheidungsgrundlage genutzt werden kann. Dieses notwendige Wissen soll im Knowledge Management durch

35

2 IT Service Management das Service Knowledge Management System (SKMS) zur Verfügung gestellt werden. Die folgende Abbildung 18 (aus OGC, 2007c) verdeutlicht den Weg von den gespeicherten Configuration Items (CIs) in der Configuration Management Database (CMDB) zum Service Knowledge Management System (SKMS):

Service Knowledge Management System (SKMS)

Entscheidung

Configuration Management System (CMS) Configuration Management Databases (CMDBs)

Abbildung 18:

Service Knowledge Management System

Die Bedeutung des Change Managements und seine Anwendung über den gesamten Service Lifecycle wird mit der ITIL V3 deutlich herausgestellt. In einigen IT-Organisationen wird der Umfang des Change Managements auf die Durchführung von Changes in der technischen Infrastruktur, zum Beispiel der Hardware in einem Rechenzentrum, eingegrenzt. Aber ITIL bringt deutlich zum Ausdruck, dass auch die Einführung eines neuen IT Service oder größere Veränderungen an einem existierenden IT Service einen Change darstellen und demzufolge in die Verantwortung des Change Managements fallen. In ITIL V3 werden daher die Ebenen des „strategischen Change“, des „taktischen Change“ und des „operationellen Change“ beschrieben. So werden zum Beispiel strategische Changes über die Service Strategy oder das Business Relationship Management eingebracht. Mit diesem Geltungsbereich des Change Management über den gesamten Service Lifecycle und über alle Bereiche – vom Configuration Item bis zum Serviceportfolio – kommt der Definition notwendiger Entscheidungsinstanzen eine große Bedeutung zu. Die folgende Abbildung 19 (aus OGC, 2007c) stellt ein mögliches Modell für die verschiedenen Ebenen dar:

36

2.4 Die Struktur gemäß ITIL Version 3 Kommunikation, Kommunikation, Entscheidungen Eskalationen für RFCs, und Aktionen Risiken, Erteilung

Change Autorisierung

Business Executive Board

Hohe Kosten/Risiken Change – erfordert Entscheidung von Executive

IT Management Board

Change wirkt sich auf mehrere Services oder organisatorische Abteilungen aus

CAB oder ECAB

Change wirkt sich nur lokal oder auf Service-Gruppe aus

Lokale Autorisierung

Abbildung 19:

Beispiele für betroffene Configuration-Ebene

Standard Change

Autorisierungsebenen für Changes

Sobald die Changes bzw. das Release in den operativen Betrieb übergeleitet sind, wird der neue oder geänderte IT Service innerhalb einer bestimmten Zeitspanne unterstützt und dann an Service Operation übergeben („Early Life Support“).

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 IT Services, um den gewünschten Wert für die Kunden und den Service Provider sicherzustellen. Die strategischen Ziele werden in dieser letzten Stufe letztendlich durch Service Operation realisiert, was seine kritische Bedeutung erkennen lässt. Die Anforderungen an neue oder zu verändernde IT Services werden innerhalb von Service Strategy auf Basis der Kunden- und Marktanforderungen getroffen. Innerhalb von Service Design und Service Transition werden die IT Services entwickelt und in den Betrieb übergeleitet. Aber innerhalb von Service Operation wird der IT Service dem Kunden zur Verfügung gestellt und in dessen Geschäftsprozesse integriert. Hier wird der IT Service nutzbar und liefert den erwarteten Mehrwert. So kann Service Operation mit einer Produktionsstätte verglichen werden, in der der IT Service ausgeliefert wird. Siehe hierzu die Darstellung der Phasen des

37

Hier wird der IT Service für den Kunden erleb- und nutzbar

2 IT Service Management Service Lifecycle und die Schnittstellen zum Kunden ([Basis der Abbildung 20 in „Continual Service Improvement“ [OGC, 2007e]):

Business (Geschäftsanforderungen) / Kunden

Service Strategy

Service Portfolio

Anforderungen

IT Services

Service Design

Service Transition Service Katalog

Service Operation

Operationelle Services

Continual Service Improvement

Abbildung 20:

Improvement Pläne u. Aktionen

Service Operation im Service Lifecycle

Auch in dieser Phase des Service Lifecycle steht nach wie vor im Vordergrund, die IT Services am Bedarf des Business auszurichten. Hierzu müssen Aktivitäten und Prozesse so koordiniert und ausgeführt werden, dass die vereinbarten Service Level-Ziele eingehalten werden. Angestrebt wird ein stabiler Service-Betrieb, um Änderungen an Design, Skalierung und Inhalt der Services und die Einhaltung der Service LevelZiele zu erlauben. Inhalte der Betrachtungen zu Service Operation sind u.a.: – – – –

die Grundkonflikte in Service Operation die Prozesse innerhalb von Service Operation die Schnittstellen zu den anderen Phasen des Service Lifecycle die Funktionen innerhalb von Service Operation

Service Operation beschreibt mit den vier Grundkonflikten: – interne IT-Sicht versus der externen Sicht,

38

2.4 Die Struktur gemäß ITIL Version 3 – Stabilität versus Fähigkeit, auf Änderungswünsche einzugehen, – Servicequalität versus Servicekosten und – reaktive versus proaktive Organisation die Herausforderungen für den IT-Betrieb. Zwischen den konkurrierenden Anforderungen wie Stabilität und der Fähigkeit, auf Änderungswünsche des Kunden einzugehen, gilt es, für die eigene IT-Organisation eine angemessene Balance zu finden. Steht zum Beispiel die Stabilität zu sehr im Vordergrund, so werden die Änderungswünsche des Kunden nicht rechtzeitig umgesetzt, und die IT-Unterstützung für die Geschäftsprozesse wird als unzureichend angesehen. Werden aber alle Änderungswünsche sehr schnell umgesetzt, so besteht die Gefahr eines instabilen IT-Betriebs. Innerhalb von Service Operation kann hinsichtlich der geeigneten Ausprägung kein Patentrezept geliefert werden, sondern es werden für die jeweilige Betrachtung mögliche Risiken beschrieben und Best Practices beschrieben, wie sich die Balance erzielen lässt. Auch für die Phase Service Operation werden Best Practices notwendiger Prozesse beschrieben. Die Anzahl der Prozesse wird gegenüber der ITIL V2 erweitert. Das Zusammenwirken der Service Operation Prozesse ist in der Abbildung 21 aus [OGC, 2007f] dargestellt. Early Life Support

Service Transition

Request Fulfilment Service Performance Reports

Lösen/Wiederherstellen

Incident Management

Monitoring/Aktionen

Event Management

Service Operation Stabilität

Qualität

Operationeller Change

„Monitor Control Kreislauf Problem

Performance

Qualität zu Kosten Feedback Technologie

Access

Continual Service Improvement

Abbildung 21:

Service Operation-Prozesse

Mit der Version 3 beschreibt ITIL erstmalig das Event Management als Service Management-Prozess. Dieser Prozess ist aber in vielen IT-Organisationen seit Jahren etabliert (= Best Practice). Die Aufgabenstellung besteht in dem Hinterlegen von Alarmen in IT-Systemen, die auf bestimmte Ereignisse reagieren. Ein Alarm könnte zum Beispiel generiert werden, wenn

39

2 IT Service Management die freie Kapazität eines Speicherbereichs einen Grenzwert erreicht. Dadurch kann in Service Operation schneller reagiert werden, und die Servicequalität wird verbessert. Können zu einzelnen Events automatisierte Aktionen hinterlegt werden, so trägt das Event Management zu einer Verringerung der Aufwendungen in Service Operation bei. ITIL stellt bei der Beschreibung heraus, dass ein Event einen Incident, ein Problem oder einen Change generieren kann. In den meisten Fällen wird ein Event zu einem Incident Record führen. Das Ziel des Incident Management mit der Wiederherstellung des „normalen Service-Betriebs“ ist gegenüber der Version 2 unverändert geblieben. Der „normale Service-Betrieb“ ist hier als Einhaltung der Vorgaben aus den SLAs zu verstehen. Da es im Rahmen der Umsetzung der ITIL Best Practice noch Abgrenzungsschwierigkeiten zwischen „Incident“ und „Problem“ gibt, wird in der Version 3 deutlich herausgestellt, dass ein Incident immer ein Incident bleibt. Ein Incident kann ein zusätzliches Problem hervorrufen, wandelt aber niemals „seinen Status oder seine Eigenschaft“ in ein Problem. An Service Operation werden von den Anwendern aber nicht nur Incidents herangetragen, sondern auch so genannte Service Requests. Service Request Eine Anfrage eines Anwenders nach Informationen, Beratung, einem StandardChange oder nach Zugriff auf einen IT Service. Dabei könnte es sich beispielsweise um das Zurücksetzen eines Passworts oder die Bereitstellung standardmäßiger IT Services für einen neuen Anwender handeln. Service Requests werden in der Regel von einem Service Desk bearbeitet und erfordern üblicherweise nicht die Einreichung eines RfC.

Mit dem „Request Fulfilment“ wird ein Prozess beschrieben, in dem diese Service Requests bearbeitet werden. Dieser Prozess wurde in den früheren Versionen von ITIL zwar nicht beschrieben, aber in vielen IT-Organisationen existiert dieser Prozess bereits und wird zum Teil als AnforderungsManagement bezeichnet. Während das Incident Management den IT Service schnellstmöglich wiederherstellen soll, hat das Problem Management die zugrunde liegende Ursache zu identifizieren und „Bekannte Fehler“ (Known Error) zu dokumentieren, so dass das Incident Management auf dieses Wissen zurückgreifen und auftretende Störungen schneller beheben kann. Gegenüber der ITIL Version 2 wurde das proaktive Problem Management in die Phase des „Continual Service Improvement“ verlagert.

40

2.4 Die Struktur gemäß ITIL Version 3 Die folgende Abbildung 22 zeigt den Zusammenhang zwischen Event, Incident und Problem Management sowie dem Request Fulfilment (aus [KESS, 2007c]):

Event Management

Incident

Workaround

Known Error Record

Abbildung 22:

Incident Management

Event

Service Request

Request Fulfilment

Change Record

Problem Management Known Error Datenbank

Prozesse aus Service Operation

Mit dem Access Management wird ein zusätzlicher Prozess beschrieben, der für die Zulassung der Nutzung von IT Services verantwortlich ist; insbesondere im Rahmen der stetig steigenden Compliance Anforderungen eine sehr wichtige Aufgabenstellung innerhalb von Service Operation. Neben diesen innerhalb von Service Operation etablierten Prozessen werden die Prozessaktivitäten beschrieben, die in den anderen Phasen des Service Lifecycle beheimatet sind, beispielhaft wird auf Aktivitäten von Service Operation im Rahmen des „Change Management“ eingegangen. Für die Organisation des Service Operation beschreibt ITIL als Organisationseinheiten so genannte „Funktionen“, innerhalb derer bestimmte Aktivitäten durchzuführen sind. Die folgende Abbildung 23 stellt diese Funktionen dar (aus [OGC, 2007d]):

41

2 IT Service Management

Service Desk

Technical Management

IT Operations Management

Application Management

Operations Control Facility Management

Abbildung 23:

Service Operation-Funktionen

Der Service Desk ist der Single Point of Contact (SPOC) für die Kommunikation zwischen Service Provider und Anwendern. Ein Service Desk bearbeitet in der Regel Incidents und Service Requests und ist für die Kommunikation mit den Anwendern zuständig. Das „Technical Management“ ist verantwortlich für die Bereitstellung von technischem Fachwissen zur Unterstützung von IT Services und für das Management der ITInfrastruktur. Das „IT Operations Management“ führt die täglichen Aktivitäten durch, die zur Verwaltung von IT Services und Unterstützung der IT-Infrastruktur erforderlich sind, wie zum Beispiel Backup und Restore. Das Application Management ist für die Verwaltung von Anwendungen während ihres gesamten Lebenszyklus verantwortlich.

2.4.6

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, Überleitung (Transi-

42

2.4 Die Struktur gemäß ITIL Version 3 tion) und Betrieb (Operation) der IT Services. Aber auch die Service Strategy erfährt aus dem Continual Service Improvement ein Feedback. Siehe hierzu die übergreifende Aufgabenstellung des Continual Service Improvement auf Basis der Darstellung in „Continual Service Improvement“, [OGC, 2007e] (siehe Abbildung 24).

Continual Service Improvement

Messung Bewertung/Feedback Service Transition

Messung Bewertung/Feedback Service Strategy Service Design

Service Operation

Messung Bewertung/Feedback

Abbildung 24:

Continual Service Improvement

Sharon Taylor, Chief Architect des Refresh Programms zur ITIL V3, verglich den Service Lifecycle mit einem Rad, wobei das Rad vom Continual Service Improvement umgeben wird, den gesamten Service Lifecycle durchdringt und für die Fortbewegung steht und einen Beharrungszustand innerhalb der IT-Organisation verhindert. Für eine optimale Unterstützung der Geschäftsprozesse müssen die IT Services und die IT Service Management-Prozesse nach klar definierten Zielen und mit relevanten Messsystemen implementiert, verwaltet und unterstützt werden. 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. ITIL führt zu Messung und Management aus:

43

2 IT Service Management Sie können nichts managen, was Sie nicht kontrollieren können. Sie können nichts kontrollieren, was Sie nicht messen können. Sie können nichts messen, was Sie nicht steuern können.

Grundvoraussetzung für ein wirksames IT Service Management sind definierte Ziele. Nur wer in der Lage ist, die Ziele für einen Prozess oder einen IT Service eindeutig zu formulieren, kann den Prozess oder den IT Service messen und so feststellen, ob die Ziele erreicht wurden oder ob ein Verbesserungsbedarf besteht. Die grundsätzliche Aufgabenstellung des Continual Service Improvement ist der folgenden Abbildung 25 zu entnehmen (Darstellung aus „The Official Introduction to Service Lifecycle“ ([OGC, 2007f]): Service Operation Service Performance Reports Daten-Analyse

Baseline & Metriken

Korrektive Aktionen

7 Step Improvement

Continual Service Improvement

Service Messung

Definition Metriken

Abbildung 25:

Service Reporting

Analyse

Verbessern

Service Improvement Plan

Service Transition-Prozesse

Das wesentliche Element von Continual Service Improvement ist die Messung von IT Services, Prozessen und Service Assets. Der Hauptgrund für Messungen besteht darin, die gesetzten Ziele erreichen zu können. Durch Messungen werden mögliche Abweichungen frühzeitig erkannt, und das Management ist in der Lage, frühzeitig gegensteuern zu können. Andererseits kann eine Übererfüllung vermieden und so die Effizienz sichergestellt werden. Darüber hinaus können Messungen auch den Erfolg durchgeführter Maßnahmen bestätigen und so für das Reporting gegenüber dem Kunden oder innerhalb des Service Providers genutzt werden. Ein wichtiger Ausgangspunkt, um einen Verbesserungsbedarf herauszustellen und den Erfolg einer durchgeführten Verbesserung zu bestätigen, besteht in der Etablierung einer definierten Ausgangsbasis (Baseline).

44

2.4 Die Struktur gemäß ITIL Version 3 Baseline: Ein Benchmark, der als Referenzpunkt verwendet wird. Beispiel: Mit einer ITSM-Baseline als Ausgangspunkt können die Folgen eines Serviceverbesserungsplans gemessen werden. Mit einer Performance Baseline können Änderungen in der Performance während der Lebensdauer eines IT Service gemessen werden.

Der „7-Step Improvement-Prozess“ ist der primäre Prozess innerhalb des Continual Service Improvement (Einzelheiten zum Prozess siehe Abschnitt „2.5.2.5 Continual Service Improvement“). Dieser Prozess hat zum Ziel, über Daten zu gesicherten Informationen zu gelangen. Durch Analyse dieser Informationen sind anschließend geeignete Verbesserungsmaßnahmen zu implementieren. Im Rahmen dieses „7-Step Improvement-Prozesses“ werden sowohl strategische, als auch taktische und auch operative Ziele verfolgt und beleuchtet, die innerhalb von Service Strategy und Service Design definiert wurden. Die identifizierten Verbesserungsmaßnahmen werden in dem Service Improvement-Plan (SIP) dokumentiert; einem Dokument, das ebenfalls in Qualitätsmanagementsystemen wie der ISO 9001 und der ISO 20000 gefordert wird. Wichtig für das Selbstverständnis dieser Phase des Service Lifecycle ist auch hier Business-Orientierung. Diese Orientierung zum Kunden und dessen Geschäftsprozessen besteht im Wesentlichen aus zwei Betrachtungsbereichen. Eine Messung der IT-Systeme hinsichtlich der Verfügbarkeit und Performance ist für jeden Service Provider selbstverständlich. ITIL spricht hier von technologischen Messungen. Auch die Messung der IT Service Management-Prozesse findet zunehmend Anwendung, die so genannten Prozess-Messungen. Aber hierbei handelt es sich in der Regel um eine ITinterne Sicht und Messung. Für den Kunden ist es viel wichtiger, ob die gelieferten IT Services den Vereinbarungen entsprechen und die Service Level-Ziele erreicht werden. Hierzu ist eine Messung der IT Services (aus Sicht des Kunden bzw. Geschäftsprozesses) notwendig. ITIL betont hier: Service-Messungen: Diese Messungen sind das Ergebnis eines „end-to-end“-Service.

Ohne funktionierende IT Services können viele Geschäftsprozesse nicht mehr durchgeführt werden. Daher ist die Messung einzelner Komponenten wie Server oder Datenbanken nicht mehr ausreichend. Der IT Service ist als Ganzes zu betrachten und zu messen. Die folgenden drei Messungen finden hierbei in der Regel ihre Anwendung:

45

2 IT Service Management – Verfügbarkeit – Zuverlässigkeit – Performance Der zweite Betrachtungsbereich in Richtung des Kunden und dessen Geschäftsprozessen sind die umzusetzenden Verbesserungsmaßnahmen. Zielsetzung des Continual Service Improvement ist nicht eine optimierte IT, sondern eine optimierte Integration der IT Services in die Business Prozesse und deren Anforderungen. Demzufolge ist der Kunde bzw. sind die Geschäftsbereiche in den Entscheidungsprozess der umzusetzenden Verbesserungsmaßnahmen unbedingt einzubeziehen. Letztendlich kann nur mit dem Kunden gemeinsam entschieden werden, welche Verbesserungsmaßnahmen den größten geschäftlichen Nutzen bringen. Eine Schlüsselrolle nimmt dabei das Service Level Management ein. Mit dem Abschluss von Service Level Agreements (SLAs) werden mit dem Kunden eindeutige Service Level-Ziele vereinbart. Vor dem Abschluss dieser SLAs ist zu prüfen, ob die definierten Ziele überhaupt messbar sind. Im Rahmen der Lieferung des IT Service sind die erbrachten Service Level zu messen, zu berichten und zu überprüfen. Mit dem Service Reporting enthält das Continual Service Improvement einen Prozess, der für die Erstellung und Bereitstellung von Berichten zu den IT Services und den erzielten Service Level verantwortlich ist. Die Kunden- und Geschäftsprozessorientierung findet Berücksichtigung in der Forderung nach Abstimmung mit dem Kunden bezüglich Format, Inhalt und Häufigkeit der Berichte. Die Ausrichtung des Service Reportings an der Sicht des Kunden bzw. an dessen Geschäft ist der folgenden Abbildung 26 zu entnehmen (aus [OGC, 2007e]). Von wesentlicher Bedeutung ist es, die gesammelten (technischen) Daten so aufzubereiten und so zu präsentieren, dass sie der Sicht des Geschäfts entsprechen und von „Nicht IT-Mitarbeitern“ verstanden werden können.

46

2.4 Die Struktur gemäß ITIL Version 3

Das Business Definition Reporting Policies und Rollen Sammlung

Businesssichten

Service Reporting

Übersetzung und Anwendung

Publikation

Abbildung 26:

Service Reporting orientiert am Kundenbedarf

Das Continual Service Improvement hat vielfältige Schnittstellen zu den anderen Phasen des Service Lifecycle. Ein Schlüsselprozess ist der bereits beschriebene Prozess des Service Level Managements. Eine weitere wichtige Schnittstelle besteht zum Service Design, denn dort sind die notwendigen Messverfahren beim Design des IT Service zu berücksichtigen und zu entwickeln.

2.4.7

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 „Service Portfolio Managements“ und des „Demand Managements“, die ebenfalls als Prozesse anzusehen sind.

47

2 IT Service Management 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 Organisationen bereits so implementiert sind, wie zum Beispiel das „Event Management“ zur Entdeckung und Interpretation von Ereignissen, die über entsprechende 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]): Prozess: „Ein strukturierter Satz an Aktivitäten, mit deren Hilfe ein bestimmtes Ziel erreicht werden soll. Ein Prozess wandelt einen oder mehrere definierte Inputs in definierte Outputs um. Ein Prozess kann beliebige Rollen, Verantwortlichkeiten, Hilfsmittel und Steuerungen für das Management enthalten, die für eine zuverlässige Bereitstellung der Outputs erforderlich sind. Ein Prozess kann den Anforderungen entsprechend Richtlinien, Standards, Leitlinien, Aktivitäten und Arbeitsanweisungen definieren.“

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 27).

48

2.4 Die Struktur gemäß ITIL Version 3 ProzessOwner

ProzessDokumentation Trigger

ProzessZiele ProzessPolicy

ProzessFeedback

Prozesssteuerung

ProzessAktivitäten

ProzessInput

ProzessProzeduren

ProzessRollen

ProzessMetriken Prozess-Arbeits -anweisungen

ProzessImprovement

Prozessdurchführung

ProzessOutput inklusive Prozess-Reports und -Reviews

Prozessbedingungen ProzessRessourcen

Abbildung 27:

ProzessBefähigungen

ITIL Version 3 Prozessmodell

Die Betrachtungsbereiche „Prozesssteuerung“ (Process Control), „Prozessdurchführung“ (Process) und „Prozessbedingungen“ (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 „Prozesssteuerung“. ITIL Version 3 definiert diesen Aufgabenbereich wie folgt (vgl. „Service Design“, [OGC, 2007b): Prozesssteuerung: „Die Aktivität der Planung und Regulierung eines Prozesses, mit dem Ziel, den Prozess effektiv, effizient und konsistent 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.

49

2 IT Service Management ITIL Version 3 sieht in den Prozessen entsprechende Metriken vor, die als Prozesskennzahlen 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. Die Vielzahl mag den Eindruck erzeugen, hierfür auch eine Vielzahl von Mitarbeitern mit deren Verantwortung betrauen zu müssen. Dabei betont ITIL ausdrücklich, dass ein Mitarbeiter durchaus die Verantwortung mehrerer Prozesse wahrnehmen kann. Dabei muss allerdings sichergestellt werden, dass diese Prozesse nicht zu einem Interessenkonflikt führen. Rollen: Ein Satz von Verantwortlichkeiten, Aktivitäten und Kompetenzen, die einer Person oder einem Team zugewiesen sind. Eine Rolle wird in einem Prozess definiert. Einer Person oder einem Team können mehrere Rollen zugewiesen sein. Die Rolle des Configuration Managers und des Change Managers können beispielsweise von ein und derselben Person wahrgenommen werden.

Bezüglich der Verantwortung für die Prozesse stellt die ITIL Version 3 folgende Anforderungen (vgl. „Service Design“, [OGC, 2007b): Jedem Prozess ist ein Process Owner2 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.

2

50

Im deutschen Glossar wird die Rolle als „Process Owner“ definiert und nicht als „Prozess Owner“

2.4 Die Struktur gemäß ITIL Version 3 Während in der ITIL Version 2 keine exakte Definition und Beschreibung für den Process Owner und Prozess-Manager existieren, werden in der ITIL Version 3 diese Rollen definiert und unterschieden: Process Owner: “Eine Rolle, verantwortlich für die Sicherstellung der Zweckmäßigkeit eines Prozesses. Zu den Verantwortlichkeiten des Process Owners gehören das Sponsoring, das Design, das Change Management sowie die kontinuierliche Verbesserung des Prozesses und seiner Messgrößen. Diese Rolle wird häufig derselben Person zugewiesen, der bereits die Rolle des Prozess-Managers zugewiesen ist. In größeren Organisationen können diese Rollen jedoch separat zugewiesen sein.” Prozess-Manager: “Eine Rolle, die für das operative Management eines Prozesses verantwortlich ist. Zu den Verantwortlichkeiten des Prozess-Managers gehören die Planung und die Koordination aller Aktivitäten, die zur Ausführung, dem Monitoring und der Berichtserstellung in Bezug auf einen Prozess erforderlich sind. Es können mehrere Prozess-Manager für einen Prozess vorhanden sein, z. B. regionale Change Manager oder IT Service Continuity Manager für jedes Rechenzentrum. Die Rolle des Prozess-Managers wird häufig der Person zugewiesen, der bereits die Rolle des Process Owners zugewiesen ist. In größeren Organisationen können diese Rollen jedoch separat zugewiesen sein.”

Um das Zusammenspiel zwischen den Prozessen und der Aufbauorganisation zu beschreiben, nutzt ITIL hierfür den Begriff der Funktion. Funktion: Ein Team oder eine Gruppe von Personen und die Hilfsmittel, die eingesetzt werden, um einen oder mehrere Prozesse oder Aktivitäten durchzuführen. Ein Beispiel dafür ist das Service Desk.

Diese Funktionen (Organisationseinheiten) sind ausgestattet mit Fähigkeiten und Ressourcen (Service Assets) und bringen Struktur und Stabilität in die IT-Organisation. In der Regel wurden Funktionen technologisch definiert, wie zum Beispiel die Gruppe für das LAN. Dadurch besteht aber auch die Gefahr der Bildung von Funktionssilos, die den externen Bezug verlieren und eine Tendenz zur internen Optimierung bilden. Durch die Prozesse wird eine Koordination zwischen Funktionen ermöglicht, werden die IT Services den Bezug zum Kunden sicherstellen.

51

Process Owner und ProzessManager

2 IT Service Management

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 Unterkapitel 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

In ITIL und COBIT sind viele Kennzahlen dokumentiert. Wir beschränken uns hier 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 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: – Anzahl der aufgetretenen Störungen – Durchschnittliche Zeitdauer bis zur Behebung oder Umgehung der Störung in Relation zur Priorität

52

2.5 ITIL Kennzahlen für IT Service Management-Prozesse – 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 (d.h. ohne Vor-OrtSupport) 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); d.h. 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

Configuration Management Das Configuration Management dient der Definition, Kontrolle, Pflege und Verifizierung der Service- und Infrastrukturkomponenten sowie der Verwaltung korrekter Konfigurationsinformationen.

53

2 IT Service Management 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 Produktionsumgebung 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:

54

2.5 ITIL Kennzahlen für IT Service Management-Prozesse – – – – –

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. 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

55

2 IT Service Management – 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örungen 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, Vertraulichkeit und Integrität, als Service Level-Ziele innerhalb der SLAs mit dem Kunden vereinbart werden. Diese Sicherheitsanforderungen gehen ein in die OLAs (Operational Level Agreements) und UCs (Underpinning Contracts).

56

2.5 ITIL Kennzahlen für IT Service Management-Prozesse Die Leistungsindikatoren des Security-Managements entsprechen demzufolge den übrigen Service Level-Zielen 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

Prozesse und 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 28 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 bearbeitet oder Aufgaben des Service Level Managements aus der ITIL Version 2 finden sich in anderen, neuen Prozessen wieder. Bei den aus der ITIL V2 bekannten Prozessen gilt es aber zu beachten, dass diese Prozesse zum Teil verändert wurden. So finden sich Inhalte aus dem Service Level Management gemäß der ITIL V2 nun in den Prozessen „Service Katalog Management“, „Service Level Management“, „Supplier Management“ und „Service Reporting“ 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. 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.

57

2 IT Service Management

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 28:

58

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 Lifecycle und ihre Prozesse

2.5 ITIL Kennzahlen für IT Service Management-Prozesse

2.5.2.1 Service Strategy

Service Portfolio M.

Demand M.

Service

Strategy Financial Management

Abbildung 29:

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. Innerhalb der Service Strategy werden in ITIL V3 zu den Prozessen keine Kennzahlen ausgewiesen.

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 zugrunde liegende IT. Auf strategischer Ebene ist über die Entwicklung von IT Services und den damit verbundenen Mehrwert zu entscheiden. Hierzu ist für den jeweiligen IT Service der Business Case zu betrachten. Der Business Case beinhaltet Informationen zu Kosten, Nutzen, Optionen, offenen Punkten, Risiken und möglichen Problemen.

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 des erhaltenen IT Service und ermöglicht die Modellierung und das Management von Service-Anforderungen.

59

2 IT Service Management Das Financial Management ist innerhalb von Service Strategy beschrieben, aber die finanziellen Aspekte sind grundsätzlich ein übergreifendes Thema, in dem viele Bereiche eines Unternehmens interagieren wie zum Beispiel das Change Management in der Bewertung von Requests for Change (RfC). Durch diesen übergreifenden Ansatz des Financial Managements wird sichergestellt, dass die Investitionen in IT Services so getätigt werden, dass der gesamte Wert und die gesamten Kosten über den gesamten Service Lifecycle betrachtet werden. Ein wichtiger Nutznießer des Financial Managements ist das Service Portfolio Management. Auf Basis der Informationen aus dem Financial Management können zum Beispiel Entscheidungen über ein Outsourcing von Leistungen besser getroffen werden. Financial Management: Die Funktionen und die Prozesse mit der Verantwortung für den Umgang mit den Anforderungen eines IT Service Providers an die Budgetierung, die Kostenrechnung und die Leistungsverrechnung.

Service Portfolio Management Ein Serviceportfolio beschreibt die IT Services eines IT Service Providers im Hinblick auf deren Wert für die Geschäftsprozesse (Business Value). Service Portfolio Management formuliert die geschäftlichen Anforderungen und ist die Antwort des IT Service Providers auf diese Bedürfnisse. Die Definition des Serviceportfolios ist eine der wichtigsten Aufgaben innerhalb von Service Strategy. Das Serviceportfolio enthält nicht nur alle in Nutzung befindlichen IT Services (= Servicekatalog), sondern auch alle beantragten und in Entwicklung befindlichen IT Services (= Servicepipeline) sowie sämtliche IT Services, die außer Kraft gesetzt sind. Mit dem Service Portfolio Management stellt der IT Service Provider die mittel- und langfristige wirksame Integration seiner IT Services in die Geschäftsprozesse des Kunden und die Generierung eines Mehrwertes für die Business-Prozesse sicher. Der IT Service Provider wird so in die Lage versetzt, frühzeitig seine IT Services an den Marktanforderungen auszurichten. Aber auch nicht mehr bzw. zukünftig nicht mehr gefragte IT Services werden identifiziert und deren Außerkraftsetzung festgelegt. Damit verbunden werden Ressourcen freigesetzt, die für andere IT Services genutzt werden können, und ansonsten notwendige Investitionen werden vermieden. Der Prozess besteht aus den Aktivitäten „Definition“, „Analyse“, „Freigabe“ und „Ausgestaltung“. Innerhalb der „Definition“ gilt es, die bestehenden IT Services und Anforderungen zu analysieren. Hierzu wird für

60

2.5 ITIL Kennzahlen für IT Service Management-Prozesse jeden IT Service der Business Case definiert. Bei der „Analyse“ wird der Inhalt der Servicestrategie festgelegt. Hierzu werden die langfristigen Ziele festgelegt und ermittelt, welche IT Services hierzu notwendig sind. In Verbindung mit diesen IT Services sind die damit verbundenen Ressourcen und Fähigkeiten zu spezifizieren. Mit einer Betrachtung zwischen dem Wert für das Business und den damit in Verbindung stehenden Kosten können IT Services priorisiert werden. Die „Freigabe“ stellt die Autorisierung des Serviceportfolios sicher. Nach der „Freigabe“ stellt die Aktivität „Ausgestaltung“ sicher, dass die IT Services kommuniziert und die damit verbundenen Ressourcen eingeplant werden. Das Serviceportfolio wird für das Management über den gesamten Lifecycle aller IT Services genutzt. Service Portfolio Management: Der Prozess, der für das Management des Serviceportfolios verantwortlich ist. Beim Service Portfolio Management steht der Wert der Services im Vordergrund, den diese für das Business darstellen.

Demand Management Demand Management 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.

Ausgangspunkt des Demand Managements sind die Business Prozesse und deren Aktivitäten. Auf Basis einer differenzierten Analyse der Servicenachfrage einzelner Businessaktivitäten können zum Beispiel die IT Services innerhalb von „Service Design“ besser entwickelt werden, und das Service Portfolio Management kann Investitionen in zusätzliche Kapazitäten, neue IT Services oder zu ändernde IT Services rechtfertigen. Mit der Identifizierung der zukünftigen Aktivitäten innerhalb der Business-Prozesse liefert das Demand Management einen wichtigen Beitrag zur angemessenen Ausgestaltung der IT Services. Überkapazitäten werden vermieden und dadurch die Kosten für den jeweiligen IT Service reduziert. Andererseits werden Unterkapazitäten vermieden, so dass die Business Prozesse nicht in Mitleidenschaft gezogen und planmäßig durchgeführt werden können.

61

2 IT Service Management Demand Management: Aktivitäten, die sich mit dem Bedarf des Kunden an Services befassen und auf diesen Bedarf sowie auf die Bereitstellung der Kapazität Einfluss nehmen, um diesem Bedarf gerecht zu werden. Auf strategischer Ebene kann das Demand Management die Analyse von Business-Aktivitätsmustern und Anwenderprofilen einbeziehen. Auf taktischer Ebene kann es eine differenzierte Leistungsverrechnung einsetzen, um die Nutzung von IT Services bei den Kunden zu Zeiten mit einer geringeren Auslastung zu fördern. Aktivitäten, die sich mit dem Bedarf des Kunden an Services befassen und auf diesen Bedarf sowie auf die Bereitstellung der Kapazität Einfluss nehmen, um diesem Bedarf gerecht zu werden. Auf strategischer Ebene kann das Demand Management die Analyse von Business-Aktivitätsmustern und Anwenderprofilen einbeziehen. Auf taktischer Ebene kann es eine differenzierte Leistungsverrechnung einsetzen, um die Nutzung von IT Services bei den Kunden zu Zeiten mit einer geringeren Auslastung zu fördern.

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 30:

62

Service Design

2.5 ITIL Kennzahlen für IT Service Management-Prozesse

Service Catalogue Management Ziel des Prozesses Service Catalogue Management (SCM) ist die Erstellung und Pflege eines Servicekatalogs 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 Serviceportfolios anzusehen. Der Servicekatalog enthält Angaben zu Lieferergebnissen, Preisen, Bestellungen und Anfragen sowie Kontaktinformationen zu allen Live IT Services, einschließlich der Services, die für das Deployment verfügbar sind. Es ist der Bereich des Serviceportfolios, der von den Kunden eingesehen werden kann. Aber nicht nur für den Kunden und den Vertrieb von IT Services ist der Servicekatalog von Bedeutung. Der Servicekatalog sollte strukturiert aufgebaut werden. Der so genannte „Business-Servicekatalog“ beinhaltet die Details aller IT Services, die den Kunden geliefert werden, und stellt die Beziehungen zwischen den IT Services und den davon abhängigen Geschäftsbereichen und Business Prozessen dar. Nur dieser Bereich ist für den Kunden sichtbar. Ein „Technischer Servicekatalog“ untermauert den Business-Servicekatalog mit den notwendigen technischen IT Services, die die Business-Services ermöglichen. Der „Technische Servicekatalog“ enthält Details zu allen IT Services sowie die Beziehungen zu den unterstützenden Services, CIs, etc., die notwendig sind, den IT Service für das Business bereitzustellen. Das Service Katalog Management stellt sicher, dass sowohl die Inhalte, als auch die hinterlegte Struktur erstellt und gepflegt werden. Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel: – die Anzahl der aufgenommenen und verwalteten Services innerhalb des Servicekatalogs als Prozentsatz der Services, die ausgeliefert und übergeben wurden und sich in der „Live-Umgebung“ befinden – die Anzahl von Abweichungen zwischen den Informationen im Servicekatalog 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-Ziel). 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.

63

2 IT Service Management Das Service Level Management repräsentiert den IT Service Provider gegenüber dem Business und das Business gegenüber dem IT Service Provider. Mit der Verantwortlichkeit für das Verhandeln von Service Level Agreements (SLAs) sowie deren Einhaltung liefert dieser Prozess einen wichtigen Beitrag für die Kundenzufriedenheit und das Vertrauen des Kunden in die Servicequalität. Damit die mit dem Kunden vereinbarten SLAs eingehalten werden können und die am IT Service beteiligten Parteien ihre Leistungen besser planen können, werden intern Operational Level Agreements (OLAs) und extern Underpinning Contracts (UCs) abgeschlossen. In Verbindung mit den Underpinning Contracts arbeitet das Service Level Management mit dem Supplier Management zusammen. Dieser Prozess arbeitet eng mit dem Continual Service Improvement (CSI) zusammen. Die vereinbarten Service Level-Ziele sind vom IT Service Provider zu messen und dem Kunden regelmäßig zu berichten. Daher muss vor dem Abschluss sichergestellt sein, dass die vereinbarten Service Level gemessen werden können. Eine weitere Schnittstelle besteht zum Service Reporting, das für das Reporting zu Ergebnissen und Trends hinsichtlich bestimmter Service Level verantwortlich ist. Beim Service Reporting sollten das Format, der Inhalt und die Häufigkeit der Berichte zuvor mit den jeweiligen Kunden abgesprochen werden und so in die SLAs eingehen. Service Level Management (SLM): Der Prozess, der für das Verhandeln von Service Level Agreements sowie deren Einhaltung verantwortlich ist. Das SLM soll sicherstellen, dass alle IT Service Management-Prozesse, Operational Level Agreements und Underpinning Contracts für die vereinbarten Service Level-Ziele angemessen sind. SLM ist für das Monitoring und die Berichterstattung in Bezug auf Service Level sowie für die regelmäßige Durchführung von Kunden-Reviews zuständig.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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.

64

2.5 ITIL Kennzahlen für IT Service Management-Prozesse

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. Hierzu muss das Capacity Management hinsichtlich der „Kosten und Kapazitäten“ sowie „Angebot und Bedarf“ einen Balanceakt durchführen. Einerseits muss das Capacity Management sicherstellen, dass die Verarbeitungskapazitäten zu vertretbaren Kosten dem Bedarf des Business nachkommen und möglichst effizient genutzt werden. Andererseits ist es die Aufgabe, dass das verfügbare Angebot der Verarbeitungsleistungen dem aktuellen und zukünftigen Bedarf des Business gerecht wird. Hierzu finden im Capacity Management drei Sub-Prozesse ihre Anwendung: Business Capacity Management (BCM): Im Kontext von ITSM die verantwortliche Aktivität, um die zukünftigen Business-Anforderungen für die Verwendung im Capacity-Plan nachzuvollziehen. Service Capacity Management (SCM): Dient der Gewinnung von Erkenntnissen zur Performance und Kapazität von IT Services. Die Ressourcen, die von jedem IT Service verwendet werden, werden für die Nutzung im Capacity-Plan erfasst, aufgezeichnet und analysiert. Component Capacity Management (CCM): Verantwortlich für die Aspekte der Kapazität, Auslastung und Performance von Configuration Items. Hier werden Daten im Capacity-Plan gesammelt, erfasst und analysiert.

Die Messung und die Trendverfolgung bestehender Kapazitäten und der erzielten Performance ist die Grundvoraussetzung für diesen Prozess. Das Review derzeitiger Kapazitäten und Performance liefert den Input für deren Verbesserung. Die Beurteilung neuer Anforderungen ermöglicht eine rechtzeitige Planung neuer Kapazitäten, verhindert Panikkäufe und liefert so einen wichtigen Beitrag für kostenwirksame IT Services. Andererseits werden Performance-Engpässe vermieden. Capacity Management: Der Prozess, bei dem sichergestellt wird, dass die Kapazität der IT Services und die IT-Infrastruktur ausreicht, um die vereinbarten Service Level-Ziele wirtschaftlich und zeitnah erreichen zu können. Beim Capacity Management werden

65

2 IT Service Management alle Ressourcen, die für die Erbringung von IT Services erforderlich sind, sowie Pläne für kurz- mittel- und langfristige Business-Anforderungen berücksichtigt.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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.) – 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. Ausgehend von den Geschäftsanforderungen ist die Verfügbarkeit eines IT Service der Kern der Kundenzufriedenheit und des Geschäftserfolgs. Ist ein IT Service nicht verfügbar, so kann in vielen Fällen der Geschäftsprozess nicht mehr durchgeführt werden, und es entsteht ein unmittelbarer Schaden für das Unternehmen. Eine schlechte Performance wird von den Anwendern und Kunden ebenfalls als Nicht-Verfügbarkeit angesehen und sollte dementsprechend bei der Definition der Verfügbarkeit berücksichtigt werden. Bei der Definition der Verfügbarkeit wird der Bezug auf die Geschäftsprozesse des Kunden deutlich: Verfügbarkeit (Availability): Fähigkeit eines Configuration Items oder IT Service, bei Bedarf die dafür vereinbarte Funktion auszuführen. Die Verfügbarkeit wird durch Aspekte in Bezug auf Zuverlässigkeit, Wartbarkeit, Servicefähigkeit, Performance und Sicherheit bestimmt.

66

2.5 ITIL Kennzahlen für IT Service Management-Prozesse Die Verfügbarkeit wird in der Regel als Prozentwert ausgedrückt, der häufig basierend auf der vereinbarten Servicezeit und der Ausfallzeit berechnet wird. Gemäß der Best Practice wird die Verfügbarkeit mithilfe von Messgrößen aus dem Business-Ergebnis des IT Service berechnet.

Zur Sicherstellung der notwendigen Verfügbarkeit werden innerhalb des Availability Managements so genannte reaktive und proaktive Aktivitäten durchgeführt. Innerhalb der reaktiven Aktivitäten ist die Verfügbarkeit der IT Services und IT-Komponenten zu messen, zu überwachen, zu analysieren und zu berichten. Werden dabei Nicht-Verfügbarkeit für IT Services und ITKomponenten ermittelt, so sind geeignete Abhilfemaßnahmen zu entwickeln. Innerhalb der proaktiven Aktivitäten besteht eine wichtige Aufgabe in der Durchführung eines Risiko Assessments und dem Management der Risiken. Betreibt zum Beispiel ein Unternehmen eine Web-Plattform zur Bestellung von Artikeln und verfügt lediglich über eine Leitung zum Internet-Serviceprovider, so ist das damit in Verbindung stehende Risiko zu analysieren, und es sind mögliche Änderungen im Design zu initiieren. Eine wichtige Aufgabe kommt hier der Business-Auswirkungsanalyse (Business Impact Analysis, BIA) zu. Innerhalb der Business-Auswirkungsanalyse werden Funktionen eines Geschäftsprozesses identifiziert, die für den Erfolg des Business entscheidend sind. Das Ergebnis dieser Analyse liefert wichtige Anforderungen für das Design der Verfügbarkeit, aber auch für die Anforderungen an die Wiederherstellung, die seitens des IT Service Continuity Managements umzusetzen sind. Availability Management: Der Prozess, der für die Definition, Analyse, Planung, Messung und Verbesserung sämtlicher Aspekte in Bezug auf die Verfügbarkeit von IT Services verantwortlich ist. Im Availability Management muss sichergestellt werden, dass die gesamte IT-Infrastruktur, sowie sämtliche Prozesse, Hilfsmittel, Rollen etc. für die vereinbarten Service Level-Ziele eine entsprechende Verfügbarkeit ermöglichen.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel: – prozentuale Verringerung in der Nichtverfügbarkeit von Services und Komponenten – prozentualer Anstieg in der Verlässlichkeit von Services und Komponenten

67

2 IT Service Management – 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 (BCM)-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. Zielsetzung des IT Service Continuity Managements besteht nicht in der Überlebensfähigkeit der IT im Katastrophenfall, sondern darin, den ordnungsgemäßen Geschäftsbetrieb schnellstmöglich zu ermöglichen. Daher wird die Integration des IT Service Continuity Managements in das übergeordnete Business Continuity Management nicht nur ausdrücklich betont, sondern es wird auch die Verantwortung des Business Continuity Managements für einzelne Phasen im ITSCM-Prozess dokumentiert. Die Prozessphasen bestehen aus der „Initiierung“, „Anforderung und Strategie“, „Implementierung“ und „Laufender Betrieb“. Die Aufgaben der „Initiierung“ und „Definitionen der Anforderungen“ sind vornehmlich Aktivitäten des Business Continuity Managements. Das ITSCM sollte in dieser Phase beteiligt werden, um einerseits die Aktivitäten des BCM zu unterstützten, aber primär, um die Beziehungen zwischen den BusinessProzessen und deren Bedeutung zu verstehen. Die erste wirkliche verantwortliche Aktivität des ITSCM ist es, eine Strategie zu entwickeln, die die Strategie des BCM untermauert. Voraussetzung für ein wirkungsvolles ITSCM ist die Kenntnis der bereits im Availability Management beschriebenen Analyse der Business-Auswirkungen, wenn der vereinbarte IT Service nicht zur Verfügung gestellt werden kann. Verbunden mit einer Analyse der Risiken kann eine angemessene Strategie festgelegt werden. Innerhalb der Implementierung wird diese Strategie umgesetzt und in den laufenden Betrieb integriert. Die beste Planung wird nicht funktionieren, wenn sie nicht einmalig und laufend getestet wird. Die Durchführung laufender Tests ist eine wichtige Aufgabe des laufenden Betriebs. Der Nachweis dieser Überprüfungen findet verstärkt Berücksichtigung bei Wirtschaftsprüfungen und anderen Auditierungen oder Revisionen.

68

2.5 ITIL Kennzahlen für IT Service Management-Prozesse Weiterhin muss sichergestellt werden, dass das ITSCM in den Change Management-Prozess eingebunden wird und im Rahmen von geplanten Changes beurteilen kann, ob mögliche Auswirkungen auf den IT Service Continuity Plan bestehen. Im IT Service Continuity Plan sind die erforderlichen Schritte für eine Wiederherstellung eines oder mehrerer IT Services dokumentiert und identifizieren darüber hinaus die Bedingungen für das Auslösen des Plans sowie die zu berücksichtigenden Mitarbeiter. IT Service Continuity Management: Der Prozess, der für die Verwaltung von Risiken verantwortlich ist, die zu schwerwiegenden Auswirkungen auf IT Services führen können. Das ITSCM stellt sicher, dass der IT Service Provider stets ein Mindestmaß an vereinbarten Service Level bereitstellen kann, indem die Risiken auf ein akzeptables Maß reduziert werden und eine Wiederherstellungsplanung für IT Services erfolgt. Das ITSCM sollte so konzipiert sein, dass es das Business Continuity Management unterstützt.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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 – regelmäßige, mindestens jährliche Reviews der Business- und IT Continuity-Pläne mit den Geschäftsbereichen.

Information Security Management Informations-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. Schon aufgrund gesetzlicher Verpflichtungen kann es sich keine Organisation leisten, die damit verbundenen Aspekte nicht zu beachten. Daher ist die Information Security eine Managementaktivität und Bestandteil des "Corporate Governance Framework“. Die Information Security ist für die Assets, Informationen, Daten und IT Services einer Organisation angemessen sicherzustellen und umfasst die Aspekte der Vertraulichkeit, Integrität und Verfügbarkeit:

69

2 IT Service Management Vertraulichkeit: Ein Sicherheitsprinzip, das fordert, dass ausschließlich autorisierte Personen auf Daten zugreifen können. Integrität: Ein Sicherheitsprinzip, das sicherstellt, dass Daten und Configuration Items nur durch autorisierte Mitarbeiter und Aktivitäten modifiziert werden. Die Integrität berücksichtigt alle möglichen Ursachen einer Modifikation, wie Ausfälle von Software oder Hardware, Umgebungs-Events und Eingriffe durch Personen. Verfügbarkeit: Fähigkeit eines Configuration Items oder IT Service, bei Bedarf die dafür vereinbarte Funktion auszuführen. Die Verfügbarkeit wird durch Aspekte in Bezug auf Zuverlässigkeit, Wartbarkeit, Servicefähigkeit, Performance und Sicherheit bestimmt. Die Verfügbarkeit wird in der Regel als Prozentwert ausgedrückt, der häufig basierend auf der vereinbarten Servicezeit und der Ausfallzeit berechnet wird. Gemäß der Best Practice wird die Verfügbarkeit mithilfe von Messgrößen aus dem Business-Ergebnis des IT Service berechnet.

Das Information Security Management System (ISMS) liefert die Basis für die Entwicklung kostenwirksamer Information Security-Programme, die die Geschäftsziele unterstützen. Das System schließt die vier „Ps“ von Personen, Prozessen, Produkten und Partnern ein, um so sicherzustellen, dass ein hohes Niveau der Security erzielt wird. Mit der ISO 27001 "Information Security Management" existiert eine anerkannte Norm, um das Information Security Management zu zertifizieren und so dessen Implementierung nachzuweisen. Das Information Security Management System basiert auf einem Regelkreis, bestehend aus der „Steuerung“, „Planung”, „Implementierung“, „Evaluierung“ und „Aufrechterhaltung“. Der Input in diesen Regelkreis besteht aus den in den SLAs vereinbarten Sicherheitsanforderungen. Information Security Management: Der Prozess, bei dem die Vertraulichkeit, Integrität und Verfügbarkeit der Assets, Informationen, Daten und IT Services einer Organisation sichergestellt werden. Das Information Security Management ist in der Regel Teil eines organisatorischen Ansatzes für das Security Management, der über den Aufgabenbereich des IT Service Providers hinausgeht, und berücksichtigt die Verwaltung papierbasierter Dokumente, Zutrittsrechte, Telefonanrufe etc. für die gesamte Organisation.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:

70

2.5 ITIL Kennzahlen für IT Service Management-Prozesse – 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 die Ausgaben für die Lieferanten den gelieferten Leistungen entsprechen.

Bereits innerhalb der Service Strategy werden grundsätzliche Betrachtungen zu den Service-Strukturen angestellt und letztendlich die ServiceStruktur definiert. Verbunden mit der Zielsetzung, einen IT Service bereitzustellen, der die Business-Prozesse unterstützt, hat der IT Service Provider eine End-To-End-Verantwortung für den IT Service. Angesichts der Komplexität der einzubeziehenden technischen IT Services werden verstärkt externe Partner in den IT Service eingebunden: Eine Entwicklung, die in anderen Branchen bereits vollzogen ist. Diese Auslagerung von technischen IT Services an externe Lieferanten oder Partner ist aber mit Risiken verbunden. Einerseits muss sichergestellt werden, dass die notwendigen IT Services tatsächlich wie vereinbart geliefert werden, andererseits müssen die Kosten dem gelieferten IT Service entsprechen. Diese Aufgabe hat das Supplier Management sicherzustellen. Hierzu ist eine für die Organisation angemessene Supplier Policy zu definieren, Lieferanten sind auszuwählen und zu kategorisieren sowie die Leistungen und Abrechnungen der Lieferanten zu bewerten. Die Bewertung der Lieferanten entscheidet über die Fortführung bestehender Verträge oder deren Kündigung. Hierzu empfiehlt ITIL die Etablierung einer Supplier- und Vertragsdatenbank (Supplier and Contract Database, SCD) zum Management der Verträge während ihres gesamten Lebenszyklus. Supplier Management: Der Prozess ist verantwortlich dafür, sicherzustellen, dass alle Verträge mit Suppliern die Anforderungen des Business unterstützen und alle Supplier ihre vertraglichen Verpflichtungen erfüllen.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:

71

2 IT Service Management – 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.

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 31:

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.

Ein wirksamer Prozess Transition Planning and Support soll die Voraussetzung dafür schaffen, dass der Service Provider ein hohes Volumen von Changes und Releases bearbeiten kann. Hierzu ist die Planung von Kapazitäten und Ressourcen für die Inbetriebnahme von neuen oder geänderten Services erforderlich, so dass die Anforderungen aus Service Strategy und Service Design umgesetzt werden können. Der Prozess Transition Planning and Support deckt dazu die notwendigen Planungen im Vorfeld der Einführung von Changes und Releases ab. Um diese Anforderungen bzw. Ziele erfüllen zu können, empfiehlt ITIL eine „Service Transition Policy“ formal zu vereinbaren. Darin soll unter anderem geregelt werden, dass alle Veränderungen (= Changes) am Service Portfolio und insbeson-

72

2.5 ITIL Kennzahlen für IT Service Management-Prozesse dere am Service Katalog über das Change Management umgesetzt werden. Dadurch soll eine frühzeitige Einbindung in den Service Lifecycle und die Ausrichtung der Transition Pläne an den Business-Anforderungen sichergestellt werden. Eine wichtige Aktivität besteht in der Definition einer Service TransitionStrategie. Diese Strategie definiert den umfassenden Ansatz zur Organisation der Service Transition und Ressourcenzuordnung und berücksichtigt unter anderem die folgenden Aspekte: – – – – – – – –

Zweck und Ziele Kontext (Kunden, Verträge etc.) Relevante Standards, Vereinbarungen, Gesetze und Verträge Identifizierung der Anforderungen und Inhalte von neuen oder geänderten Services Personal (Verantwortlichkeit, Ausbildung etc.) Ergebnisse der Aktivitäten mit obligatorischen und optionalen Dokumentationen Meilensteinplanung Finanzielle Mittel (Budget)

Zu den weiteren Aktivitäten im Prozess gehören die Vorbereitungen, die integrierte Planung und die Unterstützung der einzelnen TransitionProzesse. Transition Planning and Support: Der Prozess, der für die Planung aller Service Transition-Prozesse und die Koordinierung der hierfür benötigten Ressourcen verantwortlich ist. Zu diesen Service Transition-Prozessen zählen Change Management, Service Asset and Configuration Management, Release and Deployment Management, Service Validation and Testing, Evaluation und Knowledge Management.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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.

73

2 IT Service Management

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 Änderungsanforderungen des Business und der IT sorgen für eine Ausrichtung der Services am Bedarf des Business. Das Ziel des Change Management-Prozesses ist sicherzustellen, dass Changes in einer gesteuerten Art und Weise aufgezeichnet und dann beurteilt, autorisiert, priorisiert, geplant, getestet, implementiert, dokumentiert und überprüft werden. Das Change Management steuert Changes auf verschiedenen Ebenen. Die Ebenen bestehen aus „Operationelle Changes“, „Service Changes“ und „Strategische Changes“. Die Changes auf den verschiedenen Ebenen werden folgendermaßen eingebracht: – Strategische Changes über Service Strategy und den Business Releationship Management-Prozess – Service Changes über Service Design, Continual Service Improvement und den Service Level Management-Prozess – Operative Changes über Service Operation. In Abhängigkeit der jeweiligen Ebene, den mit dem Change verbundenen Risiken und den Ergebnissen sind verschiedene Entscheidungshierarchien in der Autorisierung des Change involviert. Die Zielsetzung besteht in der Sicherstellung, dass die Changes keine negativen Auswirkungen auf den IT Service und die Business-Prozesse haben. Ein zu administratives Change Management verleitet zur Umgehung des Prozesses und gefährdet die Zielerreichung. Mit den verschiedenen Arten von Changes beschreibt ITIL eine Vorgehensweise, die ein wirksames und dennoch nicht zu administratives Management sicherstellt. Hierzu wird zwischen „Normaler Change“, „Notfall Change“ und „Standard Change“ unterschieden. Je nach Art des Changes finden dann verschiedene Workflows ihre Anwendung. Insbesondere der „Standard Change“ verringert die mit dem Change verbundenen Aufwendungen. Dabei handelt es sich um einen vorab genehmigten Change, der von geringem Risiko ist und relativ häufig eingesetzt wird und in der Umsetzung einem bestimmten, zuvor festgelegten Workflow folgt. Change Management: Der Prozess, der für die Steuerung des Lebenszyklus aller Changes verantwortlich ist. Wichtigstes Ziel des Change Managements ist es, die Durchführung von

74

2.5 ITIL Kennzahlen für IT Service Management-Prozesse lohnenden Changes bei einer minimalen Unterbrechung der IT Services zu ermöglichen.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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 an 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 and Configuration Management liefert ein logisches Modell der IT-Infrastruktur und stellt – falls erforderlich – den Zusammenhang zwischen den IT Services mit notwendigen IT-Komponenten her.

Durch diese Bereitstellung von Informationen für den gesamten Service Lifecycle unterstützt das Service Asset and Configuration Management (SACM) unter anderem bei der Beurteilung der Auswirkung und Ursache von Incidents und Problemen, bei der Beurteilung der Auswirkung von Changes, bei der Planung und Design neuer oder geänderter Services und der Planung der Aktualisierung von Technologie und Software. Darüber hinaus liefert das Service Asset and Configuration Management – analog zum Change und IT Service Continuity Management – einen wichtigen Beitrag zum Nachweis der Einhaltung von Compliance Anforderungen. Die Configuration Items können nach den folgenden Aspekten kategorisiert werden. Die Auflistung dieser Aspekte vermittelt einen Eindruck über den Geltungsbereich des Configuration Managements: – Service Lifecyle CIs, wie der Business Case oder der Service Management-Plan – Service CIs, wie die Service-Fähigkeiten (Organisation, Prozesse, Personen, etc.) und die Service Ressourcen (Systeme, Applikationen, etc.)

75

2 IT Service Management – Organisatorische CIs, wie zum Beispiel Dokumentationen wie Policies – Interne CIs, wie Software, um den Service bereitstellen zu können – Externe CIs, wie Service Level Anforderungen – Schnittstellen CIs, die notwendig für einen „end-to-end“-Service sind. Diese Kategorien und die Definition des Configuration Items (CI) zeigen deutlich, dass das Configuration und Service Asset Management erheblich mehr ist, als die Verwaltung von Hard- und Software. Die Prozessaktivitäten bestehen aus „Management und Planung“, „Configuration Identifizierung“, „Configuration Steuerung (Control)“, „Status Accounting und Reporting“ sowie „Verfikation und Audit“. Service Asset and Configuration Management: Der Prozess, der sowohl für das Configuration Management als auch das Asset Management verantwortlich ist. Asset Management: Das Asset Management ist der Prozess, der für die Verfolgung der Werte und Besitzverhältnisse in Bezug auf finanzielle Assets sowie deren Erfassung in Berichten während ihres gesamten Lebenszyklus verantwortlich ist. Configuration Management Der Prozess, der für die Pflege von Informationen zu Configuration Items einschließlich der zugehörigen Beziehungen verantwortlich ist, die für die Erbringung eines IT Service erforderlich sind. Diese Informationen werden über den gesamten Lebenszyklus des CI hinweg verwaltet.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel: – prozentuale Verbesserung bei der Zeitplanung für Wartungsarbeiten eines Assets (nicht zu viel, nicht zu 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.

76

2.5 ITIL Kennzahlen für IT Service Management-Prozesse

Release and Deployment Management Das Ziel von Release and Deployment Management ist die Auslieferung und Überführung von Releases in die Produktion. Hier werden die Services den Kunden zur Verfügung gestellt und sichergestellt, dass die Services sinnvoll und produktiv genutzt werden können. Das Ziel des Release and Deployment Managements ist es unter anderem, genaue und umfassende Release und Deployment-Pläne zu erstellen, die den Kunden- und Business Change-Projekten ermöglichen, ihre Aktivitäten mit diesen Plänen auszurichten. Für das Verständnis und die Zielsetzung ist es wichtig, die Definition eines Release zu betrachten. Bei diesem handelt es sich um eine Zusammenstellung von Hardware, Software, Dokumentation, Prozessen oder anderen Komponenten, die für die Implementierung eines oder mehrerer genehmigter Changes an IT Services erforderlich sind. Aus dieser Definition wird deutlich, dass das Change Management verantwortlich für die Genehmigung von Changes ist. Das Release and Deployment Management ist dagegen für die Steuerung des Übergangs in die Live-Umgebung verantwortlich. Eine wichtige Aufgabe besteht dabei in der Definition der Release Units. Dabei handelt es sich um Komponenten eines IT Service, die üblicherweise im selben Release veröffentlicht werden. Eine Release Unit umfasst in der Regel genügend Komponenten, um eine nützliche Funktion auszuführen. Eine Release Unit könnte zum Beispiel die gesamte Anwendung für die Lohnbuchhaltung sein, einschließlich IT-Betriebsverfahren und Anwendertrainings. Basis der Prozessaktivitäten ist die Release Policy. Die Release Policy beinhaltet für einen oder mehrere Services unter anderem die folgenden Definitionen: – eindeutige Identifikation, Nummerierung und Namenskonventionen – Die Rollen und Verantwortungen in jeder Prozessphase – die Frequenz von Releases – Mechanismus zur Automatisierung von „Build“, „Installation“ und „Release-Verteilung“ – Kriterien für die Autorisierungen im Prozess – Kriterien und Berechtigungen, um den Early-Life Support zu beenden und an Service Operation zu übergeben. Diese Release Policy ist mit dem Kunden bzw. auf die Business-Prozesse abzustimmen.

77

2 IT Service Management Jedes Release durchläuft die Prozessaktivitäten „Planung“, „Vorbereiten von Build, Test und Deployment“, „Build und Test“, „Service Tests und Piloten“, „Planung und Vorbereitung Deployment“, „Durchführung Transfer, Deployment und Außerkraftsetzung“, „Early-Life Support“ und „Review und Abschluss Deployment“. Hier ist zu beachten, dass ein Release nicht mit dem Deployment abgeschlossen ist, sondern der Early Life Support und das Review die Prozessaktivitäten abschließen. Release and Deployment Management: Der Prozess, der sowohl für das Release Management als auch für das Deployment verantwortlich ist. Release Management: Der Prozess, der für die Planung, den zeitlichen Ablauf und die Steuerung des Übergangs von Releases in Test- und Live-Umgebungen verantwortlich ist. Das wichtigste Ziel des Release Managements ist es, sicherzustellen, dass die Integrität der Live-Umgebung aufrechterhalten wird und dass die richtigen Komponenten im Release enthalten sind. Deployment: Die Aktivität, die für den Übergang neuer oder geänderter Hardware, Software, Dokumentation, Prozesse etc. in die Live-Umgebung verantwortlich ist.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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.

Dieser Prozess soll das Vertrauen des Business in die Erfüllung der Erwartungen und getroffenen Vereinbarungen sicherstellen. Daher ist dieser Prozess nicht auf diese Phase des Service Lifecycle (= Service Transition) begrenzt, sondern setzt bereits innerhalb von Service Strategy an.

78

2.5 ITIL Kennzahlen für IT Service Management-Prozesse Die Zielsetzung des Prozesses besteht in: – Sicherstellung, dass ein Service den Wertbeitrag für Kunden und Business liefert – Planung und Implementierung eines strukturierten Validierungsund Test-Prozesses für den objektiven Nachweis gemäß der vereinbarten Anforderungen und Service Level-Ziele – Qualitätssicherung von Release, Komponenten, Service und Servicefähigkeit – Identifizierung, Bewertung und Zuordnung von Vorfällen, Fehlern und Risiken während der Transition Phase – Vertrauen schaffen, dass die erwarteten Ergebnisse und der Wert für das Business tatsächlich entstehen – Bestätigung, dass der Service „fit for purpose“ ist. Service Package Angebote, Verträge validieren

Kunden/Business Anforderungen definieren Service Anforderungen definieren

Serviceabnahme testen

Design Service Lösung

Betriebsbereitschaft testen Service Release Package Test

Design Service Release

Komponenten & Komponentengruppen Test

Design Lösung entwickeln

Level für Configuration und Testen Abbildung 32:

Build & Test

Das Service V-Modell

Mithilfe des Service V-Modells (Abbildung 32) kann sichergestellt werden, dass Service Validation and Testing früh in den Service Lifecycle eingebunden und eine Validierung und Test über alle Ebenen erfolgt (aus OGC, 2007c).

79

2 IT Service Management Von Bedeutung für das Verständnis dieses Prozesses ist es, dass der Prozess Service Validation and Testing nicht nur Fehlerfreiheit überprüft, sondern auch die Einhaltung des zugesicherten Wertes für das Business. Dieser Wert setzt sich zusammen aus der Utility und Warranty. Service Validation and Testing: Der Prozess, der für die Validation und das Testen eines neuen oder geänderten IT Service verantwortlich ist. Service Validation and Testing stellt sicher, dass der IT Service den jeweiligen Designspezifikationen entspricht und den Bedürfnissen des Business gerecht wird.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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 neue oder geänderte IT Services, um mögliche Risiken zu managen und so sicherzustellen, dass mit dem Service Change fortgefahren werden kann. Mit dieser Zielsetzung liefert der Prozess Evaluation eine Entscheidungsvorlage für das Change Management, ob ein Change genehmigt oder abgelehnt wird.

Die Lieferung von relevanten und genauen Informationen für das Change Management stellt sicher, dass Service Changes mit negativen Auswirkungen und Risiken nicht ungeprüft umgesetzt werden. Der Prozess Evaluation stellt hierzu ein konsistentes und standardisiertes Mittel zur Bewertung eines Service Changes bereit. Diese Beurteilung erfolgt gemeinsam mit dem Kunden und identifiziert sämtliche gewünschten und unerwünschten Auswirkungen. Hierzu ist die Objektivität, Fairness, Konsistenz und Offenheit in der Bewertung unumgänglich.

80

2.5 ITIL Kennzahlen für IT Service Management-Prozesse Evaluation: Der Prozess, der für die Bewertung eines neuen oder geänderten IT Service verantwortlich ist, um sicherzustellen, dass Risiken verwaltet wurden, und festlegen zu können, ob mit dem Change fortgefahren werden soll. Eine Evaluierung bezeichnet darüber hinaus den Vergleich eines Ist-Ergebnisses mit dem beabsichtigten Ergebnis oder den Vergleich unterschiedlicher Alternativen.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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.

Knowledge Management Knowledge Management liefert die Grundlage für fundierte Entscheidungen. Die im Verlauf des Lebenszyklus der Services gewonnenen Informationen und Daten werden bereitgestellt.

Dem Knowledge Management liegt das DIKW-Modell (Data-to-Information-to-Knowledge-to-Wisdom) zugrunde. Innerhalb der Organisation des Service Providers fällt eine Unmenge von Daten an, die aber noch keine Entscheidung ermöglichen. Durch die Analyse der Daten werden Informationen gewonnen. Hier werden Informationen zu den Schlüsselfragen Wer?, Was?, Wann?, und Wo? generiert. Das Knowledge entsteht durch die Anwendung der Informationen für bestimmte Maßnahmen. Das Wisdom stellt schließt die Anwendung und Umsetzung des Wissens dar. Dieses Modell ermöglicht die Schlüsselfrage des Warum? zu beantworten. In Verbindung mit dem Knowledge Management definiert ITIL das Service Knowledge Management System (SKMS). Das SKMS besteht aus einer Sammlung von Hilfsmitteln und Datenbanken, die zur Verwaltung von Wissen und Informationen verwendet werden. Ein wesentliches System für das SKMS ist das Configuration Management System. Das Knowledge Management soll die Entscheidungsqualität verbessern und die Effizienz des Service Providers erhöhen. Daher ist ein wirksames Knowledge Management als ein mächtiges Asset für alle Beteiligten (und damit auch für Kunden/Anwender) anzusehen. Knowledge Management: Der Prozess, der für die Sammlung, die Analyse, das Speichern und die gemeinsame Nutzung von Wissen und Informationen innerhalb einer Organisa-

81

2 IT Service Management tion verantwortlich ist. Wichtigster Zweck des Knowledge Managements ist eine gesteigerte Effizienz, indem bereits vorhandenes Wissen nicht erneut entwickelt werden muss.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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 33:

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 vieler Routine-Aktivitäten des Operation Managements und liefert die Eingangsstelle für viele Prozesse und Aktivitäten des Service Operation.

82

2.5 ITIL Kennzahlen für IT Service Management-Prozesse Innerhalb von Service Operation wird der IT Service für den Kunden bereitgestellt. Daher ist es in dieser Phase des Service Lifecycle sehr wichtig, mögliche Incidents (Störungen) möglichst früh zu erkennen und zu beheben, so dass die Auswirkungen für die Business-Prozesse minimiert werden. Durch die Überwachung von Events, die innerhalb der ITInfrastruktur auftreten, ist es möglich, Ausnahmebedingungen früh zu erkennen und darauf gezielt zu reagieren. Hierzu werden so genannte Alarme (Alerts) definiert, die eine Warnung melden, wenn ein Grenzwert erreicht, eine Änderung vorgenommen wird oder ein Ausfall aufgetreten ist. Die gezielte Reaktion auf die hinterlegten Alarme erfolgt dann im Event Management. Über das Event Management werden verschiedene Arten von Events gesteuert, wie zum Beispiel: – Events, die reguläre Operationen kennzeichnen, wie: ein Anwender hat sich angemeldet, um eine Applikation zu nutzen – Events, die eine Ausnahme kennzeichnen, wie: ein Anwender versucht, sich bei einer Applikation mit dem falschen Kennwort anzumelden, oder ein PC-Scan zeigt die Installation unautorisierter Software – Events, die eine ungewöhnliche aber nicht außergewöhnliche Operation kennzeichnen und so einen Hinweis für ein genaueres Monitoring liefern. Das Event Management sollte durch definierte Regeln und Tools in der Lage sein, auf bestimmte Events automatisch zu reagieren, wie zum Beispiel durch einen automatischen Neustart eines Systems. Events führen häufig zu einem Incident, der im Incident Management verfolgt wird. Ein Event kann aber auch zu einem Problem oder Change führen. Event Management: Der Prozess, der für die Verwaltung von Events während ihres Lebenszyklus verantwortlich ist. Das Event Management ist eine der wichtigsten Aktivitäten des IT-Betriebs.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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

83

2 IT Service Management – 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 Business-Prozesse minimiert werden. Die auftretenden Incidents sind zu kategorisieren und zu priorisieren. ITIL empfiehlt, die Priorisierung auf Basis der Auswirkung und Dringlichkeit durchzuführen und hilft, den erforderlichen Zeitbedarf für die auszuführenden Aktionen zu ermitteln. Die Business-Orientierung wird bei der Definition der Auswirkung und Dringlichkeit sehr deutlich. Die Auswirkung eines Incidents wird durch die Folgen auf die Business-Prozesse bestimmt und basiert häufig darauf, inwieweit Service Level betroffen sind. Die Dringlichkeit ist ein Wert, der wiedergibt, wie lange es dauert, bis ein Incident maßgebliche Auswirkungen auf das Business hat. Für die Effizienz des Incident Managements ist es von Vorteil, im Vorfeld Incident-Modelle zu definieren. Diese Modelle ermöglichen es, den Umgang mit einer bestimmten Art des Incidents im Vorfeld festzulegen und sichern in der Umsetzung eine konsistente Durchführung. Beispiele für Incident Modelle sind sicherheitsrelevante Incidents, deren Informationen an das Security Management automatisch weitergeleitet werden oder performancerelevante Incidents, die automatisiert an das Capacity Management weitergeleitet werden. Eine Herausforderung in diesem Prozess besteht in der Überzeugung aller Mitarbeiter, dass alle Incidents protokolliert werden müssen. Darüber hinaus ist die Trennung zwischen Incident und Problem Management von großer Bedeutung. Die Aufgabe des Incident Managements besteht in einer schnellen Lösung des Incidents und nicht darin, die zugrunde liegende Ursache zu ermitteln. Die Ermittlung dieser Ursache und mögliche Umgehungslösungen zu entwickeln ist die Aufgabe des Problem Managements. Incident Management: Der Prozess, der für die Verwaltung des Lebenszyklus aller Incidents verantwortlich ist. Wichtigstes Ziel des Incident Management ist eine schnellstmögliche Wiederherstellung des IT Service für die Anwender.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:

84

2.5 ITIL Kennzahlen für IT Service Management-Prozesse – 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 zum Beispiel Lizenzen und SoftwareMedien, werden beschafft und ausgeliefert.

Ein Service Request könnte zum Beispiel die Anfrage eines Anwenders nach Informationen, Beratung, einem Standard-Change oder nach Zugriff auf einen IT Service sein. Das Zurücksetzen eines Passworts oder die Bereitstellung standardmäßiger IT Services für einen neuen Anwender sind Service Requests, die an jeden Service Provider gerichtet werden. Viele an den Service Provider gerichtete Service Requests wiederholen sich, so dass ein vordefinierter Prozessablauf (ein Modell) entworfen werden kann, wie diese Anforderungen einheitlich mit einer gleich bleibenden Service-Qualität bearbeitet werden können. Diese Modelle beinhalten: – beteiligte Personen oder Support-Gruppen – geplante Zeitdauer – Eskalationswege. Die Service Requests werden normalerweise durch Implementierung eines Standard Change abgedeckt. Der Standard Change ist ein vorab genehmigter Change, der von geringem Risiko ist, relativ häufig eingesetzt wird und einem bestimmten Verfahren oder einer Arbeitsanweisung folgt. Mit dem Standard Change wird auch die Dokumentation der durchgeführten Maßnahme sichergestellt. Die Verantwortung der Aufnahme, Überwachung, Eskalation und Zuweisung der Service Requests liegt im Service Desk. Request Fulfilment: Der Prozess, der für das Management des Lebenszyklus aller Service Requests verantwortlich ist.

85

2 IT Service Management Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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.

Problem Management Der Prozess Problem Management ist verantwortlich für den Lebenszyklus aller Probleme 3 . 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. Während das Incident Management die schnelle Wiederherstellung des IT Service zum Ziel hat, muss vom Problem Management sichergestellt werden, dass sich diese Incidents nicht wiederholen. Ein gutes Problem Management stellt die Reduzierung von Incidents bzw. die Reduzierung deren Auswirkungen sicher und liefert einerseits dem Business einen stabileren IT Service, andererseits werden die Aufwendungen und Kosten für das Incident Management reduziert. Das Incident und Problem Management sind zwei eng verbundene, aber getrennte Prozesse. Ein Incident nimmt im Rahmen seiner Bearbeitung nicht den „Status“ eines Problems an, sondern bleibt während der gesamten Bearbeitung ein Incident. Sehr wohl bedingen sich Incident und Problem Management. Eine wichtige Aufgabe des Problem Managements besteht in der Dokumentation von Known Errors. Ein Known Error liegt vor, wenn die zugrunde liegende Ursache für ein Problem identifiziert und ein Workaround (Umgehungslösung) dokumentiert wurde. Diese Umgehungslösung ermöglicht die Reduzierung oder Beseitigung der Auswirkungen von Incidents oder Problemen, für die noch keine vollständige Lösung verfügbar ist, wie zum Beispiel durch den Neustart eines ausgefallenen Configuration Items. Gespeichert werden die Known Errors in der Known Error Da-

3

86

Ein Problem bezeichnet in der ITIL-Terminologie die Ursache für einen oder mehrere Incidents. 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 tenbank (KEDB), die Bestandteil des Configuration Management Systems (CMS) und des Service Knowledge Management (Systems) ist.

So wird der Zugriff des Incident Managements auf diese Umgehungslösungen sichergestellt. Mitarbeiter im Incident Management können diese Informationen abfragen, die beschriebenen Maßnahmen durchführen und konsistente und mit einer hohen Qualität verbundene Wiederherstellungsmaßnahmen durchführen. Eine gute KEDB ermöglicht eine hohe Erstlösungsquote im Service Desk. Die im Problem Management entwickelten Lösungskonzepte werden nicht vom Problem Management eigenständig umgesetzt und implementiert, sondern führen zu einem Request for Change (RfC) und unterliegen so dem Change Management. Innerhalb des Problem Managements wird zwischen dem reaktiven und proaktiven Problem Management unterschieden. Das reaktive Problem Management wird allgemein in Service Operation durchgeführt. Das proaktive Problem Management wird in Service Operation initiiert, aber generell innerhalb von Continual Service Improvement vorangetrieben. Problem Management: Der Prozess, der für die Verwaltung des Lebenszyklus aller Probleme verantwortlich ist. Wichtigstes Ziel des Problem Managements ist es, Incidents zu verhindern bzw. die Auswirkungen von Incidents zu minimieren, die nicht verhindert werden können.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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.

Aus den gestiegenen Compliance Anforderungen (zum Beispiel Sarbanes Oxley Act, SOX) resultiert die Notwendigkeit einer Regelung für den

87

2 IT Service Management Zugriff auf IT Services und Daten. Diese Anforderungen sind leicht nachzuvollziehen, wenn die Folgen eines unautorisierten Zugriffs betrachtet werden. Die möglichen Folgen von Manipulationen, aber auch die unberechtigte Weitergabe von Informationen, können für ein Unternehmen immens sein. Das Access Management wird als Prozess des IT Service Managements erstmalig in der ITIL V3 beschrieben, wird aber in vielen Organisationen betrieben. Dieser Prozess wird häufig auch als Berechtigungs-Management oder Identitäts-Management (Identity Management) bezeichnet. Im Prozess werden folgende Begriffe unterschieden: – Access (Zugriff), bezieht sich auf den Level und Umfang der ServiceFunktionalität oder Daten, für deren Nutzung ein Anwender berechtigt ist – Identity (Identität), bezieht sich auf die Information, die sie als individuell charakterisiert und die ihren Status innerhalb der Organisation verifiziert (wie der Anwender) – Rights (Rechte, auch genannt Privilegien), beziehen sich auf die aktuellen Einstellungen, wodurch einem Anwender der Zugriff zu einem Service oder einer Gruppe von Services bereitgestellt wird, typische Rechte beinhalten „lesen“, „schreiben“, etc. – Service oder Service Gruppen, es ist effizienter, einen Zugriff einer vollständigen Gruppe von Services zu gewähren – Directory Services, bezieht sich auf bestimmte Typen von Tools, die benutzt werden, um Zugriffe und Rechte zu verwalten In der Regel nimmt der Service Desk die Access-Anforderung entgegen und nutzt hierzu einen Service Request. Nach der Durchführung von Überprüfungen erfolgt die Weiterleitung an das entsprechende Team. Der Prozess ist nicht auf den Service Provider begrenzt, sondern schließt den Kunden im hinterlegten Workflow ein. Die Prozessaktivitäten bestehen aus „Zugriffsberechtigung beantragen“, „Verifikation“, „Zugriffsrechte bereitstellen“, „Monitoring des Identitäts-Status“ und „Entfernen oder Begrenzung der Rechte“. Access Management: Der Prozess, der für die Zulassung der Nutzung von IT Services, Daten und anderen Assets durch Anwender verantwortlich ist. Das Access Management bietet Unterstützung beim Schutz der Vertraulichkeit, Integrität und Verfügbarkeit von Assets, indem sichergestellt wird, dass nur berechtigte Anwender auf die jeweiligen Assets zugreifen oder Änderungen an diesen vornehmen können. Das Access Management kann auch als Berechtigungs-Management oder Identitäts-Management (Identity Management) bezeichnet werden.

88

2.5 ITIL Kennzahlen für IT Service Management-Prozesse Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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. Der Service Desk als Anforderung an die Organisation ist im Kapitel „Organizing Service Operation“ beschrieben. Der Service Desk übernimmt in der Organisation des Service Providers die Funktion als „Primary Point of Contact“ für den Anwender. Als Ansprechpartner für die Anwender nimmt der Service Desk Incidents, Service Requests und einige Kategorien von Requests for Change auf. Die Zielsetzung besteht darin, den Anwendern eine einfache Kommunikation zu ermöglichen. Mit der Funktion als Primary Point of Contact stellt der Service Provider den Anwendern eine einfache Schnittstelle zur Verfügung. Es soll vermieden werden, dass der Anwender entscheiden muss, welche Stelle innerhalb der Provider-Organisation für die jeweilige Bearbeitung verantwortlich ist. Der Service Desk ist aber nicht nur für die Aufnahme von Incidents und Service Requests verantwortlich, sondern übernimmt auch Aktivitäten in den jeweiligen Prozessen, wie zum Beispiel: – Kategorisierung und Priorisierung aller Incidents / Service Requests sowie Erfassung der relevanten Details – Erste Ebene der Untersuchung, Diagnose und Problemlösung – Eskalation von Incidents / Service Requests – Informieren von Anwendern über den Fortschritt – Schließen aller gelösten Incidents, Service Requests und andere Anfragen – Durchführung von Anwenderbefragungen. Darüber hinaus übernimmt der Service Desk die Koordination einiger ITGruppen und Prozesse. Für den Service Desk beschreibt ITIL mit dem „lokalen Service Desk“, dem „zentralen Service Desk“, dem „virtuellen Service Desk“ und „Follow the

89

2 IT Service Management Sun“ verschiedene Strukturen. Im Rahmen der Implementierung des Service Managements gilt es dann, die für die jeweilige Organisation geeignete Struktur zu spezifizieren. Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel: – Prozentsatz von Calls (Anrufen), deren Requests bzw. Störungen sofort während des ersten Kontaktes am Service Desk gelöst wurden – Prozentsatz „gelöster Calls“ ohne Unterstützung anderer Gruppen – Prozentsatz „gelöster Calls“ mit Unterstützung anderer Gruppen.

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 34:

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 Lücken (Gaps) und Problemen bei der Bereitstellung von Services, der Bewertung

90

2.5 ITIL Kennzahlen für IT Service Management-Prozesse 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: 1.

Definieren, was gemessen werden soll

2.

Definieren, was gemessen werden kann

3.

Daten sammeln

4.

Daten bearbeiten

5.

Daten analysieren

6.

Informationen präsentieren und nutzen

7.

Korrekturen durchführen.

Abbildung 35 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 35:

4. Bearbeite Daten

7 Step Improvement-Prozess

1. Definiere, was Du messen solltest (should) Als erster Schritt sollte ein Satz möglicher Messungen definiert werden, der die Ziele des IT Service Providers und deren Messung vollständig abdeckt. Der Fokus sollte hier bei der Definition liegen, welche Daten gebraucht werden und um die Zielerreichung vollständig zu messen. Eine

91

2 IT Service Management Betrachtung, ob die Daten aktuell verfügbar sind und mit einem vertretbaren Aufwand gewonnen werden können, findet hier nicht statt. Was gemessen werden sollte, ist innerhalb von Service Strategy und Service Design zu Beginn des Service Lifecycle zu identifizieren.

2. Definiere, was Du messen kannst (can) Während im ersten Schritt mögliche Daten für Messungen definiert werden, gilt es im zweiten Schritt festzustellen, was tatsächlich gemessen werden kann. Dabei können Service Provider unter Umständen feststellen, dass nicht alle Anforderungen umgesetzt werden können. Für den Service Provider ist es wichtig, die Lücken und damit verbundene mögliche Risiken zu erkennen. Die identifizierten Lücken und die damit verbundenen Auswirkungen sind dem Business, den Kunden und dem IT-Management zu berichten. Eine mögliche Abhilfe kann in der Beschaffung neuer Tools liegen, dabei sind die damit verbundenen Kosten und erzielten Vorteile zu prüfen.

3. Sammle Daten (gather) Die Zielsetzung des Continual Service Improvement besteht in der Überwachung der Service-Qualität. Hierzu sind durch eine geeignete Kombination von Monitoring-Tools und manuellen Prozessen die notwendigen Messungen zur Mittlung der erforderlichen Daten einzuführen. Der Betrachtungsbereich erstreckt sich von der Effektivität der Services, über Prozesse, Tools und Organisation bis zu den CIs. Dabei werden nicht nur Ausnahmesituationen betrachtet, sondern auch Entwicklungen wie zum Beispiel eine schleichende Verschlechterung der Verfügbarkeit. Eine Automatisierung der Datensammlung ist anzustreben und wie bereits ausgeführt Messpunkte sowohl so zu wählen, dass eine durchgängige Betrachtung („end-to-end“), als auch eine zeitliche Betrachtung möglich wird. Die in diesem Schritt gesammelten Daten sind aber noch Rohdaten und erlauben keine Rückschlüsse. Hierzu sind die gesammelten Daten entsprechend zu erarbeiten.

4. Bearbeite Daten (process) Die gesammelten Rohdaten werden in diesem Schritt so bearbeitet und in das erforderliche Format transformiert, dass über eine „end-to-end“Betrachtung die Bewertung der Leistungsfähigkeit der Prozesse und / oder IT Services möglich wird.

92

2.5 ITIL Kennzahlen für IT Service Management-Prozesse Hierzu werden unter anderem Daten aus verschiedenen Quellen konsolidiert, auf Zeitskalen abgebildet und führen zu den definierten KPIs und Kennzahlen. Die Kennzahlen können in drei Betrachtungsebenen dargestellt werden:

Technische Kennzahlen sind häufig mit den eingesetzten Komponenten und Applikationen verbunden und betrachten technische Aspekte wie Performance, Verfügbarkeit etc. Prozess-Kennzahlen 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 Kennzahlen sind das Ergebnis einer „end-to-end“-Betrachtung der Services.

5. Analysiere Daten (analyse) Durch eine Analyse der generierten Informationen können die Ergebnisse analysiert werden, um Fragen zu beantworten wie: – – – – –

„Erreichen wir die Ziele?“ „Gibt es klare Trends?“ „Sind Korrekturmaßnahmen erforderlich?“ „Welche eingeleiteten Korrekturmaßnahmen waren erfolgreich?“ „Welche Kosten entstehen?“

Insbesondere der umfassende Ansatz des Continual Service Improvement stellt sicher, dass sich die Identifizierung von möglichen Korrekturmaßnahmen nicht auf einen Bereich oder eine Phase des Lifecycle konzentriert. So kann zum Beispiel sichergestellt werden, dass auftretende Probleme in Service Operation zu Korrekturmaßnahmen innerhalb von Service Design führen.

6. Präsentiere und Nutze die Informationen (present) Dieser Schritt dient der Präsentation des gewonnenen Wissens. Hierzu sind die Ergebnisse so aufzubereiten und zu präsentieren, das sie leicht zu verstehen sind und es so ermöglicht wird, strategische, taktische und operative Entscheidungen zu treffen. Grundvoraussetzung hierzu ist eine Zielgruppen-ausgerichtete Präsentation der Ergebnisse. Insbesondere ist ein Bezug zum Business und zu den Business-Zielen herzustellen. Dabei stellt es sich als großer Vorteil dar, dem Business mögliche Verbesserungen in Verbindung mit ihrem Wertbeitrag zu präsentieren.

93

2 IT Service Management Dieser Schritt sollte aber nicht nur dazu dienen, mögliche Schwachpunkte zu präsentieren, sondern auch als Marketingmaßnahme die exzellenten IT Services herauszuheben. Hier eröffnet sich die Chance, dass die IT nicht nur als Kostenfaktor empfunden wird, sondern auch als Leistungsgeber für den Erfolg der Business-Prozesse.

7. Implementiere Korrekturmaßnahmen (implement) Das gewonnene Wissen wird verwendet, um die IT Services, die Prozesse und alle anderen unterstützenden Aktivitäten und Techniken zu optimieren, zu verbessern und zu korrigieren. Die Verbesserungsmaßnahmen, die den IT Service verbessern, sind zu identifizieren und innerhalb der Organisation zu kommunizieren. Innerhalb des Continual Service Improvement werden unter Umständen mehr Verbesserungsmöglichkeiten identifiziert, als mit den vorhandenen Ressourcen und Budget umgesetzt werden können. Daher muss der Service Provider auf Basis der Zielsetzung und der Business-Vorteile die Umsetzung der Verbesserungsmaßnahmen priorisieren. Die Umsetzung einer Verbesserungsmaßnahme führt zu einem Durchlauf des beschriebenen Zyklus. Innerhalb von „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ße 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? Key Performance-Indikatoren sind zu diesem Prozess nicht ausgeführt, sondern allgemeine Anforderungen an die Metriken.

Service Reporting Das Service Reporting liefert die notwendigen korrekten Berichte, die den Kundenerwartungen entsprechen. Aus der Vielzahl der vorliegenden Da-

94

2.5 ITIL Kennzahlen für IT Service Management-Prozesse ten sind hierzu die Daten so aufzubereiten, dass das Business die notwendigen Informationen erhält. Für das Business ist eine historische Betrachtung des geleisteten IT Service mit den erreichten Service Level und der Performance wichtig. Aber viel wichtiger sind die daraus gezogenen Kenntnisse und welche Maßnahmen eingeleitet werden, um erkannte Defizite zu beheben. Das Business verlangt eine nachvollziehbare Darstellung von den Ereignissen und wie der Service Provider sicherstellt, dass das nochmalige Geschehen nicht wieder eintritt und wie der Service Provider generell den Service verbessern wird. Service Reporting: Der Prozess, mit dem Berichte zu Ergebnissen und Trends hinsichtlich bestimmter Service Level erstellt und bereitgestellt werden. Beim Service Reporting sollte das Format, der Inhalt und die Häufigkeit der Berichte zuvor mit den jeweiligen Kunden abgesprochen werden.

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 (d. h. „end-to-end“) von großer Bedeutung, da hiervon die Geschäftsprozesse des Business abhängig sind. Vielfach berichten Service Provider dem Kunden aus der internen Sicht oder versuchen zum Teil nur über die Komponenten zu berichten, die der Service Provider sicher beherrscht, wie zum Beispiel „der Server oder die Applikation war zu 99,99 % verfügbar“. Aber wie kann der Kunde den Server nutzen, wenn zum Beispiel das LAN ausgefallen ist? Eine Messung auf Ebene der Komponenten ist notwendig und sinnvoll, aber die Messung eines IT Service muss weitergehen und den gesamten IT Service hinsichtlich seiner Unterstützung des Business-Prozesses umfassen. Eine Service Messung muss der Kundensicht und Wahrnehmung auf den IT Service entsprechen, hierzu ist eine „end-to-end“-Messung erforderlich. Service-Messungen sollten nicht nur die Vergangenheit betrachten, sondern auch Informationen zur Entwicklung liefern, um Verbesserungen rechtzeitig zu ergreifen. Das sollte eine sichere Basis für operationelle, taktische oder strategische Entscheidungen liefern. Als Key Performance-Indikatoren für das Service Management werden aus Kundensicht demzufolge herausgestellt:

95

2 IT Service Management – Verbesserte Verfügbarkeit (durch Service / Systeme / Applikationen) – Verringerung der Service Level Verletzungen (durch Service / Systeme / Applikationen) – Verringerung „mean time to repair“ (gemessen anhand von Prioritäten) – Verringerung von „Major Incidents“.

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 des Service Providers 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?“. Die Definition „Was wollen wir?“ kann nur in Partnerschaft zwischen dem Business und dem Service Provider erarbeitet werden. Zunächst mögen sich einige Wünsche des Business wie 100%ige garantierte Verfügbarkeit als „Wunschliste“ anführen. Hier gilt es, die zugrunde liegenden Begründungen zu erkennen und sich diesen Anforderungen zu stellen. Die Gründe aus Sicht des Business können zum Beispiel bestehen in:

– Einhaltung zu neuen/bevorstehenden Gesetzen (Compliance Anforderungen)

– Wettbewerb – Finanzielle Beschränkungen. Es ist für den Service Provider wichtig, lang-, mittel- und kurzfristige Ziele und Zielsetzungen für das Business zu identifizieren, so dass die zugrunde liegenden IT Services und Service Assets sich dementsprechend ausrichten können.

96

2.6 ISO 20000 Die Aktivitäten des Continual Service Improvement setzen einen betriebsbereiten IT Service voraus. Die Aktivitäten des CSI können innerhalb der Lifecycle-Phasen: Service Strategy, Service Design, Service Transition und Service Operation ausgeführt werden. 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-Zielen 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.

Der SLM Prozess ist innerhalb der Service Lifecycle-Phase von Service Design dokumentiert. Dabei ist es wichtig das CSI zu beteiligen, um so sicherzustellen, dass messbare Ziele zur Identifizierung potenzieller Service-Verbesserungen geschaffen werden. Das Service Level Management stellt einen wichtigen Trigger für den Service Improvement-Plan (SIP) dar. Der Service Improvement-Plan ist ein formeller Plan, um mögliche Verbesserungen zu einem Prozess oder einem IT Service durchzuführen. Durch die Identifizierung notwendiger Verbesserungen und deren Management mittels des SIP wird eine nachhaltige Verbesserung sichergestellt. Das Management dieses Plans ist ein Teil des Continual Service Improvement. Service Improvement-Plan (SIP): Ein formeller Plan zur Implementierung von Verbesserungen für einen Prozess oder IT Service.

Key Performance-Indikatoren sind zu diesem Prozess nicht ausgeführt.

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 Auditie-

97

2 IT Service Management rungs-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.

Eine Zertifizierung von Organisationen ist nur auf Basis der ISO 20000 möglich

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.

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]).

98

2.6 ISO 20000

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 Übereinstimmung 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, so dass 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 ISO 20000-1 enthält die Muss-Kriterien des Standards und umfasst inklusive Deckblatt und Inhaltsverzeichnis insgesamt 36 Seiten.

ISO 20000-1 enthält die Muss-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.

ISO 20000-2 enthält die Soll-Anforderungen

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

99

2 IT Service Management 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 20000Zertifizierung 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 erfolgreichen 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

100

2.6 ISO 20000 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. 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

ReleaseProzesse

Service Level Management Service Reporting

Control-Prozesse Configuration Management Change Management

Resolution-Prozesse Release Management

Abbildung 36:

Information Security Management

Incident Management Problem Management

Budgeting and accounting for IT services

RelationshipProzesse Business Relationship Management Supplier Management

IT Service Management-Prozesse der ISO 20000

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

101

2 IT Service Management Service Managements in die IT-Strategie sichergestellt. Innerhalb der folgenden Abbildung 36 werden die geforderten IT Service ManagementProzesse, ergänzt um das übergeordnete Managementsystem der ISO 20000, dargestellt (vgl. [ISO 20000-1, 2005]). Unternehmen, die eine ISO 20000-Zertifizierung anstreben, müssen alle 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: – – – –

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 – 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 37). 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.”

102

2.7 COBIT 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 37:

GeschäftsErgebnisse

Überwachung, Messen und Review

Weitere Prozesse, z.B. Geschäfts-, Lieferanten-, Kundenprozesse Zufriedenheit im Team und bei den Beteiligten insgesamt

PDCA-Methodik

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 Steu-

103

Im Rahmen einer ISO 20000-Zertifizierung werden Prozesskennzahlen überprüft.

2 IT Service Management erungszielen 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 sicherstellen. ITIL Version 3 definiert den Begriff „IT Governance“ und bezieht sich dabei auf eine Definition des IT Governance Instituts (vgl. [OGC, 2007e]): 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, so dass diese verschiedenen Best Practices besser aufeinander abgestimmt sind.

104

2.7 COBIT Speziell im Zusammenhang mit der Nachweispflicht des Sarbanes-Oxley Acts (SOX)4 (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. 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 (Lifecycle) bilden (vgl. [COBIT, 2005], Abbildung 38). 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.

4

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.

105

COBIT sind Best Practices.

2 IT Service Management 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 38:

2.7.3 Control Objectives dienen der Steuerung, nicht der Kontrolle

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

COBIT Prozess-Übersicht

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.

106

2.7 COBIT 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 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. Abbildung 39 (textuell angelehnt an [COBIT, 2005]) stellt die detaillierten Control Objectives für den Prozess „Manage Changes“ dar. 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.

107

2 IT Service Management 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 39: COBIT gliedert die PerformanceMessung in Kriterien für Effektivität und Effizienz

Zusammenhang zwischen Control Objectives in 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 Pro-

108

2.7 COBIT zesskennzahlen (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.

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

¬

Anzahl der Unterbrechungen oder Datenfehler, die durch ungenaue Spezifikation oder unvollständige Beurteilung der Auswirkungen hervorgerufen ist

KGI

KPI

Abbildung 40:

IT Key Goal Indicators treiben

¬ % der aufgezeichneten und mit automatisierten Tools verfolgten Änderungen ¬ % der Änderungen, die formale Änderungskontrollprozesse 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

KGI

Ziele, Prozesse und Metriken in COBIT

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

109

2 IT Service Management 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. 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 40). 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 Process 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 41):

110

2.7 COBIT Anforderung Prozessmanagement

Control Objectives

KPI

KGI

Prozess

Input

Ziele

Output

Aktivitäten

Abbildung 41:

2.7.4

Prozess, Ziele und Kontrollebenen in COBIT

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.

111

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.

2 IT Service Management 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, so dass aus beiden Ansätzen die Stärken zusammengeführt werden können.

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 42:

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

Eine Analyse der COBIT Best Practices 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]).

112

2.7 COBIT 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 folgenden Abbildung 42 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 42) der Prozess “DS 5 Stelle Systemsicherheit sicher” ebenfalls hervorgehoben. 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]).

113

2 IT Service Management

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: – 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

114

2.7 COBIT – 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

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:

115

2 IT Service Management – 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: – 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 (Anmerkung: ITIL bezeichnet

116

2.7 COBIT dieses als Service Level-Ziele) 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 – 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

117

2 IT Service Management 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 – 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

118

2.8 Monitoring und Reporting von SLAs

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 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

119

2 IT Service Management 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 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. Der Fokus der Kunden liegt auf den IT Services.

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.

120

2.8 Monitoring und Reporting von SLAs 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 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 greift 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.

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

121

Von der System- zur ServiceOrientierung.

2 IT Service Management 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. 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 Porter5 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 43). 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: „Die Implementierung und Verwaltung von qualitätsbasierten IT Services, die den Anforderungen des Business gerecht werden. Das IT Service Management

5

Michael E. Porter, Professor für Wirtschaftswissenschaften an der Harvard Business School und einer der führenden Ökonomen auf dem Gebiet des strategischen Managements.

122

2.8 Monitoring und Reporting von SLAs wird von IT Service Providern mithilfe einer geeigneten Kombination aus Personen, Prozessen und Informationstechnologie durchgeführt.“

IT Service Management Unternehmensinfrastruktur

IT-Service

Personalwirtschaft

IT-Service

… IT-Service

IT-Service

Beschaffung

Produktion

Wertschöpfung

IT-Service

IT-Service

Marketing & Vertrieb

= Primäre Prozesse / Aktivitäten

KundenService

= sekundäre Prozesse / Aktivitäten = geforderte und gelieferte IT-Unterstützung (IT-Service)

Abbildung 43:

Wertschöpfungskette nach Porter

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]). IT Service „Ein Service, der für einen oder mehrere Kunden von einem IT Service Provider bereitgestellt wird. Ein IT Service basiert auf dem Einsatz der Informationstechnologie und unterstützt die Business-Prozesse des Kunden. Ein IT Service besteht aus einer Kombination von Personen, Prozessen und Technologie und sollte in einem Service Level Agreement definiert werden.“

Diese Anforderungen an einen IT Service unterscheiden sich in Abhängigkeit der Bedeutung der Geschäftsprozesse für das Unternehmen stark in

123

2 IT Service Management 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.

2.8.2

Service Level Agreements

Das Service Level Management hat die Kundenanforderungen 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]): Service Level Agreement: „Eine Vereinbarung zwischen einem IT Service Provider und einem Kunden. Das SLA beschreibt den jeweiligen IT Service, dokumentiert Service Level-Ziele und legt die Verantwortlichkeiten des IT Service Providers und des Kunden fest. Ein einzelnes SLA kann mehrere IT Services oder mehrere Kunden abdecken.“

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 Servicekatalog, Service Level Agreement (SLA), Operational Level Agreement (OLA) und Underpinning Contract (UC) dem Prozess des Service Level Managements zugewiesen.

124

2.8 Monitoring und Reporting von SLAs COBIT nimmt bei der Definition von Control Objectives und Leistungsindikatoren (KGI, KPI) Bezug auf den Servicekatalog, 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 Abschnitt 2.8.5 beschrieben. 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 44 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.

125

ITIL und ISO 20000 enthalten Best Practices für die Inhalte von SLAs.

2 IT Service Management 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 44:

2.8.4 Die Struktur der SLAs ist unternehmensspezifisch.

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]). 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]).

IT Services werden system- und organisationsübergreifend erbracht.

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.

126

2.8 Monitoring und Reporting von SLAs 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. Um die Aufwendungen für das Monitoring und Reporting zu reduzieren, bietet eine mehrschichtige SLA-Struktur viele Vorteile (siehe Abbildung 45). 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 45:

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-

127

SLA-Strukturen reduzieren Aufwendungen.

2 IT Service Management 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. Messwerkzeuge und einheitliche Messverfahren sollten einheitlich vorgegeben werden.

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. 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 Service Level und Auslastungs-Kriterien sind zu vereinbaren und aufzuzeichnen.

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 Levels 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 Servicekatalog und ein Leitfaden für die inhaltliche Gestaltung der SLAs dokumentiert. Im Zusammenspiel zwischen Servicekatalog und SLA empfiehlt die ISO 20000-2, eine Referenzierung vom SLA zum Servicekatalog aufzubauen.

128

2.8 Monitoring und Reporting von SLAs 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 Level-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 Level-Zielen“ (Service Targets). Service Level-Ziele machen die vereinbarten Ziele für einen Service Level messbar. Mögliche Service Level-Ziele könnten zum Beispiel eine „Verfügbarkeit von x % pro Woche“ oder eine „Erstlösungsquote von x % pro Woche“ sein.

129

2 IT Service Management Die Einhaltung von Service Level und SLAs wird mittels vereinbarter ServiceZiele definiert, überwacht und berichtet. Service-Ziele sind aus der Kundenperspektive zu definieren.

Zur Definition der Service Level-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 Level-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.

Konzentration auf die wesentlichen Service Level

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.” 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 SLAs wie folgt: – Einleitung - Parteien der Vereinbarung - Bezeichnung und Kurzbeschreibung der Vereinbarung - Unterzeichnende

130

2.8 Monitoring und Reporting von SLAs -

–

–

–

–

–

–

–

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 Service-Erweiterungen, 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 Support-Erweiterungen, 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 der 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

131

2 IT Service Management – 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 Reportings 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 Level-Zielen) 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 Abschnitt

132

2.8 Monitoring und Reporting von SLAs 2.9.5.1 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. 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

133

Service Level sind dort zu messen, wo der Service wahrgenommen wird.

2 IT Service Management 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. Die ISO 20000 verlangt auch die Darstellung von Trends.

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 (d.h. Unterschreitung) der festgelegten Service-Ziele.

134

2.9 Integrationsinstrument: Balanced Scorecard

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 von Robert S. Kaplan und David P. Norton Anfang der 90er Jahre entwickelte Balanced Scorecard 6 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

6

Häufig abgekürzt als „BSC“, für den IT-Bereich als „IT-BSC“.

135

Die Balanced Scorecard ist ein Kennzahlen- und ManagementSystem.

2 IT Service Management damit nicht nur das operative IT-Geschäft, sondern insbesondere die strategische 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, die 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

136

2.9 Integrationsinstrument: Balanced Scorecard ergänzt daher die traditionelle finanzielle Perspektive um drei weitere Perspektiven. Auf diese Weise erhält man ein 4-dimensionales Modell, das 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, Prozesse7 und Potenziale8.

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 aufeinander abgestimmt sind.

Die Balanced Scorecard ist ein mehrdimensionales und ausgewogenes Zielsystem.

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“.

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.

7

Die Prozessperspektive wird im Original „Interne Geschäftsprozesse“ genannt.

8

Die Potenzialperspektive wird im Original „Lernen und Entwicklung“ genannt.

137

Es geht nicht um kurzfristige Gewinne sondern um Kontinuität.

2 IT Service Management 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 Schlagworten „translating strategy into action” und „measures that drive (future) performance” herausgestellt. Finanzperspektive Ziel

Kenn- Vorzahl gabe

Maßnahme

Prozessperspektive

Kundenperspektive Ziel

Kennzahl

Vorgabe

Vision und Strategie

Maßnahme

Ziel

Kenn- Vorzahl gabe

Maßnahme

Protenzialperspektive Ziel

Abbildung 46:

Kenn- Vor- Maßzahl gabe nahme

Allgemeine Balanced Scorecard

Um den Kern von Vision und Strategie ranken sich vier Betrachtungsweisen (vgl. Abbildung 46): – 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?

138

2.9 Integrationsinstrument: Balanced Scorecard – 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? Diese Ziele lassen sich beispielsweise folgendermaßen detaillieren:9

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 Reengineering 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 47). 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. 9

Die Detaillierung leitet sich aus der IT-Strategie und dem Zielsystem des Unternehmens ab.

139

2 IT Service Management

Finanzperspektive

Kundenperspektive

Prozessperspektive

Potentialperspektive Abbildung 47:

Finanzielles Ergebnis (Gewinn, Rentabilität, ...) Kundenzufriedenheit Kosten der Prozesse

Kundentreue

Qualität der Prozesse

Qualifizierte Mitarbeiter

Geschwindigkeit der Prozesse

Motivierte Mitarbeiter

Ursache-Wirkungskette

Unternehmensziele Strategien

Kundenperspektive Finanzperspektive

interne Prozessperspektive Lern- & Entwicklungsperspektive

operative Umsetzung Erfolgskontrolle Abbildung 48:

Stellung der BSC im Unternehmensplanungsprozess

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.

140

2.9 Integrationsinstrument: Balanced Scorecard Dass sich die Balanced Scorecard immer aus den Unternehmenszielen und der Strategie ableitet, verdeutlicht Abbildung 48 aus [Preißner, 2006].

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-Prozessen 10 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 --

10

Hier ist insbesondere die Vereinheitlichung im Sinne der Etablierung eines allgemein akzeptierten Sprachstandards gemeint.

141

2 IT Service Management 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: 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 entwickeln11, so bietet es sich an, das Beste aus allen Welten zu nehmen. Dies verdeutlichen wir später in unserem Kennzahlenmodell und in den Praxisbeispielen.

11

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.

142

2.9 Integrationsinstrument: Balanced Scorecard 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

Finanzen Kunden Geschäftsprozesse Lernen u. Entwicklung

143

2 IT Service Management

2.10 Konsequenzen Die Auswahl der „richtigen“ Kennzahlen ist in der Praxis ein schwieriger und mehrstufiger Prozess. Die Fragestellung, welcher Ansatz12 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 sind für ein wirksames ProzessManagement unabdingbar.

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 Definition 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, Process 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.

12

Beispielsweise ITIL oder COBIT, aber auch andere.

144

2.10 Konsequenzen 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. 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.

145

Es gilt, die jeweiligen Stärken von ITIL und COBIT zu nutzen.

2 IT Service Management

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

146

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“ explizit 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 Deming13 zum PDCA-Zyklus (Plan, Do, Check, Act), der als Deming-Zyklus international bekannt geworden ist. Deming selbst wies jedoch darauf hin, dass Walter A. Shewhart14 diesen Zyklus als Erster beschrieben hatte. Da-

13

William Edwards Deming, 1900 - 1993

14

Walter Andrew Shewhart, amerikanischer Wissenschaftler, 1891 - 1967

147

3 IT Prozess-Management her wird der PDCA-Zyklus gelegentlich auch als „Shewhart-Zyklus” bezeichnet (siehe Abbildung 49).

Act Verbessern

Plan Planen

Ständige Verbesserung Check Überprüfen

Abbildung 49:

Do Ausführen

PDCA-Zyklus

Der PDCA-Zyklus basiert auf einem prozessorientierten 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

148

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 fortlaufende, 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, Process 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.

149

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 ITOrganisationen 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 Verantwortlichkeiten nicht an Abteilungsgrenzen enden.

150

3.3 Etablierung des Prozess-Managements Mit dem fortschreitenden Out-Tasking wird das notwendige Spezialwissen teilweise durch externe Lieferanten beigestellt. Die Entscheidung 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 Vertragsabschluss 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]): Prozess: „Ein strukturierter Satz an Aktivitäten, mit deren Hilfe ein bestimmtes Ziel erreicht werden soll. Ein Prozess wandelt einen oder mehrere definierte Inputs in definierte Outputs um. Ein Prozess kann beliebige Rollen, Verantwortlichkeiten, Hilfsmittel und Steuerungen für das Management enthalten, die für eine zuverlässige Bereitstellung der Outputs erforderlich sind. Ein Prozess kann den Anforderungen entsprechend Richtlinien, Standards, Leitlinien, Aktivitäten und Arbeitsanweisungen definieren.“

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.

151

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 50): Organisation und EDV

Incident Service Desk

Client Systeme

Daten und Systeme

Serversysteme

Netze und Kommunikation

Datenbanken

LAN

WAN

Externer Onsite Support

Abbildung 50:

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.

152

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): Prozesssteuerung: „Die Aktivität der Planung und Regulierung eines Prozesses, mit dem Ziel, den Prozess effektiv, effizient und konsistent 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 51). 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 51:

IT-Prozesse und bestehende Aufbauorganisation

153

WAN

3 IT Prozess-Management Damit ergibt sich letztendlich eine Matrixorganisation mit den bekannten strukturellen Problemen. Die Mitarbeiter sind einerseits einer Linienorganisation zugehörig und unterstellt, andererseits haben sie Aktivitäten innerhalb von einem oder mehreren IT Service Management-Prozessen durchzuführen, wofür jeweils ein Process 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änderungsmanagement 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 muss. 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 beizutra-

154

3.3 Etablierung des Prozess-Managements gen. Dies erfolgt sowohl durch ein begleitendes Veränderungsmanagement, 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 Verantwortlichkeiten 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-Organisationen 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 ProzessManager und einen Process Owner etablieren, sondern diese Aufgaben zusammenführen. Die hier beschriebenen 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]): Service Manager: “Ein Manager, der für das Management des gesamten Lebenszyklus von einem oder mehreren IT Services verantwortlich ist. Zudem wird der Begriff „Service Manager“ für alle Manager verwendet, die im Bereich des IT Service Providers beschäftigt sind. Am häufigsten wird der Begriff für Business Relationship Ma-

155

3 IT Prozess-Management nager, Prozess-Manager, Account Manager oder leitende Manager verwendet, die allgemein für IT Services verantwortlich sind.”

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. Daraus folgt, dass es eine den einzelnen Process Ownern und ProzessManagern 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 Process 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 Process 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 Process Owner und Prozess-Manager die Architekten und die Bauaufsicht darstellen. Dieser Vergleich trifft aber die Aufgabenstellung nur zum Teil. Während die Tätigkeiten der Architekten und der Bau-

156

3.3 Etablierung des Prozess-Managements aufsicht mit der Fertigstellung des Gebäudes abgeschlossen sind, ist das Prozess-Management eine stetige Managementtätigkeit.

3.3.2.2 Process Owner Der Process Owner ist für die Zielerreichung des jeweiligen Prozesses verantwortlich. Der Process 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“, „Consulted“ 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 52). 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 52:

Ausschnitt der RACI-Matrix zum Change Management (vgl. [OGC, 2007c])

157

3 IT Prozess-Management Die Definition von Kennzahlen setzt definierte Prozessziele voraus

Die Definition der zu erreichenden Ziele wird mit dem Service Manager abgestimmt und entsprechend dokumentiert. In der ITIL Version 3 wird die Rolle des Process Owners wie folgt definiert (vgl. [OGC, 2007b): Process Owner: “Eine Rolle, verantwortlich für die Sicherstellung der Zweckmäßigkeit eines Prozesses. Zu den Verantwortlichkeiten des Process Owners gehören das Sponsorship, das Design, das Change Management sowie die kontinuierliche Verbesserung des Prozesses und seiner Messgrößen. Diese Rolle wird häufig derselben Person zugewiesen, der bereits die Rolle des Prozess-Managers zugewiesen ist. In größeren Organisationen können diese Rollen jedoch separat zugewiesen sein.”

Auf Basis der definierten Ziele legt der Process Owner gemeinsam mit dem Prozess-Manager die damit verbundenen Kennzahlen fest. Erst mithilfe dieser Kennzahlen kann gesichert festgestellt werden, ob der Prozess 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 Process Owner, ob die definierten Ziele erreicht werden.

Es hat sich bewährt, dass der Process 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 Process 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.

158

3.3 Etablierung des Prozess-Managements

3.3.2.3 Prozess-Manager Die Verantwortung des Prozess-Managers besteht in der erfolgreichen Umsetzung des Prozesses auf Basis der definierten Ziele. Der ProzessManager 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): Prozess-Manager: „Eine Rolle, die für das operative Management eines Prozesses verantwortlich ist. Zu den Verantwortlichkeiten des Prozess-Managers gehören die Planung und die Koordination aller Aktivitäten, die zur Ausführung, dem Monitoring und der Berichtserstellung in Bezug auf einen Prozess erforderlich sind. Es können mehrere Prozess-Manager für einen Prozess vorhanden sein, z. B. regionale Change Manager oder IT Service Continuity Manager für jedes Rechenzentrum. Die Rolle des Prozess-Managers wird häufig der Person zugewiesen, der bereits die Rolle des Process Owners zugewiesen ist. In größeren Organisationen können diese Rollen jedoch separat zugewiesen sein.“

In kleineren IT-Organisationen erfolgt keine Unterteilung zwischen Process Owner und Prozess-Manager. Die Ergebnis- und Durchführungsverantwortung wird dann gemeinsam wahrgenommen. Im Rahmen der Durchführungsverantwortung gestaltet der ProzessManager 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 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 ProzessManager 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.

159

Kennzahlen sind die Arbeitsinstrumente des ProzessManagers.

3 IT Prozess-Management 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 ProzessManager 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 über 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. 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 über 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.

160

3.4 Definition der Prozessziele und -Kennzahlen 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. 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.

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.

161

Kennzahlen sind informations- und/ oder mitbestimmungspflichtig

3 IT Prozess-Management 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, überlä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 53). 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.

162

3.4 Definition der Prozessziele und -Kennzahlen Business

Business-Anforderungen IT-Services

Messung Service Level (Ziele)

SLA (OLA/UC)

Kapazitäten

Abbildung 53:

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 ImprovementPlan (PIP) des jeweiligen Prozesses dokumentiert (siehe Abbildung 54). 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.

163

3 IT Prozess-Management Business

Business-Anforderungen IT-Services

Messung Service Level (Ziele)

SLA (OLA/UC)

Kapazitäten Service Improvement Plan (SIP) Verbesserungspotenzial

Abbildung 54:

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 55) 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 56). 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.

164

3.4 Definition der Prozessziele und -Kennzahlen 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 55:

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 56:

Prozess Improvement Pläne (PIP)

Definition der Prozessziele – Kundenanforderungen

165

3 IT Prozess-Management 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 57). 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 57:

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.

166

3.4 Definition der Prozessziele und -Kennzahlen 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 58). Der Verbesserungsbedarf wird im Rahmen von Audits und Reviews sowie anhand der vorliegenden Prozess-Kennzahlen, deren Sollwerte 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 58:

Definition der Prozessziele – Prozess Improvement-Plan

167

3 IT Prozess-Management Diese Informationen sind der Input für die „Planung und Implementierung des IT Service Managements“ (siehe Abbildung 59). 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. 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 59:

Definition der Prozessziele – Planung und Implementierung

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.

Mit diesem übergeordneten Management-Prozess wird sichergestellt, dass die IT Service Management-Prozesse auf die Geschäftsziele und daraus

168

3.4 Definition der Prozessziele und -Kennzahlen 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 Management-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 60). 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. 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.

169

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

Planung und Implementierung des IT Service Managements Anforderungen

Service Management Plan (SMP)

Abbildung 60:

Prozess Improvement Pläne (PIP) Verbesserungspotenzial

Anforderungen

IT Service ManagementProzesse

Prozess Management Pläne (PMP)

Definition der Prozessziele – Service Management-Plan

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 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 61). Die konkrete Umsetzung ist Projektaufgabe.

170

3.4 Definition der Prozessziele und -Kennzahlen 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

Abbildung 61:

Planung und Implementierung des IT Service Managements Anforderungen

Service Management Plan (SMP)

Prozess Improvement Pläne (PIP) Verbesserungspotenzial

Anforderungen

Prozess Management Pläne (PMP)

IT Service ManagementProzesse

Konformität des Managementsystems

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.

3.4.2

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 dann auf der Basis der zuvor festgelegten Prozessziele (siehe Abbildung 62). 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 ei-

171

Die Prozessdokumentation stellt die Leitlinien dar.

3 IT Prozess-Management nerseits und einem ausreichenden Gestaltungsspielraum für die Mitarbeiter andererseits. Service Management Plan (SMP)

Prozess Management Plan (PMP)

IT Service ManagementProzesse

Wird sichergestellt durch

Aktivitäten Kritische Erfolgsfaktoren Control Objectives Abbildung 62:

Prozess-Management – Prozessdesign

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. 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 notwendige Abweichungen in die richtigen Bahnen zu lenken, und Änderungen müssen Einzug in die Prozessdokumentation finden. 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 63).

172

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) Abbildung 63:

Reviews/ Audits

Prozess-Management – Überprüfung

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.

Bei der Ausgestaltung (Prozessdesign) der Prozesse und der Definition der Kennzahlen (KGI, KPI), sowie bei den durchzuführenden Audits und Reviews unterstützen die Best Practices von COBIT und ITIL (siehe Abbildung 64). 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.

173

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

COBIT

ITIL

Abbildung 64:

Prozess-Management – Nutzung von COBIT und ITIL

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. 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 65).

174

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 Konformität COBIT

Abbildung 65:

ITIL

ISO 20000

Prozess-Management – Konformität

175

3 IT Prozess-Management 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 66).

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 ITIL

COBIT

Abbildung 66:

176

ISO 20000

Prozess-Management – Prozess Improvement-Plan

3.4 Definition der Prozessziele und -Kennzahlen 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 67 aus [OGC, 2007e] dar.

Vision Mission Ziele Objectives

CSFs

KPIs

Metriken Messungen Abbildung 67:

Entwicklung von Kennzahlen

177

3 IT Prozess-Management

3.4.3

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.

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 Nutzens 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.

178

3.4 Definition der Prozessziele und -Kennzahlen

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. So unterschiedlich die beteiligten Managementebenen sind, so unterschiedlich ist auch deren Informationsbedarf hinsichtlich der etablierten IT Service Management-Prozesse und der erbrachten Services. Der ProzessManager 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 Process 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 – d.h. 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 68):

179

Kennzahlen müssen ebenengerecht sein.

3 IT Prozess-Management Anteil fehlerfreier Changes Anteil termingerechter Changes

60%

20%

Effektivität Change Management

Anteil kostengerechter Changes

20%

Anteil zurückgewiesener Changes

40% Effizienz Change Management

Anteil der Notfall-Changes Abbildung 68:

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 wie folgt darstellen (siehe Abbildung 69):

Abbildung 69:

180

Darstellung der SLAs mit dem Q-Board von Q to be

3.4 Definition der Prozessziele und -Kennzahlen Die operativen Systeme, wie zum Beispiel die Tool-Unterstützung für das Change Management, liefern die notwendigen Basis-Informationen, aus 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 70).

Top Management

Prozess Management

gewichtete Kennzahlen

ProzessKennzahlen (KGI, KPI)

ITSM-Tool(s) …. weitere operative Systeme Basisdaten aus den jeweiligen Prozessen Abbildung 70:

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.

181

3 IT Prozess-Management 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 71 und Abbildung 72 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 71:

182

Exemplarischer Prozess-Bericht – Deckblatt zum Report

3.4 Definition der Prozessziele und -Kennzahlen

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 72:

Exemplarischer Prozess-Bericht – Darstellung der Kennzahlen

183

3 IT Prozess-Management 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 73.

Abbildung 73:

184

Darstellung des Management Cockpits von iET Solutions

3.5 Von der Kennzahl zur Verbesserungsmaßnahme

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 74).

Abbildung 74:

Beispiel für eine Trenddarstellung

Der Prozess-Manager hat durch detaillierte Auswertung festzustellen, warum sich die Erstlösungsquote verschlechtert. Hierzu muss der ProzessManager 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,

185

3 IT Prozess-Management 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 75).

Abbildung 75:

Beispiel 1 für eine Analyse möglicher Ursachen

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“.

186

3.5 Von der Kennzahl zur Verbesserungsmaßnahme 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 76).

Abbildung 76:

Beispiel 2 für eine Analyse möglicher Ursachen

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, so dass Analysen und deren Richtung situativ durchgeführt werden können.

187

3 IT Prozess-Management

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. 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.

188

3.7 Der Umgang mit Kennzahlen 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 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 Process 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.

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

189

3 IT Prozess-Management 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.

190

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ätsgetreu 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.

191

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ögen15 oder CAPIs16. Aber mit welcher Fragestellung lässt sich die Anwenderzufriedenheit ermitteln?

15

Diese werden auch „User Quality Surveys“ genannt.

16

CAPI steht für „Computer Assisted Personal Interview“.

192

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-Zielen 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 ServicePersonals. 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

193

4 IT Kennzahlensysteme Systemen immer geringer. Es kommt also darauf an, das Kennzahlensystem mit optimaler Größe auszulegen.17

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.

17

Wegen des Verhältnisses von Grenzkosten und Grenznutzen.

194

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, so dass 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? Welchen 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].

195

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. Kennzahlen

Beispiele

Fazit

196

Management

Anwender

IT-Entwicklung

IT-Betrieb

Kosten

2

2

7

4

Leistungen

-

-

2

7

Nutzen

3

2

-

-

Sonstige

-

-

3

2

– 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.

197

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, so dass 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.

198

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.

199

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 kann18, 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“19. In der Praxis zeigt sich: – Der Überdeckungsgrad der Kennzahlensysteme ist eher gering, d.h. 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.

18

Dies gilt im Übrigen auch für COBIT (vgl. Kapitel 3.3).

19

Vielleicht etwas hoffnungsvoller, versöhnlicher (und diplomatischer): „Keines ohne Modifikation“.

200

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, Process 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!

201

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.

203

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 77 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 77:

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.

204

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 den 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.

205

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. 20 – 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 78). Die Kennzahlen können Key Performance-Indikatoren21 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:

20

ROI im Sinne „Return on IT“.

21

KPIs im Sinne einer betriebswirtschaftlichen Begriffsbestimmung (vgl. den Exkurs zum Begriff KPI in Kapitel 5.2.2.)

206

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 78:

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 79). 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

207

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 79:

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.

208

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 80 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 80:

Beispiele für Lücken zwischen Kunden- und Providersicht

Wir haben in der Abbildung 80 drei Punkte herausgegriffen, an denen man CSIs messen kann:

209

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen – Zwischen Leistungserwartung und Servicewahrnehmung kann es eine Lücke 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ü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 Lücken (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 Abbildung 81 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 dasteht. Andere Quellen sind natürlich das Service Level Management, aber auch der Service Desk sowie das Projekt Management.

210

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 81:

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.

211

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 DeskMitarbeiter und die Kundenzufriedenheit mit der IT.

5.2.3

IT-Controls und Controls on Demand

Durch die Vielzahl eingesetzter Monitoring Tools stehen in IT-Organisationen 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.

212

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 22 Auswertung der Service-Aufträge Erstlösungsrate (Incident Management)23 Anteil fehlerhafter Changes (Change Management)24

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

22

Dies ist eine Standard-Kennzahl für das Prozessmanagement, die wir im folgenden Kapitel behandeln.

23

Dito.

24

Dito.

213

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen

Anwendungen – Datensicherungsprotokolle – Anzahl Datensätze in SAP BW

ITIL Prozesse (Process 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-Organisationen abweichen.

214

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 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.

215

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 aus „Service Design“ (früher Service Delivery), „Service Transition“ (früher Service Support) und „Service Operations“ (früher Service Support) ein einheitliches Tool mit einer zentralen gemeinsamen Datenbank. Bei anderen ITOrganisationen werden die Service Management-Prozesse von unterschiedlichen Tools und Datenbanken 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, indem 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.

216

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 Servicekatalog.

217

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 Servicekatalog 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).

218

5.3 Prozess-Kennzahlen

5.3.2.1 Service Portfolio Management Dieser Prozess ist für das Management des Serviceportfolios 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 Serviceportfolios

Name der Kennzahl

Anteil gelieferter Services

Definition

Anteil der im Serviceportfolio definierten Services, die von Kunden genutzt werden.

Relevanz

Diese Kennzahl zeigt die Nachfrage der angebotenen Services auf.

Messwert

Auswertung der Services im Servicekatalog und im Serviceportfolio.

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 Serviceportfolios.

Name der Kennzahl

Anteil Veränderungen im Serviceportfolio

Definition

Anteil der im Serviceportfolio 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 Serviceportfolios.

219

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl

Status der Services im Serviceportfolio

Definition

Status der Services im Serviceportfolio

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 Serviceportfolios und Gruppierung anhand des Status.

Bemerkung

Die Services können den folgenden Status annehmen „Servicekatalog“, „Servicepipeline“ (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, so dass 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

220

5.3 Prozess-Kennzahlen beschaffen. Häufig auftretende Anpassungen 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 Servicekatalog

Definition

Anzahl und Anteil der im Betrieb befindlichen Services, die im Servicekatalog beschrieben sind.

Relevanz

Der Servicekatalog soll alle im Betrieb befindlichen Services enthalten. Diese Kennzahl zeigt die Qualität und Aktualität des Servicekatalogs auf.

Messwert

Vergleich der SLAs mit dem Servicekatalog.

Bemerkung

Bei der Messung wird vorausgesetzt, dass für alle im Betrieb befindlichen Services SLAs existieren.

Name der Kennzahl

Inhaltliche Abweichungen zum Servicekatalog

Definition

Anteil der inhaltlichen Abweichungen der im Betrieb befindlichen Services gegenüber den Spezifikationen im Servicekatalog.

Relevanz

Der Servicekatalog dient auch der Standardisierung von Services. Weichen die tatsächlichen Services von den Beschreibungen im Servicekatalog ab, so wird diese Standardisierung nicht erreicht.

Messwert

Vergleich der SLAs mit dem Servicekatalog.

Bemerkung

Bei der Messung wird vorausgesetzt, dass für

221

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen alle im Betrieb befindlichen Services SLAs existieren.

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 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.

222

5.3 Prozess-Kennzahlen Bemerkung

Hierzu muss definiert werden, wann ein SLA als „eingehalten“ zählt. Zum Beispiel, wenn alle 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 bzw. Contracts entstanden sind.

Relevanz

Können SLAs nicht eingehalten werden, weil der Lieferant seine Zusagen nicht einhält, so

223

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen 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 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.

224

5.3 Prozess-Kennzahlen Messwert

Auswertung der offenen Maßnahmen im SIP.

Bemerkung

Die Maßnahmen sollten im Plan mit einem Status versehen werden. Dadurch können offene 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-Ziele, 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

225

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Messwert

Die Auslastungen werden in der Regel aus dem System-Management oder zum Beispiel mit Robotern (Antwortzeiten) ermittelt.

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.

226

5.3 Prozess-Kennzahlen 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.

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.

227

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Messwert

Vergleich über mehrere Tage, Wochen, Monate der Anzahl der eingehenden zu den ausgehenden Mails.

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.

228

5.3 Prozess-Kennzahlen 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äftszeiten 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 ver-

229

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen bundenen 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 Abkü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.

230

5.3 Prozess-Kennzahlen

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 reduziert Risiken auf eine akzeptable Ebene und plant des Recovery von IT Services. Dadurch stellt es sicher, dass der IT Service Provider immer die minimal vereinbarten Service Level-Ziele einhalten 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 ITSCMPlä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-

231

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Pläne im Notfall auch funktionieren. Daher sind sie regelmäßig zu testen. Messwert

Auswertung der durchgeführten Testprotokolle.

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 ge-

232

5.3 Prozess-Kennzahlen genüber dem IT Service Provider hat und die Handhabung von Schriftstücken, Gebäudezugängen, Telefonanrufe usw. für die gesamte Organisation beinhaltet. 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öglicher 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.

233

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Messwert

Auswertung durchgeführter Audits und Revisionen.

Bemerkung

Festgestellte Verletzungen von ComplianceAnforderungen sind besonders herauszustellen.

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..

234

5.3 Prozess-Kennzahlen

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. 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 sind.

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 unter-

235

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen schieden 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 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.

236

5.3 Prozess-Kennzahlen Bemerkung

5.3.3

Es kann auch der Lieferant zur Zufriedenheit befragt werden.

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.

237

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl

Kundenzufriedenheit Service Transition-Pläne

Definition

Ergebnis der Kundenzufriedenheit bezüglich der Service Transition-Pläne.

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.

238

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

239

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-

240

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 war.

241

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen 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, so dass 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.

Relevanz

RfCs können zurückgewiesen werden, wenn sie

242

5.3 Prozess-Kennzahlen 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 IT Service.

243

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen 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.).

Name der Kennzahl

Auswirkungen fehlerhafter CIs

Definition

Anzahl der fehlerhaften Changes, deren Ursa-

244

5.3 Prozess-Kennzahlen chen 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.

245

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

246

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.2 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.

247

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.3 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.

248

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 verbundenen 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.

249

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-

250

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.

251

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

252

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-

253

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 dem 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

254

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

255

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-

256

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 weist 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.

257

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen

5.3.4.3 Request Fulfilment 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.

Messwert

Dem Service Request muss ein Workflow mit

258

5.3 Prozess-Kennzahlen 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.

259

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 Kunde nicht die Terminologie von ITIL nutzt, so sind 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“

260

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.

261

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.

262

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 Incidents 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-

263

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.

264

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 messen wollen“ werden durchzuführende Aktivitäten bis zur „Implementierung korrigierende Aktionen” beschrieben. 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.

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.

265

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen 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.

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 eines Servers oder einer Applikation zu messen und zu berichten. Die IT muss in der Lage sein, „end-to-end“-Services 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.

266

5.3 Prozess-Kennzahlen 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

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

267

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl

Mehrwert Business

Definition

Mehrwert der durchgefü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 Abschnitt 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.

268

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.

269

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 – d.h. 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, die Sie gemeinsam aus

270

6.2 ITIL-Einführung Ihrer Einschätzung, aber auch mit Ihren Mitarbeitern und dem gewählten Berater befüllen, analysieren, vergleichen und bewerten können. Die ITIL-Prozesslandkarte soll aus den Prozessbedürfnissen der IT-Organisation im Bezug auf die Unternehmensstrategie 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 Prozesswissen 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 ist die mangelnde Akzeptanz der geplanten Maßnahmen und die damit verbundene Verzögerung bei der Umsetzung.

271

Initiierung der geplanten Maßnahmen

6 Lessons learned: Empfehlungen und Ratschläge Konsequenz hieraus: Der eigenen Organisation muss nun die Chance gegeben werden, sich weiterzuentwickeln und ITIL zu adaptieren. 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. Hierzu gibt es verschiedene Möglichkeiten, beispielsweise der Besuch von Kongressen, Inhouse-Seminare oder Workshops für Ihre Mitarbeiter.

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 wählen, wie zum Beispiel das ITIL-Forum, um von den Erfahrungen anderer IT-Organisationen zu profitieren. 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.

272

6.2 ITIL-Einführung 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.“ „Wir werden in Zukunft Ihre Businessprozesse noch optimaler unterstützen können.“

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 IT-Organisation (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.

273

6 Lessons learned: Empfehlungen und Ratschläge 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. Wertschätzung des Bestehenden

Für eine erfolgreiche Etablierung der geplanten IT Service ManagementProzesse ist die Akzeptanz seitens Ihrer Mitarbeiter eine unabdingbare Voraussetzung. 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, aus den Best Practices zu lernen und sich 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 sie unbedingt selbst erarbeiten.

274

6.2 ITIL-Einführung 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) Kenntnisse verfügen, sondern auch Erfahrungen aus vergleichbaren Projekten und vergleichbaren Organisationen mitbringen. Nicht zuletzt ist die Sozialkompetenz des Beraters dabei ein weiterer wichtiger Erfolgsfaktor: „Die Chemie muss stimmen“. Der Berater muss in der Lage sein, ggf. mit anderen Beratern zusammenzuarbeiten. Hierbei kann es sich unter Umständen um Berater handeln, die im Rahmen von IT Governance-Projekten tätig sind oder die Veränderungsprozesse Ihrer 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 von Incidents“ oder „Dauer der Nichtbearbeitung der Tickets“ aus dem Incident-Prozess oder aus Tools 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

275

Einbeziehung des Betriebsrats

6 Lessons learned: Empfehlungen und Ratschläge Prozesse gemessen werden und keine Auswertung auf Mitarbeiterebene erfolgt. – 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 ProzessManager 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 Managementvorgehensweise in der IT-Organisation: 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 ITOrganisation. 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 Ihren Zielen für Ihr Unternehmen und bezogen auf die Businessprozesse. Ebenso sollte der Reifegrad, d.h. 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.

276

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.

277

6 Lessons learned: Empfehlungen und Ratschläge Zur Identifizierung der verschiedenen Motivationsgründe ist es hilfreich, über einen externen Berater mit entsprechenden Erfahrungen zu verfügen.

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 oft in IT Rechenzentren 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. In von uns beratenen Unternehmen konnte zum Beispiel mit Hilfe des Prozesses Capacity Management dargestellt werden, welche Kosteneinsparungen durch die Konsolidierung der ITInfrastruktur 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 Process 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 Process Owner und Prozess-Manager. Diese generischen Rollenbeschreibungen sind im Rahmen der Umsetzung entsprechend der jeweiligen Organisation zu operationalisieren.

278

6.2 ITIL-Einführung Diesen Empfehlungen gemäß ist der Prozessinhaber (Process Owner) für die Prozessergebnisse verantwortlich, während der Prozess-Manager für die Durchführung und die Einrichtung des Prozesses verantwortlich ist. Der Process Owner dient dem Prozess-Manager primär als Coach.

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 ProzessManagers

Die Prozess-Ziele werden nicht nur primär vom Process Owner vorgegeben, sondern auch durch ihn aus der IT-Strategie und der Balanced Scorecard abgeleitet. Aus diesen Anforderungen heraus definiert der ProzessManager 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 (natürlich auch den Process Owner)“ 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.

279

Die Rolle des Service Managers

6 Lessons learned: Empfehlungen und Ratschläge Für die Einführung der IT Service Management-Prozesse und der identifizierten Optimierungsmaßnahmen ist der Service Manager richtungsweisend, er erstellt den „Bebauungsplan“. 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 ProzessManager 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 Process 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 ProzessManager steuern auf Qualitätsebene die operative Arbeit der Mitarbeiter.

280

6.3 Kontinuierlicher Verbesserungsprozess 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. 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 82. 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.

281

6 Lessons learned: Empfehlungen und Ratschläge 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.“

Abbildung 82:

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).

282

6.3 Kontinuierlicher Verbesserungsprozess

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. 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 ProzessManager 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.

283

6 Lessons learned: Empfehlungen und Ratschläge Dem Prozess-Manager mit dem bereits am weitesten entwickelten Prozess kommt hierbei eine besondere Rolle zu. Er muss auf die anderen ProzessManager zugehen und 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. Bei den bestehenden Prozessen zeichnet sich der KVP dadurch aus, dass die Prozesse gleichmäßig (vertikal) entwickelt werden und kein Process Owner – oder Manager die Entwicklung isoliert vorantreibt.

6.3.2 Nicht zu früh beginnen

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 wirklich 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änderungsmanagements. 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 83) zum Veränderungsmanagement (vgl. [Lewin, 1958]).

284

6.3 Kontinuierlicher Verbesserungsprozess

Neue Welt

Alte Welt

Einfrieren

Auftauen

Bewegen Abbildung 83:

3-Phasen-Modell nach Lewin

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 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.

285

6 Lessons learned: Empfehlungen und Ratschläge 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. Beginnen Sie zu früh mit den nächsten Verbesserungsmaßnahmen, so nehmen Sie ihrer IT-Organisation und Ihren Mitarbeitern die Chance, die bisher erzielten Vorteile zu erleben. Das Service ImprovementProgramm

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 ITOrganisation beitragen.

286

6.3 Kontinuierlicher Verbesserungsprozess Damit entsteht 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. 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.

ITILEinführung erfordert ein Release

Diese „Verbesserungstä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. Bündeln Sie die einzelnen Verbesserungs- und Erweiterungsmaßnahmen zu einem Aufgabenpaket (Release).

Dem Process Owner kommt hierbei als Coach eine qualitätssichernde Aufgabe zu. Zum Beispiel hat der Process 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 – d.h. die Erweiterung der bestehenden IT Service Management-Prozesse – liegt beim Service Manager (beraten und unterstützt durch die Process Owner, als auch die ITLeitung) – und dem prozessverantwortlichen Prozess-Manager.

287

Der Entfaltungsprozess

6 Lessons learned: Empfehlungen und Ratschläge Es ist hilfreich, wenn die Process 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. 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 initiiert“ 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 in vollem Umfang 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 (auch die Process Owner und die IT-Leitung) – und damit indirekt auch das gesamte Management – über ein gutes Führungssystem zur Überwachung der geplanten Maßnahmen und der erzielten Prozessreife.

288

6.3 Kontinuierlicher Verbesserungsprozess 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.

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 Process Owner sowie der IT-Leitung ü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 Verbesse-

289

6 Lessons learned: Empfehlungen und Ratschläge rungsprozess und der damit verbundenen Planung entsteht so auch ein internes Benchmarking.

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 Knowhow. 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.

290

6.4 Kennzahlen Die Abstimmung des IT Service Managements auf die Business-Strategie sollte so früh wie mö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 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 müssen 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.

291

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“ (vgl. [OGC, 2005b]) führt hierzu aus: „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.

292

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.

293

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 Process Owner geben. Aufgrund der Anforderungen und seinen Erfahrungen aus dem Tagesgeschäft ist der Process 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 mit Ihren Kunden vereinbarten SLAs – 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. Im Rahmen dieser schrittweisen Erweiterung können Sie dann auch auf Best Practices wie ITIL oder COBIT zurückgreifen. Prüfen Sie die dort

294

6.4 Kennzahlen 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 sicherstellen, 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 Volumina (z.B. < 100.000 Euro; < 500.000 Euro) und damit eine Gruppierung nach A,B,C Kunden.

6.4.2

ITIL – abgestimmt auf 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 Service wahrnimmt. Dies ist in der Regel der Arbeitsplatz, und dieser Ansatz führt damit zu einer „end-to-end“-Messung des IT Service.

295

Den Kunden rechtzeitig einbinden.

6 Lessons learned: Empfehlungen und Ratschläge 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, d.h. die Realisierung einer „end-to-end“-Messung, sollte zumindest mittelbis 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 Kundenservice-Manager und dem Relationship-Manager, 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 mit Ihrem Kunden besprechen. 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.

296

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, d.h. 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.

297

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 erreichten Service Level zu berichten. Es gilt 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. Beispielsweise kann es sinnvoll sein, darzustellen, welche Folgen Störungen hatten, welche Konsequenzen ein Ausfall einzelner Standorte hatte und welche Verbesserungsmaßnahmen eingeleitet wurden, um diese Ausfälle in Zukunft zu vermeiden. Ein monatlicher Report könnte beispielsweise folgende Informationen enthalten: Im Monat März hatten wir am 12.3.2007 eine Störung in der Anwendung XYZ. Diese Störung wurde hervorgerufen durch den Austausch einer technischen Komponente, die zu einem Ausfall des Netzwerkes 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 Hardware-Wechsels vor Ort verfügbar zu haben, um damit eine schnellere Reparatur zu ermöglichen und so die Verfügbarkeit zu erhöhen. 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. 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 Management hat die Weiterentwicklung zur Aufgabe

Das Top-Management, der Service Manager, die Process 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.

298

6.4 Kennzahlen 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 vergleichen, wo Ihre IT-Organisation 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 Process 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 IT-Organisationen beobachten, andere Ansätze prüfen und mehrwertschaffende Konzepte adaptieren.

Auf 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 ProzessManager 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). – 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.

299

Mitarbeiter müssen geschult werden

6 Lessons learned: Empfehlungen und Ratschläge 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 ProzessManager 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 bewä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.

300

6.4 Kennzahlen 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 Process Owner In den vorhergehenden Kapiteln wurde bereits auf die Rolle des Service Managers, des Prozess-Managers und des Process Owners eingegangen. Oft können Process Owner und Prozess-Manager organisatorisch über Kreuz besetzt werden – dass heißt, der Process 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 Process Owner allein aufgrund der hierarchischen Stellung den ProzessManager.

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.

301

Die Balanced Scorecard ermöglicht die Ausrichtung auf die ITStrategie

6 Lessons learned: Empfehlungen und Ratschläge 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 Process 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.

Process Owner Innerhalb des RZs hat es sich als vorteilhaft erwiesen, die Rolle des Process Owners rotieren zu lassen. Durch die wechselnden Process Owner wird der Blickwinkel des Prozess-Managers im Laufe der Zeit erweitert. Wenn möglich, wird die Rolle des Process Owners aus dem Bereich besetzt, der die größten Auswirkungen des Prozesses erfährt. So kommt zum Beispiel der Process 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 Process Owner werden aus einer Hierarchieebene besetzt, die gegenüber der IT-Organisation weisungsbefugt ist. Innerhalb des Rechenzentrums unseres Beispiels sind die Process Owner Bereichs- und Abteilungsleiter, die direkt der Geschäftsführung berichten.

302

6.4 Kennzahlen

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 werden, 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 liefern. Der Process Owner ist die Person, die diesen Input sicherstellt. Der Process 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 ProzessManagers ist es dann, notwendige Maßnahmen abzuleiten, sie mit dem Process Owner und dem Service Manager abzustimmen und schließlich im Prozess umzusetzen.

303

6 Lessons learned: Empfehlungen und Ratschläge 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 Process 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 Owner und Prozess-Manager aus dem gleichen Bereich kommen. Die Rotation der Process Owner erweitert den Horizont der ProzessManager. Sehr oft kommt dem Process Owner die Rolle eines Coaches zu.

304

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.

305

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 Managements 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.

306

7 Praxisbeispiel: ALTANA Pharma AG Hier haben sich so genannte „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 den IT Service Support Prozessen 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 Servicekatalogs – Ü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 dienten 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

307

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.

308

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-

309

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, d.h. dort wo der „Schuh am meisten drückte“. Dies sind mengenorientierte Kennzahlen wie – Anzahl RfCs pro Kalenderwoche / Monat (siehe Abbildung 84) / Jahr / Workgroup / Priorisierung / Service 32 28 24

# of RfCs

20 16 12 8 4

07

7 M

ai

20

20 0

07 A

z är

pr il

20

00 r2 M

Fe

br

ua

ar nu Ja

be

7

07 20

00 r2

r2 D

ez

em

em ov N

6

6 00

06 be

er kt ob

m te ep S

O

be

us ug A

20

00

6 t2

r2

00

6 00

6

li 2

ni Ju

Ju

20 0

06 20 ai M

Abbildung 84:

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 85) 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 vorgegebene Datum des Änderungsanforderers überschritten ist – Anzahl RfCs mit verknüpften Incidents oder Problems

310

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 85:

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.

311

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.

312

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-

313

8 Praxisbeispiel: Autobahn Tank & Rast GmbH lichkeit im Focus der mittel- und langfristigen Ziele. Um dies zu gewährleisten wurde ein IT-Kennzahlensystem entwickelt, das 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, das 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.

314

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.

315

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-

317

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.

318

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 in der folgenden Abbildung 86 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 86:

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

319

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 (siehe Abbildung 87). 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.

320

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 87:

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

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 (siehe Abbildung 88).

321

9 Praxisbeispiel: Flughafen München

Abbildung 88:

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 SiloSpezialisten 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.

322

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 (siehe Abbildung 89). Die Service Management-Prozesse verbinden die langfristige Ausrichtung des Servicebereichs IT mit der kurzfristigen Zieldefinition und -verfolgung.

323

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 89:

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 Process 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 90 können die im Servicebereich IT implementierten Service Management-Prozesse entnommen werden.

324

9 Praxisbeispiel: Flughafen München

Abbildung 90:

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

325

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 91). 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).

326

9 Praxisbeispiel: Flughafen München

Abbildung 91:

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 Process 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ä-

327

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 Process Ownern ITSM-Praxistrainings mit Fallbeispielen und Toolnutzung für die Prozesse Incident-, Problem- und Change-Management , durchgeführt von den Process 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

328

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, d.h. 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 Process Owner „Problem-Management“ und seinen Linienverantwortlichen von großem Interesse, jedoch weniger für die Geschäftsführung des Unternehmens. Die folgende Tabelle (Abbildung 92) zeigt einen Auszug der ersten Ebene der Prozess-Kennzahlen:

329

9 Praxisbeispiel: Flughafen München

Abbildung 92:

Auszug der ersten Ebene der Kennzahlen des SB IT

Im Rahmen der jährlichen IT-Strategie werden konkrete Prozessziele und die Sollwerte für die einzelnen Kennzahlen mit dem Process 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

330

9 Praxisbeispiel: Flughafen München die Definition von angestrebten Zielzuständen erforderlich; der so genannte Prozess Improvement-Plan (Schema siehe Abbildung 93). 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 93:

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.

331

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 20000Zertifikat 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.

332

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

333

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 unserer IT nach ISO/TS 16949, sowie kundenspezifische Audits und IT-Überprüfungen 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.

334

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.

335

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

337

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

338

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

339

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 [itSMF, 2007] ITIL V3 Glossary Arbeitskreis Publikation ITIL® Version 3 Translation Project itSMF Deutschland e.V., (Englische Basisversion: 3.1.24), Version: 31.08.2007 [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

340

11.1 Quellenverzeichnis Download-Bereich http://www.kess-dv.de/Wir-Ueber-Uns/Beschreibungenund-Downloads/beschreibungen-und-downloads.html, 10.03.2007 [KESS, 2007a] KESS DV-Beratung GmbH Beschreibung zum ITIL Service Manager Seminar http://www.kess-dv.de/Seminare/Service-Manager/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

341

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

342

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

343

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

344

11.2 Abkürzungsverzeichnis

11.2 Abkürzungsverzeichnis ACD

Automatic Call Distribution

BCM

Business Continuity Management

BIA

Business Impact Analysis

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

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

ISO

International Organization for Standardization

345

11 Anhang 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

346

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 IT Services auf das Business ............14

Abbildung 5:

Die 5 Phasen des Service Lifecycle nach ITIL V3...............17

Abbildung 6:

Integrierter Ablauf der Lifecycle Elemente.........................18

Abbildung 7:

Service Lifecycle und Prozesse.............................................21

Abbildung 8:

Elemente Service Strategy .....................................................22

Abbildung 9:

Serviceportfolio und die einzelnen Stati .............................24

Abbildung 10: Verbindung zwischen IT Service und BusinessService......................................................................................25 Abbildung 11: Die Wertebetrachtung eines IT Service ...............................26 Abbildung 12: Service Strategy als Basis für den Service Lifecycle...........27 Abbildung 13: Service Design Aufgaben und Einbindung ........................28 Abbildung 14: Vom Serviceportfolio zum Servicekatalog..........................29 Abbildung 15: Die Inhalte und Sichten des Servicekatalogs......................31 Abbildung 16: Service Transition-Prozesse ..................................................32 Abbildung 17: Daten und Informationsquellen für ein CMS.....................34 Abbildung 18: Service Knowledge Management System...........................36 Abbildung 19: Autorisierungsebenen für Changes .....................................37 Abbildung 20: Service Operation im Service Lifecycle ...............................38 Abbildung 21: Service Operation-Prozesse ..................................................39 Abbildung 22: Prozesse aus Service Operation............................................41 Abbildung 23: Service Operation-Funktionen .............................................42 Abbildung 24: Continual Service Improvement ..........................................43 Abbildung 25: Service Transition-Prozesse ..................................................44 Abbildung 26: Service Reporting orientiert am Kundenbedarf.................47 Abbildung 27: ITIL Version 3 Prozessmodell...............................................49 Abbildung 28: Die 5 Phasen des Service Lifecycle und ihre Prozesse ......58 Abbildung 29: Service Strategy ......................................................................59

347

11 Anhang Abbildung 30: Service Design.........................................................................62 Abbildung 31: Service Transition ...................................................................72 Abbildung 32: Das Service V-Modell.............................................................79 Abbildung 33: Service Operation ...................................................................82 Abbildung 34: Continual Service Improvement ..........................................90 Abbildung 35: 7 Step Improvement-Prozess ................................................91 Abbildung 36: IT Service Management-Prozesse der ISO 20000 .............101 Abbildung 37: PDCA-Methodik...................................................................103 Abbildung 38: COBIT Prozess-Übersicht....................................................106 Abbildung 39: Zusammenhang zwischen Control Objectives in COBIT ....................................................................................108 Abbildung 40: Ziele, Prozesse und Metriken in COBIT............................109 Abbildung 41: Prozess, Ziele und Kontrollebenen in COBIT...................111 Abbildung 42: Mapping der Prozesse in ITIL Version 2 und COBIT .....112 Abbildung 43: Wertschöpfungskette nach Porter......................................123 Abbildung 44: Zusammenhang zwischen SLAs, OLAs und UCs ...........126 Abbildung 45: Beispiel für mehrschichtige SLAs ......................................127 Abbildung 46: Allgemeine Balanced Scorecard .........................................138 Abbildung 47: Ursache-Wirkungskette.......................................................140 Abbildung 48: Stellung der BSC im Unternehmensplanungsprozess ....140 Abbildung 49: PDCA-Zyklus........................................................................148 Abbildung 50: Exemplarische Darstellung der Bearbeitung eines Incidents ................................................................................152 Abbildung 51: IT-Prozesse und bestehende Aufbauorganisation ...........153 Abbildung 52: Ausschnitt der RACI-Matrix zum Change Management (vgl. [OGC, 2007c]) .......................................157 Abbildung 53: Definition der IT Services....................................................163 Abbildung 54: Definition der IT Services – Service ImprovementPlan.........................................................................................164 Abbildung 55: Definition der Prozessziele – Neue Services.....................165 Abbildung 56: Definition der Prozessziele – Kundenanforderungen.....165 Abbildung 57: Definition der Prozessziele – IT-Strategie .........................166 Abbildung 58: Definition der Prozessziele – Prozess ImprovementPlan.........................................................................................167

348

11.3 Abbildungsverzeichnis Abbildung 59: Definition der Prozessziele – Planung und Implementierung..................................................................168 Abbildung 60: Definition der Prozessziele – Service ManagementPlan.........................................................................................170 Abbildung 61: Konformität des Managementsystems..............................171 Abbildung 62: Prozess-Management – Prozessdesign..............................172 Abbildung 63: Prozess-Management – Überprüfung ...............................173 Abbildung 64: Prozess-Management – Nutzung von COBIT und ITIL .........................................................................................174 Abbildung 65: Prozess-Management – Konformität .................................175 Abbildung 66: Prozess-Management – Prozess Improvement-Plan .......176 Abbildung 67: Entwicklung von Kennzahlen ............................................177 Abbildung 68: Zusammengesetzte Prozess-Kennzahlen..........................180 Abbildung 69: Darstellung der SLAs mit dem Q-Board von Q to be .....180 Abbildung 70: Das IT Service Management Kennzahlensystem .............181 Abbildung 71: Exemplarischer Prozess-Bericht – Deckblatt zum Report.....................................................................................182 Abbildung 72: Exemplarischer Prozess-Bericht – Darstellung der Kennzahlen ...........................................................................183 Abbildung 73: Darstellung des Management Cockpits von iET Solutions ................................................................................184 Abbildung 74: Beispiel für eine Trenddarstellung.....................................185 Abbildung 75: Beispiel 1 für eine Analyse möglicher Ursachen..............186 Abbildung 76: Beispiel 2 für eine Analyse möglicher Ursachen..............187 Abbildung 77: Schema zur Klassifikation von IT-Kennzahlen ................204 Abbildung 78: Key Success-Faktoren im IT Management Report...........207 Abbildung 79: Key Success-Faktoren zur Gruppierung von KPIs und CSIs ................................................................................208 Abbildung 80: Beispiele für Lücken zwischen Kunden- und Providersicht.........................................................................209 Abbildung 81: Gaps nach OGC (aus [OGC, 2007e]) ..................................211 Abbildung 82: Deming (oder PDCA) Zyklus .............................................282 Abbildung 83: 3-Phasen-Modell nach Lewin .............................................285 Abbildung 84: Anzahl der RfCs pro Monat (Demo-Daten)......................310

349

11 Anhang Abbildung 85: Status aller RfCs (Demo-Daten)..........................................311 Abbildung 86: Organisationsstruktur Flughafen München, Servicebereich IT ..................................................................319 Abbildung 87: Von den Unternehmenszielen zu der Umsetzung in der IT ......................................................................................321 Abbildung 88: Prozessorientierte Sicht des Servicebereichs IT................322 Abbildung 89: Ausrichtung der Prozesse an der IT-Strategie..................324 Abbildung 90: Die Prozesslandkarte des Servicebereichs IT ...................325 Abbildung 91: Das ITSM-Portal des Servicebereichs IT............................327 Abbildung 92: Auszug der ersten Ebene der Kennzahlen des SB IT ......330 Abbildung 93: Auszug aus dem Service Improvement-Plan des SB IT.............................................................................................331

350

11.4 Glossar

11.4 Glossar In diesem Glossar werden die in der ITIL V3 verwendeten Begriffe erläutert. Das Glossar ist ein Auszug der offiziellen Übersetzung seitens des itSMF Deutschland e.V. und findet Einzug in die deutsche Übersetzung der offiziellen ITIL-Literatur. Access Management

Der Prozess, der für die Zulassung der Nutzung von IT Services, Daten und anderen Assets durch Anwender verantwortlich ist. Das Access Management bietet Unterstützung beim Schutz der Vertraulichkeit, Integrität und Verfügbarkeit von Assets, indem sichergestellt wird, dass nur berechtigte Anwender auf die jeweiligen Assets zugreifen oder Änderungen an diesen vornehmen können. Das Access Management kann auch als BerechtigungsManagement oder Identitäts-Management (Identity Management) bezeichnet werden.

Asset

Bezeichnung für jede Ressource oder Fähigkeit. Die Assets eines Service Providers umfassen alle Elemente, die zur Erbringung eines Service beitragen können. Assets können folgende Typen einschließen: Management, Organisation, Prozess, Wissen, Mitarbeiter, Informationen, Anwendungen, Infrastruktur und finanzielles Kapital.

Asset Management

Das Asset Management ist der Prozess, der für die Verfolgung der Werte und Besitzverhältnisse in Bezug auf finanzielle Assets sowie deren Erfassung in Berichten während ihres gesamten Lebenszyklus verantwortlich ist. Das Asset Management ist Teil des umfassenden Prozesses Service Asset and Configuration Management.

Availability Management

Der Prozess, der für die Definition, Analyse, Planung, Messung und Verbesserung sämtlicher Aspekte in Bezug auf die Verfügbarkeit von IT Services verantwortlich ist. Im Availability Management muss sichergestellt werden, dass die gesamte ITInfrastruktur, sowie sämtliche Prozesse, Hilfsmittel, Rollen etc. für die vereinbarten Service Level-Ziele eine entsprechende Verfügbarkeit ermöglichen.

351

11 Anhang Balanced Scorecard

Ein Management-Hilfsmittel, das von Dr. Robert Kaplan (Harvard Business School) und Dr. David Norton entwickelt wurde. Mit einer Balanced Scorecard kann eine Strategie in Key Performance Indicators unterteilt werden. Anhand der Performance im Vergleich mit den KPIs wird dargestellt, wie gut die Strategie umgesetzt werden konnte. Eine Balanced Scorecard verfügt über vier Hauptbereiche, von denen jeder eine kleinere Anzahl von KPIs umfasst. Diese vier Bereiche werden mit unterschiedlichem Detaillierungsgrad innerhalb der gesamten Organisation genauer untersucht.

Benchmark

Der erfasste Zustand eines Elements zu einem bestimmten Zeitpunkt. Ein Benchmark kann für eine Configuration, einen Prozess oder einen beliebigen anderen Satz von Daten erstellt werden. Ein Benchmark kann beispielsweise in folgenden Bereichen verwendet werden: Continual Service Improvement, um den Ist-Zustand beim Erzielen von Verbesserungen zu definieren oder Capacity Management, um Performance-Merkmale während des normalen Betriebs zu dokumentieren.

Best Practice

Aktivitäten oder Prozesse, deren Einsatz in mehreren Organisationen nachweislich zum gewünschten Erfolg geführt hat. ITIL ist ein Beispiel für Best Practice.

Business Case

Rechtfertigung für einen umfassenden Ausgabenposten. Beinhaltet Informationen zu Kosten, Nutzen, Optionen, offenen Punkten, Risiken und möglichen Problemen.

Business Continuity Management

Der Business-Prozess, der für den Umgang mit Risiken verantwortlich ist, die zu schwerwiegenden Auswirkungen auf das Business führen können. Das BCM sichert die Interessen der wichtigsten Stakeholder, das Ansehen, die Marke und die wertschöpfenden Aktivitäten des Business. Für den Fall einer Unterbrechung der Geschäftsabläufe werden im BCM-Prozess die Risiken auf ein akzeptables Maß reduziert und eine Planung der Wiederherstellung von Business-Prozessen vorgenommen. Das BCM legt die Ziele, den Umfang und die Anforderungen

352

11.4 Glossar für das IT Service Continuity Management fest. Business Impact Analyse

Die BIA ist die Aktivität im Business Continuity Management, die die Vital Business Functions und deren Abhängigkeiten identifiziert. Diese Abhängigkeiten können zwischen Suppliern, Mitarbeitern, anderen Business-Prozessen, IT Services etc. bestehen. Die BIA definiert die Wiederherstellungsanforderungen für IT Services. Zu diesen Anforderungen gehören die maximale Wiederherstellungszeit nach einem Ausfall, der tolerierte Datenverlust aufgrund von Ausfällen und die mindestens erforderlichen Service Level-Ziele für die jeweiligen IT Services.

Business Service Management

Im Kontext von ITSM die verantwortliche Aktivität, um zukünftige Business-Anforderungen für die Verwendung im Capacity-Plan nachzuvollziehen.

Capacity Management

Der Prozess, bei dem sichergestellt wird, dass die Kapazität der IT Services und die IT-Infrastruktur ausreicht, um die vereinbarten Service Level-Ziele wirtschaftlich und zeitnah erreichen zu können. Beim Capacity Management werden alle Ressourcen, die für die Erbringung von IT Services erforderlich sind, sowie Pläne für kurz-, mittel- und langfristige Business-Anforderungen berücksichtigt.

Change Advisory Board

Eine Gruppe von Personen, die den Change Manager bei der Bewertung, Festlegung von Prioritäten und zeitlichen Planung in Bezug auf Changes beraten. Dieses Gremium setzt sich in der Regel aus Vertretern aller Bereiche des IT Service Providers, dem Business und den Drittparteien wie z. B. Suppliern zusammen.

Change Management

Der Prozess, der für die Steuerung des Lebenszyklus aller Changes verantwortlich ist. Wichtigstes Ziel des Change Management ist es, die Durchführung von lohnenden Changes bei einer minimalen Unterbrechung der IT Services zu ermöglichen.

CMDB

Eine Datenbank, die verwendet wird, um Configuration Records während ihres gesamten Lebenszyklus zu speichern. Das Configuration Management System verwaltet eine oder mehrere CMDBs, und jede CMDB speichert Attribute von CIs sowie Beziehungen zu anderen CIs.

353

11 Anhang COBIT

Control Objectives for Information and related Technology (COBIT) bietet Anleitungen und Best Practices für die Verwaltung von IT-Prozessen. COBIT wird vom IT Governance Institute herausgegeben. Weitere Informationen dazu finden Sie unter http://www.isaca.org/.

Component Capacity Management

Verantwortlich für die Aspekte der Kapazität, Auslastung und Performance von Configuration Items Hier werden Daten im Capacity-Plan gesammelt, erfasst und analysiert.

Configuration Item

Alle Komponenten, die verwaltet werden müssen, um einen IT Service bereitstellen zu können. Informationen zu den einzelnen CIs werden in einem Configuration Record innerhalb des Configuration Management Systems erfasst und über den gesamten Lebenszyklus hinweg vom Configuration Management verwaltet. CIs unterstehen der Steuerung und Kontrolle des Change Management. CIs umfassen vor allem IT Services, Hardware, Software, Gebäude, Personen und formale Dokumentationen, beispielsweise zum Prozess und SLAs.

Configuration Management System

Ein Satz an Hilfsmitteln und Datenbanken, der für die Verwaltung der Configuration-Daten eines IT Service Providers verwendet wird. Das CMS enthält darüber hinaus Informationen zu Incidents, Problemen, Known Errors, Changes und Releases und kann auch Daten zu Mitarbeitern, Suppliern, Standorten, Geschäftsbereichen, Kunden und Anwendern beinhalten. Das CMS umfasst Hilfsmittel zum Sammeln, Speichern, Verwalten, Aktualisieren und Präsentieren von Daten zu allen Configuration Items und deren Beziehungen. Das CMS untersteht der Zuständigkeit des Configuration Management und wird von allen IT Service ManagementProzessen eingesetzt.

Critical Success Factor

Ein Bestandteil, das für einen erfolgreichen Prozess, (ein erfolgreiches) Projekt, Plan oder IT Service erforderlich ist. Um das Erreichen eines CSF zu messen, werden KPIs eingesetzt. Ein CSF in Bezug auf den „Schutz von IT Services bei der Durchführung von Changes“ könnte von KPIs wie „Verringerung des Anteils nicht erfolgreicher Changes“ und „Ver-

354

11.4 Glossar ringerung der Changes, die Incidents verursachen, in Prozent“ etc. gemessen werden. Continual Service Improvement

Eine Phase im Lebenszyklus eines IT Service und Titel einer der ITIL-Kernpublikationen. Das Continual Service Improvement ist verantwortlich für die Verwaltung von Verbesserungen in IT Service Management-Prozessen und IT Services. Dabei werden die Performance des IT Service Providers kontinuierlich gemessen und Verbesserungen an Prozessen, IT Services und der IT-Infrastruktur vorgenommen, um die Effizienz, Effektivität und Wirtschaftlichkeit zu steigern.

Definitive Media Library

Ein oder mehrere Standorte, an denen die endgültigen und genehmigten Versionen aller Software Configuration Items sicher gespeichert sind. Die DML kann darüber hinaus zugehörige CIs wie Lizenzen und Dokumentationen beinhalten. Die DML ist als einzelner logischer Speicherbereich definiert, auch wenn sie auf verschiedene Speicherorte aufgeteilt ist. Die gesamte Software in der DML untersteht der Steuerung des Change und Release Management und wird im Configuration Management System erfasst. Für ein Release ist ausschließlich der Einsatz von Software aus der DML akzeptabel.

Demand Management

Aktivitäten, die sich mit dem Bedarf des Kunden an Services befassen und auf diesen Bedarf sowie auf die Bereitstellung der Kapazität Einfluss nehmen, um diesem Bedarf gerecht zu werden. Auf strategischer Ebene kann das Demand Management die Analyse von Business-Aktivitätsmustern und Anwenderprofilen einbeziehen. Auf taktischer Ebene kann es eine differenzierte Leistungsverrechnung einsetzen, um die Nutzung von IT Services bei den Kunden zu Zeiten mit einer geringeren Auslastung zu fördern.

Deployment

Die Aktivität, die für den Übergang neuer oder geänderter Hardware, Software, Dokumentation, Prozesse etc. in die Live-Umgebung verantwortlich ist. Das Deployment ist Teil des Release and Deployment Management-Prozesses.

355

11 Anhang Effektivität

Ein Maß dafür, ob die Ziele eines Prozesses, eines Service oder einer Aktivität erreicht wurden. Bei einem effektiven Prozess oder einer effektiven Aktivität werden die zugehörigen vereinbarten Ziele erreicht.

Effizienz

Ein Maß dafür, ob die richtige Menge an Ressourcen eingesetzt wurde, um einen Prozess, einen Service oder eine Aktivität bereitzustellen. Ein effizienter Prozess erreicht seine Ziele innerhalb der kürzest möglichen Zeit bei einem minimalen Einsatz von Geldmitteln, Mitarbeitern oder anderen Ressourcen.

Emergency Change

Ein Change, der so bald wie möglich eingeführt werden muss, beispielsweise um einen Major Incident zu lösen oder ein Sicherheits-Patch zu installieren. Der Change Management-Prozess bietet in der Regel ein bestimmtes Verfahren für die Behandlung von Notfall-Changes.

Evaluation

Der Prozess, der für die Bewertung eines neuen oder geänderten IT Service verantwortlich ist, um sicherzustellen, dass Risiken verwaltet wurden, und festlegen zu können, ob mit dem Change fortgefahren werden soll. Eine Evaluierung bezeichnet darüber hinaus den Vergleich eines Ist-Ergebnisses mit dem beabsichtigten Ergebnis oder den Vergleich unterschiedlicher Alternativen.

Event

Eine Statusänderung, die für die Verwaltung eines Configuration Item oder IT Service von Bedeutung ist. Der Begriff „Event“ bezeichnet darüber hinaus einen Alarm oder eine Benachrichtigung durch einen IT Service, ein Configuration Item oder ein Monitoring Tool. Bei Events müssen in der Regel die Mitarbeiter des IT-Betriebs aktiv werden, und häufig führen Events zur Erfassung von Incidents.

Event Management

Der Prozess, der für die Verwaltung von Events während ihres Lebenszyklus verantwortlich ist. Das Event Management ist eine der wichtigsten Aktivitäten des IT-Betriebs.

Financial Management

Die Funktionen und die Prozesse mit der Verantwortung für den Umgang mit den Anforderungen eines IT Service Providers an die Budgetierung, die Kostenrechnung und die Leistungsverrechnung.

356

11.4 Glossar Governance

Sicherstellen, dass Richtlinien und Strategien auch tatsächlich implementiert werden und erforderliche Prozesse korrekt eingehalten werden. Die Governance umfasst die Definition von Rollen und Verantwortlichkeiten, Maßnahmen und Berichte sowie Aktionen zur Lösung aller identifizierten Anliegen.

Incident

Eine nicht geplante Unterbrechung eines IT Service oder eine Qualitätsminderung eines IT Service. Auch ein Ausfall eines Configuration Item ohne bisherige Auswirkungen auf einen Service ist ein Incident. Beispiel: Ein Ausfall einer oder mehrerer Festplatten in einer gespiegelten Partition.

Incident Management

Der Prozess, der für die Verwaltung des Lebenszyklus aller Incidents verantwortlich ist. Wichtigstes Ziel des Incident Management ist eine schnellstmögliche Wiederherstellung des IT Service für die Anwender.

Information Security Management

Der Prozess, bei dem die Vertraulichkeit, Integrität und Verfügbarkeit der Assets, Informationen, Daten und IT Services einer Organisation sichergestellt werden. Das Information Security Management ist in der Regel Teil eines organisatorischen Ansatzes für das Security Management, der über den Aufgabenbereich des IT Service Providers hinausgeht, und berücksichtigt die Verwaltung papierbasierter Dokumente, Zutrittsrechte, Telefonanrufe etc. für die gesamte Organisation.

Integrität

Ein Sicherheitsprinzip, das sicherstellt, dass Daten und Configuration Items nur durch autorisierte Mitarbeiter und Aktivitäten modifiziert werden. Die Integrität berücksichtigt alle möglichen Ursachen einer Modifikation, wie Ausfälle von Software oder Hardware, Umgebungs-Events und Eingriffe durch Personen.

ISO

Die International Organization for Standardization (ISO) ist der weltweit größte Entwickler von Standards. Die ISO ist eine regierungsunabhängige Organisation, die aus einem Netzwerk nationaler Standardisierungsinstitute aus 156 Ländern besteht. Weitere Informationen zu ISO finden Sie unter http://www.iso.org/.

357

11 Anhang ITIL

Ein Satz an Best Practice-Leitlinien für das IT Service Management. Inhaber von ITIL ist das OGC. ITIL umfasst eine Reihe von Publikationen, die Leitlinien zur Bereitstellung von qualitätsbasierten IT Services sowie zu den Prozessen und Einrichtungen bieten, die zur Unterstützung dieser Services erforderlich sind.

IT Service

Ein Service, der für einen oder mehrere Kunden von einem IT Service Provider bereitgestellt wird. Ein IT Service basiert auf dem Einsatz der Informationstechnologie und unterstützt die Business-Prozesse des Kunden. Ein IT Service besteht aus einer Kombination von Personen, Prozessen und Technologie und sollte in einem Service Level Agreement definiert werden.

IT Service Continuity Management

Der Prozess, der für die Verwaltung von Risiken verantwortlich ist, die zu schwerwiegenden Auswirkungen auf IT Services führen können. Das ITSCM stellt sicher, dass der IT Service Provider stets ein Mindestmaß an vereinbarten Service Level bereitstellen kann, indem die Risiken auf ein akzeptables Maß reduziert werden und eine Wiederherstellungsplanung für IT Services erfolgt. Das ITSCM sollte so konzipiert sein, dass es das Business Continuity Management unterstützt.

IT Service Management

Die Implementierung und Verwaltung von qualitätsbasierten IT Services, die den Anforderungen des Business gerecht werden. Das IT Service Management wird von IT Service Providern mithilfe einer geeigneten Kombination aus Personen, Prozessen und Informationstechnologie durchgeführt. Siehe Service Management.

IT Service Provider

Ein Service Provider, der IT Services für interne Kunden oder externe Kunden bereitstellt.

itSMF

Beim IT Service Management Forum handelt es sich um eine unabhängige Organisation, die sich der Förderung und Verbreitung eines professionellen Ansatzes für das IT Service Management widmet. Das itSMF ist eine nicht gewinnorientierte Mitgliederorganisation mit Vertretern aus zahlreichen Ländern weltweit (itSMF Verbände). Das itSMF und

358

11.4 Glossar seine Mitglieder unterstützen die Entwicklung von ITIL sowie der zugehörigen IT Service Management Standards. Weitere Informationen dazu finden Sie unter http://www.itsmf.de/. Key Performance Indicator

Eine Messgröße, die einen Prozess, einen IT Service oder eine Aktivität unterstützen soll. Es können Messungen anhand von zahlreichen Messgrößen erfolgen, es werden jedoch nur die wichtigsten dieser Größen als KPIs definiert und für eine aktive Verwaltung und Berichtserstellung in Bezug auf den Prozess, den IT Service oder die Aktivität eingesetzt. Bei der Auswahl der KPIs sollte die Sicherstellung von Effizienz, Effektivität und Wirtschaftlichkeit berücksichtigt werden.

Knowledge Management

Der Prozess, der für die Sammlung, die Analyse, das Speichern und die gemeinsame Nutzung von Wissen und Informationen innerhalb einer Organisation verantwortlich ist. Wichtigster Zweck des Knowledge Management ist eine gesteigerte Effizienz, indem bereits vorhandenes Wissen nicht erneut entwickelt werden muss.

Known Error

Ein Problem, für das die zugrunde liegende Ursache und ein Workaround dokumentiert wurden. Das Problem Management ist verantwortlich für die Erstellung und Verwaltung von bekannten Fehlern während ihres gesamten Lebenszyklus. Bekannte Fehler können auch von der Entwicklung oder den Suppliern identifiziert werden.

Lifecycle

Die unterschiedlichen Phasen während der Lebensdauer eines IT Service, Configuration Item, Incident, Problems, Change etc. Der Lebenszyklus definiert die Statuskategorien sowie die erlaubten Statusübergänge. Beispiel: Der Lebenszyklus einer Anwendung umfasst: Anforderungen, Design, Build, Deployment, Betrieb und Optimierung. Der erweiterte Incident-Lebenszyklus umfasst: Erkennung, Antwort, Diagnose, Reparatur, Instandsetzung und Wiederherstellung. Der Lebenszyklus eines Servers kann Folgendes umfassen: Bestellt, Erhalten, Testphase, Live-Phase, Entsorgt etc.

359

11 Anhang Monitoring

Wiederholte Beobachtung eines Configuration Item, IT Service oder Prozesses, um Events zu ermitteln, und sicherzustellen, dass der aktuelle Status bekannt ist.

OGC

Das OGC ist Inhaber der Marke ITIL (Copyright und Handelsmarke). Beim OGC handelt es sich um eine Behörde der britischen Regierung, die die Bereitstellung der Beschaffungsplanung für die britische Regierung unterstützt, indem ein gemeinschaftlicher Ansatz für Beschaffungsmöglichkeiten und die Steigerung der Fähigkeiten für die Beschaffung von Behörden und Abteilungen gefördert wird. Es bietet darüber hinaus Unterstützung für komplexe Projekte aus dem öffentlichen Bereich.

Operational Level Agreement

Eine Vereinbarung zwischen einem IT Service Provider und einem anderen Teil derselben Organisation. Ein OLA unterstützt die Bereitstellung von IT Services durch den IT Service Provider für den Kunden. Das OLA definiert zu liefernde Waren oder Services und die Verantwortlichkeiten der beiden Parteien. Ein OLA könnte beispielsweise bestehen zwischen: dem IT Service Provider und einer Einkaufsabteilung, um Hardware innerhalb vereinbarter Zeitspannen zu erhalten, oder dem Service Desk und einer Support-Gruppe, um eine Incident-Lösung innerhalb der vereinbarten Zeit zu erreichen.

Outsourcing

Einsatz eines externen Service Providers für die Verwaltung von IT Services.

PDCA

Ein Zyklus in vier Phasen für das Prozessmanagement, der auf Edward Deming zurückgeführt wird. „Plan-Do-Check-Act“ wird auch als Qualitätszyklus nach Deming bezeichnet. PLAN (Planen): Design oder Überarbeitung von Prozessen, die die IT Services unterstützen. DO (Durchführen): Implementierung des Plans und Verwaltung der Prozesse. CHECK (Überprüfen): Messung der Prozesse und IT Services, Vergleich mit den Zielen und Erstellung von Berichten. ACT (Handeln): Planung und Implementierung von Changes, um die Prozesse zu verbessern.

360

11.4 Glossar Problem

Die Ursache für einen oder mehrere Incidents. Zum Zeitpunkt der Erstellung eines Problem Record ist die Ursache in der Regel unbekannt. Für die weitere Untersuchung ist der Problem Management-Prozess verantwortlich.

Problem Management

Der Prozess, der für die Verwaltung des Lebenszyklus aller Probleme verantwortlich ist. Wichtigstes Ziel des Problem Management ist es, Incidents zu verhindern bzw. die Auswirkungen von Incidents zu minimieren, die nicht verhindert werden können.

Process Owner

Eine Rolle, verantwortlich für die Sicherstellung der Zweckmäßigkeit eines Prozesses. Zu den Verantwortlichkeiten des Process Owners gehören das Sponsorship, das Design, das Change Management sowie die kontinuierliche Verbesserung des Prozesses und seiner Messgrößen. Diese Rolle wird häufig derselben Person zugewiesen, der bereits die Rolle des Prozess-Managers zugewiesen ist. In größeren Organisationen können diese Rollen jedoch separat zugewiesen sein.

Prozess

Ein strukturierter Satz an Aktivitäten, mit deren Hilfe ein bestimmtes Ziel erreicht werden soll. Ein Prozess wandelt einen oder mehrere definierte Inputs in definierte Outputs um. Ein Prozess kann beliebige Rollen, Verantwortlichkeiten, Hilfsmittel und Steuerungen für das Management enthalten, die für eine zuverlässige Bereitstellung der Outputs erforderlich sind. Ein Prozess kann den Anforderungen entsprechend Richtlinien, Standards, Leitlinien, Aktivitäten und Arbeitsanweisungen definieren.

Prozess-Manager

Eine Rolle, die für das operative Management eines Prozesses verantwortlich ist. Zu den Verantwortlichkeiten des Prozess-Managers gehören die Planung und die Koordination aller Aktivitäten, die zur Ausführung, dem Monitoring und der Berichtserstellung in Bezug auf einen Prozess erforderlich sind. Es können mehrere Prozess-Manager für einen Prozess vorhanden sein, z. B. regionale Change Manager oder IT Service Continuity Manager für jedes Rechenzentrum. Die Rolle des Prozess-Managers wird häufig der Person zugewiesen, der bereits die Rolle des Process Owners zugewiesen ist. In größe-

361

11 Anhang ren Organisationen können diese Rollen jedoch separat zugewiesen sein. Prozesssteuerung

Die Aktivität der Planung und Regulierung eines Prozesses, mit dem Ziel, den Prozess effektiv, effizient und konsistent auszuführen.

RACI

Ein Modell, auf dessen Grundlage Rollen und Verantwortlichkeiten definiert werden. RACI steht für „Responsible“ (zuständig für die Durchführung), „Accountable“ (letztlich verantwortlich für die Aktivität), „Consulted“ (muss/soll beteiligt werden, liefert Input) und „Informed“ (muss über den Fortschritt informiert werden).

Reifegrad

Eine bestimmte Ebene im Reife-Modell, wie die Capability Maturity Model Integration von der Carnegie Mellon University in den USA.

Release

Eine Zusammenstellung von Hardware, Software, Dokumentation, Prozessen oder anderen Komponenten, die für die Implementierung eines oder mehrerer genehmigter Changes an IT Services erforderlich sind. Die Inhalte jedes Releases werden als eine Einheit verwaltet, getestet und implementiert.

Release and Deployment Management

Der Prozess, der sowohl für das Release Management als auch für das Deployment verantwortlich ist.

Release Management

Der Prozess, der für die Planung, den zeitlichen Ablauf und die Steuerung des Übergangs von Releases in Test- und Live-Umgebungen verantwortlich ist. Das wichtigste Ziel des Release Management ist es, sicherzustellen, dass die Integrität der LiveUmgebung aufrechterhalten wird und dass die richtigen Komponenten im Release enthalten sind. Das Release Management ist Teil des Release and Deployment Management-Prozesses.

Release Unit

Komponenten eines IT Service, die üblicherweise im selben Release veröffentlicht werden. Eine Release Unit umfasst in der Regel genügend Komponenten, um eine nützliche Funktion auszuführen. Eine Release Unit könnte z. B. ein Desktop-PC mit Hardware, Software, Lizenzen, Dokumentation usw. sein. Eine weitere Release Unit könnte die gesamte An-

362

11.4 Glossar wendung für die Lohnbuchhaltung sein, einschließlich IT-Betriebsverfahren und Anwendertrainings Request for Change

Der formale Antrag zur Durchführung eines Change. Ein RfC beinhaltet Details zum beantragten Change und kann auf Papier oder elektronisch erfasst werden. Der Begriff „RfC“ wird häufig fälschlicherweise für einen Change Record oder den Change selbst verwendet.

Request Fulfilment

Der Prozess, der für das Management des Lebenszyklus aller Service Requests verantwortlich ist.

Return of Investment

Eine Messgröße für den erwarteten Nutzen einer Investition. Einfach ausgedrückt handelt es sich beim ROI um Nettoerlös dividiert durch den Nettowert der investierten Assets.

Risikomanagement

Der Prozess, der für die Identifizierung, Bewertung und Steuerung von Risiken verantwortlich ist.

Security Management

Synonym für Information Security Management.

Service

Eine Möglichkeit, einen Mehrwert für Kunden zu erbringen, indem das Erreichen der von den Kunden angestrebten Ergebnisse erleichtert oder gefördert wird. Dabei müssen die Kunden selbst keine Verantwortung für bestimmte Kosten und Risiken tragen.

Service Asset

Jedwede Fähigkeit oder Ressource eines Service Providers. Siehe Asset.

Service Asset & Configuration Management

Der Prozess, der sowohl für das Configuration Management als auch das Asset Management verantwortlich ist.

Service Capacity Management

Dient der Gewinnung von Erkenntnissen zur Performance und Kapazität von IT Services. Die Ressourcen, die von jedem IT Service verwendet werden, werden für die Nutzung im Capacity-Plan erfasst, aufgezeichnet und analysiert.

Service Design

Eine Phase im Lebenszyklus eines IT Service. Service Design umfasst eine Reihe von Prozessen und Funktionen. Gleichzeitig ist es der Titel einer ITILKernpublikation.

Service Desk

Der Single Point of Contact für die Kommunikation

363

11 Anhang zwischen Service Provider und Anwendern. Ein Service Desk bearbeitet in der Regel Incidents und Service Requests und ist für die Kommunikation mit den Anwendern zuständig. Service Improvement-Plan (SIP)

Ein formeller Plan zur Implementierung von Verbesserungen für einen Prozess oder IT Service.

Service Knowledge Management System

Eine Sammlung von Hilfsmitteln und Datenbanken, die zur Verwaltung von Wissen und Informationen verwendet werden. Das SKMS umfasst das Configuration Management System sowie andere Hilfsmittel und Datenbanken. Das SKMS speichert, verwaltet, aktualisiert und präsentiert alle Informationen, die ein IT Service Provider zur Verwaltung des gesamten Lebenszyklus von IT Services benötigt.

Service Level

Messbare und nachweisbare Ergebnisse, die im Hinblick auf ein oder mehrere Service Level-Ziele erreicht werden. Der Begriff „Service Level“ wird im Sprachgebrauch auch als Synonym für Service Level-Ziel verwendet.

Service Level Agreement

Eine Vereinbarung zwischen einem IT Service Provider und einem Kunden. Das SLA beschreibt den jeweiligen IT Service, dokumentiert Service LevelZiele und legt die Verantwortlichkeiten des IT Service Providers und des Kunden fest. Ein einzelnes SLA kann mehrere IT Services oder mehrere Kunden abdecken.

Service Level Requirement

Eine Kundenanforderung für einen Aspekt eines IT Service. SLRs basieren auf Business-Zielen und werden zur Aushandlung vereinbarter Service LevelZiele eingesetzt.

Service Level Management

Der Prozess, der für das Verhandeln von Service Level Agreements sowie deren Einhaltung verantwortlich ist. Das SLM soll sicherstellen, dass alle IT Service Management-Prozesse, Operational Level Agreements und Underpinning Contracts für die vereinbarten Service Level-Ziele angemessen sind. SLM ist für das Monitoring und die Berichterstattung in Bezug auf Service Level sowie für die regelmäßige Durchführung von Kunden-Reviews

364

11.4 Glossar zuständig. Service Level-Ziel

Eine Verpflichtung, die in einem Service Level Agreement dokumentiert ist. Service Level-Ziele basieren auf Service Level Anforderungen und sollen die Zweckmäßigkeit des Designs eines IT Service sicherstellen. Service Level-Ziele sollten SMART (Spezifisch, Messbar, Akzeptabel, Realistisch, Terminiert) sein und basieren in der Regel auf KPIs.

Service Management

Das Service Management ist die Gesamtheit der spezialisierten organisatorischen Fähigkeiten, die zur Generierung eines Mehrwerts für Kunden in Form von Services verfügbar sind.

Service Manager

Ein Manager, der für das Management des gesamten Lebenszyklus von einem oder mehreren IT Services verantwortlich ist. Zudem wird der Begriff „Service Manager“ für alle Manager verwendet, die im Bereich des IT Service Providers beschäftigt sind. Am häufigsten wird der Begriff für Business Relationship Manager, Prozess-Manager, Account Manager oder leitende Manager verwendet, die allgemein für IT Services verantwortlich sind.

Service Operation

Eine Phase im Lebenszyklus eines IT Service. Service Operation umfasst eine Reihe von Prozessen und Funktionen. Gleichzeitig ist es der Titel einer der ITIL-Kernpublikationen.

Service Owner

Eine Rolle, die für die Bereitstellung eines bestimmten IT Service verantwortlich ist.

Service Portfolio Management

Der Prozess, der für das Management des Serviceportfolios verantwortlich ist. Beim Service Portfolio Management steht der Wert der Services im Vordergrund, den diese für das Business darstellen.

Service Reporting

Der Prozess, mit dem Berichte zu Ergebnissen und Trends hinsichtlich bestimmter Service Level erstellt und bereitgestellt werden. Beim Service Reporting sollte das Format, der Inhalt und die Häufigkeit der Berichte zuvor mit den jeweiligen Kunden abgesprochen werden.

Service Request

Eine Anfrage eines Anwenders nach Informationen, Beratung, einem Standard-Change oder nach Zugriff auf einen IT Service. Dabei könnte es sich

365

11 Anhang beispielsweise um das Zurücksetzen eines Passworts oder die Bereitstellung standardmäßiger IT Services für einen neuen Anwender handeln. Service Requests werden in der Regel von einem Service Desk bearbeitet und erfordern üblicherweise nicht die Einreichung eines RfC. Service Strategy

Der Titel einer der ITIL-Kernpublikationen. Im Rahmen der Service Strategy wird eine umfassende Strategie für IT Services und für das IT Service Management entworfen.

Service Transition

Eine Phase im Lebenszyklus eines IT Service. Service Transition umfasst eine Reihe von Prozessen und Funktionen. Gleichzeitig ist es der Titel einer der ITIL-Kernpublikationen.

Service Validation and Testing

Der Prozess, der für die Validation und das Testen eines neuen oder geänderten IT Service verantwortlich ist. Service Validation and Testing stellt sicher, dass der IT Service den jeweiligen Designspezifikationen entspricht und den Bedürfnissen des Business gerecht wird.

Servicekatalog

Eine Datenbank oder ein strukturiertes Dokument mit Informationen zu allen Live IT Services, einschließlich der Services, die für das Deployment verfügbar sind. Der Servicekatalog ist der einzige Bestandteil des Serviceportfolios, der an die Kunden ausgehändigt wird. Er unterstützt den Vertrieb und die Bereitstellung von IT Services. Der Servicekatalog enthält Angaben zu Lieferergebnissen, Preisen, Bestellungen und Anfragen sowie Kontaktinformationen.

Serviceportfolio

Die Gesamtheit aller Services, die von einem Service Provider verwaltet werden. Das Serviceportfolio wird für das Management des gesamten Lebenszyklus aller Services genutzt. Es umfasst drei Kategorien: Servicepipeline (beantragt oder in der Entwicklung), Servicekatalog (Live oder bereit zum Deployment) und außer Kraft gesetzte Services. Siehe Service Portfolio Management und Vertragsportfolio.

Single Point of Contact

Der Single Point of Contact dient als einzige, konsistente Schnittstelle für die Kommunikation mit einer Organisation oder einem Geschäftsbereich. Der Sin-

366

11.4 Glossar gle Point of Contact eines IT Service Providers wird in der Regel als „Service Desk“ bezeichnet. Supplier Management

Der Prozess ist verantwortlich dafür sicherzustellen, dass alle Verträge mit Suppliern die Anforderungen des Business unterstützen und alle Supplier ihre vertraglichen Verpflichtungen erfüllen.

Supplier- und Vertragsdatenbank

(Supplier and Contract Database, SCD). Eine Datenbank oder ein strukturiertes Dokument, das verwendet wird, um Supplier-Verträge während ihres gesamten Lebenszyklus zu verwalten. Die SCD enthält die wichtigsten Attribute aller Supplier-Verträge und sollte Teil des Service Knowledge Management Systems sein.

System Management

Der Bereich des IT Service Management, bei dem nicht das Management von Prozessen, sondern das Management der IT-Infrastruktur im Vordergrund steht.

Transition Planning and Support

Der Prozess, der für die Planung aller Service Transition-Prozesse und die Koordinierung der hierfür benötigten Ressourcen verantwortlich ist. Zu diesen Service Transition-Prozessen zählen Change Management, Service Asset and Configuration Management, Release and Deployment Management, Service Validation and Testing, Evaluation und Knowledge Management.

Underpinning Contract

Ein Vertrag zwischen einem IT Service Provider und einer Drittpartei. Die Drittpartei stellt Waren oder Services zur Verfügung, die die Bereitstellung eines IT Service für einen Kunden unterstützen. Der Underpinning Contract definiert Ziele und Verantwortlichkeiten, um die in einem SLA vereinbarten Service Level-Ziele zu erreichen.

Verfügbarkeit

Fähigkeit eines Configuration Item oder IT Service, bei Bedarf die dafür vereinbarte Funktion auszuführen. Die Verfügbarkeit wird durch Aspekte in Bezug auf Zuverlässigkeit, Wartbarkeit, Servicefähigkeit, Performance und Sicherheit bestimmt. Die Verfügbarkeit wird in der Regel als Prozentwert ausgedrückt, der häufig basierend auf der vereinbarten Servicezeit und der Ausfallzeit berechnet wird. Gemäß der Best Practice wird die Verfügbarkeit mithil-

367

11 Anhang fe von Messgrößen aus dem Business-Ergebnis des IT Service berechnet. Verification and Audit

Die Aktivitäten, mit denen sichergestellt wird, dass die Informationen in der CMDB präzise sind und dass alle Configuration Items identifiziert und in der CMDB erfasst wurden. Die Verifizierung beinhaltet routinemäßige Prüfungen im Rahmen von anderen Prozessen. Zum Beispiel die Verifizierung der Seriennummer eines Desktop-PCs, wenn ein Anwender einen Incident meldet. Ein Audit ist eine periodisch durchgeführte, formale Prüfung.

Vertraulichkeit

Ein Sicherheitsprinzip, das fordert, dass ausschließlich autorisierte Personen auf Daten zugreifen können.

Workaround

Die Reduzierung oder Beseitigung der Auswirkungen von Incidents oder Problemen, für die noch keine vollständige Lösung verfügbar sind, z. B. durch den Neustart eines ausgefallenen Configuration Item. Workarounds für Probleme werden in Known Error Records dokumentiert. Workarounds für Incidents, die nicht über zugeordnete Problem Records verfügen, werden in Incident Records dokumentiert.

368

11.5 Sachwortverzeichnis

11.5 Sachwortverzeichnis —A—

Event Management 82, 250

Access Management 87, 262

—F—

Asset 59

Financial Management 55, 59, 217

Asset Management 75 Availability Management 8, 56, 66, 228

—G— Governance 12, 104

—B—

—I—

Balanced Scorecard 3, 5, 135

Improvement Prozess 90

Benchmark 208

Incident 53

Best Practice 1, 3 Business Case 59

Incident Management 6, 52, 84, 151, 252

Business Continuity Management 56, 68

Information Security Management 69, 147, 232

Business-Servicekatalog 63

ISO 20000 3, 4, 5, 97, 99, 101, 102, 128

—C— Capacity Management 55, 65, 225

IT Prozess-Management 147 IT Service 5, 13, 121

Change Management 53, 54, 74, 239

IT Service Continuity Management 56, 68, 231

COBIT 2, 5, 103

IT Service Management 5, 52

Configuration Management 53, 75

IT Service Provider 13, 42, 124, 125, 133, 134

Continual Service Improvement 15, 42, 90, 265

IT-Controls 212

Controls on Demand 212

ITIL Best Practice 130

Critical Success Factor 110, 159

ITIL Refresh 298

—D—

—K—

Definitive Media Library 247

Kennzahlen 1, 7, 11, 52, 57, 102, 135, 147, 161, 171, 178, 188, 189, 191, 203, 214, 291

Demand Management 47, 61, 220 —E— Evaluation 80, 247

ITIL 1, 2, 3, 5, 7, 11, 16, 22, 47

Kennzahlensystem 2, 5, 141, 191, 195, 203, 206, 209

369

11 Anhang Key Performance-Indikator 57, 108, 206, 209, 211

Request Fulfilment 85, 101, 215, 258

Knowledge Management 81, 237, 248

Return on Investment 96, 136, 267

Kontinuierlicher Verbesserungsprozess 281

Risiko Management 16

—L—

—S—

Lifecycle 6, 15, 16

Security Management 56, 113, 119

—M—

Service 12

Metriken 113

Service Asset 75

Monitoring 119 —O—

Service Asset and Configuration Management 75, 215, 237, 243

Operational Level Agreement 56, 124, 222

Service Catalogue Management 63, 221

Outsourcing 273, 306

Service Design 15, 27, 62, 221

—P—

Service Desk 9, 53, 68, 89, 114, 263

PDCA-Zyklus 147 Plan-Do-Check-Act 102

Service Improvement-Plan 102, 163, 169, 181, 287

Problem Management 53, 86, 111, 114, 120, 260

Service Level 38

Process Owner 10, 50, 51, 144, 149, 154, 157, 158 Prozess-Kennzahlen 171, 178, 214 Prozess-Management 150 Prozess-Manager 51, 144, 149, 154, 159 Prozesssteuerung 49 —R— Reifegrad 290 Release and Deployment Management 77, 237, 245

Service Level Agreement 13, 61, 84, 100, 124, 125, 129, 222 Service Level Management 8, 55, 63, 97, 124, 128, 222, 268 Service Level Requirement 124 Service Level-Ziel 63, 132, 193, 222 Service Management 1, 7, 15 Service Manager 155 Service Measurement 95, 266 Service Operation 15, 37, 47, 82, 250

Release Management 54, 245

Service Portfolio Management 47, 60, 63, 219

Reporting 119

Service Reporting 94, 265

Request for Change 53, 120

370

11.5 Sachwortverzeichnis Service Request 57, 85, 89, 97, 252, 258

—T—

Service Strategy 11, 20, 59, 101, 161, 217

The 7 Step Improvement Process 265

Service Transition 15, 32, 47, 72, 237

Transition Planning and Support 72, 237

Service Validation and Testing 78, 237

—U—

Technischer Servicekatalog 63

Servicekatalog 22, 63, 128

Underpinning Contract 56, 124, 222

Serviceportfolio 22, 60, 63, 219

—V—

Single Point of Contact 263

Verification and Audit 242

Supplier Management 71, 235

—W—

System Management 191

Workaround 129

371