Manageme It

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® V3Strategien, Kennzahlen, Umsetzung

2., aktualisierte und erweiterte Auflage

Mit 93 Abbildungen

PRAXIS

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

1. Auflage 20072., 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. JedeVerwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohneZustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere fürVervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherungund Verarbeitung in elektronischen Systemen.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werkberechtigt 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 dahervon jedermann benutzt werden dürften.

Umschlaggestaltung: KünkelLopka Medienentwicklung, HeidelbergDruck und buchbinderische Verarbeitung: Wilhelm & Adam, HeusenstammGedruckt auf säurefreiem und chlorfrei gebleichtem Papier.Printed in Germany

ISBN 978-3-8348-0526-3

Das in diesem Werk enthaltene Programm-Material ist mit keiner Verpflichtung oder Garantie irgend-einer Art verbunden. Der Autor übernimmt infolgedessen keine Verantwortung und wird keine darausfolgende 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 undAuslieferung unserer Bücher wollen wir die Umwelt schonen: Dieses Buch ist auf säurefreiem undchlorfrei gebleichtem Papier gedruckt. Die Einschweißfolie besteht aus Polyäthylen und damit ausorganischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffefreisetzen.

V

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 Er-folg. 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 inte-grativer. 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 Ser-vice 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 aktu-ell in der Praxis relevant sind und Hunderte von Unternehmen – nicht nur in Deutschland – beschäftigen. Das Erstaunliche ist, dass die beiden The-men eng zusammenhängen und sich gegenseitig beeinflussen. Das Erfreu-liche ist, dass mit ITIL V3, COBIT 4 und ISO 20000 ein Best Practice Werk-zeugkasten zur Verfügung steht, mit dem man einen Großteil der Heraus-forderungen 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 Manage-ments und Fachbegriffe voraus. Die Beispiele, die wir aufgenommen haben, basieren auf unseren Erfah-rungen als auch auf Referenz- und Kundenprojekten, die wir begleitet haben.

Vorwort

VI

Ein Buch, wie dieses, entsteht nur, wenn ausgezeichnete Leute dazu bei-tragen. 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).

VII

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 Deutsch-land 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 Über-arbeitung 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:

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

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 we-niger als Lehrbuch zu ITIL V3 gedacht. Es geht um Grundlagen, Ideen, IT-Management, 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

IX

Inhaltsverzeichnis

1 Einführung und Überblick .............................................................................1

2 IT Service Management ..................................................................................52.1 Management Summary .............................................................................52.2 ITIL und ISO 20000.....................................................................................52.3 Die Struktur gemäß ITIL Version 2..........................................................7

2.3.1 Das Service Management auf Basis der ITIL Version 2...........72.3.2 Der prozessorientierte Ansatz von ITIL Version 2...................8

2.4 Die Struktur gemäß ITIL Version 3........................................................112.4.1 ITIL und der Service Lifecycle ..................................................162.4.2 Service Strategy...........................................................................202.4.3 Service Design.............................................................................272.4.4 Service Transition .......................................................................322.4.5 Service Operation .......................................................................372.4.6 Continual Service Improvement...............................................422.4.7 Der prozessorientierte Ansatz von ITIL Version 3.................47

2.5 ITIL Kennzahlen für IT Service Management-Prozesse......................522.5.1 Ausgewählte Kennzahlen der ITIL Version 2.........................522.5.2 Prozesse und ausgewählte Kennzahlen der ITIL Version 3 .57

2.6 ISO 20000 ...................................................................................................972.6.1 Die Geschichte der ISO 20000 ...................................................992.6.2 Der Aufbau der ISO 20000.........................................................992.6.3 Die Inhalte der ISO 20000 ........................................................1012.6.4 Die ISO 20000 und Kennzahlen ..............................................102

2.7 COBIT.......................................................................................................1032.7.1 Entwicklung von COBIT .........................................................1042.7.2 Struktur von COBIT .................................................................1052.7.3 Prozess-Management gemäß COBIT .....................................1062.7.4 COBIT und die IT Service Management-Prozesse ...............111

Inhaltsverzeichnis

X

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

2.8 Monitoring und Reporting von SLAs ..................................................1192.8.1 Definition und Interpretation des Begriffs „IT Service“......1212.8.2 Service Level Agreements .......................................................1242.8.3 Das Zusammenwirken von SLAs, OLAs und UCs..............1252.8.4 Der Aufbau von SLAs ..............................................................1262.8.5 Die Inhalte von SLAs................................................................1282.8.6 Monitoring und Reporting von SLAs, OLAs und UCs .......1322.8.7 Abgrenzung der Kennzahlen..................................................135

2.9 Integrationsinstrument: Balanced Scorecard ......................................1352.9.1 Kernideen...................................................................................1362.9.2 Anwendung auf den IT-Bereich .............................................1412.9.3 Ausprägungen der Balanced Scorecard ................................142

2.10 Konsequenzen.......................................................................................144

3 IT Prozess-Management..............................................................................1473.1 Management Summary .........................................................................1473.2 PDCA-Zyklus..........................................................................................1473.3 Etablierung des Prozess-Managements...............................................150

3.3.1 Der Charakter von IT-Prozessen ............................................1513.3.2 Rollen im Prozess-Management .............................................155

3.4 Definition der Prozessziele und -Kennzahlen ....................................1613.4.1 Definition der Prozessziele......................................................1613.4.2 Definition der Prozess-Kennzahlen .......................................1713.4.3 Dokumentation der Prozess-Kennzahlen..............................1783.4.4 Reporting der Prozess-Kennzahlen........................................179

3.5 Von der Kennzahl zur Verbesserungsmaßnahme .............................1853.6 Kennzahlen müssen reifen ....................................................................1883.7 Der Umgang mit Kennzahlen ...............................................................189

4 IT Kennzahlensysteme ................................................................................1914.1 Management Summary .........................................................................1914.2 Ziele ..........................................................................................................192

Inhaltsverzeichnis

XI

4.3 Überblick .................................................................................................1954.3.1 SVD 1980...........................................................................................1964.3.2 Diebold 1984.....................................................................................1974.3.3 Kargl 1996 .........................................................................................1984.3.4 Van der Zee 1996 .............................................................................199

4.4 Bewertung ...............................................................................................2004.5 Konsequenzen.........................................................................................201

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen....2035.1 Management Summary .........................................................................2035.2 Klassifikationsschema für IT-Kennzahlen ..........................................203

5.2.1 Key Success Factors..................................................................2055.2.2 Key Performance und Customer Satisfaction.......................2085.2.3 IT-Controls und Controls on Demand...................................212

5.3 Prozess-Kennzahlen...............................................................................2145.3.1 Service Strategy.........................................................................2175.3.2 Service Design...........................................................................2215.3.3 Service Transition .....................................................................2375.3.4 Service Operation .....................................................................2505.3.5 Continual Service Improvement.............................................265

6 Lessons learned: Empfehlungen und Ratschläge...................................2696.1 Management Summary .........................................................................2696.2 ITIL-Einführung .....................................................................................270

6.2.1 Analyse der bestehenden Prozesse ........................................2706.2.2 Prozess-Einführungen..............................................................2746.2.3 Die Organisation gewinnen ....................................................2776.2.4 Rollenbeschreibungen..............................................................278

6.3 Kontinuierlicher Verbesserungsprozess..............................................2816.3.1 KVP der bestehenden Prozesse ..............................................2836.3.2 KVP der neuen Prozesse..........................................................2846.3.3 Wettbewerb der Prozesseinführung ......................................2896.3.4 Reifegradanalyse der Prozesse im laufenden Betrieb..........290

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

Inhaltsverzeichnis

XII

6.4.1 IT-Prozesse am Tagesgeschäft ausrichten .............................2926.4.2 ITIL – abgestimmt auf Business- und IT-Strategie...............2956.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 .........................................................................................................33711.1 Quellenverzeichnis ...............................................................................33711.2 Abkürzungsverzeichnis.......................................................................34511.3 Abbildungsverzeichnis ........................................................................34711.4 Glossar....................................................................................................35111.5 Sachwortverzeichnis ............................................................................369

1

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.

Ein halbes Jahrhundert später mag sich einiges im gesellschaftlichen Leben geändert haben. Für ein modernes und erfolgreiches IT-Management ge-hö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-Kenn-zahlen vorgeschlagen und eingesetzt worden. ITIL als Best Practice-Ansatz unterstützt explizit die Steuerung der IT-Pro-zesse 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 Kenn-zahlen 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 Kenn-zahlen 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 sinn-voll. Sie müssen erhoben werden! Aber wie kann man sie in dieser Komplexität managen und beherrschbar machen?

ITIL und Kennzahlen: You can’t have one without the other.

ITIL V3 enthält Prozess-Kennzahlen.


2

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 IT-Kennzahlensystem entwickeln und einführen, so sollte man im Vorfeld die richtigen Fragen stellen:

– Welche Ziele verfolgen wir mit dem Kennzahlensystem? – Welche Kennzahlensysteme sind für meine IT relevant? – Wen adressiert das Kennzahlensystem? – Welche Kennzahlen können (nicht) gemessen werden? – Welchen Aufwand darf das Kennzahlensystem verursachen?

Die Beantwortung dieser oder ähnlicher Fragen führt zu einem top down-Ansatz für IT-Kennzahlensysteme, den wir oft in Praxisprojekten einge-setzt haben. Aber dies ist nur die eine Seite der Medaille: Für die reale Einführung eines IT-Kennzahlensystems ist es enorm wichtig, die IT-Organisation dort abzuholen, wo sie steht. Hier bietet sich ein bottom up-Verfahren an, durch das ermittelt wird, welche Kennzahlen bereits in ver-schiedenen Bereichen erhoben und genutzt werden.

In unserem Buch beschreiben wir diesen Ansatz in einem Praxisleitfaden, der beide Aspekte enthält.

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. 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ät-zen, 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“. Auffal-lend dabei ist, dass der Überdeckungsgrad der Kennzahlensysteme eher gering ist: Jedes Kennzahlensystem liefert neue Aspekte! 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! Im Wesentlichen hängt diese Tatsache davon ab, dass ein Kennzahlensys-tem sich in der Praxis aus dem Zielsystem der IT ableiten muss und daher strategische und taktische Dimensionen hat.

top down-Verfahren zur Entwicklung von IT-Kennzahlen-systemen.

bottum up-Verfahren zur Erhebung von Kennzahlen.

IT-Kennzahlen-systeme sind Guidelines.


3

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-Pro-zesse 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 Balan-ced Scorecard eine tragende Rolle.

Wir glauben, dass das IT Service Management einen der wichtigsten Mei-lensteine für die IT darstellt. Wir glauben auch, dass IT Service Manage-ment ohne IT-Kennzahlen, und IT-Kennzahlen ohne IT Service Manage-ment 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 bereitge-stellt werden, so wie mit den Kernideen des ITIL-basierten Prozess-Managements.

Die in ITIL V3 verfügbaren IT-Kennzahlen werden in entsprechende Zusammen-hänge eingeordnet und nach ihrem Einsatz in der Praxis klassifiziert.

Unser Buch füllt damit in den ersten 5 Kapiteln eine „Toolbox“, die IT-Verantwortliche 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 bestehen-den 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, per-sönliche Schicksale, Präferenzen, Einstellungen, Interessen, Flexibilität und

1 Kaplan und Norton haben dies als „Translating Strategy into Action“ bezeich-

net (vgl. [Kaplan et al., 1996]).

Michael Hammer: „The Balanced Scorecard – A Landmark Achievement“


4

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.

Unser Buch beschäftigt sich mit diesem sensiblen und interessanten The-ma im 6. Kapitel, das wir mit „Lessons learned“ überschrieben haben. Basierend auf unseren Projekterfahrungen stellen wir ein Vorgehensmo-dell vor, mit dem die notwendigen Veränderungs- und Überleitungspro-zesse – 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-Kenn-zahlen setzen wir ein?

– Kapitel 5: Praxisleitfaden zur Entwicklung von IT-Kennzahlensyste-men mit Klassifikationsschemata und Prozess-Kennzahlen aus ITIL V3 und unseren Projekterfahrungen.

– Kapitel 6: Wie geht man am besten in IT Service Management-Projekten vor? Empfehlungen aus unseren Projekten für Transition und Change-Prozesse.

Praxisbeispiele: – Kapitel 7: IT Service Management im regulierten Umfeld am Bei-

spiel der ALTANA Pharma AG – Kapitel 8: Autobahn Tank & Rast GmbH mit einem Kennzahlensys-

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

Change und Verände-rungs-Prozes-se sind we-sentliche Bestandteile des Vorge-hensmodells.

5

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 Management-Prozesse 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 Kennzah-lensystemen 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 Kenn-zahlensystems 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 Prozess- und IT-Management das Kennzahlensystem als Führungsinstrument ver-steht und aktiv einsetzt.

2.2 ITIL und ISO 20000 ITIL und ISO 20000 „IT Service Management“ sind zwei international be-währte Practices zur erfolgreichen Etablierung eines IT Service Manage-ments. Die Zielsetzung eines IT Service Managements besteht in der Be-reitstellung von IT-Leistungen (IT Services) zur Unterstützung der Ge-schäftsprozesse. Hierzu sind die notwendigen Leistungen zu planen, be-reitzustellen, zu überprüfen und bei Bedarf zu optimieren.


6

Um die Ziele des IT Service Managements zu erreichen, haben sich in den letzten Jahren IT-Prozesse etabliert, die ein wirksames Management si-cherstellen und grundsätzlich in allen IT-Organisationen etabliert werden können. Diese IT Service Management-Prozesse sind in den ITIL Best Prac-tices sowie der ISO 20000 dokumentiert. Der Ansatz von ITIL Version 2 bestand in der Bereitstellung von Best Prac-tices zur Gestaltung, Implementierung, Betrieb und Optimierung der not-wendigen IT Service Management-Prozesse. Mit der Veröffentlichung der ITIL Version 3 wurden die Ausrichtung und der Inhalt umfangreich erwei-tert. 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 Vorgehens-weisen 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 Mindestanforderun-gen an ein IT Service Management definiert, liefert ITIL hierzu Best Practi-ces für den Aufbau des organisationsspezifischen IT Service Managements. Die Prozessorientierung von ITIL und der ISO 20000 stellt eine weitgehen-de 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 Kennt-nisse der Prozessziele und der damit verbundenen Prozessaktivitäten be-steht 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. Hier-zu 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 verant-wortlich zu machen. Die Kennzahl „Anzahl von Störungen“ wird zwar in

2.3 Die Struktur gemäß ITIL Version 2

7

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 Management-Prozesse 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 Manage-ment-Prozesse dokumentiert. ITIL ist ein De-facto-Standard für das IT Service Management, da die meis-ten 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 ab-gelöst wurde.


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 „Op-timiertes IT Management mit ITIL“ [Victor et al., 2005] werden die wesent-lichen Aspekte von ITIL 2 und ein Einführungsleitfaden beschrieben.


8

Planning to Implement Service Management

Service Delivery

Service Support

Application Management

SecurityManagement

Service Management

TheBusiness

Perspective

ICTInfra-

structureManage-

ment

The

Business

The

Technologie

Planning to Implement Service Management

Service Delivery

Service Support


SecurityManagement

Service Management

TheBusiness

Perspective

ICTInfra-

structureManage-

ment

The

Business

The

Technologie

Abbildung 1: 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 abge-leitet werden und kann Input für einen anderen Prozess darstellen. So nimmt zum Beispiel der Prozess des Capacity Managements in enger Zu-sammenarbeit mit dem Service Level Management (SLM) die Kundenanfor-derungen 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-


9

keit. Jeder IT Service Management-Prozess hat eine charakteristische Ziel-richtung und trägt im Zusammenwirken mit den anderen IT Service Ma-nagement-Prozessen dazu bei, dass dem Kunden die notwendigen IT Ser-vices zur wirkungsvollen Unterstützung seiner Geschäftsprozesse geliefert werden.

Die ITIL Best Practices beinhalten Prozessbeschreibungen mit wechselseitigen Aktivitäten.

ServiceSupport

ServiceDelivery

Incident Management

Configuration Management

ReleaseManagement

ChangeManagement

ProblemManagement

Availability Management

Service Level Management

Capacity Management

Financial Management

Continuity Management

ServiceSupport

ServiceDelivery

Incident Management


ReleaseManagement

ChangeManagement

ProblemManagement



Capacity Management


Continuity Management

Abbildung 2: 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.”


10

Hierzu sind in einem generischen Prozessmodell die wichtigsten Aufga-ben beschrieben (siehe Abbildung 3, aus „Best Practice Einführung in ITIL“, [OGC, 2005a]).

Input Output

Prozessausführung

Aktivitäten undSubprozesse

Prozessmanagement

Qualitätsparameter und KPIs

Prozess-Owner

Ziele desProzesses

Prozessbedingungen

Ressourcen Rollen

Input Output

Prozessausführung

Aktivitäten undSubprozesse

Prozessmanagement

Qualitätsparameter und KPIs

Prozess-Owner

Ziele desProzesses

Prozessbedingungen

Ressourcen Rollen

Abbildung 3: Generisches ITIL-Prozessmodell

Auf Basis der vom Process Owner vorgegebenen Prozessziele gilt es, die notwendigen Aktivitäten und Subprozesse der jeweiligen IT Service Ma-nagement-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) organisati-onsneutralen Best Practices. Daher werden zur Durchführung von Pro-zessaktivitäten Rollen definiert, die mit den erforderlichen Ressourcen zu unterstützen sind. Die Leistungsindikatoren (KPIs) dienen auch zum Ma-nagement der eingesetzten Ressourcen.

Ohne Qualitätsparameter und Leistungsindikatoren (KPIs) ist ein wirksames Prozess-Management unmöglich.

Der Process Owner gibt die Prozess-ziele vor und kann anhand der KPIs die Erreichung der Ziele fest-stellen.


11

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 Manage-ment-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 Ma-nagement, 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 emp-fohlenen 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 Trans-lation 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 zentra-len Publikation „Service Strategy“ wird ein wichtiger Beitrag zur IT Go-

ITIL Kennzahlen sind lediglich Empfehlungen.


12

vernance geliefert. Im Rahmen der IT Governance soll sichergestellt wer-den, 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äfts-zielen 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 Kun-den ermöglicht werden, sondern es wird mit der ITIL V3 eine IT- / Busi-ness Integration angestrebt. In den meisten Organisationen ist inzwischen die Abwicklung eines Ge-schäftsprozesses ohne entsprechende IT-Unterstützung nicht mehr denk-bar. In einigen Fällen findet die Durchführung eines Geschäftsprozesses inzwischen nur durch elektronische Systeme und ohne manuelle Bearbei-tungsschritte 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 Erschei-nungsbild der gesamten Organisation nach außen zum Kunden. Gleichzei-tig 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 IT-Unterstützung zum elementaren Bestandteil des Geschäftserfolges. Diese Unterstützung eines Geschäftsprozesses wird in den ITIL Best Prac-tices 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 herausge-stellt. 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?“.


13

Damit verbunden ist auch die Erweiterung der Definition für den IT Ser-vice (aus „Service Strategy“, [OGC, 2007a]). Hier wird der allgemeine Be-griff 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 Informations-technologie 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 Technolo-

gien. – 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 Per-sonal 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äfts-prozesse 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 Res-sourcen und Fähigkeiten. ITIL V3 bezeichnet diese Ressourcen und Fähig-keiten als Service Assets, die im nachfolgenden Kapitel „Service Stra-tegy“ näher betrachtet werden. Mithilfe dieser Ressourcen und Fähigkei-ten wird dem Business der notwendige IT Service bereitgestellt, der in die Business Prozesse integriert ist. Teilweise ist, wie zum Beispiel für Web-Shops, 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.


14

Internet

Business Services(Produkte, Waren)

Business Prozesse

IT Services

Ressourcen und Fähigkeiten

Business Service

Business Service

ITService

ITService

ITService

ITService

Internet

Business Services(Produkte, Waren)

Business Prozesse

IT Services

Ressourcen und Fähigkeiten

Business Service

Business Service

ITService

ITService

ITService

ITService

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 Kompetenzproble-men 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-Organisa-tionen hat sich diese Rolle bereits etabliert, wenn auch zum Teil unter ei-


15

nem anderen Namen. Häufig wird diese Rolle als Service Manager be-zeichnet. Da innerhalb der ITIL Best Practice mit der Version 3 auch die Rolle des Service Managers beschrieben wird, gilt es, innerhalb der jewei-ligen IT-Organisation eindeutige Bezeichnungen und Rollendefinitionen zu finden. In der Vergangenheit führte die Bezeichnung „IT Infrastructure Lib-rary“ zu Missverständnissen. So wurde der Begriff „Infrastructure“ fälsch-licherweise 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 Kundenanforderun-gen 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 organisatori-schen 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 ei-

nem kontinuierlichen Verbesserungsprozess (Continual Service Im-provement).


16

Hierzu werden nicht nur Service Management-Prozesse beschrieben, son-dern 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 Ma-nagement.

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 Leis-tungen 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 Ser-vice 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 be-trieben und den Geschäftsprozessen zur Verfügung gestellt (Service Ope-ration). 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 Or-ganisationen sollen ermöglicht werden. Ziele sind: Struktur, Stabilität und Stärke auf der Basis dauerhafter Prinzipien, Methoden und Werkzeuge.


17

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.

ServiceTransition

ServiceDesign

ContinualService

Improvement

Service Strategy

ServiceOperation

ServiceTransition

ServiceDesign

ContinualService

Improvement

Service Strategy

ServiceOperation

ServiceTransition

ServiceDesign

ContinualService

Improvement

Service Strategy

ServiceOperation

Abbildung 5: Die 5 Phasen des Service Lifecycle nach ITIL V3.

Diese Phasen haben nicht nur spezielle Zielsetzungen und Aufgaben in-nerhalb des Service Lifecycle, sondern auch definierte Übergänge zwi-schen den einzelnen Phasen. Die folgende Abbildung 6 veranschaulicht die Hauptaktivitäten der ein-zelnen Phasen sowie ihre Übergänge bzw. Schnittstellen (vereinfachte Dar-stellung 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 Stel-le werden die Übergänge zwischen den einzelnen Phasen beschrieben.


18

Serv

ice

Stra

tegi

eSt

rate

gie

Gen

erie

rung

Def

initi

on d

es

Mar

ktes

Serv

ice

Leve

lPa

ckag

e

Dem

and

Man

agem

ent

Entw

ickl

ung

Ang

ebot

e

Serv

ice

Port

folio

Man

agem

ent

Serv

ice

Des

ign

Serv

ice

Port

folio

Man

agem

ent

Entw

ickl

ung

Ang

ebot

e

Serv

ice

Leve

lM

anag

emen

t

Ver

hand

eln/

Ver

einb

aren

Supp

lier

Man

agem

ent

Serv

ice

Des

ign

Pack

age

Serv

ice

Tran

istio

nC

hang

eM

anag

emen

t

Serv

ice

Ass

etC

onfig

urat

ion

Man

agem

ent

Rele

ase

&D

eplo

ymen

tM

anag

emen

t

Risi

ken

optim

iere

nV

erifi

zier

enEa

rly

Life

Supp

ort

Serv

ice

Ope

ratio

nEv

ent

Man

agem

ent

Mon

itori

ng&

Akt

ione

nIn

cide

ntM

anag

emen

tLö

sen

& W

iede

rher

stel

len

Requ

est

Fulfi

lmen

tSe

rvic

ePe

rfor

man

ceR

epor

ts

CSI

Serv

ice

Mea

sure

men

tD

efin

ition

Met

rike

nSe

rvic

eRe

port

ing

Ana

lyse

Impr

ovem

ent

Serv

ice

Stra

tegi

eSt

rate

gie

Gen

erie

rung

Def

initi

on d

es

Mar

ktes

Serv

ice

Leve

lPa

ckag

e

Dem

and

Man

agem

ent

Entw

ickl

ung

Ang

ebot

e

Serv

ice

Port

folio

Man

agem

ent

Serv

ice

Des

ign

Serv

ice

Port

folio

Man

agem

ent

Entw

ickl

ung

Ang

ebot

e

Serv

ice

Leve

lM

anag

emen

t

Ver

hand

eln/

Ver

einb

aren

Supp

lier

Man

agem

ent

Serv

ice

Des

ign

Pack

age

Serv

ice

Tran

istio

nC

hang

eM

anag

emen

t

Serv

ice

Ass

etC

onfig

urat

ion

Man

agem

ent

Rele

ase

&D

eplo

ymen

tM

anag

emen

t

Risi

ken

optim

iere

nV

erifi

zier

enEa

rly

Life

Supp

ort

Serv

ice

Ope

ratio

nEv

ent

Man

agem

ent

Mon

itori

ng&

Akt

ione

nIn

cide

ntM

anag

emen

tLö

sen

& W

iede

rher

stel

len

Requ

est

Fulfi

lmen

tSe

rvic

ePe

rfor

man

ceR

epor

ts

CSI

Serv

ice

Mea

sure

men

tD

efin

ition

Met

rike

nSe

rvic

eRe

port

ing

Ana

lyse

Impr

ovem

ent

A

bbild

ung

6:

Inte

grie

rter

Abl

auf d

er L

ifec

ycle

Ele

men

te


19

Eine der wichtigsten Aufgaben der Service Strategy ist die Definition des Serviceportfolios. Mittels des so genannten „Service Level Package“ wer-den IT Services beschrieben, die den Kunden zur Verfügung gestellt wer-den und innerhalb von Service Design zu entwickeln sind. Die in Service Design entwickelten IT Services werden mittels so genannter „Service De-sign 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 ITIL-Publikation die Best Practice und gibt so einen Leitfaden zur Ausgestal-tung dieser Phase. Dabei sind nicht nur die relevanten IT Service Manage-ment-Prozesse beschrieben, sondern unter anderem auch die phasenbezo-genen 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 rele-vanten 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 Servi-ce Level Management werden die wesentlichen Aspekte innerhalb von Service Design beschrieben. Ergänzungen hierzu finden sich noch im Con-tinual Service Improvement. Im Fall des Incidents Managements (Störungs-Management) ist die Zuord-nung 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 beschrei-ben und anzuwenden sind. Als Beispiel für die phasenübergreifende An-wendung von Prozessen dient der Prozess des Change Managements. Dieser Prozess ist für die Steuerung des Lebenszyklus aller Changes ver-antwortlich. Wichtigstes Ziel des Change Managements ist es, die Durch-führung von lohnenden Changes bei einer minimalen Unterbrechung der


20

IT Services zu ermöglichen. Da damit die gesicherte Überführung von Changes in die Betriebsumgebung verbunden ist, findet sich dieser Pro-zess 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 Dienstlei-stungen anbieten.

– Die ITIL Complementary Guidance als ergänzender Leitfaden für in-dustrielle Bereiche, Organisationstypen, Betriebsmodelle und tech-nologische Architekturen.

– Die ITIL Web Support Services mit Zusatzprodukten, Prozessmodel-len, Templates und Studien.

Ergänzt werden diese offiziellen Publikationen der OGC um eine allge-meine 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 Stra-tegy (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 viel-mehr 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 Verbesserungs-kreislaufs des Continual Service Improvement.


21

IT Financial Management

Service PortfolioManagement

Demand Management

StrategieGenerierung

ServiceMeasurement

ServiceReporting

Service Catalogue ManagementService Level ManagementAvailability Management

Capacity ManagementIT Service Continuity Management

IT Security ManagementSupplier Management

Change ManagementTransition Planning

Service Asset and Configuration Management

Knowledge Management

Release and Deployment ManagementService Validation and Testing

Evaluation

Event ManagementIncident Management

Request FulfilmentProblem ManagementAccess Management

Common ServiceOperation Activities

ServiceStrategy

Continual ServiceImprovement

ServiceDesign

ServiceTransition

ServiceOperation

Service Lifecycle –Governance Prozesse Operational Service Lifecycle Prozessezb

ServiceImprovement

IT Financial Management

Service PortfolioManagement

Demand Management


ServiceMeasurement

ServiceReporting

Service Catalogue ManagementService Level ManagementAvailability Management

Capacity ManagementIT Service Continuity Management

IT Security ManagementSupplier Management

Change ManagementTransition Planning

Service Asset and Configuration Management


Release and Deployment ManagementService Validation and Testing

Evaluation

Event ManagementIncident Management

Request FulfilmentProblem ManagementAccess Management

Common ServiceOperation Activities

ServiceStrategy

Continual ServiceImprovement

ServiceDesign

ServiceTransition

ServiceOperation

Service Lifecycle –Governance Prozesse Operational Service Lifecycle Prozessezb

ServiceImprovement

Abbildung 7: Service Lifecycle und Prozesse

Ausgangspunkt der Phase Service Strategy sind die Identifizierung, Aus-wahl und Priorisierung von Geschäftschancen und Marktplätzen. Betrach-tungen und Analysen der Marktentwicklung und die Definition von Zie-len 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 anbie-ten, sondern auch für interne IT-Bereiche. Hierzu gilt es, auch die Frage zu


22

beantworten: „Wie können wir uns von der Konkurrenz bzw. externen Dienstleistern abheben?“. Innerhalb der Service Strategy gilt es, auf Basis dieser Fragestellung geeig-nete 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 kon-zipieren. Mit Unterstützung des IT Financial Managements werden ein Serviceport-folio 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 Lifecyc-le“ nun wie folgt detailliert werden (Auszug aus der Darstellung in „The Official Introduction to Service Lifecycle“ ([OGC, 2007e]):

ServiceStrategie


Definition des Marktes

DemandManagement

EntwicklungAngebote

ServicePortfolio

Management

Kostenmodelle Return on InvestmentGelegenheiten und Grenzen Return on Value

IT Financial ManagementServiceLevel

Package

Service Design

ServiceStrategie


Definition des Marktes

DemandManagement

EntwicklungAngebote

ServicePortfolio

Management

Kostenmodelle Return on InvestmentGelegenheiten und Grenzen Return on Value

IT Financial ManagementServiceLevel

Package

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 Service-katalog lediglich die IT Services, die sich in der Nutzung bzw. im Über-gang in die Betriebsumgebung befinden.


23

Innerhalb von Service Strategy gilt es, nicht nur zu entscheiden, welche IT Services zu liefern und zu entwickeln sind, sondern auch, welche IT Servi-ces 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 freige-setzten 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 Serviceport-folios, 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 Bereitstel-lung 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:


24

Service Status:¬ Requirements¬ Defined¬ Analyzed¬ Approved

¬ Chartered¬ Designed¬ Developed¬ Built¬ Test¬ Released¬ Operational¬ Retired

Service-pipeline

Service-katalog

Außerkraft-gesetzte Services

Serv

icep

ortfo

lio

Serv

ice

Life

cycl

e

Service Status:¬ Requirements¬ Defined¬ Analyzed¬ Approved

¬ Chartered¬ Designed¬ Developed¬ Built¬ Test¬ Released¬ Operational¬ Retired

Service-pipeline

Service-katalog

Außerkraft-gesetzte Services

Serv

icep

ortfo

lio

Serv

ice

Life

cycl

e

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 Risikobe-trachtungen im Hinblick auf das Serviceportfolio werden angegangen. Neben dem Faktor operationelle Effizienz geht es entscheidend um ganz-heitliche, nachhaltige und effektvolle Entscheidungen und Leistungen und deren Entwicklung. Strategische Reviews helfen, Fähigkeiten zu verbes-sern, und tragen zum weiteren Ausbau von Geschäftsstrategien und -chancen bei. Das Fazit in einem kurzen Satz wäre wohl, die Service Strategy folgender-maß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 Kun-den 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 Manage-ment liefert hierfür ein Modell mit den entsprechenden Metriken (vgl. Abbildung 10).


25

Andere Elemente

IT-Infrastruktur

Geld

Personen

IT Service

Configuration Items Anwendungen

Prozesse

Organisation

IT Service

Fähigkeiten und Ressourcen

IT Service Provider

Geschäftsprozess

Integration in Geschäftsprozessermöglicht Wertbeitrag

Nutzt den IT ServiceNimmt Leistungen in Anspruch

Andere Elemente

IT-Infrastruktur

Geld

Personen

IT Service

Configuration Items Anwendungen

Prozesse

Organisation

IT Service

Fähigkeiten und Ressourcen

IT Service Provider

Geschäftsprozess

Integration in Geschäftsprozessermöglicht Wertbeitrag

Nutzt den IT ServiceNimmt Leistungen in Anspruch

Abbildung 10: Verbindung zwischen IT Service und Business-Service

Business Service Management:

„Ein Ansatz zur Verwaltung von IT Services, bei dem die unterstützten Business-Prozesse 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 Ge-schäftsprozesse des Kunden hat zu den bereits vorgestellten neuen Defini-tionen des Begriffs „Service“ bzw. „IT Service“ geführt. In diesen Definiti-onen wird zum Ausdruck gebracht, dass der IT Service einen Mehrwert für den Kunden erbringt. Die Service Level Agreements (SLAs) stellen hierzu einen wichtigen Bei-trag dar; wobei sicherzustellen ist, dass diese SLAs einen IT Service aus Sicht des Geschäftsprozesses beschreiben und nicht die Bereitstellung ei-nes technischen Systems wie den Betrieb eines SAP-Systems im Rechen-zentrum. 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 Ge-schäftsbetrieb nicht ausreichend herausgestellt wird. Mit ITIL V3 soll der für den Kunden generierte Mehrwert betrachtet wer-den. Hierzu werden mit der „Warranty“ (Gewährleistung) und „Utility“ (Nutzen) zwei Dimensionen beschrieben.


26

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.

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

Utility

Warranty

W/F

Zwecke erfüllt?Unterstützt

Leistung?

Verschiebt Grenzen?

W/F

ODER

UND

Wertschaffend?

UNDW/F

Verfügbar?

Kontinuität?

Kapazität?

Sicherheit?Anf

orde

rung

en

erfü

llt ?

betriebsfähig?W/F = wahr / falsch

Zwec

kmäß

ig? Utility

Warranty

W/F

Zwecke erfüllt?Unterstützt

Leistung?

Verschiebt Grenzen?

W/F

ODER

UND

Wertschaffend?

UNDW/F

Verfügbar?

Kontinuität?

Kapazität?

Sicherheit?Anf

orde

rung

en

erfü

llt ?

betriebsfähig?W/F = wahr / falsch

Zwec

kmäß

ig?

Abbildung 11: Die Wertebetrachtung eines IT Service

Wurde das Service Management bisher als taktische oder operative Auf-gabe angesehen, so stellt das Service Management jetzt einen geschlosse-nen Regelkreis dar, wobei die Phase Service Strategy die Basis bildet (siehe Abbildung 12, aus „Service Strategy“, [OGC, 2007a]).


27

ServiceStrategy

ServiceTransition

ServiceDesign

ServiceOperation

ContinualService

Improvement

•Service Portfolio•Service Katalog

Service OperationAnforderungen

Service DesignAnforderungen

Service TransitionAnforderungen

Messungund

Bewertung

Messungund

BewertungStrategie Implementierung

ServiceStrategy

ServiceTransition

ServiceDesign

ServiceOperation

ContinualService

Improvement

•Service Portfolio•Service Katalog

Service OperationAnforderungen

Service DesignAnforderungen

Service TransitionAnforderungen

Messungund

Bewertung

Messungund

BewertungStrategie Implementierung

Abbildung 12: Service Strategy als Basis für den Service Lifecycle

2.4.3 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 Erfor-dernisse, Ressourcen und Fähigkeiten

– Das Design von Service Management Systemen und Tools, insbe-sondere des Serviceportfolios für das Management und die Steue-rung der IT Services während des gesamten Lebenszyklus

– Das Design der technologischen Architekturen und der Manage-mentsysteme, die erforderlich sind, um den IT Service bereitzu-stellen

– Das Design der Prozesse, die benötigt werden zum Design, Transi-tion, Operation und Improvement der IT Services


28

– Das Design der Messsysteme und Metriken der IT Services, der Ar-chitekturen, 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 defi-niert werden, so dass der gelieferte IT Service den Erwartungen der Kun-den 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 effek-tiven und effizienten Service-Lösung. Die sich ständig verändernden An-forderungen 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 Service-Lösungen mit existierenden Lösungen konsistent und kompatibel zu ge-stalten.

ServiceDesign

SupplierManagement

Verhandeln/Vereinbaren

ServiceLevel

ManagementDesign Lösung

Service-katalog

Management

ServiceLevel

Package

Service Transition

Service Strategy

Availability Capacity Security Continuity

Design ausgewogener Zuverlässigkeit Anforderungen ComplianceArchitektur

ServiceDesign

Package Messsysteme

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.


29

Die Aufgaben des Service Design und die Einbindung in den Service Life-cycle 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 Kundenanforderun-gen aufzunehmen und zu analysieren. Eine damit verbundene Aufgabe ist die Analyse der bestehenden Fähigkeiten innerhalb der eigenen Organisa-tion. 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ähig-keiten für den neuen bzw. zu ändernden IT Service Diskrepanzen, so sind geeignete Maßnahmen zu konzipieren. Dabei ist es nicht unbedingt erfor-derlich, die notwendigen Fähigkeiten innerhalb der eigenen IT-Organisati-on 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 beschrie-ben.

Serviceportfolio

• Beschreibung• Wertbeitrag• Geschäftspläne

(Business Cases)• Prioritäten• Risiken• Angebote und

Einheiten• Kosten und

Preisgestaltung

Servicekatalog(e)

• Services• Unterstützte Produkte• Richtlinien (Policies)• Bestellung und

erforderliche Prozesse• Unterstützte Liefer- und

Zahlungsbedingungen• Eingangspunkt und

Eskalationen• Preisgestaltung und

Verrechnung

Serviceportfolio

• Beschreibung• Wertbeitrag• Geschäftspläne

(Business Cases)• Prioritäten• Risiken• Angebote und

Einheiten• Kosten und

Preisgestaltung

Servicekatalog(e)

• Services• Unterstützte Produkte• Richtlinien (Policies)• Bestellung und

erforderliche Prozesse• Unterstützte Liefer- und

Zahlungsbedingungen• Eingangspunkt und

Eskalationen• Preisgestaltung und

Verrechnung

Abbildung 14: Vom Serviceportfolio zum Servicekatalog


30

Das Serviceportfolio ist eine zentrale Informationsquelle innerhalb des Ser-vice 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 Serviceportfo-lios ist der Servicekatalog mit den Informationen zu sämtlichen in der Nut-zung und der Überführung in die Betriebsumgebung befindlichen IT Ser-vices. 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 IT-Organisation 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 beispiels-weise die Bereitstellung von Finanzdienstleistungen für Kunden einer Bank oder die Lieferung von Waren an Kunden eines Einzelhandelsgeschäfts. Die erfolgrei-che 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 Busi-ness-Services so zu gestalten, dass sie die sich ändernden Anforderungen der Kunden und deren Geschäftsprozesse erfüllen. Hierzu sind die not-wendigen unterstützenden IT Services zu bestimmen und auszugestalten. Der Prozess des Servicekatalog Managements hat zum Ziel, dass ein Service-katalog erstellt und gepflegt wird, der diese Informationen über alle ope-rationellen 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äh-rend innerhalb der IT die damit verbundenen (internen) IT Services in Verbindung gebracht werden (aus [OGC, 2007b]):


31

BusinessProzess 1

BusinessProzess 2

BusinessProzess 3

Service A Service B Service C Service D Service E

Technischer Servicekatalog

Support Services

Hardware Software Applikationen Daten

Business Servicekatalog

BusinessProzess 1

BusinessProzess 2

BusinessProzess 3

Service A Service B Service C Service D Service E

Technischer Servicekatalog

Support Services

Hardware Software Applikationen Daten

Business Servicekatalog

Abbildung 15: Die Inhalte und Sichten des Servicekatalogs

Liegt das Service Design vor, so ist es die Aufgabe des Service Level Ma-nagements, die entsprechenden Service Level Agreements (SLA) mit dem Kunden zu verhandeln, zu vereinbaren und sicherzustellen, dass die ver-einbarten Service Level-Ziele eingehalten werden. Dazu zählt unter ande-rem die Sicherstellung der Zuverlässigkeits- und Compliance-Anforderun-gen. 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 Underpin-ning Contracts zu verhandeln und zu vereinbaren. Dies erfolgt in Zusam-menarbeit zwischen dem Service Level Management und Supplier Mana-gement. Sämtliche Prozesse des Service Design und deren Zielsetzung können dem Abschnitt „2.5.2.2 Service Design“ entnommen werden.


32

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

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 Pro-duktion zu übernehmen und die durch Kunden und Stakeholder spezifi-zierten 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 entneh-men (Darstellung aus „The Official Introduction to Service Lifecycle“ ([OGC, 2007f]):

ServiceTransition

ChangeManagement

Optimierung RiskienService Asset &ConfigurationManagement

VerifizierenRelease &

DeploymentManagement

ServiceDesign

Package

Service Operation

Service Design

Planung & Support Validierung & Testen Evaluierung Knowledge

Qualitätssicherung Service Abnahme Konformität Entscheidung FähigkeitenUtility und Warranty

EarlyLife

Support

ServiceTransition

ChangeManagement

Optimierung RiskienService Asset &ConfigurationManagement

VerifizierenRelease &

DeploymentManagement

ServiceDesign

Package

Service Operation

Service Design

Planung & Support Validierung & Testen Evaluierung Knowledge

Qualitätssicherung Service Abnahme Konformität Entscheidung FähigkeitenUtility und Warranty

EarlyLife

Support

Abbildung 16: Service Transition-Prozesse

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


33

von Service Transition können dem Abschnitt „2.5.2.3 Service Transiti-on“ entnommen werden. 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 wer-den. 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 Verant-wortung 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“ be-reitzustellen ist. Daher werden auch Informationen wie beispielsweise zu SLAs benötigt und als CIs hinterlegt. Aber auch Applikationen sind CIs.

Configuration Items sind mehr als Hard- und Software


34

Ä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 ent-hält darüber hinaus Informationen zu Incidents, Problemen, Known Errors, Changes und Releases und kann auch Daten zu Mitarbeitern, Suppliern, Stand-orten, Geschäftsbereichen, Kunden und Anwendern beinhalten. Das CMS um-fasst Hilfsmittel zum Sammeln, Speichern, Verwalten, Aktualisieren und Präsen-tieren 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 Configura-tion Management System:

ProjektDokumenta-

tion

Projekt Software

Definitive Multimedia

Library 1

Daten- und Informations-

Quellen und Tools

Strukturiert

DefinitiveMediaLibrary

Physikalische CMDBs

Plattform Configuration

Tools

Software Configuration Management

Discovery,

Asset Management

und

Audit Tools

Enterprise Applikationen

Access Management

Human Ressourcen

Supply ChainManagement

Customer RelationshipManagement

Definitive DocumentLibrary 1

CMDB1

CMDB2

wie Datenbank Netzwerk,

Mainframe, VerteilteDesktop

ProjektDokumenta-

tion

Projekt Software

Definitive Multimedia

Library 1

Daten- und Informations-

Quellen und Tools

Strukturiert

DefinitiveMediaLibrary

Physikalische CMDBs

Plattform Configuration

Tools

Software Configuration Management

Discovery,

Asset Management

und

Audit Tools

Enterprise Applikationen

Access Management

Human Ressourcen

Supply ChainManagement

Customer RelationshipManagement

Definitive DocumentLibrary 1

CMDB1

CMDB2

wie Datenbank Netzwerk,

Mainframe, VerteilteDesktop

Abbildung 17: Daten und Informationsquellen für ein CMS


35

Innerhalb des „Release und Deployment Managements“ werden die Re-leases in den IT-Betrieb übergeleitet. Hierbei ist sicherzustellen, dass das Release effektiv in einen Einsatzbereich bzw. eine Zielumgebung ausge-bracht (deployed) werden kann und die damit verbundenen Geschäftsan-forderungen 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 Configu-ration Management“ über alle Phasen des Service Lifecycle seine Anwen-dung findet. Denn diese Informationen können das Serviceportfolio inner-halb von Service Strategy betreffen, Informationen für das Service Design enthalten, die Auswirkungsanalyse von Changes innerhalb Service Transi-tion unterstützen, bei Service Operation einen „Known Error“ für das In-cident Management liefern und für die Phase Continual Service Improve-ment 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 Effizienzsteige-rung. 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


36

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

Configuration ManagementSystem (CMS)

Service KnowledgeManagement System

(SKMS)

Configuration ManagementDatabases (CMDBs)

Entscheidung

Configuration ManagementSystem (CMS)

Service KnowledgeManagement System

(SKMS)

Configuration ManagementDatabases (CMDBs)

Entscheidung

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 herausge-stellt. In einigen IT-Organisationen wird der Umfang des Change Manage-ments 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 Chan-ge Managements fallen. In ITIL V3 werden daher die Ebenen des „strategi-schen Change“, des „taktischen Change“ und des „operationellen Chan-ge“ 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 Entscheidungsin-stanzen eine große Bedeutung zu. Die folgende Abbildung 19 (aus OGC, 2007c) stellt ein mögliches Modell für die verschiedenen Ebenen dar:


37

Kommunikation, Entscheidungen und Aktionen

Kommunikation,Eskalationen für RFCs,

Risiken, Erteilung

BusinessExecutive Board

ITManagement Board

CABoder ECAB

Lokale Autorisierung

Beispiele für betroffeneConfiguration-Ebene

Hohe Kosten/RisikenChange –

erfordert Entscheidungvon Executive

Change wirkt sich aufmehrere Services

oder organisatorische Abteilungen aus

Change wirkt sich nur lokal oder

auf Service-Gruppe aus

Standard Change

ChangeAutorisierung

Kommunikation, Entscheidungen und Aktionen

Kommunikation,Eskalationen für RFCs,

Risiken, Erteilung

BusinessExecutive Board

ITManagement Board

CABoder ECAB

Lokale Autorisierung

Beispiele für betroffeneConfiguration-Ebene

Hohe Kosten/RisikenChange –

erfordert Entscheidungvon Executive

Change wirkt sich aufmehrere Services

oder organisatorische Abteilungen aus

Change wirkt sich nur lokal oder

auf Service-Gruppe aus

Standard Change

ChangeAutorisierung

Abbildung 19: Autorisierungsebenen für Changes

Sobald die Changes bzw. das Release in den operativen Betrieb übergelei-tet sind, wird der neue oder geänderte IT Service innerhalb einer bestimm-ten 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 in-nerhalb von Service Strategy auf Basis der Kunden- und Marktanforderun-gen getroffen. Innerhalb von Service Design und Service Transition wer-den die IT Services entwickelt und in den Betrieb übergeleitet. Aber inner-halb 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

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


38

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

AnforderungenServiceStrategy

ServicePortfolio

ServiceKatalog

Business (Geschäftsanforderungen) / Kunden

ServiceDesign

ServiceTransition

ServiceOperation

ContinualService

Improvement

OperationelleServices

ImprovementPläne u. Aktionen

IT ServicesAnforderungenAnforderungenServiceStrategy

ServicePortfolio

ServiceKatalog

Business (Geschäftsanforderungen) / Kunden

ServiceDesign

ServiceTransition

ServiceOperation

ContinualService

Improvement



ImprovementPläne u. Aktionen

IT ServicesIT Services

Abbildung 20: Service Operation im Service Lifecycle

Auch in dieser Phase des Service Lifecycle steht nach wie vor im Vorder-grund, die IT Services am Bedarf des Business auszurichten. Hierzu müs-sen 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 Level-Ziele 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,


39

– 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 ange-messene Balance zu finden. Steht zum Beispiel die Stabilität zu sehr im Vordergrund, so werden die Änderungswünsche des Kunden nicht recht-zeitig 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 jewei-lige Betrachtung mögliche Risiken beschrieben und Best Practices beschrie-ben, 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.

ServicePerformance

Reports

ServiceOperation

RequestFulfilment

Lösen/Wiederherstellen IncidentManagement

Monitoring/Aktionen EventManagement

EarlyLife

Support

Continual Service Improvement

Service Transition

Operationeller Change Problem Technologie Access

Stabilität „Monitor Control Kreislauf FeedbackQualität zu KostenPerformanceQualität

ServicePerformance

Reports

ServiceOperation

RequestFulfilment

Lösen/Wiederherstellen IncidentManagement

Monitoring/Aktionen EventManagement

EarlyLife

Support


Service Transition

Operationeller Change Problem Technologie Access

Stabilität „Monitor Control Kreislauf FeedbackQualität zu KostenPerformanceQualität

Abbildung 21: Service Operation-Prozesse

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


40

die freie Kapazität eines Speicherbereichs einen Grenzwert erreicht. Da-durch kann in Service Operation schneller reagiert werden, und die Servi-cequalität wird verbessert. Können zu einzelnen Events automatisierte Aktionen hinterlegt werden, so trägt das Event Management zu einer Ver-ringerung 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 „nor-malen Service-Betriebs“ ist gegenüber der Version 2 unverändert geblie-ben. 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 Ei-genschaft“ in ein Problem. An Service Operation werden von den Anwendern aber nicht nur Inci-dents herangetragen, sondern auch so genannte Service Requests.

Service Request

Eine Anfrage eines Anwenders nach Informationen, Beratung, einem Standard-Change oder nach Zugriff auf einen IT Service. Dabei könnte es sich beispiels-weise um das Zurücksetzen eines Passworts oder die Bereitstellung standard-mäßiger IT Services für einen neuen Anwender handeln. Service Requests wer-den 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-Organisatio-nen existiert dieser Prozess bereits und wird zum Teil als Anforderungs-Management bezeichnet. Während das Incident Management den IT Service schnellstmöglich wie-derherstellen soll, hat das Problem Management die zugrunde liegende Ursache zu identifizieren und „Bekannte Fehler“ (Known Error) zu doku-mentieren, so dass das Incident Management auf dieses Wissen zurück-greifen 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.


41

Die folgende Abbildung 22 zeigt den Zusammenhang zwischen Event, Incident und Problem Management sowie dem Request Fulfilment (aus [KESS, 2007c]):

Event

IncidentService Request

Work-around

Known Error

Record

Known Error

Datenbank

Event Management

Request Fulfilment

Problem Management

Incident Management Change

Record

Event

IncidentService Request

Work-around

Known Error

Record

Known Error

Datenbank

Event Management

Request Fulfilment

Problem Management

Incident Management Change

Record

Abbildung 22: 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; insbe-sondere im Rahmen der stetig steigenden Compliance Anforderungen eine sehr wichtige Aufgabenstellung innerhalb von Service Operation. Neben diesen innerhalb von Service Operation etablierten Prozessen wer-den 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 Organi-sationseinheiten so genannte „Funktionen“, innerhalb derer bestimmte Aktivitäten durchzuführen sind. Die folgende Abbildung 23 stellt diese Funktionen dar (aus [OGC, 2007d]):


42

Service Desk

IT Operations ManagementTechnical

Management

Operations Control


Facility Management

Service Desk

IT Operations ManagementTechnical

Management

Operations Control


Facility Management

Abbildung 23: Service Operation-Funktionen

Der Service Desk ist der Single Point of Contact (SPOC) für die Kommunika-tion zwischen Service Provider und Anwendern. Ein Service Desk bearbei-tet in der Regel Incidents und Service Requests und ist für die Kommuni-kation 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 IT-Infrastruktur. Das „IT Operations Management“ führt die täglichen Akti-vitä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 wie-derholbare Prozessaktivitäten anzustreben, um Service-Qualität zu de-monstrieren, sondern geht darüber hinaus und fordert als Teil der ange-strebten Service-Qualität einen Prozess permanenten Strebens nach Ver-besserungen. Primärer Zweck des Continual Service Improvement (CSI) (vgl. [OGC, 2007e]) ist die kontinuierliche Anpassung der IT Services an die sich stän-dig 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 „Busi-ness Value“ für den Kunden im Hinblick auf Design, Überleitung (Transi-


43

tion) und Betrieb (Operation) der IT Services. Aber auch die Service Stra-tegy 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 Improve-ment“, [OGC, 2007e] (siehe Abbildung 24).

ServiceTransition

ServiceDesign

Service Strategy

ServiceOperation

ContinualService

Improvement

MessungBewertung/Feedback



ServiceTransition

ServiceDesign

Service Strategy

ServiceOperation

ContinualService

Improvement




Abbildung 24: Continual Service Improvement

Sharon Taylor, Chief Architect des Refresh Programms zur ITIL V3, ver-glich 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 Beharrungszu-stand 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 Er-folgsfaktoren sorgfältig zu definieren. ITIL führt zu Messung und Management aus:


44

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 defi-nierte 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 Ver-besserungsbedarf besteht. Die grundsätzliche Aufgabenstellung des Continual Service Improvement ist der folgenden Abbildung 25 zu entnehmen (Darstellung aus „The Offi-cial Introduction to Service Lifecycle“ ([OGC, 2007f]):

ContinualService

Improve-ment Service

MessungDefinition Metriken Service

ReportingAnalyse Verbessern

ServicePerformance

Reports

Service Operation

7 Step Improvement

Baseline & Metriken Daten-Analyse Korrektive Aktionen

ServiceImprovement

Plan

ContinualService

Improve-ment Service

MessungDefinition Metriken Service

ReportingAnalyse Verbessern

ServicePerformance

Reports

Service Operation

7 Step Improvement

Baseline & Metriken Daten-Analyse Korrektive Aktionen

ServiceImprovement

Plan

Abbildung 25: Service Transition-Prozesse

Das wesentliche Element von Continual Service Improvement ist die Mes-sung 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. Anderer-seits kann eine Übererfüllung vermieden und so die Effizienz sicherge-stellt werden. Darüber hinaus können Messungen auch den Erfolg durch-gefü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 herauszu-stellen und den Erfolg einer durchgeführten Verbesserung zu bestätigen, besteht in der Etablierung einer definierten Ausgangsbasis (Baseline).


45

Baseline:

Ein Benchmark, der als Referenzpunkt verwendet wird. Beispiel: Mit einer ITSM-Baseline als Ausgangspunkt können die Folgen eines Servicever-besserungsplans gemessen werden. Mit einer Performance Baseline können Änderungen in der Performance wäh-rend 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 Ab-schnitt „2.5.2.5 Continual Service Improvement“). Dieser Prozess hat zum Ziel, über Daten zu gesicherten Informationen zu gelangen. Durch Analy-se dieser Informationen sind anschließend geeignete Verbesserungsmaß-nahmen zu implementieren. Im Rahmen dieses „7-Step Improvement-Pro-zesses“ werden sowohl strategische, als auch taktische und auch operative Ziele verfolgt und beleuchtet, die innerhalb von Service Strategy und Ser-vice Design definiert wurden. Die identifizierten Verbesserungsmaßnahmen werden in dem Service Im-provement-Plan (SIP) dokumentiert; einem Dokument, das ebenfalls in Qualitätsmanagementsystemen wie der ISO 9001 und der ISO 20000 gefor-dert 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 Betrach-tungsbereichen. Eine Messung der IT-Systeme hinsichtlich der Verfügbarkeit und Perfor-mance ist für jeden Service Provider selbstverständlich. ITIL spricht hier von technologischen Messungen. Auch die Messung der IT Service Mana-gement-Prozesse findet zunehmend Anwendung, die so genannten Pro-zess-Messungen. Aber hierbei handelt es sich in der Regel um eine IT-interne 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 Komponen-ten wie Server oder Datenbanken nicht mehr ausreichend. Der IT Service ist als Ganzes zu betrachten und zu messen. Die folgenden drei Messun-gen finden hierbei in der Regel ihre Anwendung:


46

– Verfügbarkeit – Zuverlässigkeit – Performance

Der zweite Betrachtungsbereich in Richtung des Kunden und dessen Ge-schä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 Pro-zesse und deren Anforderungen. Demzufolge ist der Kunde bzw. sind die Geschäftsbereiche in den Entscheidungsprozess der umzusetzenden Ver-besserungsmaßnahmen unbedingt einzubeziehen. Letztendlich kann nur mit dem Kunden gemeinsam entschieden werden, welche Verbesserungs-maß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 Ge-schäfts entsprechen und von „Nicht IT-Mitarbeitern“ verstanden werden können.


47

Das Business

Businesssichten

Sammlung

Definition Reporting Policies und Rollen

Übersetzung und Anwendung

Publikation

Service Reporting

Das Business

Businesssichten

Sammlung

Definition Reporting Policies und Rollen

Übersetzung und Anwendung

Publikation

Service Reporting

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 wich-tige Schnittstelle besteht zum Service Design, denn dort sind die notwen-digen 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 Ser-vice 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 Opera-tion“ und „Continual Service Improvement“ insgesamt 26 IT Service Ma-nagement-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.


48

Diese umfangreiche Erweiterung mag den Leser vielleicht zunächst er-schrecken, 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 implemen-tiert 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 An-hang) vgl. „Service Design“, [OGC, 2007b] (siehe Abbildung 27).


49

Prozesssteuerung

Prozess-Owner

Prozessdurchführung

Prozess-Output

inklusiveProzess-Reports

und -Reviews

Trigger

Prozess-Dokumentation

Prozess-Ziele

Prozess-Feedback

Prozess-Input

Prozess-Aktivitäten

Prozess-Prozeduren

Prozess-Metriken

Prozess-Rollen

Prozess-ImprovementProzess-Arbeits

-anweisungen

Prozess-Ressourcen

Prozess-Befähigungen

Prozessbedingungen

Prozess-Policy

Prozesssteuerung

Prozess-Owner

Prozessdurchführung

Prozess-Output

inklusiveProzess-Reports

und -Reviews

Trigger

Prozess-Dokumentation

Prozess-Ziele

Prozess-Feedback

Prozess-Input

Prozess-Aktivitäten

Prozess-Prozeduren

Prozess-Metriken

Prozess-Rollen

Prozess-ImprovementProzess-Arbeits

-anweisungen

Prozess-Ressourcen

Prozess-Befähigungen

Prozessbedingungen

Prozess-Policy

Abbildung 27: ITIL Version 3 Prozessmodell

Die Betrachtungsbereiche „Prozesssteuerung“ (Process Control), „Pro-zessdurchführung“ (Process) und „Prozessbedingungen“ (Process Enab-lers) 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 inner-halb 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 entwi-ckeln und als Messpunkte in den Prozess zu integrieren. Mithilfe der imp-lementierten Messpunkte werden Kennzahlen generiert, die in Prozess-Reports einfließen und eine Steuerung des Prozesses sicherstellen.


50

ITIL Version 3 sieht in den Prozessen entsprechende Metriken vor, die als Pro-zesskennzahlen ein Feedback zur Prozessdurchführung liefern.

Der Output eines Prozesses muss den betrieblichen Anforderungen ent-sprechen, die aus den Geschäftszielen abgeleitet sind. Werden diese An-forderungen 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 Management-Reports darzustellen und bieten die Basis für gegebenenfalls notwendige Verbesserungsmaßnahmen.

Die mit der ITIL Version 3 beabsichtigte Business-Integration findet sich aus-drü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 meh-rerer 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 Im deutschen Glossar wird die Rolle als „Process Owner“ definiert und nicht

als „Prozess Owner“

Effektivität und Effizienz eines Prozesses


51

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 Aufbauorgani-sation 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ähigkei-ten und Ressourcen (Service Assets) und bringen Struktur und Stabilität in die IT-Organisation. In der Regel wurden Funktionen technologisch defi-niert, 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ög-licht, werden die IT Services den Bezug zum Kunden sicherstellen.

Process Owner und Prozess-Manager


52

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 be-reits IT Service Management-Prozesse implementiert haben, nutzen hierzu die Version 2. Eine Aktualisierung dieser implementierten Prozesse wird kontinuierlich erfolgen, aber nicht kurzfristig umzusetzen sein. Unterneh-men, die vor der Implementierung stehen, werden dahingehend wahr-scheinlich die Version 3 als Basis für das IT Service Management heranzie-hen. 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. Inner-halb des Kapitels 5 „Entwicklung von IT-Kennzahlensystemen“ geben wir Kennzahlen an, die sich in der Praxis bewährt haben, und gehen insbeson-dere darauf ein, wie diese Kennzahlen in ein übergeordnetes Kennzahlen-system zu integrieren sind. Aufgrund des generischen Ansatzes werden in ITIL mögliche Leistungs-indikatoren und Metriken aufgezeigt. Die konkrete Ausgestaltung der Metrik mit detaillierter Spezifikation und Bedeutung für das Prozess-Management ist Aufgabe des Prozessdesigns. In ITIL und COBIT sind viele Kennzahlen dokumentiert. Wir beschränken uns hier aber auf die, die im Rahmen unserer Projekterfahrung eine wich-tige 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äftsbe-triebs. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leis-tungsindikatoren sind:

– Anzahl der aufgetretenen Störungen – Durchschnittliche Zeitdauer bis zur Behebung oder Umgehung der

Störung in Relation zur Priorität

In ITIL und COBIT sind viele Kenn-zahlen doku-mentiert

2.5 ITIL Kennzahlen für IT Service Management-Prozesse

53

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

Support) behoben werden konnten Bei der Auswertung entsprechender Leistungsindikatoren ist zu beachten, dass ITIL „Incident“ als Oberbegriff für Störungen und Service-Requests nutzt. Im Incident Management-Prozess werden daher auch Service-Re-quests erfasst und bearbeitet. Für die Aussagekraft der obigen Kennzahlen müssen daher im Rahmen der Kennzahlenermittlung Störungen und Ser-vice-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 durchge-führt. Zu den reaktiven Aufgaben zählen die Aktivitäten von der Identifi-zierung von Problemen bis zu einer möglichen Umsetzung über das Chan-ge Management. Die proaktiven Aktivitäten sollen dagegen sicherstellen, Störungen zu verhindern, bevor sie auftreten. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leis-tungsindikatoren 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 entspre-chenden Problems bis zur Identifizierung des Bekannten Fehlers

– Anzahl und Auswirkung von Störungen, bevor das zugrunde lie-gende Problem gelöst ist

– Häufigkeit der Probleme unterteilt nach Status, IT Service, Auswir-kung, 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 Ver-waltung korrekter Konfigurationsinformationen.


54

Die seitens der ITIL Best Practices dokumentierten wesentlichen Leis-tungsindikatoren 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 Ma-nagement 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 stan-dardisierte Methoden und Verfahren durchzuführende Änderungen effi-zient 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 Leis-tungsindikatoren sind:

– Anzahl durchgeführter Änderungen, als Summe und gegliedert in IT Service, CI-Typ usw.

– Anteil zurückgewiesener RfCs – Anteil erfolgreicher Änderungen – Anteil termingerechter Änderungen – Anteil Backouts (Fallback; zurückgesetzte Änderungen) – Anteil Änderungen innerhalb des geplanten Budgets

Release Management Das Release Management hat die Bereitstellung, Verteilung und Verfolgung eines oder mehrerer Changes in einem Release in der Produktionsumge-bung zum Ziel und soll durch die Anwendung formeller Verfahren und Prüfungen die Produktionsumgebung schützen. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leis-tungsindikatoren sind:


55

– 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 Zyk-lus von Definition, Verhandlung, Vereinbarung, Messung, Berichterstat-tung und Reviews der IT Services. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leis-tungsindikatoren 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 Leis-tungsindikatoren sind:

– Die Budgetpläne werden termingerecht erstellt – Die monatlichen, vierteljährlichen und jährlichen finanziellen Ge-

schä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 IT-Kapazitä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 Leis-tungsindikatoren sind:

– Anteil von Störungen durch nicht ausreichende Kapazitäten – Anteil von SLA-Verletzungen aufgrund mangelnder Performance


56

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

Plans

Availability Management Zielsetzung des Availability Managements ist die Gewährleistung der Ser-vice-Verfügbarkeit, um die Verpflichtungen gegenüber dem Business er-füllen zu können. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leis-tungsindikatoren 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 ei-nerseits die Erfüllung der Sicheranforderungen aus den SLAs und anderer externer Anforderungen. Andererseits ist ein definierter Grundschutz zu schaffen. Die Publikation „ITIL Best Practice für Security-Management“ spezifiziert für diesen Prozess keine Leistungsindikatoren (vgl. [OGC, 2006a]). Die ITIL Best Practices zum Security-Management verfolgen das Konzept, dass die Sicherheitsanforderungen, bestehend aus Verfügbarkeit, Vertrau-lichkeit 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).


57

Die Leistungsindikatoren des Security-Managements entsprechen demzu-folge 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 Leistungsindi-katoren 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 Pro-zesse der ITIL Version 2 teilweise hinsichtlich der Ziele und Aufgabenstel-lung 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 „Ser-vice Katalog Management“, „Service Level Management“, „Supplier Ma-nagement“ und „Service Reporting“ wieder. Diese durchgeführten Anpassungen gegenüber der ITIL Version 2 haben auch Auswirkungen auf die damit verbundenen Kennzahlen und Metri-ken, deren Definition und deren Vergleichbarkeit. Im Folgenden werden die 5 Phasen des Service Lifecycle mit ihren Prozes-sen vorgestellt und die seitens der ITIL Best Practices dokumentierten Key Performance-Indikatoren beispielhaft beschrieben.


58

Service Strategy


Service Portfolio

M. Demand

M.

Service Catalogue M.

Service Level M.

Capacity M.

Availability M.

Service Continuity M.

InformationSecurity M.

Supplier M.

Transition Planningand Support

Change Management

Service Assetand Configuration M.

Release andDeployment M.

Service Validationand Testing

Evaluation

EventManagement

Problem M.

Request Fulfilment

Access Management

Service Desk

KnowledgeMgmt.

IncidentManagement

Return on Investment

(ROI) for CSI

The 7 Step Improvement

Process

Service Reporting

ServiceMeasurement

The BusinessQuestions

for CSI

ServiceLevel

Manage-ment

ServiceTransition

ServiceOperation

ServiceDesign

ContinualService

Improvement

Service Strategy


Service Portfolio

M. Demand

M.


Service Level M.

Capacity M.

Availability M.



Supplier M.


Change Management




Evaluation

EventManagement

Problem M.

Request Fulfilment

Access Management

Service Desk

KnowledgeMgmt.

IncidentManagement


(ROI) for CSI

The 7 Step Improvement

Process

Service Reporting

ServiceMeasurement

The BusinessQuestions

for CSI

ServiceLevel

Manage-ment

ServiceTransition

ServiceOperation

ServiceDesign

ContinualService

Improvement

Abbildung 28: Die 5 Phasen des Service Lifecycle und ihre Prozesse


59

2.5.2.1 Service Strategy

Service Strategy


Service Portfolio

M.

DemandM.

Service Strategy


Service Portfolio

M.

DemandM.

Abbildung 29: Service Strategy

Die Publikation „Service Strategy“ ([OGC, 2007a]) weicht von den übrigen vier Publikationen dahingehend ab, dass sie kein Kapitel „Prozesse“ ent-hält. Im Rahmen des Kapitels „Service Economics“ werden Aspekte be-schrieben, die einen Charakter von Prozessen haben. Als Prozesse sind dabei das „Financial Management“, das „Service Portfolio Manage-ment“ 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 Finanz-Terminologie. 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 Mehr-wert zu entscheiden. Hierzu ist für den jeweiligen IT Service der Business Case zu betrachten. Der Business Case beinhaltet Informationen zu Kos-ten, Nutzen, Optionen, offenen Punkten, Risiken und möglichen Proble-men. Es gibt einen Wandel in der Wahrnehmung der IT und ihres Wertes für das Business. Financial Management hilft bei der Identifizierung, Doku-mentation und Akzeptanz des Wertes des erhaltenen IT Service und er-möglicht die Modellierung und das Management von Service-Anforderun-gen.


60

Das Financial Management ist innerhalb von Service Strategy beschrieben, aber die finanziellen Aspekte sind grundsätzlich ein übergreifendes The-ma, in dem viele Bereiche eines Unternehmens interagieren wie zum Bei-spiel 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 wer-den, 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 Port-folio Management. Auf Basis der Informationen aus dem Financial Mana-gement 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). Ser-vice 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 (= Servicepipe-line) 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 Ge-schä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 auszu-richten. Aber auch nicht mehr bzw. zukünftig nicht mehr gefragte IT Ser-vices werden identifiziert und deren Außerkraftsetzung festgelegt. Damit verbunden werden Ressourcen freigesetzt, die für andere IT Services ge-nutzt werden können, und ansonsten notwendige Investitionen werden vermieden. Der Prozess besteht aus den Aktivitäten „Definition“, „Analyse“, „Frei-gabe“ und „Ausgestaltung“. Innerhalb der „Definition“ gilt es, die beste-henden IT Services und Anforderungen zu analysieren. Hierzu wird für


61

jeden IT Service der Business Case definiert. Bei der „Analyse“ wird der Inhalt der Servicestrategie festgelegt. Hierzu werden die langfristigen Zie-le festgelegt und ermittelt, welche IT Services hierzu notwendig sind. In Verbindung mit diesen IT Services sind die damit verbundenen Ressour-cen 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 Autorisie-rung 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 Life-cycle 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 Manage-ments: 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 Ser-vicenachfrage 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 Kapa-zitäten, neue IT Services oder zu ändernde IT Services rechtfertigen. Mit der Identifizierung der zukünftigen Aktivitäten innerhalb der Busi-ness-Prozesse liefert das Demand Management einen wichtigen Beitrag zur angemessenen Ausgestaltung der IT Services. Überkapazitäten wer-den vermieden und dadurch die Kosten für den jeweiligen IT Service re-duziert. Andererseits werden Unterkapazitäten vermieden, so dass die Business Prozesse nicht in Mitleidenschaft gezogen und planmäßig durch-geführt werden können.


62

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 Anwenderprofi-len einbeziehen. Auf taktischer Ebene kann es eine differenzierte Leistungsver-rechnung 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 Bereit-stellung der Kapazität Einfluss nehmen, um diesem Bedarf gerecht zu werden. Auf strategischer Ebene kann das Demand Management die Analyse von Busi-ness-Aktivitätsmustern und Anwenderprofilen einbeziehen. Auf taktischer Ebene kann es eine differenzierte Leistungsverrechnung einsetzen, um die Nut-zung von IT Services bei den Kunden zu Zeiten mit einer geringeren Auslastung zu fördern.

2.5.2.2 Service Design


Service Level M.

Capacity M.

Availability M.



ServiceDesign

Supplier M.


Service Level M.

Capacity M.

Availability M.



ServiceDesign

Supplier M.

Abbildung 30: Service Design


63

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, Bestel-lungen und Anfragen sowie Kontaktinformationen zu allen Live IT Servi-ces, 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 auf-gebaut 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 Ge-schä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“ ent-hält Details zu allen IT Services sowie die Beziehungen zu den unterstüt-zenden Services, CIs, etc., die notwendig sind, den IT Service für das Busi-ness 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 Performance-Indikatoren 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 Ser-vicekatalog und der „realen Welt“.

Service Level Management Der Service Level Management-Prozess definiert und vereinbart für alle aktu-ellen 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 Mes-sungen und Reports helfen bei den notwendigen Verbesserungen zur Zu-friedenheit der Kunden.


64

Das Service Level Management repräsentiert den IT Service Provider ge-genüber dem Business und das Business gegenüber dem IT Service Provi-der. 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 Partei-en ihre Leistungen besser planen können, werden intern Operational Level Agreements (OLAs) und extern Underpinning Contracts (UCs) abgeschlos-sen. 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 Pro-vider 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 soll-ten 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 Performance-Indikatoren sind zum Beispiel:

– prozentuale Verringerung nicht erfüllter SLA-Ziele – prozentuale Verringerung bedrohter SLA-Ziele – prozentualer Anstieg der Kunden-Wahrnehmung und -Zufrieden-

heit von SLA-Leistungen via Service Reviews und Kunden Zufrie-denheits-Befragungen

– prozentuale Verringerung von SLA-Verletzungen, die durch Unter-auftragnehmer verletzt wurden.


65

Capacity Management Das Capacity Management (Kapazitätsmanagement) stellt sicher, dass IT-Kapazitäten zu gerechtfertigten Kosten jederzeit in allen IT-Bereichen exis-tieren und rechtzeitig die abgestimmten aktuellen und zukünftigen An-forderungen des Business abdecken. Hierzu muss das Capacity Management hinsichtlich der „Kosten und Ka-pazitäten“ sowie „Angebot und Bedarf“ einen Balanceakt durchführen. Einerseits muss das Capacity Management sicherstellen, dass die Verarbei-tungskapazitäten zu vertretbaren Kosten dem Bedarf des Business nach-kommen 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 Anwen-dung:

Business Capacity Management (BCM):

Im Kontext von ITSM die verantwortliche Aktivität, um die zukünftigen Busi-ness-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. Ande-rerseits 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 wirt-schaftlich und zeitnah erreichen zu können. Beim Capacity Management werden


66

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.


– akkurate Business Vorhersagen (Vorhersagen über Arbeitsauslas-tungen in der Produktion; prozentuale Genauigkeit der Vorhersa-gen von Business Trends, etc.)

– Wissen über aktuelle und zukünftige Technologien (Fähigkeit, Per-formance und Durchsatz aller Services und Komponenten zu moni-toren; rechtzeitige Ausrichtung und Implementierung neuer Tech-nologien, 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 Perfor-mance-Probleme; Verringerung von Überkapazitäten der IT, etc.)

– Fähigkeit zur Planung und Implementierung der angemessenen IT-Kapazitäten zur Befriedigung der Business-Anforderungen (prozen-tuale Verringerung der Anzahl von Incidents, die durch schlechte Performance ausgelöst werden; prozentuale Verringerung verlore-ner 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äftspro-zess 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ücksich-tigt werden. Bei der Definition der Verfügbarkeit wird der Bezug auf die Geschäftspro-zesse 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, Wartbar-keit, Servicefähigkeit, Performance und Sicherheit bestimmt.


67

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 IT-Komponenten ermittelt, so sind geeignete Abhilfemaßnahmen zu entwi-ckeln. Innerhalb der proaktiven Aktivitäten besteht eine wichtige Aufgabe in der Durchführung eines Risiko Assessments und dem Management der Risi-ken. Betreibt zum Beispiel ein Unternehmen eine Web-Plattform zur Be-stellung von Artikeln und verfügt lediglich über eine Leitung zum Inter-net-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 (Busi-ness Impact Analysis, BIA) zu. Innerhalb der Business-Auswirkungsana-lyse 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 Verbesse-rung sämtlicher Aspekte in Bezug auf die Verfügbarkeit von IT Services verant-wortlich 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ög-lichen.


– prozentuale Verringerung in der Nichtverfügbarkeit von Services und Komponenten

– prozentualer Anstieg in der Verlässlichkeit von Services und Kom-ponenten


68

– 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 allumfas-senden Business Continuity Management (BCM)-Prozess. Es stellt sicher, dass die IT-technischen Betriebsmittel und Services (einschließlich Rech-nersysteme, Netzwerke, Anwendungen, Datenbestände, Telekommunika-tionsanlagen, technischer Support und Service Desk) nach einem Ausfall oder einer Störung innerhalb der erforderlichen und vereinbarten Zeit-grenzen 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 ord-nungsgemäßen Geschäftsbetrieb schnellstmöglich zu ermöglichen. Daher wird die Integration des IT Service Continuity Managements in das über-geordnete Business Continuity Management nicht nur ausdrücklich be-tont, 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 vornehm-lich 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 Business-Prozessen und deren Bedeutung zu verstehen. Die erste wirkliche verant-wortliche 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-Auswir-kungen, wenn der vereinbarte IT Service nicht zur Verfügung gestellt wer-den kann. Verbunden mit einer Analyse der Risiken kann eine angemes-sene 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 fin-det verstärkt Berücksichtigung bei Wirtschaftsprüfungen und anderen Au-ditierungen oder Revisionen.


69

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


– regelmäßige Audits der ITSCM-Pläne, um das Erreichen der verein-barten Wiederherstellungsanforderungen des Business sicherzustel-len

– 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 Servi-ces und Service Management-Aktivitäten. Schon aufgrund gesetzlicher Verpflichtungen kann es sich keine Organisa-tion 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 angemes-sen sicherzustellen und umfasst die Aspekte der Vertraulichkeit, Integrität und Verfügbarkeit:


70

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 Perso-nen, 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 Informa-tion Security Management zu zertifizieren und so dessen Implementie-rung nachzuweisen. Das Information Security Management System basiert auf einem Regel-kreis, 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 organi-satorischen Ansatzes für das Security Management, der über den Aufgaben-bereich des IT Service Providers hinausgeht, und berücksichtigt die Verwaltung papierbasierter Dokumente, Zutrittsrechte, Telefonanrufe etc. für die gesamte Organisation.



71

– prozentuale Verringerung der im Service Desk berichteten Si-cherheits-Verletzungen

– prozentuale Verringerung bei den Auswirkungen von Sicherheits-Verletzungen und Incidents

– prozentualer Anstieg der SLA-Konformität zu den Sicherheitsbe-stimmungen

– 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 Servi-ces, um dem Business die vereinbarte Service-Qualität zukommen zu las-sen und sicherzustellen, dass die Ausgaben für die Lieferanten den gelie-ferten Leistungen entsprechen. Bereits innerhalb der Service Strategy werden grundsätzliche Betrachtun-gen zu den Service-Strukturen angestellt und letztendlich die Service-Struktur definiert. Verbunden mit der Zielsetzung, einen IT Service bereit-zustellen, der die Business-Prozesse unterstützt, hat der IT Service Provi-der eine End-To-End-Verantwortung für den IT Service. Angesichts der Komplexität der einzubeziehenden technischen IT Services werden ver-stä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 gelie-fert 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 defi-nieren, Lieferanten sind auszuwählen und zu kategorisieren sowie die Leistungen und Abrechnungen der Lieferanten zu bewerten. Die Bewer-tung der Lieferanten entscheidet über die Fortführung bestehender Ver-trä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.



72

– Anstieg der Anzahl von Lieferanten, die vertraglich vereinbarte Zie-le einhalten

– Anstieg der Anzahl der mit Lieferanten durchgeführten Service- und Vertrags-Reviews

– Reduzierung der Anzahl von durch Lieferanten verursachten Ser-vice-Verletzungen

– Anstieg der Anzahl von Lieferanten mit ernanntem Lieferanten-Ma-nager.

2.5.2.3 Service Transition


Change Management




EvaluationKnowledge

Mgmt.

ServiceTransition


Change Management




EvaluationKnowledge

Mgmt.

ServiceTransition

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 kon-trolliert. Ein wirksamer Prozess Transition Planning and Support soll die Vorausset-zung dafür schaffen, dass der Service Provider ein hohes Volumen von Changes und Releases bearbeiten kann. Hierzu ist die Planung von Kapa-zitäten und Ressourcen für die Inbetriebnahme von neuen oder geänder-ten 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-


73

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 sicher-gestellt werden. Eine wichtige Aktivität besteht in der Definition einer Service Transition-Strategie. Diese Strategie definiert den umfassenden Ansatz zur Organisa-tion 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 Do-

kumentationen – Meilensteinplanung – Finanzielle Mittel (Budget)

Zu den weiteren Aktivitäten im Prozess gehören die Vorbereitungen, die integrierte Planung und die Unterstützung der einzelnen Transition-Prozesse.

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 Anzahl implementierter Releases, die – im Hinblick auf Kosten, Qualität, Scope und Release-Zeitplan – die mit dem Kunden verein-barten Anforderungen erfüllen

– Reduzierung von Abweichungen der aktuellen gegen die vorherge-sagten 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 brin-gen

– Reduzierung der Anzahl von Problemen, Risiken und Verzögerun-gen, die durch unzulängliche Planung verursacht werden.


74

Change Management Die Anforderungen im Business des Kunden verändern sich fortlaufend. Change Management reagiert auf diese Änderungsanforderungen und ma-ximiert den Wert für den Kunden, während gleichzeitig Incidents, Störun-gen und Überarbeitungen reduziert werden. Die Reaktionen auf die Än-derungsanforderungen des Business und der IT sorgen für eine Ausrich-tung 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 beur-teilt, 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 wer-den folgendermaßen eingebracht:

– Strategische Changes über Service Strategy und den Business Relea-tionship Management-Prozess

– Service Changes über Service Design, Continual Service Improve-ment 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 ne-gativen Auswirkungen auf den IT Service und die Business-Prozesse ha-ben. 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 wirksa-mes und dennoch nicht zu administratives Management sicherstellt. Hier-zu wird zwischen „Normaler Change“, „Notfall Change“ und „Standard Change“ unterschieden. Je nach Art des Changes finden dann verschie-dene Workflows ihre Anwendung. Insbesondere der „Standard Chan-ge“ 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 verantwort-lich ist. Wichtigstes Ziel des Change Managements ist es, die Durchführung von


75

lohnenden Changes bei einer minimalen Unterbrechung der IT Services zu ermöglichen.


– Anzahl der Änderungen (Changes) an den Services, die die mit den Kunden vereinbarten Anforderungen z.B. hinsichtlich Qualität/Kos-ten/Zeit erfüllten (ausgedrückt als Prozentsatz an allen Änderun-gen)

– der Nutzen der Änderungen, ausgedrückt als „Wert der durchge-fü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 schlech-te/unvollständige Bewertung der Auswirkungen verursacht wur-den.

– 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 zwi-schen 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 wich-tigen Beitrag zum Nachweis der Einhaltung von Compliance Anforderun-gen. Die Configuration Items können nach den folgenden Aspekten kategori-siert werden. Die Auflistung dieser Aspekte vermittelt einen Eindruck über den Geltungsbereich des Configuration Managements:

– Service Lifecyle CIs, wie der Business Case oder der Service Man-agement-Plan

– Service CIs, wie die Service-Fähigkeiten (Organisation, Prozesse, Personen, etc.) und die Service Ressourcen (Systeme, Applikationen, etc.)


76

– Organisatorische CIs, wie zum Beispiel Dokumentationen wie Poli-cies

– 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“, „Confi-guration 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 Be-richten während ihres gesamten Lebenszyklus verantwortlich ist.


Der Prozess, der für die Pflege von Informationen zu Configuration Items ein-schließlich der zugehörigen Beziehungen verantwortlich ist, die für die Erbrin-gung eines IT Service erforderlich sind. Diese Informationen werden über den gesamten Lebenszyklus des CI hinweg verwaltet.


– prozentuale Verbesserung bei der Zeitplanung für Wartungsarbei-ten eines Assets (nicht zu viel, nicht zu lange)

– Grad der Abstimmung zwischen unterstützter Wartung und Busi-ness Support

– als Ursache von Service-Ausfällen identifizierte Assets – verbesserte Geschwindigkeit für das Incident Management zur

Identifizierung fehlerhafter CIs und die Wiederherstellung des Ser-vice

– Auswirkung von Incidents und Fehlern mit Bezug auf bestimmte CI-Typen, z.B. von bestimmten Lieferanten oder Entwicklungsgrup-pen.


77

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 Busi-ness 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 ei-nes Release zu betrachten. Bei diesem handelt es sich um eine Zusammen-stellung von Hardware, Software, Dokumentation, Prozessen oder ande-ren Komponenten, die für die Implementierung eines oder mehrerer ge-nehmigter Changes an IT Services erforderlich sind. Aus dieser Definiti-on wird deutlich, dass das Change Management verantwortlich für die Genehmigung von Changes ist. Das Release and Deployment Manage-ment 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 Anwen-dertrainings. Basis der Prozessaktivitäten ist die Release Policy. Die Release Policy bein-haltet für einen oder mehrere Services unter anderem die folgenden Defi-nitionen:

– eindeutige Identifikation, Nummerierung und Namenskonventio-nen

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

den und an Service Operation zu übergeben. Diese Release Policy ist mit dem Kunden bzw. auf die Business-Prozesse abzustimmen.


78

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 abge-schlossen ist, sondern der Early Life Support und das Review die Prozess-aktivitä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.


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


79

Die Zielsetzung des Prozesses besteht in: – Sicherstellung, dass ein Service den Wertbeitrag für Kunden und

Business liefert – Planung und Implementierung eines strukturierten Validierungs-

und Test-Prozesses für den objektiven Nachweis gemäß der verein-barten Anforderungen und Service Level-Ziele

– Qualitätssicherung von Release, Komponenten, Service und Service-fä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.

Kunden/BusinessAnforderungen

definieren

ServiceAnforderungen

definieren

Design ServiceLösung

Design ServiceRelease

Design Lösungentwickeln

Build& Test

Service PackageAngebote, Verträge

validieren

Serviceabnahmetesten

Betriebsbereit-schaft testen

Service ReleasePackage Test

Komponenten &Komponenten-gruppen Test

Level für Configuration und Testen

Kunden/BusinessAnforderungen

definieren

ServiceAnforderungen

definieren

Design ServiceLösung

Design ServiceRelease

Design Lösungentwickeln

Build& Test

Service PackageAngebote, Verträge

validieren

Serviceabnahmetesten

Betriebsbereit-schaft testen

Service ReleasePackage Test

Komponenten &Komponenten-gruppen Test

Level für Configuration und Testen

Abbildung 32: 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 einge-bunden und eine Validierung und Test über alle Ebenen erfolgt (aus OGC, 2007c).


80

Von Bedeutung für das Verständnis dieses Prozesses ist es, dass der Pro-zess Service Validation and Testing nicht nur Fehlerfreiheit überprüft, son-dern auch die Einhaltung des zugesicherten Wertes für das Business. Die-ser 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.


– 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 Beseiti-gung jeglicher Fehler oder Abweichungen möglichst früh im Service Lebenszyklus erfolgt, da dies beträchtlich billiger ist als die Fehler-beseitigung 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 fortge-fahren 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 Auswirkun-gen 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 er-folgt gemeinsam mit dem Kunden und identifiziert sämtliche gewünsch-ten und unerwünschten Auswirkungen. Hierzu ist die Objektivität, Fair-ness, Konsistenz und Offenheit in der Bewertung unumgänglich.


81

Evaluation:

Der Prozess, der für die Bewertung eines neuen oder geänderten IT Service ver-antwortlich 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.


– 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-Informa-tion-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 Informa-tionen 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 Samm-lung 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-


82

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


– Incidents und verlorene Zeiten, kategorisiert als „Mangel an An-wender-Wissen“

– durchschnittliche Diagnose- und Reparatur-Zeit für Fehler, die in-house behoben werden

– Incidents bzgl. neuer oder veränderter Services, die durch Referenz auf die Wissensbasis behoben wurden.

2.5.2.4 Service Operation

EventManagement

Problem M.

RequestFulfilment

Access Management

Service Desk

IncidentManagement

ServiceOperation

EventManagement

Problem M.

RequestFulfilment

Access Management

Service Desk

IncidentManagement

ServiceOperation

Abbildung 33: Service Operation

Event Management Event Management befähigt zur Entdeckung und Interpretation von Ereig-nissen (Events) und ermöglicht deren Steuerung. Deshalb ist Event Mana-gement die Basis vieler Routine-Aktivitäten des Operation Managements und liefert die Eingangsstelle für viele Prozesse und Aktivitäten des Ser-vice Operation.


83

Innerhalb von Service Operation wird der IT Service für den Kunden be-reitgestellt. Daher ist es in dieser Phase des Service Lifecycle sehr wichtig, mögliche Incidents (Störungen) möglichst früh zu erkennen und zu behe-ben, so dass die Auswirkungen für die Business-Prozesse minimiert wer-den. Durch die Überwachung von Events, die innerhalb der IT-Infrastruktur 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 ge-steuert, 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 ver-sucht, sich bei einer Applikation mit dem falschen Kennwort anzu-melden, oder ein PC-Scan zeigt die Installation unautorisierter Soft-ware

– Events, die eine ungewöhnliche aber nicht außergewöhnliche Ope-ration kennzeichnen und so einen Hinweis für ein genaueres Moni-toring liefern.

Das Event Management sollte durch definierte Regeln und Tools in der Lage sein, auf bestimmte Events automatisch zu reagieren, wie zum Bei-spiel 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.


– Anzahl von Ereignissen je Kategorie – Anzahl von Ereignissen nach Signifikanz – Anzahl und Prozentsatz an Ereignissen, die menschliche Interven-

tion erforderten und ob dies durchgeführt wurde


84

– Anzahl und Prozentsatz an Ereignissen, die in Incidents oder Ände-rungen resultierten.

Incident Management Das primäre Ziel des Incident Management-Prozesses ist die schnelle Wie-derherstellung 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üh-renden Aktionen zu ermitteln. Die Business-Orientierung wird bei der Definition der Auswirkung und Dringlichkeit sehr deutlich. Die Auswir-kung 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 Um-gang 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 per-formancerelevante Incidents, die automatisiert an das Capacity Manage-ment 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 lie-gende Ursache zu ermitteln. Die Ermittlung dieser Ursache und mögliche Umgehungslösungen zu entwickeln ist die Aufgabe des Problem Manage-ments.

Incident Management:

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



85

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

hungslösung, aufgeschlüsselt nach Auswirkung (impact code).

Request Fulfilment Request Fulfilment ist der für die Behandlung der Service Requests verant-wortliche Prozess. Er stellt definierte Informationskanäle für die Anwen-der bereit, mit denen Anforderungen gestellt und Services entgegenge-nommen werden können. Darüber hinaus werden Informationen über die Verfügbarkeit von Services und Prozeduren für deren Nutzung bereitge-stellt. Standardleistungen, wie zum Beispiel Lizenzen und Software-Medien, 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 Be-reitstellung 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 wer-den 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 geneh-migter 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 Zuwei-sung der Service Requests liegt im Service Desk.

Request Fulfilment:

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


86


– 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 Probleme3. 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 wer-den, dass sich diese Incidents nicht wiederholen. Ein gutes Problem Ma-nagement stellt die Reduzierung von Incidents bzw. die Reduzierung de-ren Auswirkungen sicher und liefert einerseits dem Business einen stabile-ren 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 gesam-ten Bearbeitung ein Incident. Sehr wohl bedingen sich Incident und Prob-lem Management. Eine wichtige Aufgabe des Problem Managements besteht in der Doku-mentation von Known Errors. Ein Known Error liegt vor, wenn die zugrunde liegende Ursache für ein Problem identifiziert und ein Worka-round (Umgehungslösung) dokumentiert wurde. Diese Umgehungslösung ermöglicht die Reduzierung oder Beseitigung der Auswirkungen von In-cidents oder Problemen, für die noch keine vollständige Lösung verfügbar ist, wie zum Beispiel durch den Neustart eines ausgefallenen Configura-tion Items. Gespeichert werden die Known Errors in der Known Error Da-

3 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 wei-tere Untersuchung der Ursache verantwortlich.


87

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 Wiederherstel-lungsmaß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 Ma-nagement wird allgemein in Service Operation durchgeführt. Das proakti-ve 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 verant-wortlich ist. Wichtigstes Ziel des Problem Managements ist es, Incidents zu ver-hindern bzw. die Auswirkungen von Incidents zu minimieren, die nicht verhin-dert werden können.


– 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 Security- und Availability Management definierten Richtlinien und Aktionen zustän-dig. Aus den gestiegenen Compliance Anforderungen (zum Beispiel Sarbanes Oxley Act, SOX) resultiert die Notwendigkeit einer Regelung für den


88

Zugriff auf IT Services und Daten. Diese Anforderungen sind leicht nach-zuvollziehen, wenn die Folgen eines unautorisierten Zugriffs betrachtet werden. Die möglichen Folgen von Manipulationen, aber auch die unbe-rechtigte 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 Service-Funktionalität oder Daten, für deren Nutzung ein Anwender be-rechtigt ist

– Identity (Identität), bezieht sich auf die Information, die sie als in-dividuell charakterisiert und die ihren Status innerhalb der Organi-sation verifiziert (wie der Anwender)

– Rights (Rechte, auch genannt Privilegien), beziehen sich auf die ak-tuellen Einstellungen, wodurch einem Anwender der Zugriff zu ei-nem Service oder einer Gruppe von Services bereitgestellt wird, ty-pische 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 beste-hen aus „Zugriffsberechtigung beantragen“, „Verifikation“, „Zugriffs-rechte 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ügbar-keit 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 Identi-täts-Management (Identity Management) bezeichnet werden.


89


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

dern.

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 „Or-ganizing 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 Ansprech-partner für die Anwender nimmt der Service Desk Incidents, Service Re-quests und einige Kategorien von Requests for Change auf. Die Zielset-zung besteht darin, den Anwendern eine einfache Kommunikation zu ermöglichen. Mit der Funktion als Primary Point of Contact stellt der Ser-vice 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 An-

fragen – Durchführung von Anwenderbefragungen.

Darüber hinaus übernimmt der Service Desk die Koordination einiger IT-Gruppen 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


90

Sun“ verschiedene Strukturen. Im Rahmen der Implementierung des Ser-vice Managements gilt es dann, die für die jeweilige Organisation geeig-nete Struktur zu spezifizieren. Die seitens der ITIL Best Practices dokumentierten Key Performance-Indikatoren sind zum Beispiel:

– Prozentsatz von Calls (Anrufen), deren Requests bzw. Störungen so-fort 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


(ROI) for CSI

The 7 StepImprovement

Process

Service Reporting

ServiceMeasurementThe

BusinessQuestions

for CSI

ServiceLevel

Manage-ment

ContinualService

Improvement


(ROI) for CSI

The 7 StepImprovement

Process

Service Reporting

ServiceMeasurementThe

BusinessQuestions

for CSI

ServiceLevel

Manage-ment

ContinualService

Improvement

Abbildung 34: Continual Service Improvement

The 7 Step Improvement Process Hier werden Fragen gestellt nach den Business-Treibern hinter der ITIL-Implementierung, 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


91

von Ressourcen (Time and Budget) zum Schließen der Lücken und schließlich nach den Ergebnissen der Aktivitäten beim Streben nach „Ser-vice 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:

Ziele

3. Sammle Daten

7. ImplementiereKorrektur-maßnahmen

6. Präsentiere und nutze die Informationen

Identifiziere:VisionStrategieTaktische ZieleOperative Ziele

2. Definiere,was Dumessen kannst

1. Definiere,was Dumessen solltest

5. Analysiere Daten

4. BearbeiteDaten

Ziele

3. Sammle Daten

7. ImplementiereKorrektur-maßnahmen

6. Präsentiere und nutze die Informationen

Identifiziere:VisionStrategieTaktische ZieleOperative Ziele

2. Definiere,was Dumessen kannst

1. Definiere,was Dumessen solltest

5. Analysiere Daten

4. BearbeiteDaten

Abbildung 35: 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 ge-braucht werden und um die Zielerreichung vollständig zu messen. Eine


92

Betrachtung, ob die Daten aktuell verfügbar sind und mit einem vertretba-ren Aufwand gewonnen werden können, findet hier nicht statt. Was gemessen werden sollte, ist innerhalb von Service Strategy und Ser-vice 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 wer-den, gilt es im zweiten Schritt festzustellen, was tatsächlich gemessen wer-den 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 Risi-ken 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 Über-wachung der Service-Qualität. Hierzu sind durch eine geeignete Kombi-nation 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 be-reits 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 entspre-chend 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.


93

Hierzu werden unter anderem Daten aus verschiedenen Quellen konsoli-diert, auf Zeitskalen abgebildet und führen zu den definierten KPIs und Kennzahlen. Die Kennzahlen können in drei Betrachtungsebenen darge-stellt 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 Beur-teilung 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 ope-rative Entscheidungen zu treffen. Grundvoraussetzung hierzu ist eine Zielgruppen-ausgerichtete Präsenta-tion 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 Wert-beitrag zu präsentieren.


94

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 optimie-ren, zu verbessern und zu korrigieren. Die Verbesserungsmaßnahmen, die den IT Service verbessern, sind zu identifizieren und innerhalb der Orga-nisation 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 Ser-vice Provider auf Basis der Zielsetzung und der Business-Vorteile die Um-setzung 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 Ände-rungen in Bezug zu den Zielen durchzuführen?

– Wer ist der Owner des KPIs? Wer ist verantwortlich für das Sam-meln und die Analyse der Daten? Wer ist für Verbesserungen basie-rend 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-


95

ten sind hierzu die Daten so aufzubereiten, dass das Business die notwen-digen 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 ver-langt 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 As-pekte 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 Ge-schä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 Mes-sung eines IT Service muss weitergehen und den gesamten IT Service hin-sichtlich seiner Unterstützung des Business-Prozesses umfassen. Eine Ser-vice Messung muss der Kundensicht und Wahrnehmung auf den IT Servi-ce entsprechen, hierzu ist eine „end-to-end“-Messung erforderlich. Service-Messungen sollten nicht nur die Vergangenheit betrachten, son-dern 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:


96

– Verbesserte Verfügbarkeit (durch Service / Systeme / Applikationen) – Verringerung der Service Level Verletzungen (durch Service / Sys-

teme / Applikationen) – Verringerung „mean time to repair“ (gemessen anhand von Priori-

tä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 Perso-nalkosten, Tools, Beratungskosten, etc. Auf der anderen Seite ist zu bewer-ten, 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, son-dern 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 Aus-druck 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 defi-nieren „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ün-dungen 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 zugrun-de liegenden IT Services und Service Assets sich dementsprechend aus-richten können.

2.6 ISO 20000

97

Die Aktivitäten des Continual Service Improvement setzen einen betriebs-bereiten 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 Pro-zess. 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 Ser-vice-Verbesserungen geschaffen werden. Das Service Level Management stellt einen wichtigen Trigger für den Ser-vice Improvement-Plan (SIP) dar. Der Service Improvement-Plan ist ein formeller Plan, um mögliche Verbesserungen zu einem Prozess oder ei-nem IT Service durchzuführen. Durch die Identifizierung notwendiger Verbesserungen und deren Management mittels des SIP wird eine nach-haltige 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 Service-orientierung 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-


98

rungs-Organisation auf der Basis einer internationalen Qualitätsnorm zer-tifizieren zu lassen. Mit dieser Norm wird dem steigenden Bedarf des Nachweises eines wirk-samen IT Service Managements Rechnung getragen. In diesem Zusam-menhang 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 Mana-gement-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.

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 gemein-same internationale Referenz (Norm) für alle IT-Organisationen bereitge-stellt, die IT Services für interne oder externe Kunden erbringen. 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 interna-tional definierte Mindestanforderung an das IT Service Management ange-sehen werden.

Mit der ISO 20000 existiert seit dem 15. Dezember 2005 eine international aner-kennte Norm für das IT Service Management. Auf der Basis dieser Norm ist eine Zertifizierung der implementierten IT Service Management-Prozesse einer Or-ganisation 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 Volks-wirtschaften eine ISO 20000-Zertifizierung verlangen werden" (vgl. [Gart-ner, 2006]).

Eine „ITIL Zertifizierung“ für Organi-sationen ist nicht möglich.

Eine Zertifizierung von Organisa-tionen ist nur auf Basis der ISO 20000 möglich

2.6 ISO 20000

99

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 Manage-ment 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 Prac-tices maßgeblich mitgewirkt. Dadurch ist eine weitgehende Übereinstim-mung 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, sicher-stellen und nachweisen muss, um die Zertifizierung zu erhalten. Die ISO 20000-1 enthält die Muss-Kriterien des Standards und umfasst inklu-sive Deckblatt und Inhaltsverzeichnis insgesamt 36 Seiten. 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 Ma-nagement-Prozesse im Rahmen des formellen Standards. Die ISO 20000-2 umfasst 44 Seiten. Anhand des Umfangs der Dokumentation kann die Zielsetzung der ISO 20000 leicht nachvollzogen werden. Die Norm definiert Anforderun-gen 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

ISO 20000-1 enthält die Muss-An-forderungen

ISO 20000-2 enthält die Soll-An-forderungen


100

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 Inhal-ten der SLAs (vgl. [ISO 20000-2, 2005], Kapitel 6.1.2 „Service Level Agree-ments“): „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 Servi-ces …“. Wie das Beispiel zeigt, stehen die ITIL Best Practices und die ISO 20000 nicht in Konkurrenz zueinander, sondern ergänzen sich zweckmäßig. Un-geachtet einer möglichen Zertifizierung liefern die ITIL Best Practices Gui-delines zum Aufbau der IT Service Managements. Die notwendigen IT Service Management-Prozesse werden beschrieben, Rollen definiert, Do-kumente 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 Pla-nungssicherheit ihr IT Service Management etablieren. IT-Organisationen, die die ITIL Best Practices als Leitfaden zum Design ihrer IT Service Ma-nagement-Prozesse nutzten, haben so eine gute Basis für eine ISO 20000-Zertifizierung geschaffen. Die ISO 20000 definiert Mindestanforderungen und hilft dadurch, sich zunächst auf die Mindestanforderungen zu kon-zentrieren. Hierzu die Presseerklärung des Flughafens München zur er-folgreichen ISO 20000-Zertifizierung „… um die Prozessneugestaltung mit der erforderlichen Motivation durchzuführen, wurde die Zertifizierung des Servicebe-reichs nach BS15000 (jetzt ISO 20000) als Meilenstein definiert. Die Zertifizie-rung als erste Zielmarke zu definieren, um einerseits das Augenmerk des Be-reichsmanagements und aller betroffenen Mitarbeiter klar zu fokussieren, anderer-seits 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 Ver-sion 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 gefor-dert werden. Allerdings sind in der ITIL Version 3 die Prozesse gegenüber

ITIL und ISO 20000 ste-hen nicht im Wettbewerb, sondern er-gänzen sich zweckmäßig

2.6 ISO 20000

101

der ISO 20000 erweitert worden, wie zum Beispiel durch die Aufteilung des „alten“ Incident Managements in „Incident Management“ und „Re-quest 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 Manage-ment, 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 ent-hä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 Im-provement“ das übergeordnete Managementsystem ebenfalls beschrieben.

Service Delivery-Prozesse

Control-Prozesse

Configuration ManagementChange ManagementRelease-

Prozesse

ReleaseManagement

Relationship-Prozesse

Resolution-ProzesseIncident ManagementProblem Management

Business RelationshipManagement

Supplier Management

Capacity Management

Service Continuityand Availability

Management

Information SecurityManagement

Budgeting and accounting for IT

services


Planen und Implementieren neuer oder geänderter Services

Planung und Implementierung des Service Managements

Anforderungen an ein Management System

Service Reporting

Service Delivery-Prozesse

Control-Prozesse

Configuration ManagementChange ManagementRelease-

Prozesse

ReleaseManagement

Relationship-Prozesse

Resolution-ProzesseIncident ManagementProblem Management

Business RelationshipManagement

Supplier Management

Capacity Management

Service Continuityand Availability

Management

Information SecurityManagement

Budgeting and accounting for IT

services


Planen und Implementieren neuer oder geänderter Services

Planung und Implementierung des Service Managements

Anforderungen an ein Management System

Service Reporting

Abbildung 36: 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 langfris-tige Planungen miteinander vereinen. Damit wird die Integration des IT


102

Service Managements in die IT-Strategie sichergestellt. Innerhalb der fol-genden Abbildung 36 werden die geforderten IT Service Management-Prozesse, 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 zertifi-ziert 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 Ma-nagement-Prozesse vorgeben bzw. empfohlen. Die ISO 20000 verlangt allerdings eine Etablierung der Prozessverantwor-tung und das Prozess-Management (Management Control) für sämtliche IT Service Management-Prozesse. Es ist innerhalb der eigenen Organisa-tion 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 Übereinstim-

mung 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 Ma-nagement-Prozesse Kennzahlen zu definieren sind. Hinzu kommt, dass der kontinuierliche Verbesserungsprozess integraler Bestandteil der ISO 20000 ist. Hierzu wird in der Norm die Plan-Do-Check-Act-Methodik beschrieben (aus [van Bon, 2006], vgl. Abbildung 37). Dieser kontinuierliche Verbesserungsprozess ist nicht nur für die überge-ordneten 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.”

2.7 COBIT

103

Geschäfts-Anforderungen

Kunden-Anforderungen

Anforderungenneue/geänderte

Services

Weitere Prozesse, z.B. Geschäfts-, Lieferanten-,

Kundenprozesse

Service Desk

Weitere Teams,z.B. Security,

IT-Betrieb

Neue oder geänderteServices

Kunden-Zufriedenheit

Geschäfts-Ergebnisse


Kundenprozesse

Zufriedenheit imTeam und bei den

Beteiligten insgesamt

Management von Services

Management von Verantwortlichkeiten

PLANPlanen des

Service Managements

CHECKÜberwachung, Messen

und Review

ACTKontinuierlicheVerbesserung

DOImplementieren des

Service Managements




Services


Kundenprozesse

Service Desk


IT-Betrieb




Services


Kundenprozesse

Service Desk


IT-Betrieb





Kundenprozesse







Kundenprozesse



Management von Services

Management von Verantwortlichkeiten

PLANPlanen des

Service Managements

CHECKÜberwachung, Messen

und Review

ACTKontinuierlicheVerbesserung

DOImplementieren des

Service Managements

Abbildung 37: 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 Zertifizierungs-organisation auch überprüft, wie die ermittelten Kennzahlen mit den Zie-len korrespondieren und welcher Handlungsbedarf aus den Kennzahlen abgeleitet werden kann. Die Anforderungen und Empfehlungen der ISO 20000 hinsichtlich Moni-toring und Reporting von SLAs beschreiben wir in Kapitel 2.8.6 „Monito-ring und Reporting von SLAs, OLAs und UCs“.

2.7 COBIT Je bedeutender und kritischer die IT-Unterstützung für die Geschäftspro-zesse einer Organisation ist, umso wichtiger ist der Einsatz eines geeigne-ten Steuerungsinstruments für die Aktivitäten der IT. Vor diesem Hinter-grund 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 In-formation Systems Audit and Control Association (ISACA). Wie der Or-ganisationsname bereits verrät, war COBIT speziell für den Einsatz bei Wirtschaftsprüfern vorgesehen. Aufgrund der Ausrichtung an der Audi-tierung liegen die Stärken von COBIT naturgemäß in den definierten Steu-

Im Rahmen einer ISO 20000-Zertifi-zierung werden Prozesskenn-zahlen über-prüft.


104

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 aus-drücklich betont, dass die praktische Ausgestaltung organisationsspezi-fisch 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. Allge-mein 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 verantwor-tungsvoll eingesetzt und Risiken angemessen überwacht werden. COBIT, aber auch die ITIL Best Practices, sollen diese Maßgaben der IT Governan-ce 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 man-agement. It is an integral part of enterprise governance and consists of the lead-ership, organizational structures and processes that ensure that the organiza-tion’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 gemein-same Basis für die Auditierung von IT-Organisationen innerhalb von Prü-fungsorganisationen zu schaffen. Hierzu wurden analog zu der Entwick-lung von ITIL entsprechende Best Practices von Experten unterschiedli-cher 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 Weiterentwick-lung 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 Practi-ces besser aufeinander abgestimmt sind.

2.7 COBIT

105

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 stra-tegische 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 basie-ren 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 verantwor-tungsvoll 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 Aufga-ben 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 geschlosse-nen Lebenszyklus (Lifecycle) bilden (vgl. [COBIT, 2005], Abbildung 38). Für jeden der 34 IT-Prozesse dokumentiert COBIT die jeweilige Best Prac-tice 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.

COBIT sind Best Practices.


106

Prozesse- Def. u. Manage Service Level- Manage Services von Dritten- Manage Performance

und Kapazitäten- Manage kontinuierliche

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

Prozesse- Überwache und bewerte

IT-Performance- Überwache und bewerte

interne „Controls”- Stelle die angeordnete

Compliance sicher - Sorge für IT-Governance

Geschäftsziele

DS: Deliver and Support

ME: Monitor and Evaluate

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

Ressourcen- Manage die Qualität- Beurteile und Manage

die Risiken- Manage Projekte

Prozesse- Identifiziere automa-

tisierte 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


und Kapazitäten- Manage kontinuierliche

Services- Stelle Systemsicherheit sicher- Identifiz. u. verrechne Kosten- Schule u. trainiere Anwender- Manage Service Desk






Geschäftsziele
















Abbildung 38: COBIT Prozess-Übersicht

2.7.3 Prozess-Management gemäß COBIT In COBIT sind für jeden Prozess „Control Objectives“ definiert. COBIT versteht Control Objectives als Minimalanforderungen für ein wirkungs-volles 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.

Control Objectives dienen der Steuerung, nicht der Kontrolle

2.7 COBIT

107

Die Control Objectives dokumentieren das Ziel oder den Zweck eines Pro-zesses 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 Ob-jective 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 Ziel-erreichung 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 Infra-struktur 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 über-prüft werden. Diese Aktivitäten schließen Changes an Verfahren, an Pro-zessen, an Systemen und an Services ein. Durch diese Aktivitäten sollen die Risiken von Changes minimiert werden, die sich negativ auf die Stabi-lität und Integrität der Produktivumgebung auswirken. COBIT definiert für den Prozess „Manage Changes“ insgesamt 6 detail-lierte Control Objectives. Ein detailliertes Control Objective lautet „Notfall Changes” (AI6.3: Emergency Changes). Dieses Control Objective fordert, einen Prozess für die Definition, Auf-nahme, Beurteilung und Genehmigung von Notfall-Changes zu erstellen. Dokumentationen und Tests können unter Umständen auch nach der Imp-lementierung 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.


108

AI6: Manage Changes

AI6.1: Standard-Changes und Prozeduren

AI6.4: Statusverfolgung und Reporting

AI6.2: Bewertung von Auswirkungen, Priorisierung und Freigabe

AI6.3: Notfall-Changes

AI6.5: Abschluss und Dokumentation

AI6: Manage Changes

AI6.1: Standard-Changes und Prozeduren

AI6.4: Statusverfolgung und Reporting

AI6.2: Bewertung von Auswirkungen, Priorisierung und Freigabe

AI6.3: Notfall-Changes

AI6.5: Abschluss und Dokumentation

Abbildung 39: Zusammenhang zwischen Control Objectives in COBIT

Während ITIL die Leistungsindikatoren der Prozesse pauschal als Key Performance-Indikators (KPIs) bezeichnet, betrachtet COBIT die Leis-tungsmessung der Prozesse als „Performance-Messung“ und unterschei-det 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 er-reicht (Effektivität). KGIs sind daher an dem jeweiligen Prozess-Output orientiert. Mit den KPIs wird dagegen die Leistungsfähigkeit eines Prozesses in Rela-tion 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äftsan-forderungen ergeben sich die Ziele für den IT-Bereich. Diese übergeordne-ten Ziele bestimmen dann die jeweiligen Prozessziele, und mit den Pro-

COBIT gliedert die Performance- Messung in Kriterien für Effektivität und Effizienz

2.7 COBIT

109

zesskennzahlen (KGIs, KPIs) erfolgt die Messung, ob die Prozesse die Ziel-setzungen erfüllen.

Prozessziele und Kennzahlen für Prozesse werden top down definiert. Sie erge-ben sich aus den IT-Zielen aus den Geschäftsanforderungen.

¬ % der aufgezeichneten und mit automatisier-ten Tools verfolgten Änderungen

¬ % der Änderungen, die formale Änderungs-kontrollprozessebefolgen

¬ …

Key Goal Indicators

¬ % der nicht erfolgreichen Änderungen der Infrastruktur, die durch ungeeignete Änderungs-spezifikationenhervorgerufen sind

¬ …

Ziel der Aktivitäten

¬ Definition und Kommunikation der Verfahren für Changes inklusive Notfalländerungen -patches

¬ …

Ziel des Prozesses

¬ Führe genehmigte Änderungen an der IT-Infrastruktur und Anwendungen durch

¬ Bewerte die Auswirkungen der Changes auf die IT-Infrastruktur, …

¬ …

Werden gemessen durch Werden gemessen durch

trei

ben

IT Key Goal Indicators

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

Ziel der IT

¬ Reagiere auf Geschäftsan-forderungen in Übereinstimmung mit der Unter-nehmensstrategie

¬ Reduziere Mängel und Nacharbeit bei Lösungen …

¬ …

Werden gemessen durch

trei

ben

Definierte Ziele

Mes

sung

der

Zie

lerr

eich

ung

KPI Metriken für Prozesse KGI

KPI Metriken für IT-Ziele KGI

Key Performance Indicators

¬ % der aufgezeichneten und mit automatisier-ten Tools verfolgten Änderungen

¬ % der Änderungen, die formale Änderungs-kontrollprozessebefolgen

¬ …

Key Goal Indicators

¬ % der nicht erfolgreichen Änderungen der Infrastruktur, die durch ungeeignete Änderungs-spezifikationenhervorgerufen sind

¬ …

Ziel der Aktivitäten

¬ Definition und Kommunikation der Verfahren für Changes inklusive Notfalländerungen -patches

¬ …

Ziel des Prozesses

¬ Führe genehmigte Änderungen an der IT-Infrastruktur und Anwendungen durch

¬ Bewerte die Auswirkungen der Changes auf die IT-Infrastruktur, …

¬ …

Werden gemessen durch Werden gemessen durch

trei

ben

IT Key Goal Indicators

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

Ziel der IT

¬ Reagiere auf Geschäftsan-forderungen in Übereinstimmung mit der Unter-nehmensstrategie

¬ Reduziere Mängel und Nacharbeit bei Lösungen …

¬ …

Werden gemessen durch

trei

ben

Definierte Ziele

Mes

sung

der

Zie

lerr

eich

ung

KPI Metriken für Prozesse KGI

KPI Metriken für IT-Ziele KGI

Key Performance Indicators

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


110

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 Nachar-beiten 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 Pro-zesse 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 Manage-ment 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-Manage-ment stellen sich wie folgt dar (siehe Abbildung 41):

2.7 COBIT

111

Input Output

Prozess

KGI

Aktivitäten

Ziele

Control Objectives

AnforderungProzessmanagement KPI

Input Output

Prozess

KGI

Aktivitäten

Ziele

Control Objectives

AnforderungProzessmanagement KPI

Abbildung 41: Prozess, Ziele und Kontrollebenen in COBIT

2.7.4 COBIT und die IT Service Management-Prozesse COBIT enthält relevante Prozesse und Metriken für den gesamten IT-Be-reich. 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 Versio-nen 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 konvergie-ren 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 ande-ren erhöht die enge Verbindung zur ISO 20000 die praktische Relevanz des ITIL Ansatzes.

Mit der Ver-sion 4.0 hat sich COBIT stärker an den ITIL Best Practices ausgerichtet.

Es gilt, die Vorteile von ITIL und COBIT zu nutzen.


112

Bei der Prozessbeschreibung begnügt sich COBIT hingegen mit einer kur-zen Aufzählung von Aktivitäten. Für den Prozess „Manage Chan-ges“ beispielsweise sind die Prozessaktivitäten in fünf Sätzen dokumen-tiert. COBIT liefert jedoch im Gegensatz zu ITIL gute Ansätze für die Defi-nition 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 Empfehlun-gen für die Umsetzung liegen, bietet COBIT gute Ansätze für Metriken. Die Pro-zesse für das IT Service Management stimmen in den Best Practices grundsätz-lich überein, so dass aus beiden Ansätzen die Stärken zusammengeführt werden können.


und Kapazitäten- Manage kontinuier-

liche Services- Stelle Systemsicherheit sicher- Identifiz. u. verrechne Kosten- Schule u. trainiere Anwender- Manage Service Desk






Geschäftsziele

















und Kapazitäten- Manage kontinuier-

liche Services- Stelle Systemsicherheit sicher- Identifiz. u. verrechne Kosten- Schule u. trainiere Anwender- Manage Service Desk






Geschäftsziele
















Abbildung 42: Mapping der Prozesse in ITIL Version 2 und COBIT

Eine Analyse der COBIT Best Practices und der IT Service Management-Prozesse auf Basis der ITIL Best Practices zeigt eine große Überstimmung von Prozessen und deren Ziele bzw. Aktivitäten (vgl. [Kurth, 2006]).

2.7 COBIT

113

Die übereinstimmenden IT Service Management-Prozesse zwischen den ITIL Best Practices Version 2 und COBIT wurden seitens des IT Gover-nance Institute analysiert und dokumentiert (vgl. [COBIT, 2007]). Der fol-genden 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 übereinstim-mend ausgewiesen. Im Rahmen der ISO 20000 ist aber das Security Mana-gement 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 überge-ordnete 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 detail-lierten Spezifikationen und die Bedeutung für das Prozess-Management sind dagegen nicht in COBIT dokumentiert. Diese Festlegungen und Aus-gestaltungen 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 Prozess-ziele und die daraus resultierenden KPIs und KGIs ausgewiesen (vgl. [COBIT, 2005]).


114

2.7.6 COBIT Metriken für IT Service Management-Prozesse

Manage Service Desk und Incidents (Manage Service Desk and Inci-dents: DS8) Zielsetzung dieses Prozesses ist die wirkungsvolle Nutzung der IT-Sys-teme durch die Lösung und Analyse von Anwenderanfragen und Inci-dents. 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 Anwen-derzufriedenheit 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 Iden-tifizierung der Ursache

– Anteil der Probleme, für die eine Ursachenanalyse betrieben wurde – Häufigkeit der Berichte oder Aktualisierung über anhaltende Pro-

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

2.7 COBIT

115

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

bleme

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 Spei-cherung der Konfigurationsattribute der IT-Anlagen und der Baselines, sowie die Prüfung, ob sie mit den tatsächlichen Konfigurationen überein-stimmen. Die in COBIT dokumentierten KPIs sind:

– Anzahl der Abweichungen in Bezug auf unvollständige oder feh-lende Konfigurationsinformationen

– Durchschnittliche Zeitdauer zwischen der Identifizierung einer Ab-weichung und deren Korrektur

Die in COBIT dokumentierten KGIs sind: – Anzahl der Abweichungen zwischen den gespeicherten und tat-

sächlichen Konfigurationsdaten – Anteil der erworbenen Lizenzen und der nicht in der Datenbank ge-

speicherten Lizenzen Die in COBIT dokumentierten IT Key Goal Indicators sind:

– Anteil der Compliance-Probleme aufgrund unzulässiger Konfigura-tionen von IT-Anlagen

Manage Changes (Manage Changes: AI6) Das Ziel des „Manage Changes“ ist, Änderungen innerhalb der Produk-tivumgebung auf eine formell gesteuerte Art und Weise durchzuführen. Zu Changes zählen neben Änderungen an der Infrastruktur und an beste-henden 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:


116

– 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 Sys-teme nach der Installation ohne größere Probleme betrieben werden kön-nen. 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 Verbesse-rungen

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

zeptanztests zurückzuführen sind – Ausfallzeiten der Anwendung, die durch ungenügende Tests her-

vorgerufen werden Die in COBIT dokumentierten IT Key Goal Indicators sind:

– Anteil der Interessenvertreter, die mit der Daten-Integrität der neu-en Systeme zufrieden sind

Definiere und Manage Service Level (Define and manage service lev-els: DS1) Das Service Level Management hat die Ausrichtung der wesentlichen IT Services an der Geschäftsstrategie zum Ziel. Hierzu sind Serviceanforde-rungen zu identifizieren, die Service Level (Anmerkung: ITIL bezeichnet

2.7 COBIT

117

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 errei-chen. 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 Investiti-onsplanung zu etablieren und zu betreiben. Dieses Managementsystem


118

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 ca-pacity DS3) Das Ziel des Capacity Managements liegt in der Performanceoptimierung der IT-Infrastruktur, der Ressourcen und Kapazitäten in Übereinstim-mung mit den Geschäftsanforderungen. Hierzu sind die im SLA verein-barten 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 hinausge-

hen – 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 un-

zureichender Kapazitätsplanung

2.8 Monitoring und Reporting von SLAs

119

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äts-plans

– Häufigkeit der Reviews des IT-Kontinuitätsplans – Anteil der kritischen IT-Komponenten mit automatisierter Verfüg-

barkeitsü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 un-

geplanter 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 Si-cherheitsschwachstellen 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, ge-

lö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 Un-ternehmens und seiner Kunden auszurichten, die Qualität der erbrachten


120

IT Services zu verbessern sowie die langfristigen Kosten der Service-Tätigkeit zu reduzieren (vgl. [itSMF, 2001]). Um diese Ziele zu erreichen, haben sich international anerkannte Best Practices für IT-Prozesse durch-gesetzt. 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 do-kumentierten Prozesse sind über definierte Schnittstellen und gemeinsame Dokumente und Daten miteinander verknüpft. Der Output eines Prozes-ses 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 er-stellt 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 ih-ren 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 Ma-nagement noch aus IT-Sicht. Diese Sichtweise wandelte sich mit der Her-ausgabe der ITIL Version 2, bei der sich die ITIL Best Practices auf die Ausrichtung des IT Service Managements und die Gestaltung der entspre-chenden 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 Pro-zesszielen und ihrer unternehmensspezifischen Ausrichtung sicher, dass die geschäftlich notwendigen IT Services wirkungsvoll erbracht werden und so die Ziele des IT Service Managements erreicht werden können. Das Hauptaugenmerk der Kunden liegt auf der Lieferung der geschäftlich notwendigen und mit der IT-Organisation vereinbarten IT Services. Die Betrachtung der damit verbundenen IT-Prozesse ist für den Kunden se-kundär. Sie ist primär an deren Output im Rahmen der gelieferten IT Ser-vices 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.

Der Fokus der Kunden liegt auf den IT Services.


121

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 zunehmen-der Bedeutung für einen reibungslosen Geschäftsprozess wurde offen-sichtlich, 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 Anwen-der entwickelt. Mit der Weiterentwicklung innerhalb der Informations-Technologie 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 Wahrneh-mung des Kunden im Mittelpunkt“ (vgl. [OGC, 2005a]). Die heutige Interpretation des IT Service-Begriffes konzentriert sich dem-zufolge 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 Kundenanforderun-gen 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 pri-mä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 kei-nerlei manuelle Eingriffe mehr, wie zum Beispiel das „Online-Banking“. Um sich der Bedeutung der IT für die geschäftlichen Tätigkeiten eines

Von der System- zur Service-Orientierung.


122

Unternehmens bewusst zu werden, ist die Frage „was würde beim Ausfall der IT-Systeme geschehen“ sehr hilfreich. Damit die geschäftlichen Aktivi-täten entsprechend unterstützt werden können, ist in der Regel das Zu-sammenwirken 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 Gesamt-systems ist für die Unterstützung der Geschäftsprozess entscheidend. Die IT-Organisation muss erkennen, dass der Systembetrieb keinen Selbst-zweck darstellt, sondern zweckdienliche Geschäftsprozesse mit der not-wendigen IT-Unterstützung für den Unternehmenserfolg entscheidend sind.

Für das Selbstverständnis der IT ist es wichtig zu erkennen, dass die Bereitstel-lung der IT Services in erster Linie der Unterstützung der betrieblichen Primär-aktivitä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üt-zenden Prozesse oder sekundären Aktivitäten unterstützen die Durchfüh-rung 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). 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 Kundenbe-zug 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.

ITIL stellt den IT Service in direkten Bezug zum Geschäfts-prozess


123

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

Beschaffung Produktion Marketing & Vertrieb

Kunden-Service

= Primäre Prozesse / Aktivitäten = sekundäre Prozesse / Aktivitäten

…

Personalwirtschaft

Unternehmensinfrastruktur

= geforderte und gelieferte IT-Unterstützung(IT-Service)

IT-Service

IT-Service IT-Service IT-Service IT-Service

IT-Service

Wert-schöpfung

IT Service Management

Beschaffung Produktion Marketing & Vertrieb

Kunden-Service

= Primäre Prozesse / Aktivitäten = sekundäre Prozesse / Aktivitäten

…

Personalwirtschaft

Unternehmensinfrastruktur

= geforderte und gelieferte IT-Unterstützung(IT-Service)

IT-Service

IT-Service IT-Service IT-Service IT-Service

IT-Service

Wert-schöpfung


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 Informationstech-nologie und unterstützt die Business-Prozesse des Kunden. Ein IT Service be-steht aus einer Kombination von Personen, Prozessen und Technologie und soll-te in einem Service Level Agreement definiert werden.“

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


124

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ßgebli-chen Output wahr. Die damit verbundenen IT Service Management-Pro-zesse sind in der Regel eine interne Betrachtung der IT-Organisation.

Die Kunden- und Geschäftssicht ist bei der Definition der notwendigen IT-Unter-stü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 Requi-rements (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 Pro-zess, in dem die Kundenanforderungen auf die zu erbringende Service-qualitä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 Vereinba-rung 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) ab-geschlossen. 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, Ser-vice Level Agreement (SLA), Operational Level Agreement (OLA) und Underpinning Contract (UC) dem Prozess des Service Level Managements zugewiesen.


125

COBIT nimmt bei der Definition von Control Objectives und Leistungsin-dikatoren (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 Rahmenbe-dingungen 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 not-wendigen Inhalten von SLAs. Diese Inhalte werden in Abschnitt 2.8.5 be-schrieben.

Die ITIL Best Practices und die ISO 20000-2 enthalten Empfehlungen für die in-haltliche 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 Kun-de ist der Auftraggeber des IT Service. Der IT-Provider ist der für die Be-reitstellung 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 sicher-stellen 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 Bei-spiel für einen IT Service „Gehaltsabrechnung“ die Anforderungen an die Verfügbarkeit in einzelne OLAs und UCs einfließen könnten.

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


126

SLA „Gehaltsabrechnung“

Leistungsgegenstand: „Beschreibung der Funktionalität des IT-Service“

Leistungsumfang: „SAP-HR inkl. Lizenzen für 25 Benutzer, Support und Anpassungen“

Servicezeit: gem. Betriebskalender7: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

OLA „HR / Server“

Leistungsgegenstand: „Bereitstellung Server für Modul SAP-HR“

Verfügbarkeit: 99,8% p.W.

OLA „HR / LAN“

Leistungsgegenstand: „Bereitstellung LAN“


UC „HR / WAN“

Leistungsgegenstand: „Anbindung Niederlassung X“


SLA „Gehaltsabrechnung“

Leistungsgegenstand: „Beschreibung der Funktionalität des IT-Service“

Leistungsumfang: „SAP-HR inkl. Lizenzen für 25 Benutzer, Support und Anpassungen“

Servicezeit: gem. Betriebskalender7: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

OLA „HR / Server“

Leistungsgegenstand: „Bereitstellung Server für Modul SAP-HR“


OLA „HR / LAN“

Leistungsgegenstand: „Bereitstellung LAN“


UC „HR / WAN“

Leistungsgegenstand: „Anbindung Niederlassung X“

Verfügbarkeit: 99,4% p.W. Abbildung 44: Zusammenhang zwischen SLAs, OLAs und UCs

2.8.4 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 her-aus: „... es ist nicht leicht, generelle Aussagen zu machen, da jede Situation ein-zigartig ist.“ (vgl. [OGC, 2006b]). Vor dem Aufbau und der inhaltlichen Gestaltung von SLAs gilt es zu-nächst, die bestehenden Kundenanforderungen aufzunehmen sowie das existierende Leistungsportfolio, also die bestehenden IT Services, zu erfas-sen und zu strukturieren (vgl. [Victor et al., 2005]). Erst im Anschluss, das heißt wenn die Strukturierung der IT Services vor-liegt, 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üs-sen sich daher über (bestehende) organisatorische und systemtechnische Grenzen innerhalb der IT-Organisation hinwegsetzen.

Die Struktur der SLAs ist unterneh-mensspezi-fisch.

IT Services werden sys-tem- und or-ganisations-übergreifend erbracht.


127

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 Ser-vice 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 SLA-Struktur 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 Aufwen-dungen für die Aktualisierung und die Reduzierung von Inkonsistenzen.

- Unternehmens-Ebene:- Unternehmensweite SLA-

Vereinbarungen- Allgemeine Definitionen

und Regelungen zum Monitoring

- Kunden-Ebene:- Kundenbezogene SLA-

Vereinbarungen

- Unterstes Level:- Servicebezogene SLA-

Vereinbarungen- Ausgestaltung des auf

Unternehmens-Ebene definierten Monitoring

- Unternehmens-Ebene:- Unternehmensweite SLA-

Vereinbarungen- Allgemeine Definitionen

und Regelungen zum Monitoring

- Kunden-Ebene:- Kundenbezogene SLA-

Vereinbarungen

- Unterstes Level:- Servicebezogene SLA-

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

SLA-Struk-turen reduzie-ren Aufwen-dungen.


128

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 Ser-vices zu vereinbaren. Bei mehrschichtigen SLAs können auf der obersten Ebene, der Unterneh-mens-Ebene, allgemeine Regelungen für das Monitoring und Reporting der IT Services vereinbart werden. So kann zum Beispiel beschrieben wer-den, 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 wer-den. Dies reduziert nicht die Aufwendungen für die konkreten Messungen, stellt aber die Vergleichbarkeit der einzelnen IT Services sicher.

2.8.5 Die Inhalte von SLAs

2.8.5.1 Vorgaben / Empfehlungen der ISO 20000 Die ISO 20000-1 beschreibt die Mindestanforderungen an die Dokumenta-tion von IT Services mittels SLAs. So fordert die ISO 20000-1: „Der gesamte Umfang der gelieferten Services mit den zugehörigen Service Levels und Aus-lastungs-Kriterien müssen zwischen den Parteien vereinbart und aufgezeichnet werden“ oder „Jeder gelieferte Service muss in einem oder mehreren SLAs defi-niert, 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 Ma-nagements.

Innerhalb der ISO 20000-2 wird dagegen auf die inhaltliche Gestaltung der notwendigen Dokumente eingegangen. So sind Best Practices zum Ser-vicekatalog und ein Leitfaden für die inhaltliche Gestaltung der SLAs do-kumentiert. Im Zusammenspiel zwischen Servicekatalog und SLA emp-fiehlt die ISO 20000-2, eine Referenzierung vom SLA zum Servicekatalog aufzubauen.

Messwerk-zeuge und einheitliche Messverfah-ren sollten einheitlich vorgegeben werden.

Service Level und Auslas-tungs-Krite-rien sind zu vereinbaren und aufzu-zeichnen.


129

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, Problembehe-bungen, 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 verein-

barte 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) umzu-setzen.

Die ISO 20000-2 beinhaltet die Definition von „Service Level-Zielen“ (Ser-vice 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.


130

Die Einhaltung von Service Level und SLAs wird mittels vereinbarter Service-Ziele definiert, überwacht und berichtet.

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 Be-griffe wie „Buchungsvorgänge“ und „Anzahl gespeicherter Artikel“ ver-wendet werden. Messgrößen wie „CPU-Auslastung“ oder „Datenbankgrö-ße“ entsprechen dagegen in der Regel nicht der Kundenperspektive und sind zu vermeiden. 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 Erfah-rungen 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 as-pects 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 weitestge-hend 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

Service-Ziele sind aus der Kundenper-spektive zu definieren.

Konzentration auf die we-sentlichen Service Level


131

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

terungen, 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-Unterbrechun-

gen oder als MTBF (Mean Time Between Failures) bzw. als MTBSI (Mean Time Between System Incidents) ausge-drückt

– Support - Support-Zeiten (sofern diese nicht mit den Service-Zeiten

identisch sind) - Vereinbarungen für die Anforderung von Support-Erwei-

terungen, 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 Transakti-onen, die Anzahl der gleichzeitig aktiven Anwender)

– Antwortzeitverhalten - Zielvorgaben für durchschnittliche oder maximale Ant-

wortzeiten 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


132

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

wortungen des Kunden (zum Beispiel Backup von nicht angebundenen PCs, Passwort-Änderungen)

- Einzelheiten zu verminderten oder geänderten Service-Zielen für den Katastrophenfall (falls kein separates SLA für solche Situationen existiert)

– Leistungsverrechnung - Einzelheiten zum Verteilungsschlüssel und zu den Zeit-

räumen der Leistungsverrechnung (sofern die Leistungen in Rechnung gestellt werden)

– Service-Berichte und Reviews - Der Inhalt, die Häufigkeit und Verteilung der Service-Be-

richte - 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 be-richten.

Um das Monitoring der SLAs, OLAs und UCs sicherzustellen, müssen sämtliche beschriebenen Service Level messbar sein (siehe Abschnitt


133

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 resultieren-den Anforderungen an die Messbarkeit zu verstehen, erfolgt hier noch-mals die Darstellung der Kundensicht auf den IT Service. Der Kunde be-nö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 PC-Arbeitsplatz? 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äu-tern 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

Service Level sind dort zu messen, wo der Service wahrgenom-men wird.


134

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än-dern. Das Monitoring und Reporting der Service Level und der Nachweis der Einhaltung der Service-Ziele tragen zur Steigerung der Kundenzufrie-denheit bei.

Das Monitoring und das Reporting der Service Level und der eingehaltenen Ser-vice-Ziele muss im Eigeninteresse des IT Service Providers liegen. Daher sind die SLAs, OLAs und UCs eindeutig zu formulieren, dürfen keine mehrdeutigen In-terpretationen zulassen und sind gegenüber den festgelegten Service-Zielen zu messen.

In der ISO 20000-1 wird aber nicht nur verlangt, dass die Service Level zu messen und gegenüber den Service-Zielen zu berichten sind, sondern die Forderung wird fortgeführt: „…showing both current and trend information. The reasons for non-conformance shall be reported and reviewed.” (vgl. [ISO 20000-1, 2005]). Aus dieser Empfehlung ergeben sich weitere Anforderungen an die Auf-zeichnung 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 an-hand 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 Be-wertung der Ursachen für die Nichterreichung (d.h. Unterschreitung) der festge-legten Service-Ziele.

Die ISO 20000 verlangt auch die Darstel-lung von Trends.

2.9 Integrationsinstrument: Balanced Scorecard

135

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 Ge-schäftsprozesse einer Organisation. Sie stellen die Außensicht auf die IT-Organisation dar. Das Kundeninteresse besteht in der Einhaltung der zu-gesicherten 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 defi-nierten Service Level und der Auslegungskriterien. Die Einhaltung dieser Krite-rien 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 defi-nierten 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 Scorecard6 ist nicht nur ein Messsystem, sondern vielmehr ein exzellentes Management- und Steuerungssystem. Sie kann in unterschiedlichen Unternehmensbereichen eingesetzt werden. Nach unse-rer Erfahrung eignet sie sich besonders gut als Management- und Repor-ting-Instrument für IT-Organisationen bzw. deren Bereiche. Wir verwenden die Balanced Scorecard als Integrationsinstrument, das in der Lage ist, Kennzahlen aus unterschiedlichen Systemen zusammenzu-führen, zu verknüpfen und für entsprechende Adressatenkreise geeignet darzustellen. In den Projekten, die wir in IT-Organisationen unterschiedli-cher 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“.

Die Balanced Scorecard ist ein Kennzah-len- und Management-System.


136

damit nicht nur das operative IT-Geschäft, sondern insbesondere die stra-tegische Ausrichtung der IT-Organisation bis hin zum IT-Marketing in der Balance.

2.9.1 Kernideen Die Kernideen der Arbeiten von Robert S. Kaplan und David P. Norton sind einfach und faszinierend. Liest man die ersten Seiten aus [Kaplan et al., 1996], fällt es schwer, das Buch zur Seite zu legen. -- Zitatanfang -- „Imagine entering the cockpit of a modern jet airplane and seeing only a single instrument there. How would you feel about boarding the plane after the following conversation with the pilot?

– Question: I’m surprised to see you are operating the plane with only a single instrument. What does it measure?

– Answer: Air speed. I’m really working on air speed this flight. – Question: That’s good. Air speed certainly seems important. But

what about altitude. Wouldn’t an altimeter be helpful? – Answer: I worked on altitude for the last few flights and I’ve gotten

pretty good on it. Now I have to concentrate on proper air speed. – Question: But I noticed you don’t even have a fuel gauge. Wouldn’t

that be useful? – Answer: You are right: fuel is significant, but I can’t concentrate on

doing too many things well at the same time. So, on this flight I’m concentrating on air speed.”

-- Zitatende -- Die Frage, ob man nach diesem Gespräch hier mitfliegen würde, lässt sich leicht beantworten: Unabhängig vom Können des Piloten und unabhängig von der Qualität des Flugzeugs bleibt der fade Nachgeschmack, dass eine einzige Kennzahl, 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 tra-dierten strategischen Unternehmensführung, die sich im Wesentlichen an finanziellen Kennzahlen (z.B. Return on Investment oder Eigenkapitalren-tabilität) orientiert. Diese Kennzahlen werden als eindimensional und vergangenheitsorientiert kritisiert. Sie würden außerdem zu einer kurzfris-tig orientierten Investitionspolitik führen, da Zukunftsmaßnahmen, z.B. im Bereich Forschung und Entwicklung, sich kurzfristig in der Erfolgsrech-nung nur auf der Kostenseite niederschlagen. Die Balanced Scorecard in der von Kaplan und Norton vorgestellten Form


137

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 ver-schiedenen Blickwinkeln beleuchtet und bewertet.

Die von Kaplan und Norton vorgeschlagene Balanced Scorecard ist 4-dimensio-nal. Sie enthält die 4 Perspektiven: Finanzen, Kunden, Prozesse7 und Potenziale8.

Neben der Mehrdimensionalität des Zielsystems basiert die Balanced Sco-recard auf einer weiteren Idee, die sich leicht im täglichen Leben wieder-finden lässt. Der Begriff „balanced“ sagt aus, dass die Perspektiven ausge-glichen 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 Score-card nur dann Sinn macht, wenn die einzelnen Komponenten richtig auf-einander abgestimmt sind. Nach dem Prinzip der Balanced Scorecard macht es keinen Sinn, eine Per-spektive in den Vordergrund zu schieben und dafür andere zu vernachläs-sigen. Es handelt sich um ein Zielsystem, in dem die Mehrdimensionalität nicht nur als Option enthalten ist, sondern explizit gefordert und garan-tiert wird.

Wendet man die Balanced Scorecard auf den IT-Bereich an, so hat dies eine gra-vierende 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 mit-tel- 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 langfris-tigen 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.

Die Balanced Scorecard ist ein mehrdi-mensionales und ausgewo-genes Ziel-system.

Es geht nicht um kurzfristi-ge Gewinne sondern um Kontinuität.


138

Wichtigstes Ziel der Balanced Scorecard ist die Umsetzung von Unterneh-menszielen auf allen Ebenen. Dies wird dadurch erreicht, dass sich, ausge-hend 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.

Visionund

Strategie

Kundenperspektive

Ziel Kenn-zahl

Vor-gabe

Maß-nahme

Prozessperspektive

Ziel Kenn-zahl

Vor-gabe

Maß-nahme

Finanzperspektive

Ziel Kenn-zahl

Vor-gabe

Maß-nahme

Protenzialperspektive

Ziel Kenn-zahl

Vor-gabe

Maß-nahme

Visionund

Strategie

Kundenperspektive

Ziel Kenn-zahl

Vor-gabe

Maß-nahme

Kundenperspektive

Ziel Kenn-zahl

Vor-gabe

Maß-nahme

Prozessperspektive

Ziel Kenn-zahl

Vor-gabe

Maß-nahme

Prozessperspektive

Ziel Kenn-zahl

Vor-gabe

Maß-nahme

Finanzperspektive

Ziel Kenn-zahl

Vor-gabe

Maß-nahme

Finanzperspektive

Ziel Kenn-zahl

Vor-gabe

Maß-nahme

Protenzialperspektive

Ziel Kenn-zahl

Vor-gabe

Maß-nahme

Abbildung 46: Allgemeine Balanced Scorecard

Um den Kern von Vision und Strategie ranken sich vier Betrachtungswei-sen (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 Kun-den auftreten, um seine Vision zu verwirklichen?

Die Balanced Scorecard ist ein top down-Instrument zur Strategie-umsetzung.


139

– 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 Unter-nehmen Veränderungs- und Wachstumspotenziale fördern, um sei-ne 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 Teilaufga-ben 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 Un-

ternehmens ab.


140

Finanzperspektive

Prozessperspektive

Kundenperspektive

Potentialperspektive

Finanzielles Ergebnis(Gewinn, Rentabilität, ...)

Kunden-zufriedenheit

Kosten derProzesse

Kundentreue

Qualität derProzesse

Geschwindigkeitder Prozesse

QualifizierteMitarbeiter

MotivierteMitarbeiter

Finanzperspektive

Prozessperspektive

Kundenperspektive

Potentialperspektive

Finanzielles Ergebnis(Gewinn, Rentabilität, ...)

Kunden-zufriedenheit

Kosten derProzesse

Kundentreue

Qualität derProzesse

Geschwindigkeitder Prozesse

QualifizierteMitarbeiter

MotivierteMitarbeiter

Abbildung 47: Ursache-Wirkungskette

Strategien

Unternehmensziele

operative Umsetzung

Erfolgskontrolle

Kunden-perspektive

Lern- & Entwick-lungsperspektive

interne Prozess-perspektive

Finanz-perspektive

Strategien

Unternehmensziele

operative Umsetzung

Erfolgskontrolle

Kunden-perspektive

Lern- & Entwick-lungsperspektive

interne Prozess-perspektive

Finanz-perspektive

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.


141

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 in-zwischen weitgehend akzeptiert. Der Nutzen im Hinblick auf Perfor-mance-Steigerung und Strategie-Überprüfung liegt auf der Hand. Es geht darum, die IT-Organisation als Ganzes über ihre verschiedenen Funktio-nen hinweg zu steuern. Es geht darum, dass dies konform mit der IT-Strategie geschieht und darum, dass diese aus der Geschäftsstrategie abge-leitet 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öp-fung 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 Pro-zessmodell dem Ziel der Vereinheitlichung von IT Service-Prozessen10 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 im-

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


142

Die Grundidee von ITIL V3 ist richtig und bestätigt unsere Arbeiten in vielen Projekten, in denen es darum ging, Kennzahlensysteme zur Steue-rung und zum Reporting einzusetzen:

Es gibt viele Möglichkeiten, Perspektiven für eine IT Balanced Scorecard zu defi-nieren.

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 Sco-recard 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 De-tails ein, sondern geben das Ergebnis in Form einer Tabelle an (siehe fol-gende Seite, in Anlehnung an [Bung, 2006], Seite 27). Die Gegenüberstellung der verschiedenen Ansätze zeigt, dass es schwer-fällt, einen allgemein gültigen Ansatz zur Strukturierung der Perspektiven einer Balanced Scorecard anzugeben. Es fällt auf, dass es keinen Sprach-standard gibt. Möchte man in der Praxis eine Balanced Scorecard für den IT-Bereich ent-wickeln11, so bietet es sich an, das Beste aus allen Welten zu nehmen. Dies verdeutlichen wir später in unserem Kennzahlenmodell und in den Pra-xisbeispielen.

11 Wir sprechen hier immer von einer (!) Balanced Scorecard, um den Sprach-

gebrauch einfach zu halten. Für IT-Bereiche können auch mehrere Balanced Scorecards existieren, die gegebenenfalls zusammenhängen.


143

Entwicklungsstufen zur IT Balanced Scorecard

Ansatz von

Perspektiven Jahr Anmerkung

Kaplan und Norton

– Finanzen – Kunden – Geschäftsprozesse – Lernen u. Entwicklung

1996 Kein expliziter Bezug zur IT.

Van Grem-bergen und Saull

– Beitrag zum Kernge-schäft

– Kundenorientierung – Operative Leistungen – Zukunftsorientierung

2001 Die Kundenorientierung wird beibehalten, drei neue Perspektiven wer-den vorgeschlagen, insb. die Bestimmung des Added Values der IT.

Kütz – Finanzmanagement – Kundenmanagement – Prozess-Management – Innovationsmanagement – Mitarbeitermanagement – Lieferantenmanagement

2003 Zusätzlich wird die Lie-ferantenperspektive eingeführt. Die Potenzi-alperspektive wird in Mitarbeiter- und Innova-tionsmanagement aufge-teilt.

Wiggers, Kok und de Boer-de Wit

– Finanzen – Kunden – Geschäftsprozesse – Lernen u. Entwicklung

2004 Enthält die gleichen Perspektiven wie Kaplan et al., diese werden aller-dings inhaltlich an die IT angepasst.

Schmid-Klee-mann

– Unternehmensbeitrag – Kunden – IT-Leistungserstellung – IT-Einsatz – Zukunft

2004 Auch hier der Versuch, den Wertbeitrag der IT zu bestimmen. Die Zu-kunftsperspektive und der IT-Einsatz leiten sich aus der Potenzialper-spektive ab.

ITIL 2 und ITIL V3

– Finanzen – Kunden – Interne Prozesse – Innovation (bzw. Lernen

und Entwicklung)

2000 und 2007

4 Perspektiven, die mit denen der Original BSC übereinstimmen. Die Beschreibung der Per-spektiven ist in V 3 we-sentlich differenzierter als in V 2.


144

2.10 Konsequenzen Die Auswahl der „richtigen“ Kennzahlen ist in der Praxis ein schwieriger und mehrstufiger Prozess. Die Fragestellung, welcher Ansatz12 der geeig-nete 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ön-nen, um das bestmögliche durchgängige Kennzahlensystem für die jewei-lige Organisation aufzubauen. ITIL führt hierzu aus (Service Strategy [OGC, 2007a]):

Ein wirkungsvolles IT Service Management entsteht durch die Nutzung von Best Practices (Standards) und deren Ausrichtung an den spezifischen Fähigkeiten der eigenen Organisation.

Kennzahlen (KGIs und KPIs) und der Aufbau eines Kennzahlensystems sind kein Selbstzweck. Die Kennzahlen sind nicht zu definieren und zu berichten, weil COBIT und ITIL entsprechende KPIs bzw. KGIs beinhalten. Es geht auch nicht darum, diese Kennzahlen zu definieren, weil es die ISO 20000 verlangt. COBIT und ITIL empfehlen bzw. die ISO 20000 ver-langt vielmehr die Definition von Kennzahlen für jeden IT Service Mana-gement-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 verste-hen 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 notwen-dige Definition ergänzender und anderer Kennzahlen muss immer in Be-zug auf die spezifischen Prozess-Ziele einer IT-Organisation erfolgen.

12 Beispielsweise ITIL oder COBIT, aber auch andere.

Kennzahlen sind für ein wirksames Prozess-Management unabdingbar.

2.10 Konsequenzen

145

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 dokumen-tierten KPIs und KGIs zu berücksichtigen. Sie sollten aber grundsätzlich hin-sichtlich ihrer Anwendbarkeit für die jeweilige IT-Organisation bzw. für die Pro-zessziele kritisch hinterfragt und nicht ungeprüft übernommen werden. Bei Be-darf ist die Definition abweichender oder zusätzlicher Kennzahlen notwendig.

Bei der Definition von KGIs und KPIs ist auch zu prüfen, ob die notwendi-gen Informationen vorliegen, mit welchem Aufwand die Kennzahlen ge-wonnen 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 Be-trachtungsbereiche 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 Kennzahlen-system.

ITIL, ISO 20000 und COBIT sind als Bausteine für ein übergreifendes Steuerungs-system 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.

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


146

ITIL ISO 20000 COBIT IT-BSC

Prozessbe-schrei-bung

Detaillierte (generische) Prozessbe-schreibungen

Enthält keine Prozessbe-schreibungen, sondern Min-destanforde-rungen an die ITSM-Prozesse

Enthält keine detail-lierten Pro-zess-beschrei-bungen

Enthält keine Prozessbe-schreibungen

Bekannt-heitsgrad

Seit Mitte der 80er Jahre nachhaltig steigende Bekanntheit und Beliebtheit

Erfährt zuneh-mende Bedeu-tung, insbeson-dere für IT Service Provi-der

Bekannt-heitsgrad weiter stei-gend, insbe-sondere durch SOX

Bekanntheits-grad weiter steigend

Anerken-nung

ITIL Zertifizie-rung relevant bei Stellenbe-setzung; noch verlangte „ITIL-Konfor-mität“ wird durch ISO 20000 abgelöst

Als internatio-naler Standard weltweit aner-kannt, einzige Möglichkeit einer Zertifi-zierung

In den USA bei Wirt-schaftsprü-fern weit verbreitet und zuneh-mend auch in Europa

Weltweit aner-kannter Ma-nagement-ansatz zur Strategieum-setzung

Templates Enthält Best Practices für SLA, RfC, Incident-Record etc.

Enthält Best Practices für SLA-Inhalte

Enthält Best Practices für IT-Prozesse

Enthält Best Practices für Kennzahlen-systeme

Kennzah-len

Schwache generische Beschreibung der Prozess-Kennzahlen

Enthält Anfor-derungen an Vorhandensein von Kennzah-len, gibt keine vor

Kennzahlen (-systematik) auch in der Praxis effek-tiv

Integrations-werkzeug für Kennzahlen

Eine IT Balanced Scorecard kann ver-schiedene Ansätze integrieren.

147

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 Manage-ment. In diesem Kapitel nun werden die damit verbundenen Anforderun-gen und Voraussetzungen an das Prozess-Management beschrieben. Von wesentlicher Bedeutung ist dabei die Verankerung des Service Mana-gements 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 Be-rücksichtigung finden können.

3.2 PDCA-Zyklus ITIL Version 3 geht innerhalb der Publikation „Continual Service Improve-ment“ explizit auf ein Regelsystem zur kontinuierlichen Verbesserung von Prozessen und Services ein. Normen, wie die ISO 20000 „IT Service Mana-gement“, 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 Ma-nagementlehren des amerikanischen Wissenschaftlers W. Edwards De-ming13 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


148

her wird der PDCA-Zyklus gelegentlich auch als „Shewhart-Zyklus” be-zeichnet (siehe Abbildung 49).

Check Überprüfen

DoAusführen

ActVerbessern

PlanPlanen

StändigeVerbesserung

Check Überprüfen

DoAusführen

ActVerbessern

PlanPlanen

StändigeVerbesserung

Abbildung 49: PDCA-Zyklus

Der PDCA-Zyklus basiert auf einem prozessorientierten Managementan-satz, der aus den folgenden Phasen besteht (vgl. [ISO 20000-1, 2005]):

– Plan (Planen): Die Phase dient der Einführung der Prozesse und der damit ver-bundenen 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

3.2 PDCA-Zyklus

149

einzelnen Prozess-/Service-Zielen und Anforderungen, sowie zur Berichterstattung der Ergebnisse.

– Act (Verbessern): Liegen Ergebnisse aus der Überprüfung vor, so sind diese zu analy-sieren und geeignete Maßnahmen zu ergreifen, um die Leistungs-fähigkeit der Prozesse nachhaltig zu verbessern.

Diese identifizierten Verbesserungen finden wiederum Eingang in „Plan“. Dadurch ist kontinuierliche Verbesserung sichergestellt. Prozess-Manage-ment 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, wel-ches 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 Pro-zessverbesserung 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 Pro-zess-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 Management-Prozessen.

Es muss zum Selbstverständnis des Service Managers, Process Owners und Pro-zess-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.


150

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 gewon-nen werden können, sind die IT Service Management-Prozesse in der Or-ganisation zu verankern. Dazu ist es nicht ausreichend, einzelne in den ITIL Best Practices doku-mentierten Aktivitäten umzusetzen oder ausgewählte Control Objectives aus COBIT sicherzustellen. Vielmehr müssen die Prozesse mit einem Pro-zess-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üh-rung der IT Service Management-Prozesse ein äußerst kritischer Erfolgs-faktor. In der Regel sind die bestehenden IT-Organisationen hierarchisch struktu-riert, wobei sich deren Struktur stark an den eingesetzten Hardware-Syste-men bzw. an Software/Applikationen orientiert. So gibt es Organisations-bereiche, die das LAN, die Datenbanken, die Applikationen oder die Si-cherheitskomponenten planen, implementieren und betreuen. Diese Struk-tur ist historisch gewachsen und hat sich durch die stetig steigende Kom-plexität der eingesetzten IT-Komponenten ergeben. Der Einsatz der IT-Komponenten setzt entsprechendes Spezialwissen der IT-Mitarbeiter vor-aus. Zum wirkungsvollen Management dieser Spezialisten werden die IT-Mitarbeiter 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 IT-Organisationen etabliert. Wie im vorhergehenden Kapitel bereits ausge-führt, werden unter dem IT Service ein oder mehrere IT-Systeme verstan-den, 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 organisati-onsü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.

Bestehende Strukturen in der IT orien-tieren sich an den eingesetz-ten Kompo-nenten.

3.3 Etablierung des Prozess-Managements

151

Mit dem fortschreitenden Out-Tasking wird das notwendige Spezialwis-sen 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ün-den 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 zuver-lässige Bereitstellung der Outputs erforderlich sind. Ein Prozess kann den An-forderungen entsprechend Richtlinien, Standards, Leitlinien, Aktivitäten und Arbeitsanweisungen definieren.“

Am Beispiel des Incident Managements soll diese Begriffsdefinition veran-schaulicht 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 abge-schlossene 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 Spe-zialwissen übernommen wird. Dies hat zur Konsequenz, dass die IT-Prozesse organisationsübergreifend durchgeführt werden.


152

IT-Prozesse durchdringen die gesamte IT-Organisation, schließen gegebenenfalls externe Lieferanten ein und enden demzufolge nicht an bestehenden organisato-rischen Grenzen.

Die mögliche Bearbeitung eines Incidents könnte wie folgt abgewickelt werden (Abbildung 50):

Organisation und EDV

Daten undSysteme

Netze undKommunikation

ServersystemeClient Systeme Datenbanken LAN WAN

Incident

Service Desk

ExternerOnsite Support


Daten undSysteme



Incident

Service Desk


Abbildung 50: Exemplarische Darstellung der Bearbeitung eines Incidents

In dem abgebildeten Beispiel wird der Incident dem „Service Desk“ ge-meldet 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 „ex-ternen Onsite Support“ mit deren Behebung. Nach der erfolgten Behebung wird der „Service Desk“ entsprechend informiert. Dieses Beispiel einer einfachen Bearbeitung im Incident Management ver-deutlicht, dass die IT-Prozesse die gesamte IT-Ogranisation durchdringen und zum Teil externe Lieferanten sowie Kunden einbeziehen.


153

Die Aufgabe des Prozess-Managements ist es, sicherzustellen, dass der Prozess die definierten Ziele erfüllt. Hierzu definiert ITIL die Prozesssteu-erung 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 Pro-zessdurchführung liegt beim Prozess-Management des jeweiligen Prozes-ses. 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ässli-che Prozesse. Das führt dazu, dass die bestehende hierarchische IT-Organisation querschnittlich von IT-Prozessen durchdrungen wird (Abbildung 51).


Daten undSysteme



Service Desk


Incident Management

Problem Management

Change Management

Release Management

…


Capacity Management

Security Management


Daten undSysteme



Service Desk


Incident Management

Problem Management

Change Management

Release Management

…


Capacity Management

Security Management Abbildung 51: IT-Prozesse und bestehende Aufbauorganisation


154

Damit ergibt sich letztendlich eine Matrixorganisation mit den bekannten strukturellen Problemen. Die Mitarbeiter sind einerseits einer Linienorga-nisation zugehörig und unterstellt, andererseits haben sie Aktivitäten in-nerhalb 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 jeweili-gen 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 Linien-organisation 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ände-rungsmanagement und die aktive Beteiligung der „Betroffenen“, so wer-den die IT Service Management-Prozesse nicht wirkungsvoll sein. Die notwendige und als Ziel gesetzte Transparenz hinsichtlich der Leistungs-fähigkeit und des Optimierungspotenzials der Prozesse und der IT Servi-ces 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 letzt-endlich wenig zielführend sein. So wie ein Veränderungsmanagement und die Überzeugung notwendig sind, so muss aber andererseits auch sichergestellt werden, dass die festge-legten 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 Konse-quenzen gehört zur Managementverantwortung. Im Einzelfall kann es durchaus vorkommen, dass vom Prozess abwei-chend 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-


155

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 hierarchi-schen Organisationsstruktur betrieben werden kann, sind die Verantwort-lichkeiten eindeutig zu definieren. Diese Definition betrifft einerseits die Abgrenzung zwischen der Linien- und Prozessverantwortung. Anderer-seits sind auch für das IT Service Management die Verantwortlichkeiten festzulegen. Dazu sind die wahrzunehmenden Rollen im Prozess-Management 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 be-stehende Begriffsdefinitionen bzw. die hier dokumentierten Rollenbe-zeichnungen anzupassen sind. Analog zu den ITIL Best Practices stellen die folgenden Rollenschreibun-gen Empfehlungen dar, deren Umsetzung von der jeweiligen Situation abhängig ist. So wird eine kleine IT-Organisation nicht einen Prozess-Manager 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 beschrie-ben. In einigen Textpassagen wurde zwar auf einen Service Manager hin-gewiesen, 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-


156

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 („se-nior 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 Prozess-Managern vorgesetzte Instanz gibt und diese dem oberen Management angehört. Das IT Service Management und die damit verbundenen Prozesse dienen keinem Selbstzweck, sondern sind in die IT-Planung und -Strategie einzu-binden. Letztendlich leiten sich die konkrete Ausrichtung der Prozesse und ihre Zielsetzung aus den Business-Anforderungen und der IT-Strategie ab. Dabei kann sich die konkrete Ausprägung in Abhängigkeit von den aktu-ellen 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 Anforderun-gen im Hinblick auf Kapazitäten und Performance auf wirtschaftliche Weise er-füllt werden ...“. Befindet sich eine Organisation in einer starken Wachs-tumsphase, 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 Bereitstel-lung in der Regel ein größeres Gewicht. Die grundsätzliche Zielsetzung an ein Capacity Management ändert sich zwar nicht, aber die konkrete Aus-gestaltung 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 Auswir-kungen auf das Kennzahlensystem haben. Diese Vorgaben werden vom oberen Management getroffen und liegen in der Verantwortung des Servi-ce Managers. Eine weitere Aufgabe des Service Managers besteht darin, eine Eskalati-onsebene für die Process Owner und Prozess-Manager zu bieten, da die einzelnen IT Service Management-Prozesse durchaus konkurrierende Zie-le 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 Aufgabenstel-lung nur zum Teil. Während die Tätigkeiten der Architekten und der Bau-


157

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 Ergebnisverant-wortung für den jeweiligen Prozess. Eine Möglichkeit, die Verantwortlichkeiten für Aktivitäten übersichtlich darzustellen, besteht mittels einer RACI-Matrix. Dabei leitet sich der Name aus den vier Verantwortlichkeiten „Responsible“, „Accountable“, „Con-sulted“ und „Informed“ ab. Dabei wird Responsible als Verantwortung für die Durchführung verstanden. Accountable ist dagegen die Person, die die Gesamt- und letztendlich die Ergebnisverantwortung trägt. Bei der Darstellung in Form der RACI-Matrix werden in einer Matrix Rol-len gegenüber Aktivitäten aufgetragen (Abbildung 52). Durch Eintragen der Buchstaben R, A, C und I werden die Aktivitäten den Rollen zugeord-net. Diese Form zur Darstellung der Prozessaktivitäten und Rollen (Funk-tionen innerhalb der Organisation) wird von ITIL und COBIT genutzt. Role Responisibility Change

sponsor, e.g. busi-ness and IT leaders

Change en-abler, e.g. process own-ers, service owners

Change agent, e.g. team leader instructing change

Change target, e.g. individual performing the change

Articulate a vision for the business and service change in their domain

A/R A/R C I

Recognize and handle resistance to change

A/R A A C

Initiate change, under-stand the levers for change and the obstacles

A/R A/R C C

Manage change and input to change plan

A/R A/R C C

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


158

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 Pro-zesses. Zu den Verantwortlichkeiten des Process Owners gehören das Sponsor-ship, das Design, das Change Management sowie die kontinuierliche Verbes-serung 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 mit-hilfe 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 Business-Anforderungen 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 signa-lisieren dem Process Owner, ob die definierten Ziele erreicht werden.

Es hat sich bewährt, dass der Process Owner dem IT-Management ange-hö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 Wider-stände überwinden muss. Hier kann ihm ein Process Owner aus dem IT-Management die notwendige Unterstützung bieten. Außerdem wird da-mit ein wichtiges Signal für alle Mitarbeiter gegeben: „IT Service Manage-ment 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.

Die Defini-tion von Kennzahlen setzt definier-te Prozesszie-le voraus


159

3.3.2.3 Prozess-Manager Die Verantwortung des Prozess-Managers besteht in der erfolgreichen Umsetzung des Prozesses auf Basis der definierten Ziele. Der Prozess-Manager ist für die Durchführung des Prozesses verantwortlich. In der ITIL Version 3 wird die Rolle des Prozess-Managers wie folgt defi-niert (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ön-nen 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ön-nen diese Rollen jedoch separat zugewiesen sein.“

In kleineren IT-Organisationen erfolgt keine Unterteilung zwischen Pro-cess Owner und Prozess-Manager. Die Ergebnis- und Durchführungsver-antwortung wird dann gemeinsam wahrgenommen. Im Rahmen der Durchführungsverantwortung gestaltet der Prozess-Manager den Prozess und definiert die durchführenden Aktivitäten. Er stellt sicher, dass der Prozess mit den notwendigen Ressourcen unterstützt wird. Der Prozess-Manager hat dazu die kritischen Erfolgsfaktoren (CSF: Critical Success Factors) zu identifizieren und durch geeignete Maßnah-men abzusichern (= „Plan“ im PDCA-Zyklus). Mögliche Schwachstellen im Prozess sind vom Prozess-Manager zu analy-sieren und durch geeignete Verbesserungsmaßnahmen nachhaltig zu be-seitigen (= „Act“ im PDCA-Zyklus). Angesichts der Komplexität der Prozesse und der verschiedenen Beteilig-ten in unterschiedlichen Organisationseinheiten benötigt der Prozess-Manager hierzu eine gesicherte Informationsbasis, er benötigt Prozess-kennzahlen (= „Check“ im PDCA-Zyklus). Die Prozess-Kennzahlen sind Indikatoren. Sie informieren über die Zieler-reichung 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.

Kennzahlen sind die Ar-beitsinstru-mente des Prozess-Managers.


160

Die Kennzahlen sind für den Prozess-Manager ein äußerst wichtiges Manage-ment-Werkzeug. Sie signalisieren, was im Prozess passiert und – in Verbindung mit Trenddaten – wie sich der Prozess entwickelt. Nur mit entsprechenden Kennzahlen kann der Prozess-Manager seiner Verantwortung nachkommen.

Um feststellen zu können, warum etwas passiert ist, muss der Prozess-Manager einzelne Kennzahlen in Zusammenhang bringen. Zum Beispiel könnte geprüft werden, ob neue Services eingeführt wurden und damit erklärbar wird, warum die Lösungszeiten den vorgegeben Wert nicht mehr erreichen. Der Prozess-Manager muss hierzu die Einflussfaktoren identifizieren, Zusammenhänge zuordnen und letztendlich die eigentli-chen Ursachen analysieren (= „Check“ im PDCA-Zyklus). Die IT Service Management-Prozesse sind gekennzeichnet durch wechsel-seitige Aktivitäten. Der Prozess-Manager benötigt daher nicht nur das Know-how für seinen eigenen Prozess, sondern muss auch über Grundla-genwissen 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 Generie-rung dieser Kennzahl benötigt demzufolge Informationen aus dem In-cident Management. Hierzu muss der Prozess-Manager über das beschrie-bene 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 Manage-ment-Prozessen. Bei der Gestaltung des Prozesses und der Definition der Kenn-zahlen 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 Aktivi-täten im Prozess durch, die ihrer fachlichen Qualifikation entsprechen. Neben der entsprechenden theoretischen Schulung benötigen die Mitar-beiter auch das Wissen über die konkrete Zielsetzung des Prozesses. Hier-zu empfiehlt es sich, zunächst auch die Prozess-Mitarbeiter in den ITIL Grundlagen zu schulen und anschließend die Prozessschulungen durch-zuführen.

3.4 Definition der Prozessziele und -Kennzahlen

161

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 erziel-ten 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. Insbe-sondere sollte dem Betriebs- bzw. Personalrat dargelegt werden, dass das System der Beurteilung von Prozessen dient und nicht der Beurteilung von Mitarbeitern.


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 Fol-genden 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-Zertifizie-rung empfiehlt es sich jedoch generell, diese Vorgehensweise bei der Ein-führung von IT Service Management-Prozessen zu nutzen. Diese Vorgehensweise entspricht auch der ITIL Version 3 mit dem be-schriebenen Service Lifecycle und der „Service Strategy“ als Mittelpunkt bzw. Ausgangspunkt des Service Lifecycle.

Kennzahlen sind informa-tions- und/ oder mitbe-stimmungs-pflichtig


162

Die hier beschriebene Vorgehensweise stellt sicher, dass die IT Service Manage-ment-Prozesse den Geschäftsanforderungen entsprechen, in die IT-Strategie ein-gebunden sind und die definierten Ziele mit endlichen Ressourcen wirkungsvoll erreicht werden können.

Die Kennzahlen und deren Zielwerte sind unmittelbar mit den Prozesszie-len 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 zu-vor 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 An-forderungen aus den Geschäftsprozessen beziehen sich in erster Linie auf die bereitzustellenden IT Services. In der Regel liegen die damit verbunde-nen (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 Vereinba-rungen sicherzustellen. Wie diese Bereitstellung bestmöglich erfolgt, über-lässt der Kunde der IT-Organisation, in deren Verantwortung die entspre-chende 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 jewei-ligen Service Level sowie die Kapazitätsanforderungen zu messen, zu be-richten und regelmäßigen Reviews zu unterziehen.


163

Service Level(Ziele)

Kapazitäten

Messung IT-Services

Business-Anforderungen

SLA(OLA/UC)

Business


Kapazitäten

Messung IT-Services


SLA(OLA/UC)

BusinessBusiness

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 dokumen-tieren. Betreffen diese Verbesserungsmaßnahmen die implementieren IT Service Management-Prozesse, so werden sie im Prozess Improvement-Plan (PIP) des jeweiligen Prozesses dokumentiert (siehe Abbildung 54). In der ISO 20000 werden zwar Reviews in den Prozessen und deren Doku-mentation gefordert, aber nicht näher spezifiziert, wo diese Dokumenta-tion zu erfolgen hat. In der Projektpraxis hat sich herausgestellt, dass der SIP hierfür wenig geeignet ist, da hier eine Vermischung von Informatio-nen erfolgt. Für die Dokumentation sind daher die PIPs zu definieren. Dieses Konzept wurde erstmalig erfolgreich bei der ISO 20000-Zertifizie-rung der badenIT umgesetzt und wird im Folgenden vorgestellt.


164


Kapazitäten

ServiceImprovement

Plan(SIP)Verbesserungs-

potenzial

Messung IT-Services


ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

Business


Kapazitäten

ServiceImprovement


potenzial

Messung IT-Services


ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

BusinessBusiness

Abbildung 54: Definition der IT Services – Service Improvement-Plan

Bei Kunden-Anforderungen an neue IT Services und bei veränderten An-forderungen 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 verbun-denen Prozessaktivitäten anzupassen sind. Außer den Anforderungen an die IT Services gibt es weitere übergeord-nete 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, nach-gewiesen durch die ISO 20000-Zertifizierung. Als zweiter Block stehen die regulativen Anforderungen (Compliance Anforderungen) wie zum Bei-spiel SOX, Euro SOX, Basel II oder GXP für Unternehmen in der Pharma-Branche. Diese Anforderungen haben Auswirkungen auf die IT Service Manage-ment-Prozesse, deren Zielsetzung und letztendlich auf die damit verbun-denen Kennzahlen.


165


Kapazitäten

ServiceImprovement


potenzial

MessungNeue oder veränderte IT-Services

IT-Services


ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

Business


Kapazitäten

ServiceImprovement


potenzial


IT-Services


ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

BusinessBusiness

Abbildung 55: Definition der Prozessziele – Neue Services


Kapazitäten

ServiceImprovement


potenzial



IT-Services



ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

Business


Kapazitäten

ServiceImprovement


potenzial



IT-Services



ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

BusinessBusiness

Abbildung 56: Definition der Prozessziele – Kundenanforderungen


166

Auf Basis der geschäftspolitischen Ziele des Unternehmens, die größten-teils 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.


Kapazitäten

ServiceImprovement


potenzial



IT-Services



IT-Strategie

ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

Business


Kapazitäten

ServiceImprovement


potenzial



IT-Services



IT-Strategie

ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

BusinessBusiness

Abbildung 57: 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 Ver-sion dadurch zum Ausdruck gebracht, dass das Financial Management der „Service Strategy“ zugeordnet ist. Die Geschäftsanforderungen an das Service Management können im Rah-men einer übergeordneten Balanced Scorecard und einer daraus abgeleite-ten 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 umge-setzt. 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.


167

Eine weitere Quelle für die Definition der Prozessziele der IT Service Ma-nagement-Prozesse, damit deren Kennzahlen und Sollwerte, sind die Er-gebnisse der „Prozess Improvement-Pläne“ (PIPs). In diesen Plänen ist prozessbezogen der jeweils identifizierte Verbesserungsbedarf der IT Ser-vice Management-Prozesse dokumentiert (siehe Abbildung 58). Der Ver-besserungsbedarf wird im Rahmen von Audits und Reviews sowie an-hand der vorliegenden Prozess-Kennzahlen, deren Sollwerte und der nachfolgenden Analysen des Prozesses ermittelt.


Kapazitäten

ServiceImprovement


potenzial



IT-Services



IT-Strategie

ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

Business

IT ServiceManagement-

Prozesse

Verbesserungs-potenzial


Kapazitäten

ServiceImprovement


potenzial



IT-Services



IT-Strategie

ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

BusinessBusiness


Prozesse


Prozesse


Abbildung 58: Definition der Prozessziele – Prozess Improvement-Plan


168

Diese Informationen sind der Input für die „Planung und Implementie-rung 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.


Kapazitäten

ServiceImprovement


potenzial



IT-Services



IT-Strategie

ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

Business


Prozesse


Planung und Implementierung

des IT ServiceManagements


Kapazitäten

ServiceImprovement


potenzial



IT-Services



IT-Strategie

ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

BusinessBusiness


Prozesse


Prozesse




Abbildung 59: Definition der Prozessziele – Planung und Implementierung

Diese übergeordnete Management-Aufgabe ist nicht als einmaliger Vor-gang zu verstehen, sondern sie ist eine fortlaufende Aktivität und ent-spricht 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


169

abgeleitete IT-Strategie ausgerichtet sind. Durch die kontinuierliche An-passung an eine sich ändernde Umgebung und durch die laufende Er-folgsüberprüfung wird die Nachhaltigkeit der implementierten Prozesse sichergestellt. Das Ergebnis der „Planung und Implementierung des IT Service Manage-ments“ sind die Zielvorgaben für die einzelnen IT Service Management-Prozesse. Diese Vorgaben sind ein Teil des dokumentierten „Service Ma-nagement-Plans“ (SMP). Während im Service Improvement-Plan (SIP) die identifizierten Serviceverbesserungen definiert sind, enthält der Service Management-Plan (SMP) die Dokumentation des aktuellen IT Service Ma-nagement-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 Manage-mentziele für den jeweiligen Prozess konkretisiert. Der PMP kann als Pro-zessdokumentation mit allen notwendigen Informationen wie Prozessbe-schreibung, Kennzahlen und deren Zielwerte, etc. angesehen werden. Der hier beschriebene Managementansatz mag zunächst komplex und administrativ erscheinen, aber er stellt letztendlich die wirksame Ausrich-tung des IT Service Managements sicher und sorgt für einen zielgerichte-ten 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. Gege-benenfalls sind Quick-Wins – abhängig von der bestehenden Ist-Situation – zu erzielen, sie stehen aber nicht im Fokus eines Prozess-Managements.


170


Kapazitäten

ServiceImprovement


potenzial



IT-Services



IT-Strategie

ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

Business


Prozesse




Anforderungen

ServiceManagement

Plan(SMP)

ProzessManagement

Pläne(PMP)

Anforderungen


Kapazitäten

ServiceImprovement


potenzial



IT-Services



IT-Strategie

ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

BusinessBusiness


Prozesse


Prozesse




Anforderungen

ServiceManagement

Plan(SMP)

ProzessManagement

Pläne(PMP)

Anforderungen

Abbildung 60: Definition der Prozessziele – Service Management-Plan

Der hier beschriebene konzeptionelle Management-Ansatz erfüllt die An-forderungen der ISO 20000.

Dieser Management-Ansatz stellt sicher, dass die konkrete Zielsetzung der ein-zelnen IT Service Management-Prozesse aus den Geschäftsanforderungen strin-gent abgeleitet wird. Im nächsten Kapitel wird dargestellt, wie die Kennzahlen und Sollwerte auf Basis der Zielsetzung definiert werden. Damit wird sicherge-stellt, dass die Kennzahlen unmittelbar oder mittelbar mit den Geschäftsanforde-rungen der Kunden korrespondieren.

Die ISO 20000 dokumentiert die Anforderungen an dieses Management-System und kann zum Nachweis der Konformität herangezogen werden (siehe Abbildung 61). Die konkrete Umsetzung ist Projektaufgabe.


171


Kapazitäten

ServiceImprovement


potenzial



IT-Services



IT-Strategie

ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

Business


Prozesse




Anforderungen

ProzessManagement

Pläne(PMP)

Anforderungen

ISO 20000IT Service

Management

Konformität

ServiceManagement

Plan(SMP)


Kapazitäten

ServiceImprovement


potenzial



IT-Services



IT-Strategie

ProzessImprovement

Pläne(PIP)

SLA(OLA/UC)

BusinessBusiness


Prozesse


Prozesse




Anforderungen

ProzessManagement

Pläne(PMP)

Anforderungen

ISO 20000IT Service

Management

Konformität

ServiceManagement

Plan(SMP)

Abbildung 61: Konformität des Managementsystems

Es können zwar dezentral einzelne Service Management-Prozesse imple-mentiert 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 spezifi-zieren, die Prozessaktivitäten zu definieren und die kritischen Erfolgs-faktoren 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 zwi-schen der Dokumentation notwendiger Informationen und Vorgaben ei-

Die Prozess-dokumenta-tion stellt die Leitlinien dar.


172

nerseits und einem ausreichenden Gestaltungsspielraum für die Mitarbei-ter andererseits.

AktivitätenKritische Erfolgsfaktoren

Control Objectives

Wird sichergestellt durch

ServiceManagement

Plan(SMP)


ProzesseProzess

ManagementPlan

(PMP)


Control Objectives


ServiceManagement

Plan(SMP)


Prozesse


ProzesseProzess

ManagementPlan

(PMP)

Abbildung 62: Prozess-Management – Prozessdesign

Hier sollte nicht der Anspruch bestehen, dass der erste Entwurf alle Even-tualitäten abdeckt und fehlerfrei ist. Erfahrungsgemäß ergibt sich im tägli-chen Betrieb ein Optimierungsbedarf. Diese Einstellung und Erwartungs-haltung sollte auch gegenüber den Mitarbeitern kommuniziert werden. Die Mitarbeiter sollten aufgerufen werden, den notwendigen Verbesse-rungsbedarf 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 Soll-werten, Reviews und Audits durchgeführt werden. Dabei gehen die Er-gebnisse aus den durchgeführten Reviews und Audits wiederum in Kenn-zahlen ein (siehe Abbildung 63).


173


Control Objectives


ServiceManagement

Plan(SMP) IT Service

Management-Prozesse

Überprüfen /Verbessern

Kennzahlen(KPI, KGI)

Reviews/Audits

ProzessManagement

Plan(PMP)


Control Objectives


ServiceManagement


Management-Prozesse


Prozesse



Reviews/Audits

ProzessManagement

Plan(PMP)

Abbildung 63: 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 Prozesszie-len abgeleitet.

Bei der Ausgestaltung (Prozessdesign) der Prozesse und der Definition der Kennzahlen (KGI, KPI), sowie bei den durchzuführenden Audits und Re-views unterstützen die Best Practices von COBIT und ITIL (siehe Abbildung 64). Diesen Publikationen können entsprechende praxiser-probte 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 ent-sprechenden Kennzahlen und deren Zielwerte im Rahmen des Prozessde-signs definiert werden.


174


Control Objectives


ServiceManagement


Management-Prozesse



Reviews/Audits

COBIT

Best Practice

ITIL

ProzessManagement

Plan(PMP)


Control Objectives


ServiceManagement


Management-Prozesse


Prozesse



Reviews/Audits

COBIT

Best Practice

ITIL

ProzessManagement

Plan(PMP)

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 entspre-chend unterstützen und herangezogen werden.

Sind die Kennzahlen und Zielwerte definiert, so empfiehlt es sich, als Qualitäts-check zu prüfen, ob von der Kennzahl eine unmittelbare oder mittelbare Verbin-dung zu einem Geschäftsziel besteht.

Möchte die IT-Organisation die Konformität mit der ISO 20000 nachwei-sen, so können der ISO 20000-1 (vgl. [ISO 20000-1, 2005]) die Anforderun-gen entnommen werden, die vom jeweiligen Prozess sichergestellt und nachgewiesen werden müssen (siehe Abbildung 65).


175


Control Objectives


ServiceManagement


Management-Prozesse



Reviews/Audits

COBIT

Best Practice

ITIL

Konformität

ISO 20000

ProzessManagement

Plan(PMP)


Control Objectives


ServiceManagement


Management-Prozesse


Prozesse



Reviews/Audits

COBIT

Best Practice

ITIL

Konformität

ISO 20000

ProzessManagement

Plan(PMP)

Abbildung 65: Prozess-Management – Konformität


176

Die Kennzahlen und deren laufende Überprüfung stellen die Basis für die gegebenenfalls notwendigen Verbesserungen der Prozesse dar. Ohne aus-reichende Messung kann letztendlich keine zielgerichtete Verbesserung erreicht werden. Die Ergebnisse dieser Verbesserungsphase finden Einzug in dem Prozess Improvement-Plan PIP (siehe Abbildung 66).


Control Objectives


ServiceManagement


Management-Prozesse



Reviews/Audits

COBIT

Best Practice

ITIL

Konformität

ISO 20000

ProzessImprovement

Plan(PIP)

ProzessManagement

Plan(PMP)


Control Objectives


ServiceManagement


Management-Prozesse


Prozesse



Reviews/Audits

COBIT

Best Practice

ITIL

Konformität

ISO 20000

ProzessImprovement

Plan(PIP)

ProzessManagement

Plan(PMP)

Abbildung 66: Prozess-Management – Prozess Improvement-Plan


177

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 nachfol-gende Abbildung 67 aus [OGC, 2007e] dar.

Vision

Mission

Ziele

Objectives

CSFs

KPIs

Metriken

Messungen

Vision

Mission

Ziele

Objectives

CSFs

KPIs

Metriken

Messungen

Abbildung 67: Entwicklung von Kennzahlen


178

3.4.3 Dokumentation der Prozess-Kennzahlen Für die Dokumentation empfiehlt es sich, die Kennzahl mit der entspre-chenden Definition, der Messmethode und anderen relevanten Informati-onen 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 Pro-zesszieles

Zielwert Zielwert der Kennzahl, der sich aus der Zieldefinition für den Prozess ergibt

Beziehung zu anderen Prozessen Prozesse, die diese Kennzahl beein-flussen

Datenquelle Beschreibung der Quelle für die zugrunde liegenden Daten

Formel Berechnungsmethode der Kenn-zahl

Erhebungsfrequenz Festlegung, wann/wie oft die Kenn-zahl fortgeschrieben wird

Auditfrequenz Festlegung, wann/wie oft die Kenn-zahl hinsichtlich ihres Nutzens und ihrer Verwendung überprüft wird

Anmerkungen Zusatzinformationen 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 Kennzahlen-Steckbrief zu dokumentieren ist. Es empfiehlt sich, die Beschreibung der Kennzahlen in den Service Management-Plan (SMP) aufzunehmen.


179

3.4.4 Reporting der Prozess-Kennzahlen An der Zieldefinition und der Ausrichtung der IT Service Management-Prozesse 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 unter-schiedlich ist auch deren Informationsbedarf hinsichtlich der etablierten IT Service Management-Prozesse und der erbrachten Services. Der Prozess-Manager benötigt im Rahmen seiner Durchführungsverantwortung ver-schiedene Kennzahlen (KGI, KPI), die ihm detaillierte Informationen be-zü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 Rol-len des Prozess-Managers und zum Teil des Process Owners leicht umset-zen. 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 dokumen-tiert. 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 be-richtet. Nehmen wir an, die Fragestellung würde lauten: „Hat der Prozess Change Management seine Zielsetzung erfüllt?“ Dann müssen die Prozess-Kennzahlen 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 zusammenge-setzte Kennzahl zum Prozess durch die Gewichtung der einzelnen Ziele und der damit verbundenen Kennzahlen wie folgt ergeben (siehe Abbildung 68):

Kennzahlen müssen ebe-nengerecht sein.


180

Anteil fehlerfreierChanges

Anteil termin-gerechter Changes

Anteil kosten-gerechter Changes

EffektivitätChange Management

60%

20%

20%

Anteil zurück-gewiesener Changes

Anteil derNotfall-Changes

EffizienzChange Management

40%

60%

ZielerreichungChange Management

70%

30%

Anteil fehlerfreierChanges

Anteil termin-gerechter Changes

Anteil kosten-gerechter Changes

EffektivitätChange Management

60%

20%

20%

Anteil zurück-gewiesener Changes

Anteil derNotfall-Changes

EffizienzChange Management

40%

60%

ZielerreichungChange Management

70%

30%

Abbildung 68: 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: Darstellung der SLAs mit dem Q-Board von Q to be


181

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

ServiceManagement

Plan

ServiceImprovement

Plan

ITSM-Tool(s) …. weitere operative Systeme

Basisdaten aus den jeweiligen Prozessen

Prozess-Kennzahlen(KGI, KPI)

gewichteteKennzahlen

Top Management

ProzessManagement

ServiceManagement

Plan

ServiceImprovement

Plan

ITSM-Tool(s) …. weitere operative Systeme

Basisdaten aus den jeweiligen Prozessen

Prozess-Kennzahlen(KGI, KPI)

gewichteteKennzahlen

Top Management

ProzessManagement

Abbildung 70: 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 Ampelfar-ben darzustellen, nach dem Motto „Ein Bild sagt mehr als tausend Worte“. Hierzu wird der dargestellte Wert in Abhängigkeit der Sollwerte entspre-chend farbig dargestellt oder grafisch animiert. Dazu können zum Beispiel Ampelsymbole oder Tachoscheiben herangezogen werden.


182

Werden zu den absoluten Werten noch die Sollwerte und ein Trend aus-gewiesen, so können die Prozess-Kennzahlen kompakt und dennoch in-formativ dargestellt werden. Abbildung 71 und Abbildung 72 zeigen ein anonymisiertes Projektbeispiel zum Reporting von Prozess-Kennzahlen. Die erste Seite zeigt die Gesamt-betrachtung und den Trend des Prozesses, während auf der zweiten Seite die einzelnen Prozess-Kennzahlen, deren Sollwerte und Trends ausgewie-sen werden.

IncidentManagement

Berichtsmonat: 04/2007

90

95

100

105

110

1 2 3 4 5 6 7 8 9 10 11 12

Zielerreichung in Prozent

Monat/2007

Prozent

IncidentManagement

Berichtsmonat: 04/2007

90

95

100

105

110

1 2 3 4 5 6 7 8 9 10 11 12

Zielerreichung in Prozent

Monat/2007

Prozent

Abbildung 71: Exemplarischer Prozess-Bericht – Deckblatt zum Report


183

ErstlösungSoll60%

Ist62%

Major Incident

Soll5

Ist2

Lösungszeit Prio 1Prio 2

Soll2

Ist1,9

4 4,1 0

5

10

15

1 2 3 4 5 6 7 8 9 10 11 12

50

55

60

65

70

1 2 3 4 5 6 7 8 9 10 11 12

0

2

4

6

8

1 2 3 4 5 6 7 8 9 10 11 12

Monat/2007

Monat/2007

Monat/2007

Erstlösungsquote in %

Anzahl Major Incidents

Lösungszeit in Std.

ErstlösungSoll60%

Ist62%

Major Incident

Soll5

Ist2


Soll2

Ist1,9

4 4,1


Soll2

Ist1,9

4 4,1 0

5

10

15

1 2 3 4 5 6 7 8 9 10 11 12

50

55

60

65

70

1 2 3 4 5 6 7 8 9 10 11 12

0

2

4

6

8

1 2 3 4 5 6 7 8 9 10 11 12

Monat/2007

Monat/2007

Monat/2007

Erstlösungsquote in %

Anzahl Major Incidents

Lösungszeit in Std.

Abbildung 72: Exemplarischer Prozess-Bericht – Darstellung der Kennzahlen


184

Die Hersteller von Tools haben den Bedarf für eine übersichtliche, abge-stufte Darstellung erkannt und bieten hierzu so genannte „Management-Cockpits“ an. Ein Beispiel gibt die folgende Abbildung 73.

Abbildung 73: Darstellung des Management Cockpits von iET Solutions

3.5 Von der Kennzahl zur Verbesserungsmaßnahme

185

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 Errei-chung eines Prozesszieles gefährdet ist. Dabei kann der Indikator lediglich etwas aufzeigen. Die eigentliche Ursa-che 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 Prozess-Manager analytisch tätig werden, indem er versucht, verschiedene Ein-flussfaktoren zu untersuchen, die einen möglichen Einfluss auf die Erstlö-sungsquote haben. Angenommen, ein neuer IT Service wurde eingeführt,


186

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än-gigkeit vom betroffenen Service ausgewertet. In diesem Beispiel zeigt die Auswertung eine schlechter werdende Erstlösungsquote für die Services „eMail“ und „Kfz-Dialog“.

3.5 Von der Kennzahl zur Verbesserungsmaßnahme

187

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äg-lichen Betrieb und das Wissen um mögliche Abhängigkeiten. Die möglichen Ursachen sind nicht immer offensichtlich, sondern erfor-dern 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.


188

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 Kenn-zahlen 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 be-wältigende Volumen im Prozess verschaffen. Welche Inputs hat der Pro-zess 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 zeitli-che Entwicklung. Trendinformationen können frühzeitig Handlungsbe-darf 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 Kennzah-lensystem 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 ausgewer-tet 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 Ein-führung dieser Kennzahlen zu konzentrieren.

3.7 Der Umgang mit Kennzahlen

189

Im Anschluss können diese Kennzahlen um Kennzahlen für eine Betrach-tung der Effizienz erweitert werden.

Die Anzahl genutzter Kennzahlen sollte im eingeschwungenen Zustand pro Pro-zess bei maximal 10-15 Kennzahlen liegen.

3.7 Der Umgang mit Kennzahlen Die Kennzahlen dienen primär als Management-Werkzeug für den Pro-zess-Manager und den Process Owner. Diese können anhand der Kenn-zahlen erkennen, ob die Prozessziele erreicht werden und ob der Prozess wirkungsvoll durchgeführt wird. Darüber hinaus unterstützen die Kenn-zahlen den Prozess-Manager bei der Identifizierung eines möglichen Ver-besserungspotenzials, 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 Bedeu-tung 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 vor-gegeben, 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 orien-tieren.

Der Prozess-Manager muss sich dieses Verhaltens bewusst sein. Eine Mög-lichkeit, dem zu begegnen, besteht darin, mit einer anderen Kennzahl ne-gativen 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 ver-standen 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


190

die große Gefahr, dass aus den übermittelten Kennzahlen falsche Schlüsse gezogen werden. Was an dieser Stelle als Selbstverständlichkeit verstan-den werden kann, hat in einigen Organisationen zu erheblichen Schwie-rigkeiten geführt. Die Aufgabe des Problem Managements besteht zum Beispiel darin, Probleme zu identifizieren. Steigt die Kennzahl der identi-fizierten Probleme, so ist dies ein Indikator für einen gut funktionierenden Problem Management-Prozess. Es wäre dagegen fatal, wenn das Mana-gement die wachsende Zahl identifizierter Probleme falsch interpretiert und dem Problem Management negativ anlastet.

191

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ätsge-treu widerspiegeln, zum anderen müssen sie Anreize für die Veränderun-gen schaffen. Dies ist die Aufgabe von Kennzahlensystemen. In der IT gibt es wahr-scheinlich 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üg-lich 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 darstel-len. 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 stra-tegischen 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 In-nenwirkung ist CIO-Sache. Kennzahlensysteme bilden hierfür eine ent-scheidende Basis, nicht nur als Steuerungs-, sondern insbesondere als Kommunikationsinstrument.


192

4.2 Ziele Für Unternehmen steht heute nicht mehr zur Diskussion, dass Effizienz und Effektivität ihrer Organisationseinheiten objektiv, präzise und zuver-lässig ermittelt werden müssen. Dies gilt für IT-Organisationen im Beson-deren. Das frühzeitige Erkennen von Problemen und Verbesserungspo-tenzialen 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 ein-deutig und für alle Beteiligten verständlich sein und von diesen ak-zeptiert werden.

– Der Aufwand zur Erfassung einer Kennzahl sollte gering sein, um eine möglichst häufige, schnelle und preiswerte Ermittlung zu er-mö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 be-gü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 kontrol-lierbar sein. Andernfalls liefern sie ein falsches Bild der tatsächli-chen 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 er-mitteln?

15 Diese werden auch „User Quality Surveys“ genannt. 16 CAPI steht für „Computer Assisted Personal Interview“.

4.2 Ziele

193

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än-gen 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 abge-schlossen haben. Dem Anwender sind zum Teil diese SLAs mit den Servi-ce 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 Interpretati-onsmöglichkeiten. Ein Service Desk, der wenig kontaktiert wird, kann eine hohe Anwenderzufriedenheit im Sinne „Alles läuft reibungslos“ bedeuten, aber auch, dass die Anwender es „aufgegeben haben“, sich an die IT zu wenden, beispielsweise wegen Inkompetenz oder Arroganz des Service-Personals. Das Beispiel zeigt, dass man zur Ermittlung der Anwenderzufriedenheit nicht mit einer Kennzahl auskommt.

In einem Kennzahlensystem sollen sich sorgfältig ausgewählte Kennzahlen ge-genseitig ergänzen, um ein möglichst ausgewogenes und präzises Gesamtbild zu liefern.

Genauso wie einzelne Kennzahlen sollte ein gutes Kennzahlensystem An-forderungen 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, so-fern sie optimal eingesetzt wird. Dieser wird aber mit wachsenden


194

Systemen immer geringer. Es kommt also darauf an, das Kennzah-lensystem 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 Bestim-mung 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äzi-seres Maß, das weniger fehler- und zufallsanfällig ist. Auch wird eine Ma-nipulation der resultierenden Kennzahl deutlich schwieriger und aufwen-diger. 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 Einzel-fall 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 Anwen-derverhaltens 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 Kontakt-hä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.

4.3 Überblick

195

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 verfol-gen 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 spezi-fische Anwendungsszenarien besonders geeignet. Die Qualität und Eig-nung 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 Anpassun-gen einsetzen lässt, ist es wichtig, vorab einige Kriterien zu nennen, an-hand derer sich der Aufwand einer Implementierung abschätzen lässt:

– Stimmt die Zielsetzung des Kennzahlensystems mit den Anforde-rungen ü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 aus-formuliert werden?

– Wie aufwendig ist die Implementierung des Systems? Werden die verwendeten Kennzahlen bereits erhoben? Welchen Aufwand wür-de 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 Kennzah-lensysteme. Unsere Stopps sind aber nur kurz. Für längere Aufenthalte empfehlen wir einen Blick in die Originalarbeiten oder das sehr empfeh-lenswerte Buch von Martin Kütz [Kütz, 2007].


196

4.3.1 SVD 1980 Herkunft Schweizerische Vereinigung für Datenverarbeitung

Quelle EDV-Kennzahlen (1980), Bern/Stuttgart

Idee SVD 1980 ist ein kompaktes, relativ allgemein gehalte-

nes Kennzahlensystem, das 34 nach Adressaten grup-pierte Kennzahlen enthält.

Struktur Gruppierung nach Adressat und Art der Kennzahl. Insgesamt 34 Kennzahlen. Kennzahlen Management Anwender IT-Ent-

wicklung IT-Betrieb

Kosten 2 2 7 4

Leistungen - - 2 7

Nutzen 3 2 - -

Sonstige - - 3 2

Beispiele – IT-Produktivitätsindex (Management / Nutzen)

– Nutzenpunkte (Anwender / Nutzen) – Anzahl IT-Mitarbeiter (IT-Entwicklung / Sons-

tige) – Mean Time to Repair (MTTR) (IT-Betrieb / Leis-

tung)

Fazit Einige Kennzahlen müssen für den konkreten Einsatz in der Praxis spezifiziert werden, z.B. was „Nutzen-punkte“ im Einzelnen sind.

4.3 Überblick

197

4.3.2 Diebold 1984 Herkunft Diebold Deutschland GmbH

Quelle Diebold Kennzahlensystem (1984), 3. Auflage, Frankfurt

Idee Dieses von der Unternehmensberatung Diebold entwi-

ckelte Kennzahlensystem stellt eine hierarchische Struk-tur dar, in die konkrete Kennzahlen eingearbeitet wer-den können.

Struktur Hierarchische Strukturierung mit insgesamt 19 Unter-gruppen

– 1 Spitzenkennzahl – 2 Kennzahlenbereiche (A, B) – Kennzahlenunterbereiche (AA, AB, ...) – Kennzahlengruppen (AAA, AAB, ...) – Kennzahlenuntergruppen (AAAA, AAAB, ...)

Beispiele – Anteil IT-Kosten bezogen auf Umsatz (Spitzen-

kennzahl) – 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 wich-tige) Aspekte wie „Innovationsverhalten“ und „Zu-kunftsorientierung“ praktisch und objektiv messen lassen. Die hierarchische Struktur bietet Vorteile dadurch, dass eine an den jeweiligen Adressaten angepasste Informa-tionstiefe erreicht werden kann. Zu klären ist dabei allerdings, auf welche Art und Weise die Kennzahlen einer Gruppe zur jeweils höheren Hierarchiestufe zu-sammengerechnet werden können.


198

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

Struktur 5 Koordinationsfelder mit insgesamt 163 Kennzahlen – Strategische IT-Planung (34) – Planung / Durchführung von IT-Projekten (30) – Wirtschaftlichkeit (24) – Anwendungsbetrieb und IT-Infrastruktur (52) – Verrechnung von Kosten und Leistungen (23)

Beispiele – 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 formu-liert, 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.

4.3 Überblick

199

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 Per-spektiven mit insgesamt 200 Kennzahlen: Kennzahlen Kunden-

perspekt. Interne Persp.

Innovations-persp.

Finanz-persp.

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

Beispiele Leistungsmanagement, interne Perspektive

Ziel: „Ein guter Arbeitgeber sein.“ – Mitarbeiterzufriedenheit – Fluktuationsrate – Wettbewerbsfähigkeit der Gehälter – ...

Fazit Der einseitige Fokus auf die Kosten- und Finanzperspek-

tive kann zu kurzsichtigem Handeln verleiten. Die Kun-den-, Innovations- und Prozessperspektiven sollen hel-fen, 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.


200

4.4 Bewertung Die betrachteten Kennzahlensysteme zeigen, dass es verschiedene, glei-chermaß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ör-mige Strukturen erlauben das gleichzeitige Gliedern der Kennzahlen nach dem Bereich und einem zweiten Kriterium. Eine (zusätzliche) hierarchische Strukturierung der Kennzahlen ist mög-lich 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 ge-schickte 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 Kenn-zahlen.

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

4.5 Konsequenzen

201

– 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 Un-ternehmen 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-Kennzahlen-

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

203

5 IT Praxisleitfaden für die Entwicklung von Kenn-zahlensystemen

5.1 Management Summary In diesem Kapitel gehen wir darauf ein, wie ein praxistaugliches IT-Kennzahlensystem 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 Haupt-problem bei der Entwicklung eines IT-Kennzahlensystems darin besteht, die Komplexität des Systems zu reduzieren. Daher widmen wir uns die-sem Problem gleich am Anfang des Kapitels und zeigen auf, wie man Kennzahlen in Cluster unterteilen kann, damit ein „Mehr-Ebenen-Kennzahlen-System“ ohne Überfrachtung und Überforderung der Füh-rungsebene entsteht. Insbesondere sind Kennzahlen hinsichtlich ihres Einsatzes und der strate-gischen Bedeutung zu verdichten. Dies sollte den entsprechenden IT-Mitarbeitern ü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 verant-wortlich. 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 IT-Organisation 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 wer-den müssen, geschweige denn an die Geschäftsführung.

5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen

204

Die Frage „Erheben wir die richtigen Kennzahlen?“ sollte man etwas de-taillieren und erweitern: „Erheben wir die richtigen Kennzahlen zum rich-tigen 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 IT-Kennzahlen dargestellt.

Kennzahleneiner

IT-Organisation

Top ManagementGeschäftsführung

Balanced Scorecard (KSFs)

IT-ManagementCIO

IT - Kunden

Controls on Demand

IT-Controls

KPIs CSIs

SLAs

Kennzahleneiner

IT-Organisation

Top ManagementGeschäftsführung

Balanced Scorecard (KSFs)

IT-ManagementCIO

IT - Kunden

Controls on Demand

IT-Controls

KPIs CSIs

SLAs

Abbildung 77: Schema zur Klassifikation von IT-Kennzahlen

Hierzu die 3 Kernideen des Modells: – Im Wesentlichen lassen sich die Kennzahlen einer IT-Organisations-

einheit in drei größere Gruppen einteilen, die sich an den Adressa-ten 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 Situatio-nen benötigt. Diese Kennzahlen sollten als „Kennzahlen auf Ab-ruf“ (Controls on Demand) vorgehalten werden.

5.2 Klassifikationsschema für IT-Kennzahlen

205

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

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 Produkti-onsfaktor für Unternehmen darstellt. Sie ist wettbewerbsbestimmend, da sie nicht nur die Systeme „am Laufen hält“, sondern gleichzeitig eine be-deutende 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 standar-disieren, Skaleneffekte auszunutzen und das Risiko zu minimieren.

– Grow and Transform the Business: Die IT ist ein wesentlicher Teil der „Entwicklungsabteilung für Ge-schäftsprozesse“. Sie verändert und optimiert die Kernprozesse von Unternehmen, legt die Basis für neue Märkte und ist eine strategi-sche Waffe im Wettbewerb.

Die IT ist damit nicht Selbstzweck, sondern sie trägt messbar zum Business Va-lue 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 imple-mentieren 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 Unter-nehmen und die IT schädlich sein können. Sehr zu empfehlen ist ein „Management Report zur Lage der IT im Unter-nehmen“. Wir haben diese Art des „Reportings“ in vielen Unternehmen verschiedener Größen und Branchen erfolgreich eingeführt. In den meis-ten Fällen wird dieser Report mit Interesse von der Geschäftsführung ent-gegengenommen.


206

Der Report sollte jährlich erscheinen. Er beschreibt und bewertet die IT im Hinblick auf ihre Leistungsfähigkeit. Wichtig dabei sind die folgenden Dinge:

– Der Management Report muss auf einer mehrdimensionalen Bewer-tung 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 Manage-ment verständlich sein.

– Der Management Report darf Marketingaspekte beinhalten und ver-folgen. Er ist eine Selbstdarstellung und dient dem Erreichen strate-gischer Ziele.

– Er muss einen Überblick über die durchgeführten Projekte enthalten. Dabei ist herauszustellen, inwiefern die Projekte zum Business Va-lue 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 interessie-ren das Top Management? Dies sind sicherlich nicht die technischen De-tails 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 Suc-cess-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 Kennzahlensys-tem 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.)

Der IT Management Report richtet sich an das Top Management.


207

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

...

Kundenperspektive

Mitarbeiterperspektive

Finanzperspektive

IT Management Report 2006

...

Kundenperspektive

Mitarbeiterperspektive

Finanzperspektive

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


208

Situation des Unternehmens bezieht. Expandiert das Unternehmen bei-spielsweise in andere Länder, so kann dies der Grund für erhöhte IT-Aufwände sein. Hat man in den letzten Jahren die IT-Plattformen konsoli-diert, so kann dies in den Folgejahren ein Grund für sinkende Investitio-nen sein.

IT-Strategie

KPIKPI

KPIKPI

KPIKPI

KPIKPI

KPIKPIKPIKPI

KPIKPI

Kennzahlen-system

CSICSI

CSICSI

CSICSI

CSICSI CSICSI

KPIKPI

KeySuccessFactor

KeySuccessFactor

KeySuccessFactor

KeySuccessFactor

KeySuccessFactor

KeySuccessFactor

IT-Strategie

KPIKPI

KPIKPI

KPIKPI

KPIKPI

KPIKPIKPIKPI

KPIKPI

Kennzahlen-system

CSICSI

CSICSI

CSICSI

CSICSI CSICSI

KPIKPI

KeySuccessFactor

KeySuccessFactor

KeySuccessFactor

KeySuccessFactor

KeySuccessFactor

KeySuccessFactor

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 allge-meine 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 Unterneh-mens bezogen werden.

5.2.2 Key Performance und Customer Satisfaction Alle IT Service Management-Ansätze sehen IT-Organisationen als IT Ser-vice 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-Infrastruk-tur nutzen.


209

In IT-Kennzahlensystemen sollte die Kundenfokussierung Berücksichtigung fin-den. 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 Custo-mer Satisfaction Index (CSI), der angibt, wie der Kunde einen entsprechen-den Service empfindet. Es wird sozusagen die „gefühlte“ Qualität bewer-tet. 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 Pro-vidersicht 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 Pro-vidersicht unterschiedlich sein kann.

CustomerSatisfaction

Index

CustomerSatisfaction Index

CustomerSatisfaction

Index

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


210

– Zwischen Leistungserwartung und Servicewahrnehmung kann es eine Lücke geben. Dies ist in der Praxis oft der Fall, wenn IT-Marketingaspekte zu kurz kommen.

– Zwischen Leistungserwartung des Kunden und der durch den Pro-vider 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 Kun-den 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 zu-ließ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 Improve-ment“ [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 Kommunikations-problem bzw. eine falsche Erwartungshaltung, die auf Seiten des Kunden besteht.

Für IT-Kennzahlensysteme bedeutet dies, dass CSIs auf der Ebene des IT-Managements 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 Kundenkon-takte wahrgenommen werden. Der wichtigste Sensor liegt hier sicherlich beim CIO selbst, der wahrnehmen muss, wie die IT im Unternehmen da-steht. Andere Quellen sind natürlich das Service Level Management, aber auch der Service Desk sowie das Projekt Management.


211

Externe u. interneKommunikation,

Einflüsse und Treiber

Was wollen wir?

Was brauchen wir?

Was bekommen wir?Erwarteter Service

Was bekamen wir?Erhaltener Service

Service Operation

Service Transition

Service Strategy

Service Design

ErfahrungVergangenheit

Kom

munikation

zum K

unden

GAP 3

GAP 2GAP 1

GAP 16

GAP 15

GAP 4

GAP 14

GAP 13

GAP 12

GAP 11

GAP 10

GAP 5

GAP 7

GAP 9

GAP 8GAP 6

Externe u. interneKommunikation,

Einflüsse und Treiber

Was wollen wir?

Was brauchen wir?

Was bekommen wir?Erwarteter Service

Was bekamen wir?Erhaltener Service

Service Operation

Service Transition

Service Strategy

Service Design

ErfahrungVergangenheit

Kom

munikation

zum K

unden

GAP 3

GAP 2GAP 1

GAP 16

GAP 15

GAP 4

GAP 14

GAP 13

GAP 12

GAP 11

GAP 10

GAP 5

GAP 7

GAP 9

GAP 8GAP 6

Abbildung 81: Gaps nach OGC (aus [OGC, 2007e])

Exkurs: Zum Begriff „Key Performance Indicator (KPI)“ Es sei an dieser Stelle angemerkt, dass der Begriff Key Performance Indica-tor (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 organiza-tion. 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 or-ganization's strategy.” COBIT (vgl. [COBIT, 2005]): Hier werden die wesentlichen Leistungsindikatoren als Key Goal Indica-tors (Effektivität) bezeichnet, während KPIs „lediglich“ die Effizienz be-schreiben.


212

ITIL definiert KPIs als (vgl. [OGC, 2007c]):

A Metric that is used to help manage a Process, IT Service or Activity. Many Met-rics 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 Effec-tiveness 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 IT-Controlling durchgesetzt und kann auch im Zusammenhang mit nicht-COBIT-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. 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 „IT-Projekte in time und in budget“. Beispiele für CSIs sind die „empfundene“ Kompetenz der Service Desk-Mitarbeiter und die Kundenzufriedenheit mit der IT.

5.2.3 IT-Controls und Controls on Demand Durch die Vielzahl eingesetzter Monitoring Tools stehen in IT-Organisati-onen zeitnah immense Datenmengen zur Verfügung, die prinzipiell als Kennzahlen nutzbar sind. Es macht auf keiner Ebene des Kennzahlensystems – weder auf der Ge-schäftsführungs- noch auf der IT Management Ebene – Sinn, eine unüber-schaubare Menge von Kennzahlen in ein monatliches Reporting einzube-ziehen. 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.

Auf der IT-Management-Ebene sind KPIs und CSIs zu reporten.


213

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 ha-ben wir hier in unseren Projekten eine stärkere Ähnlichkeit der Kennzah-lensysteme untereinander erkennen können. Die Idee, Cockpits einzuset-zen, die diese Kennzahlen automatisch aus den operativen Systemen gene-rieren, setzt sich immer mehr durch. Die Steuerung der IT über ein Cock-pit kann vor allen Dingen zeitnah erfolgen und bedarf nicht der aufwen-digen Sammlung und Auswertung von Daten zu einem bestimmten Zeit-punkt. Controls on Demand werden auf Anforderung reported. Sie müssen zwar generell zur Verfügung stehen, werden aber nur situationsbedingt einge-setzt, 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 fol-

genden Kapitel behandeln. 23 Dito. 24 Dito.


214

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 Klassi-fizierung 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, Mes-sung 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 Projekt-erfahrung. Sie können von Fall zu Fall von den implementierten Methoden in IT-Organisationen abweichen.

5.3 Prozess-Kennzahlen

215

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 lie-fern 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örungsmeldun-gen dargestellt wird.

Durch die Darstellung von Trends für die im Anschluss beschriebenen Kennzah-len 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 not-wendig ist. Hier muss jeweils der Aufwand zur Generierung mit der Steu-erungsrelevanz der Kennzahl und des möglichen Verbesserungspotenzials bewertet werden. Um Zusatzaufwendungen zu vermeiden, sollten die Kennzahlen mög-lichst ohne zusätzlichen Erfassungsaufwand aus den operativen IT-Syste-men gewonnen werden. Speziell die Kennzahlen für die Prozesse Incident Management, Request Fulfilment, Problem Management, Access Manage-ment, 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 Prozes-sen 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 Kennzah-len 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 Manage-ment 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.

Kennzahlen sind als Trend und Relation darzustellen.

Kennzahlen sind möglichst aus operativen Systemen zu generieren.


216

Änderungen im IT Service Management-Tool sind auf mögliche Auswirkungen hinsichtlich der Kennzahlengenerierung zu bewerten. Daher sollten auch Ände-rungen am IT Service Management-Tool über das Change Management gesteu-ert werden.

Die Tool-Unterstützung in den einzelnen IT-Organisationen ist sehr viel-fältig. Zum Teil existiert zumindest für einen Teil der Prozesse aus „Servi-ce Design“ (früher Service Delivery), „Service Transition“ (früher Service Support) und „Service Operations“ (früher Service Support) ein einheitli-ches Tool mit einer zentralen gemeinsamen Datenbank. Bei anderen IT-Organisationen werden die Service Management-Prozesse von unter-schiedlichen Tools und Datenbanken unterstützt. Daher wird in den fol-genden 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 be-dingen 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.

Eine wichtige Datenbasis für die Messung von Kennzahlen stellt der Pro-zess 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 auf-weisen. 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 Datenqua-lität nicht gegeben, leidet der Informationsgehalt von Kennzahlen in ande-ren IT Service Management-Prozessen. Kann hier keine ausreichende Da-tenqualität sichergestellt werden, so muss über eine alternative Messme-thode nachgedacht werden. Zum Beispiel, indem Probleme anstatt der Incidents ausgewertet werden.

Kennzeichnend für das IT Service Management sind Prozesse mit wechselseiti-gen Aktivitäten und Schnittstellen. Daher werden häufig Daten aus anderen Pro-zessen 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.

Änderungen im Tool sind Changes und als solche zu behandeln

Datenqualität im Prozess kritisch be-werten und ggf. eine andere Mes-sung wählen


217

5.3.1 Service Strategy

5.3.1.1 Financial Management Der Prozess und die Funktionen des Financial Management sind verant-wortlich 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 Kosten-

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

ziellen Risiken. Messwert Gegenüberstellung der Plan-Kosten zu den tat-

sä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äftspro-

zesse sichergestellt. Hierzu werden servicebezo-gene IT-Kosten bzw. Preise benötigt.

Messwert Auswertung der Kosten im Servicekatalog.


218

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

den nachvollziehbar und widerspruchsfrei sein. Messwert Auswertung der durchgeführten und dokumen-

tierten 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 be-wertet werden und sind Basis für Forderungen an die sicherzustellende Qualität des Service Managements.

Messwert Identifizierung kritischer Services aus dem Ser-vicekatalog und Überprüfung auf vorhandene BIA.

Name der Kennzahl IT-Kosten am Umsatz Definition Anteil der IT-Kosten am Umsatz des Unterneh-

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


219

5.3.2.1 Service Portfolio Management Dieser Prozess ist für das Management des Serviceportfolios verantwort-lich. Er berücksichtigt die Services in Bezug auf den für das Business gelie-ferten Wert. Name der Kennzahl Anzahl Services im Portfolio Definition Anzahl der definierten Services im Portfolio Relevanz Ist einerseits als Referenzwert notwendig, ande-

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

ces, die von Kunden genutzt werden. Relevanz Diese Kennzahl zeigt die Nachfrage der angebo-

tenen Services auf. Messwert Auswertung der Services im Servicekatalog und

im Serviceportfolio. Name der Kennzahl Anteil Relationen IT Services zu Geschäftspro-

zessen Definition Anteil der abgebildeten Relationen zu den über-

geordneten 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 Ge-schä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 Dyna-

mik der geplanten und angebotenen Services. Messwert Auswertung des Serviceportfolios.


220

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 be-findlichen Services.

Messwert Auswertung des Serviceportfolios und Gruppie-rung anhand des Status.

Bemerkung Die Services können den folgenden Status an-nehmen „Servicekatalog“, „Servicepipe-line“ (Service noch nicht produktiv) und „Reti-red Services“

5.3.1.3 Demand Management Das Demand Management hat die Kundenanforderungen an die IT Servi-ces 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 Neupro-

jekte in einer speziellen Applikationsdomain, einem Applikationsbereich etc.

Relevanz Festlegung der Priorität in der Umsetzung von Applikationsprojekten. Festlegung der IT Res-sourcenauslastung mit dem Kunden.

Messwert Anzahl der IT Projektanmeldungen pro Appli-kationsbereich und Zeitraum

Bemerkung Transparenz zwischen Kunde und IT bzgl. der IT Ressourcenauslastung.

Name der Kennzahl Anzahl kurzfristiger Kapazitätsanpassungen Definition Anzahl kurzfristiger Anpassungen der bereitzu-

stellenden Kapazitäten Relevanz Kurzfristige Anpassungen der Kapazitäten füh-

ren zu Zusatzkosten. Entweder entstehen unge-nutzt Überkapazitäten oder Zusatzkapazitäten sind kurzfristig – daher in der Regel – teuer zu


221

beschaffen. Häufig auftretende Anpassungen sind ein Indiz für Probleme beim Demand Ma-nagement.

Messwert Ergebnisse aus dem Review des Capacity Ma-nagements

5.3.2 Service Design

5.3.2.1 Service Catalogue Management Das Service Catalogue Management soll sicherstellen, dass ein Serviceka-talog entwickelt und gewartet wird, der genaue Information über alle ak-tuellen 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 befindli-chen 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 exis-tieren.

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 Standardisie-rung von Services. Weichen die tatsächlichen Services von den Beschreibungen im Serviceka-talog ab, so wird diese Standardisierung nicht erreicht.

Messwert Vergleich der SLAs mit dem Servicekatalog. Bemerkung Bei der Messung wird vorausgesetzt, dass für


222

alle im Betrieb befindlichen Services SLAs exis-tieren.

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 ent-sprechen. 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 Manage-

ment 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 ande-rem auch die Flexibilität des IT Service Provi-ders.

Messwert Abfrage in der Kundenzufriedenheitsumfrage. Bemerkung Zusätzlich kann dieser Aspekt auch innerhalb

einer Anwenderzufriedenheitsumfrage abge-fragt werden.

Name der Kennzahl Einhaltung der SLAs Definition Anteil der SLAs, deren Vereinbarungen ein-

gehalten 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 ver-bunden.

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.


223

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

menarbeit zwischen Kunde und IT Service Pro-vider. 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 Unternehmens-einheit 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 Unternehmens-bereiche 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 entstan-den sind.

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


224

müssen entsprechende Folgeaktivitäten einge-leitet 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 ein-geleitet 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 plan-mäß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.


225

Messwert Auswertung der offenen Maßnahmen im SIP. Bemerkung Die Maßnahmen sollten im Plan mit einem Sta-

tus 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 Ge-schä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 auszuwei-sen.

Name der Kennzahl Lastspitzen und Gesamtauslastungsrate Definition Darstellung der Lastspitzen und Gesamtauslas-

tung 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


226

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 Kun-denunzufriedenheit 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 doku-

mentierten Veränderungen gegenüber den tat-sächlichen Veränderungen.

Relevanz Eine gute Planung ist wichtig für das Financial Management. Eine gute Planung verhindert kurzfristige und in der Regel teurere Beschaf-fungsmaß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 Hand-lungsbedarf.

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.


227

Messwert Die Anzahl ist dem System Management zu entnehmen, ggf. auch dem Configuration Ma-nagement. Die Anzahl der zentralen Systeme kann dem Configuration Management System entnommen werden.

Name der Kennzahl Kosteneinsparung durch das Capacity Manage-

ment pro Bereich oder Technologie Definition Einsparungssumme in Euro, die durch optima-

leren Einsatz von Technik (z.B. Verdichtung von Applikationen durch Virtualisierung) ein-gespart werden kann.

Relevanz Capacity wird in immer mehr Unternehmen nicht nur in der Prognose von Kapazitätswachs-tum 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 Technologie-optimierungen sichert die Möglichkeit, in inno-vative 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 ein-gehende Wert stark ansteigen ist dies z.B. der Hinweis auf SPAM oder Mail-Attacken, dem unbedingt entgegen zu treten ist, um die Res-sourcen weiterhin optimal zu nutzen.

Relevanz Erkennen von „Ressourcenverschwendungen“ – Hinweis auf die Einführung neuer Technolo-gien um einen Kostenanstieg dauerhaft zu ver-meiden.


228

Messwert Vergleich über mehrere Tage, Wochen, Monate der Anzahl der eingehenden zu den ausgehen-den Mails.

5.3.2.4 Availability Management Der Prozess ist verantwortlich für die Definition, Analyse, Planung, Mes-sung 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 Komponen-

ten innerhalb des vereinbarten Zeitraums. Relevanz Die Verfügbarkeit ist als wichtigster Service

Level anzusehen. Deren Kenntnis ist ein wichti-ger Input für das Service Level Management.

Messwert Die Definition der Messung ist abhängig von der geforderten Qualität und den damit ver-bundenen Kosten. Von der Auswertung von Incidents ist abzuraten. Bei hohen Anforderun-gen erfolgt die Messung in der Regel über Mess-PCs.

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

chergestellt, so führt dies in der Regel zu Ge-schäftsausfällen.

Messwert Auswertung der gemessenen Verfügbarkeit gegenüber dem Soll-Wert.

Bemerkung Die SLA-Verletzungen sind pro SLA auszuwei-sen.


229

Name der Kennzahl Nicht-Verfügbarkeit innerhalb kritischer Ge-schäftszeiten

Definition Nicht-Verfügbarkeit innerhalb kritischer Ge-schäftszeiten für einen IT Service.

Relevanz Wurden mit dem Kunden kritische Geschäfts-zeiten vereinbart, so ist die Verfügbarkeit in-nerhalb dieser Zeit besonders herauszustellen.

Messwert Die Definition der Messung ist abhängig von der geforderten Qualität und den damit ver-bundenen Kosten. Von der Auswertung von Incidents ist abzuraten. Bei hohen Anforderun-gen erfolgt die Messung in der Regel über Mess-PCs.

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 (Anwen-der) genutzt werden kann.

Relevanz Während die Verfügbarkeit ein statisches Maß ist, bestimmt die mittlere Ausfallzeit die jewei-lige Dauer. Maximale Dauer kann zusammen mit der Verfügbarkeit als Service Level verein-bart werden.

Messwert Die Definition der Messung ist abhängig von der geforderten Qualität und den damit ver-


230

bundenen Kosten. Von der Auswertung von Incidents ist abzuraten. Bei hohen Anforderun-gen erfolgt die Messung in der Regel über Mess-PCs.

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 verwen-det. Es ist daher stets zu prüfen, ob die Zeit-spanne 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äs-

sigkeit des IT Service. Messwert Die Definition der Messung ist abhängig von

der geforderten Qualität und den damit ver-bundenen Kosten. Von der Auswertung von Incidents ist abzuraten. Bei hohen Anforderun-gen erfolgt die Messung in der Regel über Mess-PCs.

Name der Kennzahl Qualität des Availability Plans Definition Übereinstimmung der im Availability Plan do-

kumentierten 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 Beschaf-fungsmaß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.


231

5.3.2.5 IT Service Continuity Management Der Prozess IT Service Continuity Management (ITSCM) ist verantwort-lich 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 Conti-nuity 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äftsanforde-

rungen und den jeweiligen Service-Anforderun-gen auszurichten. Innerhalb von SLAs sind diese zu dokumentieren.

Messwert Überprüfung der vorhandenen SLAs. Bemerkung Hier wird davon ausgegangen, dass für sämtli-

che 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ühr-

ten ITSCM Überprüfungen. Relevanz Es muss sichergestellt werden, dass die ITSCM-

Pläne im Notfall auch funktionieren. Daher sind sie regelmäßig zu überprüfen.

Messwert Auswertung der durchgeführten Reviews und Audits.

Bemerkung Ergänzend sollte das Datum des letzten Audits / Reviews ausgewiesen werden.

Name der Kennzahl Anzahl und Anteil erfolgreicher ITSCM-Tests Definition Anzahl und Anteil der erfolgreich durchgeführ-

ten ITSCM-Tests. Relevanz Es muss sichergestellt werden, dass die ITSCM-


232

Pläne im Notfall auch funktionieren. Daher sind sie regelmäßig zu testen.

Messwert Auswertung der durchgeführten Testproto-kolle.

Bemerkung Die Tests sollten zumindest einmal jährlich zu-sammen 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 Schulungs-maßnahmen.

Name der Kennzahl Zeitdauer für Aktualisierung der ITSC-Pläne Definition Zeitdauer für Aktualisierung der ITSC-Pläne

aufgrund eines identifizierten Änderungsbe-darfs.

Relevanz Änderungen können sich aufgrund geänderter Kundenanforderungen oder durchgeführter Changes ergeben. Dann ist sicherzustellen, dass die notwendigen Änderungen zeitnah umge-setzt werden.

Messwert ITSC-Pläne sind CIs. Im Rahmen der Versions-verfolgung kann aus dem Configuration Mana-gement System die Zeitspanne ermittelt wer-den.

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 Infor-mation Security Management ist normalerweise ein Teil des organisatori-schen Ansatzes zum Security Management, das einen breiteren Scope ge-


233

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

lyse möglicher Bedrohungen und deren präven-tive Reduktion. Diese Kennzahl zeigt die Quali-tät der Prävention auf und ist Indikator für mögliche Verbesserungen.

Messwert Auswertung der Incident Records mit der Kate-gorie „Security“ und der Codierung „Auswir-kung“ (Impact).

Bemerkung Voraussetzung ist, dass die Security Incidents entsprechend erkannt und dokumentiert wer-den.

Name der Kennzahl Anteil SLAs mit Sicherheits-Klauseln Definition Anteil des SLAs, die Klauseln zu den Si-

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


234

Messwert Auswertung durchgeführter Audits und Revi-sionen.

Bemerkung Festgestellte Verletzungen von Compliance-Anforderungen sind besonders herauszustellen.

Name der Kennzahl Anzahl vergeblicher Login-Versuche Definition Anzahl der festgestellten vergeblichen Login-

Versuche. Relevanz Eine hohe Anzahl vergeblicher Login-Versuche

zeigt mögliche illegale Versuche der Informati-onsbeschaffung auf.

Messwert Auswertung der Protokolldatei entsprechender Identifizierungssysteme.

Bemerkung Hierzu sind „auffällige“ User-IDs zur Präven-tion herzustellen.

Name der Kennzahl Anzahl Verbesserungsvorschläge zur Security Definition Anzahl der eingereichten Verbesserungsvor-

schläge und Verbesserungsmaßnahmen im Be-reich des Security Managements.

Relevanz Die Kennzahl zeigt die zunehmende Akzeptanz und Wahrnehmung von Sicherheitsbelangen.

Messwert Auswertung der Service und Prozess Improve-ment-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 da-mit z.B. in äußere und innere Sicherheit.

Relevanz Abstimmung, Umsetzung und Monitoring der Investitionen in die Security eines Unterneh-mens

Messwert Investitionen pro Jahr aufgeteilt in interne und externe Security oder z.B. Virenschutz, Fire-walls, Sniffer etc..


235

5.3.2.7 Supplier Management Der Prozess Supplier Management ist dafür verantwortlich, sicherzustel-len, dass alle Verträge mit Lieferanten die Geschäftsanforderungen unter-stü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 Nicht-

einhaltung von UCs zurückzuführen sind. Relevanz Die Nichteinhaltung von UCs führt in der Regel

zu Service Level-Verletzungen und zu Kunden-unzufriedenheit. Ü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 beauf-

tragten Lieferanten. Relevanz Formelle Streitfälle mit Lieferanten sind ein

Indiz für nicht eindeutige Vereinbarungen in-nerhalb der UCs.

Messwert Die Streitfälle sind vom Supplier Manager in einem System zu speichern.

Bemerkung Bei Bedarf kann hier im Rahmen einer Drill-Down-Funktion noch nach dem Anlass unter-


236

schieden werden, wie zum Beispiel bemängelte Rechnungen oder Verletzungen von Complian-ce-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 IT-

Steuerung unterliegen. Definition Anzahl der Lieferanten, die einem Supplier-

und 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 zuge-ordnete Anzahl kann diesem System ent-nommen 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 Zusammenar-

beit zeigt sich auch außerhalb der festgelegten Service Level.

Messwert Zufriedenheitsbefragung der innerhalb der IT mit dem Lieferanten zusammenarbeitenden Bereiche.


237

Bemerkung Es kann auch der Lieferant zur Zufriedenheit befragt werden.

5.3.3 Service Transition

5.3.3.1 Transition Planning and Support Der Prozess „Transition Planning und Support“ ist verantwortlich für die Planung der gesamten Service Transition-Prozesse und Koordination der erforderlichen Ressourcen. Diese Prozesse sind „Change Management“, „Service Asset and Configuration Management “, „Release and Deploy-ment 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 Re-leases von Relevanz, sondern auch, dass der implementierte Inhalt der Planung und Verein-barung entspricht. Die Auswirkung der Einhaltung der Kostenpla-nung ist abhängig von der Leistungsverrech-nung.

Messwert Hierzu sind in den Release-Records die Pla-nungsinformationen hinsichtlich Kosten, Ter-mine und geplante Inhalte (Changes) zu spei-chern und mit dem Auslieferungsumfang, Ter-min 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 Ge-wichtung dieser Aspekte notwendig. Es ist auch möglich, aus den einzelnen Aspekten (Kosten, Termine, etc.) einzelne Kennzahlen zu definie-ren.


238

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 Anwen-der) -zufriedenheit.

Messwert Abfrage in der Kundenzufriedenheitsumfrage Bemerkung Hier ist zusätzlich auch eine Abfrage der An-

wender möglich. Name der Kennzahl Zufriedenheit Service Team Definition Zufriedenheit in den Projekt- und Service-

Teams mit den in der Phase Service Transition definierten Verfahren.

Relevanz Die korrekte Nutzung der beschrieben Verfah-ren hängt von der Praktikabilität und von Ak-zeptanz innerhalb der Service Teams und der beteiligten Projekt-Teams ab.

Messwert Hierzu sind interne Feedbacks einzuholen und auszuwerten.


239

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 Ma-nagements besteht darin, die Durchführung vorteilhafter Changes zu er-mö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. Betrach-tet werden alle RfCs, die vom Change Manage-ment bearbeitet wurden, das heißt auch zu-rückgewiesene RfCs.

Relevanz Die Kennzahl ist wichtig als Referenzwert. Dar-über hinaus zeigt die Anzahl der Changes die Flexibilität der IT-Organisation, auf Kundenan-forderungen 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, Applika-tion, etc.) notwendig. Eine weitere Aufschlüsselung besteht in der Darstellung der Prioritäten, wobei die „Emer-gency Changes“ besonders herausgehoben wer-den 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 Chan-

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


240

Indiz für eine unzureichende Auswirkungsana-lyse der RfCs. Fehlerhafte Changes führen zu Geschäftsausfällen, dadurch sinkt die Kunden-zufriedenheit. Weiterhin führen fehlerhafte Changes innerhalb der IT zu Zusatzaufwen-dungen, das heißt die IT-Kosten steigen.

Messwert Im Idealfall werden im Betrachtungszeitraum die implementierten Changes aus der Change-DB ermittelt und geprüft, ob hierfür Incident Records existieren (im Incident Record ist die Nummer des Changes als Grund für den Inci-dent vermerkt).

Bemerkung Für die Aussagekraft dieser Kennzahl sind die Datenqualität und das Know-how im Incident Management entscheidend. Wird ein fehlerhaf-ter Change nicht als Grund der Störung erkannt und eingetragen, so hat dies erheblichen Ein-fluss auf die Qualität dieser Kennzahl. Hier wäre dann zu überlegen, ob alternativ die Prob-leme 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 Effek-tivitä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ächli-chen“ Implementierung verglichen.

Bemerkung Bei Bedarf können weitere Aspekte hinsichtlich der Qualität der Terminplanung verfolgt wer-


241

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 vereinbar-ten 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 Kundenzu-friedenheit. Muss die IT für die Kosten auf-kommen, so führen Changes mit höheren Durchführungskosten zu einer nicht eingeplan-ten Kostensteigerung innerhalb der IT. Die Kennzahl zeigt die Qualität der Planung und Analyse von Changes hinsichtlich der Aufwen-dungen auf.

Messwert Zum Change sind die damit verbundenen Auf-wendungen (Personal, Material) zu erfassen. Aus der Change-DB werden diese Aufwendun-gen 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 imple-mentiert werden. Dann ist es wichtig, dass die Möglichkeit besteht, in den gesicherten Aus-gangszustand 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 ermit-telt, die zurückgenommen werden mussten, und die Changes, deren Back-Out-Plan erfolg-reich war.


242

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

beitungsstau 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 ein-gereicht.

Messwert

Ermittelt werden aus der Change-DB die An-zahl der RfCs für die Aktivität „Asses and eva-luate 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 Ma-nagements 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 Configu-ration Management“ ausgewertet.

Name der Kennzahl Anteil zurückgewiesener RfCs Definition Die Kennzahl zeigt an, wie viele der eingereich-

ten RfCs vom Change Management zurückge-wiesen wurden.

Relevanz RfCs können zurückgewiesen werden, wenn sie


243

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 An-zahl der RfCs, die den Status „zurückgewie-sen“ 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 Verfol-gung und das Reporting der Werte und Ownership sämtlicher finanzieller Assets während des gesamten Lebenszyklus verantwortlich. Das Configu-ration Management ist für die Pflege der Information über Configuration Items (CIs) und deren Beziehungen verantwortlich, die für die Bereitstel-lung 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 Configura-

tion Items (CIs). Relevanz Die Anzahl der CIs dient für weitere Betrach-

tungen als Referenzwert. Messwert Ermittlung der CIs aus dem Configuration Ma-

nagement System (CMS) Bemerkung Hierfür sollte eine Drill-Down-Funktion existie-

ren, 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 unterschied-lichen Prozessen und Aktivitäten als Planungs-grundlage. Fehlerhafte Informationen haben eine negative Auswirkung auf die Qualität des IT Service.


244

In Verbindung mit Compliance-Anforderungen, wie zum Beispiel SOX oder Versicherungsbe-stimmungen, können geschäftliche Schäden bzw. Kosten entstehen.

Messwert CI-Abweichungen zwischen Soll- und Ist-Be-stand sind im CMS beim betroffenen CI zu do-kumentieren. Ausgewertet werden die Ergeb-nisse 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 Nut-

zung befindlichen Software-Lizenzen. Hierzu müssen die CIs mit einem entsprechenden Sta-tus „in Nutzung“ und Codierung für „Soft-ware“ 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 existie-

ren, um die CIs aufgliedern zu können (IT-Zuordnung zum Service oder CI-Typen, wie Applikationen etc.).

Name der Kennzahl Auswirkungen fehlerhafter CIs Definition Anzahl der fehlerhaften Changes, deren Ursa-


245

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 Chan-ges. Fehlerhafte Informationen können zu Aus-fällen von IT Services und für das Business füh-ren, wenn hierdurch Changes fehlerhaft sind.

Messwert Zur Generierung dieser Kennzahl sind die Er-gebnisse der Reviews im Change Management auszuwerten.

Bemerkung In der Literatur wird als Kennzahl auch „Inci-dents oder Probleme aufgrund fehlerhafter CIs“ beschrieben. Hier ist kritisch zu prüfen, ob eine eindeutige und verlässliche Unterschei-dung 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 aus-

zuwerten. Mittels Codierung sind festgestellte Abweichungen und deren Korrektur zu doku-mentieren.

5.3.3.4 Release and Deployment Management Der Prozess ist verantwortlich für das Release und Deployment Manage-ment. Dabei ist das Release Management für die Planung, Terminplanung und Steuerung der Überführung von Releases in die Test- und Live-Umge-bung verantwortlich Das primäre Ziel des Release Managements besteht im Schutz der Live-Umgebung und der Herausgabe der richtigen Kompo-nenten. Das Deployment Management ist verantwortlich für die Überfüh-rung von neuer oder geänderter Hardware, Software, Dokumentation, Prozesse usw. in die Live-Umgebung.


246

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

tungen als Referenzwert. Messwert Ermittlung der durchgeführten Releases aus der

Release-DB. Bemerkung Hierfür sollte eine Drill-Down-Funktion existie-

ren, 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 durchge-

fü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 Behe-bung Zusatzkosten für die IT-Organisation auf.

Messwert Auswertung der Incidents im Betrachtungszeit-raum, die auf einen Release referenzieren.

Bemerkung Hier sollte eine Drill-Down-Funktion auf betrof-fene IT Services bestehen. Kann das Incident Management die notwendi-gen 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


247

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 Kenn-zahl 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 Mana-gement“

Bemerkung Hierzu sind nicht nur festgestellte Abweichun-gen im Audit zum CI zu dokumentieren, son-dern 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 aufzuneh-men und das CMS zu aktualisieren.

Messwert Ermittlung auf Basis durchgeführter Verifikatio-nen 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 Al-ternative mit einer anderen. Name der Kennzahl Anzahl Abweichungen in der Service Perfor-

mance Definition Anzahl der festgestellten Abweichungen zwi-

schen der bereitgestellten und der benötigten Service Performance.


248

Relevanz Zur Unterstützung der Geschäftsprozesse muss der Service die benötigte Performance sicher-stellen. 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 Kundenunzufrieden-heit.

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 Re-cords 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 Reduzie-

rung ist ein Zeichen für die verbesserte Effi-zienz.

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 Manage-ments ist es, durch das Reduzieren der Notwendigkeit das Wissen wieder zu entdecken, die Effizienz zu verbessern.


249

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 Zusatz-ressourcen und Kosten innerhalb der IT-Organisation.

Messwert Auswertung der Incident Records mit der Kate-gorie „fehlendes Anwender-Wissen“.

Bemerkung Hierzu können auch die damit verbundenen Be-arbeitungszeiten 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 Ma-nagement 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.


250

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 redu-zieren 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 Hauptaktivi-täten von IT Operation. Bisher wurden in ITIL und der ISO 20000 die Events im Incident Manage-ment 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 Be-

trachtungen als Referenzwert. Sie kann zusam-


251

men mit einer Trend-Darstellung auch als Indiz für die Qualität des Events Managements ge-nutzt werden.

Messwert Ermittlung der Records aus der Event-DB. Bemerkung Hierfür sollte eine Drill-Down-Funktion existie-

ren, 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 Betrach-tungszeitraum.

Relevanz Die Anzahl der Events dient für weitere Be-trachtungen als Referenzwert. Sie kann zusam-men mit einer Trend-Darstellung auch als Indiz für die Qualität des Events Managements ge-nutzt 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, Plattfor-men, 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 Er-eignisse vom System erkannt werden, bevor sie sich zum Beispiel als Störung beim Anwender äußern. Dies führt zu einer höheren Verfüg-barkeit und größeren Kundenzufriedenheit.

Messwert Ermittlung der Records aus der Event-DB und Incident-DB bzw. Problem-DB.


252

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.


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

vice Level. Eine Nicht-Verfügbarkeit wirkt sich unmittelbar auf die Geschäftsprozesse aus. Die-se Kennzahl zeigt an, wie gut diese Incidents / Probleme erkannt werden.


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 behan-delt. Für Auswertungszwecke ist hier eine Eingrenzung der erfassten Vor-gä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 Be-

trachtungen als Referenzwert. Sie kann zusam-men mit einer Trend-Darstellung auch als Indiz für die Qualität des Problem Managements genutzt werden. Eine steigende Anzahl wirkt


253

sich darüber hinaus auf die Kundenzufrieden-heit aus. Bei einer steigenden Anzahl führt de-ren Behebung zu steigenden Prozess- und IT-Kosten.

Messwert Ermittlung der Incident Records aus der Inci-dent-DB.

Bemerkung Die Gesamtanzahl ist allein wenig aussagekräf-tig. 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 Be-

trachtungszeitraum. Relevanz Major Incident führen i. d. R. zu größeren Aus-

fällen des IT Service und so der relevanten Ge-schä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 zwi-schen den Anwendern und dem Service Desk gelöst werden konnten.

Relevanz Eine gute Erstlösungsquote steigert die Anwen-derzufriedenheit 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 Re-duzierung 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-


254

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 zuge-wiesenen 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 Reaktions-zeit bearbeitet wurden.

Relevanz Die Bedeutung ist abhängig von den vereinbar-ten Service Level. Ist die Reaktionszeit als Ser-vice Level vereinbart, so ist deren Einhaltung wichtig für die Kundenzufriedenheit. Innerhalb der IT ist die Reaktionszeit ein wichti-ges Maß für die Bearbeitung von weitergeleite-ten Störungen. Hohe Reaktionszeiten können auf eine zu hohe Arbeitslast für die betroffene


255

Support-Einheit hinweisen. Messwert Mit der Festlegung der Priorität zu einem Inci-

dent wird die vereinbarte Reaktionszeit ermit-telt. Die Kennzahl wird durch Auswertung der Incident Records und dem Vergleich zwischen der geplanten Reaktionszeit und der tatsächli-chen 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än-

gigkeit von IT Service und Priorität (SLA) müs-sen 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 wich-tige Kennzahl für die Effektivität des Prozesses. Durch deren Einhaltung wird die Anwender- und 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


256

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 An-wender wieder arbeiten kann. Es ist mit dem Kunden festzulegen, wann ein Incident als ab-geschlossen 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 Kenn-zahl ist ein Indikator für die Effizienz des Pro-zesses.

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

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

lich 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 notwen-dig.

Name der Kennzahl Anteil fehlerhaft zugewiesener Incidents Definition Die Kennzahl weist die Kosten für die Auf-


257

nahme und Behebung von Incidents aus. Relevanz Werden Incidents einer fehlerhaften Support-

Gruppe zugewiesen, so entstehen zusätzliche Bearbeitungskosten (Effizienz) und die Bearbei-tungszeit verlängert sich (Effektivität).

Messwert Hierzu muss im Incident Record bei einer Wei-terleitung 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 Auf-

nahme eines Incidents fehlerhaft zugewiesener Kategorien aus.

Relevanz Die Kategorisierung unterstützt die Suche von Known Errors, Workarounds sowie die Weiter-leitung von Incidents. Fehlerhafte Kategorien wirken sich negativ auf die Effizienz und Effek-tivitä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 „Re-open“ Aktivität dokumentiert werden. Die An-zahl der Incidents mit dieser Aktivität wird ausgewertet.

Bemerkung Häufig werden Incidents nicht wiedereröffnet, sondern als neue Incidents aufgenommen.


258

5.3.4.3 Request Fulfilment Der Prozess ist für das Management des Lifecycle sämtlicher Service Re-quests 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 Betrachtungs-

zeitraum. Relevanz Die Anzahl der Service Requests dient für wei-

tere Betrachtungen als Referenzwert. Messwert Ermittlung der Service Requests Records aus

der Request-DB. Name der Kennzahl Bearbeitungszeit Service Requests Definition Darstellung der mittleren Bearbeitungszeit "Ser-

vice 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 Bearbei-tungszeit abgeschlossen wurden.

Relevanz Die Einhaltung der vereinbarten Service Re-quest-Zeiten ist eine wichtige Kennzahl für die Effektivität des Prozesses. Durch deren Einhal-tung wird die Anwender- und Kundenzufrie-denheit beeinflusst.

Messwert Dem Service Request muss ein Workflow mit


259

einer geplanten Bearbeitungszeit hinterlegt sein. Auf dieser Basis kann die Einhaltung überwacht werden.

Bemerkung Diese Kennzahl kann als Service Level in Ser-vice-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 verschie-

denen Arten von Service Requests (zum Beispiel Passwort-Reset, Umzug, etc.).

Relevanz Die Kosten werden für die Kalkulation des Ser-vice benötigt. Darüber hinaus zeigt die Kenn-zahl als Trenddarstellung die Effizienz auf.

Messwert Zur Ermittlung müssen zu den einzelnen Akti-vitäten die benötigten Arbeitsstunden erfasst werden.

Name der Kennzahl Kundenzufriedenheit Service Request Definition Grad der Kundenzufriedenheit mit der Durch-

führung von Service Requests. Relevanz Die Kennzahl zeigt die Ausrichtung des Prozes-

ses auf die Geschäftsanforderungen auf. Messwert Abfrage in der Kundenzufriedenheitsumfrage Bemerkung Hier ist zusätzlich auch eine Befragung der

Anwender möglich.


260

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

trachtungen als Referenzwert. Messwert Ermittlung der Problem-Records aus der Prob-

lem-DB. Bemerkung Die Gesamtanzahl ist wenig aussagekräftig.

Hier sollte eine Drill-Down-Funktion auf betrof-fene 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 implementie-ren sind.

Messwert Auswertung der Probleme, die noch nicht abge-schlossen sind

Bemerkung Die Gesamtzahl ist wenig aussagekräftig. Hier sollte die Gesamtzahl aufgebrochen werden in „Problemursache unbekannt“, „Known Error“, „RfC gestellt“


261

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 Kundenzu-friedenheit beeinträchtigt, wenn Incidents wei-terhin auftreten oder nur unzureichende Work-arounds 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 aus-sagekräftig. Hier sollte ein Drill-Down auf be-troffene IT Services, CIs, etc. möglich sein.

Name der Kennzahl RfCs aufgrund von Problemen Definition Anzahl der vom Problem Management initiier-

ten RfCs. Relevanz Eine hohe Anzahl vom Problem Management

eingereichter RfCs kann ein Indiz für die Effek-tivitä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 Inci-dents 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.


262

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 Manage-ment 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 Mana-gement 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 Zugriffsberech-

tigungen im Betrachtungszeitraum. Relevanz Die Anzahl der Anforderungen dient für wei-

tere Betrachtungen als Referenzwert. Messwert Ermittlung der Access-Records aus der Access-

DB. Bemerkung Die Gesamtanzahl ist wenig aussagekräftig.

Hier sollte eine Drill-Down-Funktion auf betrof-fene IT Services, Abteilungen, etc. möglich sein.

Name der Kennzahl Incidents aufgrund fehlerhafter Zugriffsrechte Definition Anzahl der Incidents aufgrund fehlerhaft ver-

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

rung der Zugriffsrechte.


263

Relevanz Die Anzahl der Bearbeitungsinstanzen ist ein Maß für die Effizienz des Prozesses.

Messwert Ermittlung der Access-Records aus der Access-DB und der beteiligten Bearbeiter von der Auf-nahme bis zum Abschluss.

Name der Kennzahl Kosten für Zugriffsberechtigungen Definition Kosten für die Generierungen der Zugriffsbe-

rechtigungen. Relevanz Die Kosten für die Generierungen der Zugriffs-

berechtigungen 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-Re-cords 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 ver-waltet die Incidents und Service Requests und wickelt auch die Kommuni-kation mit den Anwendern ab.Der Service Desk beschreibt die funktionalen Anforderungen an eine Or-ganisation und ist kein Service Management-Prozess. Der Service Desk ist in verschiedene Prozesse eingebunden, mit dem Schwerpunkt in den Pro-zessen Incident Management und Request Fulfilment. In diesem Kapitel werden die Kennzahlen ausgewiesen, die nicht zu den bereits ausgewiese-nen 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 auf-

grund eines zu langen Wartezeitraums den Anruf beenden, ohne mit einem Mitarbeiter des Service Desk gesprochen zu haben. Diese Kenn-


264

zahl ist ein wichtiges Maß für die Anwender- und 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 Telefonan-

ruf entgegengenommen wird, ist ein wichtiges Maß für die Anwender- und Kundenzufrieden-heit.

Messwert Die durchschnittliche Dauer, bis ein Telefonan-ruf entgegengenommen wird, ist der Telefonan-lage (ACD) zu entnehmen.

Bemerkung Diese Kennzahl kann Bestandteil eines SLAs sein.

Name der Kennzahl Gesprächsdauer Definition Durchschnittliche Dauer pro Gespräch (Telefon-

kontakt) mit dem Anwender. Relevanz Das Ziel des Service Desk besteht in der Erreich-

barkeit durch den Anwender. Zu lange Gesprä-che gefährden die Erreichbarkeit für andere Anwender. Daher kann eine maximale Ge-sprächsdauer festgelegt werden. Diese Kenn-zahl zeigt, ob diese Vorgabe erreicht wird.

Messwert Die durchschnittliche Dauer, bis ein Telefonan-ruf entgegengenommen wird, ist der Telefonan-lage (ACD) zu entnehmen.

Bemerkung Diese Kennzahl kann Bestandteil eines OLAs sein.


265

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 Mes-sung von grundlegender Bedeutung. Das CSI beschreibt hierzu den „7 Step Improvement-Prozess“. Ausgehend von „Definition was sie mes-sen wollen“ werden durchzuführende Aktivitäten bis zur „Implementie-rung 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 Manage-

ment identifizierten Probleme. Relevanz Ein proaktives Problem Management steigert

die Service-Qualität und reduziert die Aufwen-dungen für reaktive Maßnahmen.

Messwert Auswertung der Problem-DB. Bemerkung In der ITIL Version 3 gehört das proaktive Prob-

lem Management nicht mehr zu den Aktivitäten des Problem Managements im Service Opera-tion.

5.3.5.2 Service Reporting Der Prozess ist für die Erstellung und Lieferung von Berichten über Leis-tung 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.


266

Name der Kennzahl Kundenzufriedenheit Service Reporting Definition Ergebnis der Kundenzufriedenheit mit dem

Service Reporting. Relevanz Das Service Reporting und die enthaltenen so-

wie dargestellten Informationen müssen den Geschäfts- bzw. Kundenanforderungen entspre-chen.

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

hafte oder inkonsistente Informationen enthal-ten sind.

Relevanz Fehlerhafte Service Reports führen zur Kunden-unzufriedenheit.

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 Kom-ponente, wie eines Servers oder einer Applikation zu messen und zu be-richten. 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 Organi-sationen Gebrauch machen.


267

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 Kosten-gründen diese Messung lediglich für geschäfts-kritische 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 Ein-sparungen (IT / Business)“ und „Mehrwert Bu-siness“ 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


268

Name der Kennzahl Mehrwert Business Definition Mehrwert der durchgeführten Verbesserungs-

maß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 wer-den, um zu beurteilen, welche Verbesserungsmaßnahmen sinnvoll sind und dem Business den größten Nutzen bringen. Name der Kennzahl Kundenzufriedenheit Verbesserungsmaßnah-

men Definition Ergebnis der Kundenzufriedenheit mit den

identifizierten und umgesetzten Verbesserungs-maßnahmen.

Relevanz Die Kennzahl identifiziert die Einbeziehung des Business in das Continual Service Improvement.

Messwert Abfrage in der Kundenzufriedenheitsumfrage.

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 ver-bundenen Kennzahlen betreffen die Maßnahmen innerhalb des Continual Service Improvements.

269

6 Lessons learned: Empfehlungen und Ratschläge

6.1 Management Summary Wir haben viele ITIL-Projekte durchgeführt, geleitet oder wenigstens be-gleitet. 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. Ins-besondere 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 unterneh-mensspezifischen IT Service Management-Prozesse definieren und designen. Hierzu kann ITIL einen wichtigen Beitrag leisten, darf da-bei 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 verbes-sern.

– Faktisch etabliert die Einführung von durchgängigen IT Service Ma-nagement-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 Lie-feranten. Sie müssen sicherstellen, dass die organisatorische Veran-kerung 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änderungsmanage-ment werden die an das Projekt bzw. an die späteren Prozesse ge-richteten Erwartungen nicht erfüllt. Ein fehlendes Veränderungsma-nagement wird Zeitverschiebungen und Zusatzaufwendungen her-vorrufen. Im schlimmsten Fall kann es zum Scheitern des gesamten Vorhabens führen.


270

6.2 ITIL-Einführung

6.2.1 Analyse der bestehenden Prozesse Auf den ersten Blick mag es kurios erscheinen, aber jede – auch Ihre – IT-Organisation betreibt bereits IT Service Management-Prozesse. Zielset-zung 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 Mitarbei-ter ggf. noch nicht ausreichend kennen. Eine Lösungsmöglichkeit für Sie und die im Vorhaben involvierten Mitar-beiter 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ück-greifen. Berater bieten i. d. R. zusätzlich den Vorteil, nicht nur über das theoretische Grundwissen, sondern auch über Erfahrungen in vergleichba-ren Projekten zu verfügen. Besonders wichtig bei diesem Ansatz: Sie müs-sen 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 Wis-senstransfer sicherstellt.

Fungiert Ihr Berater nicht als Coach, so kann sowohl die Implementierungsana-lyse, 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 Pro-zesse wird sinken.

Auf der Basis von ITIL sollten Sie analysieren und vergleichen, welche der dort beschriebenen IT Service Management-Prozesse und Aktivitäten be-reits (zumindest vermeintlich) in Ihrer IT-Organisation etabliert sind. Da-bei ist zunächst eine generische Betrachtung der Prozesse ausreichend. Als Hilfestellung hierbei bietet sich eine tabellarische Darstellung an: Tra-gen 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, Me-thoden und Nutzungsgrad. Diese ITIL-Prozesslandkarte ist eine erste, einfache Darstellung des bestehenden Reifegrades, die Sie gemeinsam aus

Berücksich-tigung bestehender Prozesse


271

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 Beteili-gung 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 ech-te 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 betrof-fenen Personen haben. Sie benötigen eine objektive Feststellung der Ist-Situation und keine geschönte Darstellung. Eröffnen Sie Ihren Mitarbeitern die Chance zur Offenheit und verzichten Sie auf Rügen für „Fehlverhal-ten“. Geben Sie ihren Mitarbeitern die notwendige Sicherheit für eine un-geschö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 be-werten und mit anderen IT-Organisationen vergleichen. Die Nutzung der ITIL Best Practices zur Optimierung der IT Service Ma-nagement-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, wer-den häufig externe Berater frühzeitig mit den Durchführungsleistungen beauftragt. Die Gefahr bei diesem Szenario liegt in den auftretenden Ak-zeptanzproblemen: 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 Akzep-tanz der geplanten Maßnahmen und die damit verbundene Verzögerung bei der Umsetzung.

Initiierung der geplanten Maßnahmen


272

Konsequenz hieraus: Der eigenen Organisation muss nun die Chance ge-geben 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 Ma-nagements. 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äfts-prozesse Ihres Kunden. Nutzen Sie solche Beispiele und stellen Sie heraus, welche Vorteile Ihnen ein IT Service Management nach ITIL hierbei gebo-ten hätte. Sie können auch den Weg über Konferenzen wählen, wie zum Beispiel das ITIL-Forum, um von den Erfahrungen anderer IT-Organisati-onen zu profitieren. Als Grund für die Einführung von ITIL werden häufig die damit erreich-bare höhere Servicequalität und die bessere Ausrichtung auf die Ge-schä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 Ein-führung von ITIL verbundenen Investitionen amortisieren.

Ganz gleichgültig, ob die Nutzung der ITIL Best Practices vom Manage-ment 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.


273

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 Kun-den bzw. dem Markt zu. Häufig verlangen Ihre Kunden in Angebotsauf-forderungen oder bei Ausschreibungen, dass die anbietende IT-Organisa-tion (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 Implementierungs-projekt wird unter diesen Voraussetzungen in der Regel mit einem höhe-ren 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-Pro-zesse zu etablieren, so müssen Sie Ihren Mitarbeitern die damit verbunde-nen Ziele vermitteln. Mit der Einführung von Prozessen soll eine Messbar-keit des IT Service Managements und eine Identifizierung von Schwach-stellen 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 outge-sourced“. Versuchen Sie diesen Ängsten mit Gegenbeispielen aus anderen IT-Organisationen zu begegnen. Erklären Sie Ihren Mitarbeitern, dass Outsourcing in der Regel keinen Sinn macht, wenn die Prozesse in der IT-Organisation gut funktionieren, trans-parente Services und Leistungen erbracht und die gesetzten Ziele erreicht werden. Stellen Sie den mit IT Service Management angestrebten Nach-weis der eigenen Leistungsfähigkeit als möglichen Schutz vor Outsourcing heraus.


274

Informieren Sie Ihre Mitarbeiter frühzeitig über die geplanten Maßnahmen und die damit verfolgten Ziele. Motivieren Sie die Mitarbeiter und begegnen Sie den Ängsten Ihrer Mitarbeiter.

Für eine erfolgreiche Etablierung der geplanten IT Service Management-Prozesse 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ög-lichkeiten der ITIL Best Practices auf, um diese Prozesse weiter zu verbes-sern. Ihre Mitarbeiter sollten ITIL als Angebot verstehen, auf das darin dokumentierte Wissen zurückzugreifen. Dafür muss ITIL als Chance ge-sehen 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 ganz-heitliche Betrachtung der IT in Ihrer Organisation zu verankern.

6.2.2 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 Manage-ment-Prozesse aus Ihrer IT-Organisation heraus, von Ihren Mitarbeitern entwickelt werden. Ihre Mitarbeiter können dabei Ihre praktischen Erfah-rungen einbringen und so sicherstellen, dass die geplanten Prozesse auf die Geschäftsprozesse Ihres Kunden ausgerichtet sind sowie den Anforde-rungen 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.

Wertschät-zung des Bestehenden

Selbst erarbeiten statt fertig kaufen


275

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 Pro-jekten 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 zusammen-zuarbeiten. Hierbei kann es sich unter Umständen um Berater handeln, die im Rahmen von IT Governance-Projekten tätig sind oder die Verände-rungsprozesse 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 pra-xisorientiert 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 „Einhal-tung 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ßnah-men zu informieren; in Teilbereichen wird möglicherweise die Zustim-mung des Betriebsrates erforderlich sein.

Informieren und beteiligen Sie den Betriebsrat frühzeitig. Unterstreichen Sie, dass Prozesse ausgewertet werden sollen und nicht die Leistung einzelner Mit-arbeiter. Machen Sie klar, dass die geplanten Maßnahmen der internen Optimie-rung 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 Meilenstei-nen informiert. Es wurde mit dem Betriebsrat vereinbart, dass die

Einbeziehung des Betriebs-rats


276

Prozesse gemessen werden und keine Auswertung auf Mitarbeiter-ebene 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 Prozess-Manager beteiligt werden.

– Eine detaillierte Absprache der geplanten und erhobenen Kennzah-len mit dem Betriebsrat liegt in der Verantwortung der eingesetzten Prozess-Manager.

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 IT-Organisation. Wie bei allen Veränderungsmaßnahmen wird hierzu eine ausreichende Zeit benötigt. Die Mitarbeiter müssen die Veränderungen adaptieren und verinnerlichen. Eine Veränderung über Nacht ist nicht zu erzwingen. Ebenso ist es nicht ratsam, zu große Veränderungen auf einmal durch-zuführen. Sie sollten unbedingt stufenweise vorgehen. Dies gilt sowohl für die Ge-samtheit aller IT Service Management-Prozesse, als auch innerhalb der einzelnen Prozesse. Es ist wenig ratsam, sämtliche IT Service Manage-ment-Prozesse gleichzeitig zu implementieren. In der Regel beginnt man mit der Implementierung des Service Level Ma-nagements, 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 Business-prozesse. Ebenso sollte der Reifegrad, d.h. die Qualität der einzelnen Prozesse schrittweise gesteigert werden. Die Veränderungen müssen von den Mit-arbeitern 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 ver-traut 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.

Qualität vor Geschwindigkeit


277

6.2.3 Die Organisation gewinnen Innerhalb Ihrer IT-Organisation existieren verschiedene Interessengrup-pen. Sie müssen die Motivation der einzelnen Interessengruppen identifi-zieren und sie anschließend auf Basis der identifizierten Motivations-gründe für ITIL gewinnen. Eine wichtige Motivation zur Nutzung von ITIL besteht in der bereits be-schriebenen Chance, die IT-Organisation und sich persönlich weiterzuent-wickeln. 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 etab-liert, 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 Manage-ment-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 Kosten-betrachtungen und einen häufig gegebenen Wachstums- oder Konsoli-dierungsdruck 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 durch-gefü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. Kommunikati-onsprobleme innerhalb der IT-Organisation und die Vernetzung der ein-zelnen 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.


278

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: 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 Re-porting 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 Kosteneinsparun-gen 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 IT-Infrastruktur erzielt wurden.

6.2.4 Rollenbeschreibungen Innerhalb der ITIL Best Practices bis Version 2 finden Sie Rollenbeschrei-bungen zu den einzelnen Prozess-Managern der IT Service Management-Prozesse. 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 Pro-cess Owner sind der Originalliteratur zur ITIL Version 2 nicht zu entneh-men. 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 Rollen-beschreibungen sind im Rahmen der Umsetzung entsprechend der jeweili-gen Organisation zu operationalisieren.

Der Gewinn für die Organisation

Die Rollen gemäß der ITIL Best Practices


279

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 Weisungs-rechten innerhalb seines Prozesses ausgestattet sein. Die Prozess-Ziele werden nicht nur primär vom Process Owner vorgege-ben, sondern auch durch ihn aus der IT-Strategie und der Balanced Score-card abgeleitet. Aus diesen Anforderungen heraus definiert der Prozess-Manager die notwendigen Prozess-Ziele und die damit verbundenen Kennzahlen. Es muss sichergestellt werden, dass die Prozess-Manager ein Grundver-ständnis aller IT Service Management-Prozesse haben. Dadurch wird ei-nerseits erreicht, dass der eigene Prozess hinsichtlich seiner Schnittstellen, Abhängigkeiten und Verzahnungen besser gemanagt werden kann. Ande-rerseits motivieren diese Kenntnisse und die damit verbundenen Auf-stiegsmö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 die-se wichtige Rolle wie folgt: „Einzelne Prozess-Ziele können partiell miteinander konkurrieren, Umset-zungsmaß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ür-lich 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, Markt- und Kunden-Analyse, Lieferanten-Management, Inventarisierung, Kosten Ma-nagement und insbesondere das Auslieferungs- und Lebenszyklus-Management von Produkten und Services.

Die Rolle des Prozess-Managers

Die Rolle des Service Managers


280

Für die Einführung der IT Service Management-Prozesse und der identifi-zierten Optimierungsmaßnahmen ist der Service Manager richtungs-weisend, er erstellt den „Bebauungsplan“.

Die Rolle des Service Managers muss mit einem erfahrenen Manager besetzt werden.

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 Manage-ment-Prozesse. Mit der Implementierung der neuen IT Service Management-Prozesse kann vorübergehend eine Phase der Instabilität entstehen. Mit den bisheri-gen Abläufen waren die Mitarbeiter vertraut, mit den neu implementier-ten Prozessen sind sie es noch nicht. Erworbene Kompetenzen, gehen un-ter 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.

Das mittlere Management setzt einerseits die Vorgaben des Top-Manage-ments im täglichen Betrieb aktiv um. Andererseits muss es die Prozess-Manager unterstützen und ihnen den erforderlichen Freiraum verschaffen. Die Einführung von durchgängigen Prozessen mit dezidierter Prozessver-antwortung 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 wer-den, 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.

Mit der Einführung von IT Service Management-Prozessen kann sich die Rolle von Mitarbeitern im IT Service aus deren Sicht verkomplizieren. Waren sie vorher ausschließlich einem Vorgesetzten verantwortlich (und dort der Ergebniserbringung), wird ihre Tätigkeit nun in verschiedenen Prozessen überwacht, und die Weisungen unterschiedlicher Prozess-Manager steuern auf Qualitätsebene die operative Arbeit der Mitarbeiter.

Die Rolle des Top-Managements

Die Rolle des mittleren Managements

Die Rolle der Mitarbeiter

6.3 Kontinuierlicher Verbesserungsprozess

281

Stellen Sie sicher, dass Ihre Mitarbeiter sich in dieser Situation nicht verlo-ren vorkommen. Die Hierarchie, insbesondere das mittlere Management, muss die Prozesse aktiv unterstützen, um damit die Ziele der ITIL-Einfüh-rung nachhaltig zu unterstützten. Die Prozess-Manager geben den Mitarbeitern „Leitplanken“ (Prozessleitli-nien) 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 Unter-nehmen. 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 Implementie-rung Ihrer IT Service Management-Prozesse genutzt werden können, müs-sen Sie einen Veränderungsprozess in Ihrer IT-Organisation initiieren. Ohne flankierende Maßnahmen führt das „Einführen“ von ITIL zu Akzep-tanzproblemen 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 IT-Organisation gelebt werden. Dazu müssen Ihre Mitarbeiter die Prozesse verste-hen, mitgestalten und insbesondere die Erfolge erfahren.

6.3 Kontinuierlicher Verbesserungsprozess Eine wichtige Komponente der ITIL Best Practices ist das im konzeptiona-len Ansatz enthaltene Qualitätsmanagement. Hierzu verweisen die ITIL Best Practices auf verschiedene Methoden wie zum Beispiel auf „Six Sig-ma“ 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 Pro-zesse ist, dass Sie eine fortlaufende Überprüfung, ein Monitoring sämtli-cher implementierten IT Service Management-Prozesse durchführen. Auf die dazu notwendige Ermittlung von Kennzahlen wird im nächsten Kapi-tel eingegangen.


282

In der Publikation „Best Practice für Service Support“ vgl. [OGC, 2005b]) heißt es hierzu: „Dieser Ansatz bedingt, dass ein Unternehmen nach defi-nierten Prozessen agiert, seine Aktivitäten in Bezug auf die Zielerreichung misst, sowie die aus den Prozessdurchläufen folgenden Outputs im Hin-blick auf mögliche Prozessverbesserungen überprüft.“

Abbildung 82: Deming (oder PDCA) Zyklus

Die Norm ISO 20000, der (einzige) internationale Standard für das IT Ser-vice Management, konkretisiert diesen Ansatz der ITIL Best Practices wei-ter. 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 Verbesse-rungsmaß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 Informa-tionen können Sie den im Quellenverzeichnis aufgeführten Publikationen zu ISO 20000 entnehmen.

Ein professionelles IT Service Management bedingt unabdingbar die stetige Mes-sung der Prozesse und die Identifikation von möglichen Verbesserungsmaßnah-men (KVP: Kontinuierlicher Verbesserungs-Prozess).


283

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-Prozes-sen befinden sich dabei in einer vermeintlich komfortablen Ausgangsposi-tion: 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 spe-ziell die Prozess-Manager von bestehenden Prozessen benötigen die inten-sivste Unterstützung durch eine externe Begleitung.

Sie müssen die IT Service Management-Prozesse, die am weitesten entwickelt sind (mit der höchsten Prozessreife), besonders eng begleiten.

Ansonsten besteht die große Gefahr, dass sich der betroffene Prozess-Manager aufgrund der durchgeführten Ist-Aufnahme (ITIL-Prozessland-karte) 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 Be-gleiters ist es, als Coach den Prozess-Manager „einzufangen“. Durch die Forcierung der Vernetzung vermeiden Sie eine isolierte Opti-mierung einzelner IT Service Management-Prozesse, die ansonsten den anderen Prozessen davoneilen würden. Die isolierte Optimierung einzel-ner Prozesse kann zu Mehraufwendungen führen, wenn später die not-wendigen Schnittstellen und unter Umständen damit verbundene Aktivi-täten angepasst werden müssen.

Es ist für Ihre IT-Organisation von großem Vorteil, wenn eine gleichmäßige ver-tikale Entfaltung der geplanten IT Service Management-Prozesse betrieben wird.

Diese Forderung bedeutet nicht, dass Sie alle IT Service Management-Pro-zesse gleichzeitig einführen sollen. Es ist vielmehr pro Projekt- bzw. Imp-lementierungsphase eine synchrone Entwicklung der einzelnen Prozesse sicherzustellen.


284

Dem Prozess-Manager mit dem bereits am weitesten entwickelten Prozess kommt hierbei eine besondere Rolle zu. Er muss auf die anderen Prozess-Manager zugehen und die Vernetzung der einzelnen Prozesse aktiv voran-treiben und sicherstellen. Planen Sie zum Beispiel die Etablierung des Incident, Problem und Chan-ge Managements und ist der Prozess des Incident Managements am wei-testen fortgeschritten, so muss der Prozess-Manager des Incident Manage-ments die führende Rolle bei der erforderlichen Vernetzung der drei Pro-zesse 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 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 ruhi-gen 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 ver-bundene (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ände-rungsmanagements. Der Soziologe Kurt Lewin gilt als Wegbereiter der Organisationsentwick-lung. 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]).

Nicht zu früh beginnen


285

Neue Welt

Alte Welt

Einfrieren

Bewegen

Auftauen

Neue Welt

Alte Welt

Einfrieren

Bewegen

Auftauen

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-Organisatio-nen erzielten Erfolge verwiesen werden. Die bestehende IT-Organisation wird „aufgetaut“. Ist das „Auftauen“ der IT-Organisation (und der Mitar-beiter) erreicht, werden in der Phase der „Bewegung“ neue Prozesse imp-lementiert und die Mitarbeiter in deren Handhabung ausgebildet und eingewiesen. Es ist dann von großer Bedeutung, dass dieser Zustand zunächst „einge-froren“ wird. Mit den alten Abläufen waren Ihre Mitarbeiter vertraut. Die Implementie-rung der neuen IT Service Management-Prozesse führt zu einer Instabilität. Die Mitarbeiter sind mit den neuen Prozessabläufen und den damit ver-bundenen Abläufen noch nicht vertraut. Sie fühlen sich unsicher. Ihre Aufgabe besteht jetzt darin, den Mitarbeitern die notwendige Sicher-heit 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.


286

Erst wenn die Mitarbeiter mit den neuen Prozessaktivitäten vertraut sind, sollten Sie eine weitere Verbesserung und Erweiterung des Prozesses an-gehen. Zusätzlich ist die Phase des „Einfrierens“ für die Motivation Ihrer IT-Organisation 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 Aktivi-tä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ög-lich 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 Vor-teile dieser Prozess in der täglichen Arbeit bietet. Damit stellen Sie die Motivation der Mitarbeiter für weitere Verände-rungsmaß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. 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 konse-quenter. 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 Umset-zung 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 wie-der das Tagesgeschäft das Geschehen. Bis zum nächsten akuten Auftreten eines Problems gerät die identifizierte Schwachstelle samt Optimierungs-bedarf wieder in Vergessenheit. Ein Service Improvement-Programm und die Möglichkeit, dass jeder Mit-arbeiter hierzu einen Input liefern kann, hilft Ihnen nachhaltig, die Quali-tät der Prozesse und des IT Service zu verbessern.

Ihre Mitarbeiter haben mit dem Service Improvement-Programm die Chance, sich einzubringen und zu erleben, wie sie persönlich zum Erfolg der IT-Organisation beitragen.

Das Service Improvement-Programm


287

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 Ser-vice Improvement-Plan und die Erstellung einer Umsetzungsplanung. Die Einführung und der Ausbau der IT Service Management-Prozesse sollten in Stufen und mit Stabilisierungsphasen (Projektpausen) erfolgen. Dazu muss der Prozess-Manager die zuvor geplanten Projektphasen sowie den Input aus dem SIP bewerten, die mit den Maßnahmen verbundenen Vorteile identifizieren und die Umsetzung planen. Diese „Verbesserungstätigkeit“ ist mit dem IT Service Management-Pro-zess des Release Management vergleichbar. Es ist nicht zweckmäßig, eine Reihe von Änderungen jeweils einzeln und nacheinander zu implementie-ren. Sie sollten vielmehr die Einzelmaßnahmen bündeln und als Aufga-benpaket (Release) durchführen.

Bündeln Sie die einzelnen Verbesserungs- und Erweiterungsmaßnahmen zu ei-nem Aufgabenpaket (Release).

Dem Process Owner kommt hierbei als Coach eine qualitätssichernde Auf-gabe zu. Zum Beispiel hat der Process Owner beim Prozess-Manager kri-tisch zu hinterfragen, ob die nächste Umsetzungsmaßnahme sowohl in-haltlich als auch vom Zeitpunkt her die IT-Organisation nicht überfrachtet. Sobald diese Abstimmung erfolgt ist, muss der Prozess-Manager die ge-planten Verbesserungen und Erweiterungen in der IT-Organisation ge-genü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 Inci-dent, 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 Mana-ger (beraten und unterstützt durch die Process Owner, als auch die IT-Leitung) – und dem prozessverantwortlichen Prozess-Manager.

ITIL-Einführung erfordert ein Release

Der Entfaltungs-prozess


288

Es ist hilfreich, wenn die Process Owner für alle IT Service Management-Prozesse zu Beginn benannt werden, auch wenn die Prozesse noch nicht implementiert wurden. Die Prozess-Manager können mit der Entschei-dung des Managements über die Einführung eines Prozesses benannt werden. Wichtig ist, nicht nur die implementierten Prozesse hinsichtlich ihrer Ziel-erreichung 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 ver-folgt werden kann, könnten die obigen Stufen der IT Service Management-Prozesse mit einem Ampelsystem dargestellt werden. Für die Gestaltung des Ampelsystems empfiehlt es sich, auf der vertikalen Achse die unter-nehmenswichtigen Prozesse (z.B. Incident, Problem, Change aufzuführen etc.) und auf der horizontalen Achse die involvierten Gruppen, Abteilun-gen, 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 In-formationen ü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 Vor-schläge zur Verbesserung); die Prozesstools werden ausgereizt.

– Stufe 4: die Organisation denkt darüber nach, Erweiterungen und Verbesse-rungen 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 Mana-gement – über ein gutes Führungssystem zur Überwachung der geplanten Maßnahmen und der erzielten Prozessreife.


289

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 Wirk-samkeit in der Linie überprüfen.

6.3.3 Wettbewerb der Prozesseinführung Für die Einführung der IT Service Management-Prozesse werden so ge-nannte „Quick-Wins“ benötigt. In unserer schnelllebigen Zeit akzeptiert kein Management mehr Projekte, deren erste Erfolge nach 9 Monaten ein-treten. Daher müssen die Prozess-Manager bei der Prozesseinführung die Quick-Wins 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änderungs-management 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 Kommunikationsplatt-form. 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 Bei-spiel 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 de-monstrieren, wie mithilfe des Configuration Managements sehr viel schneller wichtige Informationen abgerufen werden können. Dadurch, dass die Prozess-Manager erste Erfolge aufzeigen, entsteht in-nerhalb der IT-Organisation ein Wettbewerb der Prozesseinführung. An-dere Prozess-Manager haben ein Interesse daran, ebenfalls Erfolge aufzu-zeigen. Es entsteht eine Sogwirkung. Durch die gemeinsame Kommunikationsplattform ist die notwendige Transparenz gegeben. Zusammen mit dem kontinuierlichen Verbesse-


290

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ür-fen nicht zu einer Behinderung des Betriebs innerhalb Ihrer IT-Organisa-tion 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 ent-steht 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 hinter-lä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üh-rungsphase kann zu diesen Problemen führen. In der Regel werden große Defizite zu den ITIL Best Practices identifiziert, und die Mitarbeiter ver-binden dies mit einer Disqualifikation ihrer Leistungen und ihres Know-how. Der Berater muss daher unbedingt als Coach auftreten. Erfahrene Berater sind in der Lage, sich durch eine kurze Bestandsaufnahme einen Eindruck zu verschaffen, der für eine Planung der notwendigen Maßnah-men 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 Über-prüfung erst dann erfolgt, wenn eine reelle Chance besteht, dass die An-forderungen erfüllt werden können. Mit einer externen Zertifizierung können Sie Ihre Mitarbeiter weiter moti-vieren und in Ihrer IT-Organisation den Erfolg der vollzogenen Verände-rungsmaßnahmen nachweisen. Die Zertifizierung nach der ISO 20000 be-legt, 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 Wert-schätzung zu geben und das bisher Erreichte positiv unterstreichen zu können.

6.4 Kennzahlen

291

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 IT-Organisation, welche IT Services, welche Service Level und welche Mes-sungen realistisch zugesichert werden können. Sie vermeiden dadurch eine falsche Erwartungshaltung bei Ihrem Kunden. Holen Sie dann unbe-dingt Ihren Kunden ab, erläutern Sie ihm die jetzige Situation, gehen Sie ggf. auf die Kostensituation ein und binden Sie ihn in die weitere Entwick-lung 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 rele-vanten 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 Aus-richtung auf die Geschäftsprozesse Ihres Unternehmens zu überprüfen. In diesem Kapitel stellen wir Ihnen vor, wie Sie Ihre IT Service Manage-ment-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 Transi-tion Management weiterhin notwendig bleibt.


292

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 ge-wä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 opti-malen Beitrag der vom Prozess verfolgten geschäftlichen Zielsetzung leis-ten, 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 Ser-vice Management-Prozessen abzeichnen.

Die Prozesssteuerung von IT Service Management-Prozessen ist ohne Kennzah-len unmöglich. Sie benötigen Kennzahlen für jeden einzelnen IT Service Manage-ment-Prozess.

Die Kennzahlen werden dabei zum Teil aus den operativen Systemen ge-wonnen, wie zum Beispiel aus den in einem Tool für das Incident Manage-ment dokumentierten Aktivitäten. Die gespeicherten Informationen wer-den dabei zu aussagekräftigen Kennzahlen verdichtet, mit denen die Ef-fektivitä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 mes-sen und haben dadurch die Basis für ein erfolgreiches Management der Prozesse geschaffen.

Ein Nutznießer der Kennzahlen ist Ihr IT-Management, z.B. Gruppen- oder Abteilungsleiter. Anhand weniger signifikanter Kennzahlen kann sich das IT-Management einen Überblick über die aktuelle Situation ver-schaffen.

6.4 Kennzahlen

293

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 Mitar-beiter. Ein sprunghaftes Ansteigen von Incidents kann auf eine Flächen-störung hinweisen. Das Management sollte jeweils die Gründe hinterfra-gen 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 un-bedingt 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% erfor-dern 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 einfa-chen Kennzahlen beginnen. Komplexere Kennzahlen – z.B. „Wie viele Incidents werden auf Probleme referenziert?“ – sollten erst in einer zwei-ten oder dritten Stufe des kontinuierlichen Verbesserungsprozesses (KVP) angewandt werden. Für das Incident Management ist es zunächst ausreichend, wenn Sie fest-stellen, wie viele Incidents überhaupt gemeldet und bearbeitet werden. Die Verfolgung des Trends der Incidents und die Identifizierung signifi-kanter 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 „We-niger ist oft mehr“. Wenn noch keine Messwerte vorliegen, sollten Sie sich zu-nächst auf wenige signifikante Kennzahlen konzentrieren.

Wenige, der IT-Organisati-on nutzbrin-gende, Kenn-zahlen


294

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. Wer-den 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 Pub-likationen. 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 Kenn-zahlen 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 Linien-organisation kann der Process Owner geben. Aufgrund der Anforderun-gen 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 be-einflussbar sein. Kann ein Linien-Manager die Kennzahlen nicht sinnvoll nutzen, so findet ITIL beim Management keine Anerkennung! Im Rahmen der schrittweisen Weiterentwicklung Ihrer IT Service Manage-ment-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

Schrittweise Erweiterung der Kennzah-len

6.4 Kennzahlen

295

dokumentierten Kennzahlen auf sinnvolle Nutzung in Ihrer IT-Organisati-on, 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 Anfor-derung als Stufe Ihres KVP planen und nicht zu Beginn des Prozesses in-tegrieren. 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 Ser-vices und unterstreicht insbesondere die Bedeutung von Kundenbeziehun-gen. Dies bedeutet, dass die IT-Organisation bereitstellen sollte, was im-mer mit dem Kunden vereinbart wurde, was wiederum eine enge Bezie-hung zwischen der IT-Organisation und deren Kunden und Partnern vor-aussetzt.“ Planen Sie die Einführung von „kundennahen“ IT Service Management-Prozessen (z.B. Service Level Management oder Financial Management for IT Services), sollten Sie vorab die Erwartungshaltung des Kunden in Er-fahrung 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 An-satz führt damit zu einer „end-to-end“-Messung des IT Service.

Den Kunden rechtzeitig einbinden.


296

Diese „end-to-end“-Messungen können jedoch zurzeit in vielen Unterneh-men noch nicht durchgeführt werden, da die notwendigen Werkzeuge fehlen. Die Implementierung dieser Werkzeuge ist in der Regel – in Ab-hängigkeit von den betrachteten IT Services und der genutzten IT-Infra-struktur – mit nicht unerheblichen Investitionen verbunden.

Eine kunden- bzw. serviceorientierte Messung und ein entsprechendes Repor-ting, d.h. die Realisierung einer „end-to-end“-Messung, sollte zumindest mittel- bis langfristig Ihr Ziel sein. Da dieses Ziel häufig nicht kurzfristig erreichbar ist, sollten Sie gemeinsam mit dem Kunden machbare Lösungen definieren.

Prüfen Sie zunächst, was zurzeit an Messungen und damit an verbindli-chen 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 Pro-zess-Manager sollte dies gemeinsam mit dem für den Kunden verantwort-lichen 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 Rela-tionship-Manager, der den Kunden strategisch verantwortet, vorgenom-men. Die innerhalb Ihrer IT-Organisation bestehenden Möglichkeiten zur Defi-nition 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 mach-bar ist – auf den Kunden zu. Ist dieser Vorschlag dem Kunden nicht aus-reichend, so seien Sie offen für die Anforderungen Ihres Kunden. Zeigen Sie dem Kunden aber auch die damit für ihn ggf. verbundenen finanziel-len 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 selbstver-stä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.

6.4 Kennzahlen

297

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-Fak-tor“. Gibt es innerhalb Ihrer IT-Organisation in bestimmten Bereichen besonderen Handlungsdruck, so empfiehlt sich eine Priorisierung derjeni-gen 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-Pro-zess priorisiert eingeführt werden. Ein weiterer wichtiger Aspekt für die Priorisierung von IT Service Mana-gement-Prozessen ist das Wissen um die Geschäftsstrategie Ihres Kunden. Sie müssen diese Strategie verstehen, um zu entscheiden, wie Sie ihre Pro-zessentfaltung 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ön-nen 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 IT-Stö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 reduzie-ren Aufwände für Folge-Maßnahmen und tragen so mit dem Change Ma-nagement zu einer weiteren Kosteneinsparung bei.

So wie die Geschäftsstrategie Ihres Kunden in die IT-Strategie einfließt, so beein-flusst die Geschäftsstrategie auch die Einführungsplanung Ihrer IT Service Ma-nagement-Prozesse.

Auch wenn Sie über erste Kennziffern verfügen, sollten Sie Ihrem Kunden keine technischen Kennziffern berichten.

Die Strategie des Kunden verstehen


298

Grundsätzlich besteht Ihre Verantwortung darin, Ihrem Kunden die er-reichten Service Level zu berichten. Es gilt die Maxime, dieses Reporting in einer Sprache und Darstellung vor-zunehmen, die der Kunde versteht, also in der Sprache des Kunden, nicht in der Sprache des Technikers. Beispielsweise kann es sinnvoll sein, darzu-stellen, welche Folgen Störungen hatten, welche Konsequenzen ein Ausfall einzelner Standorte hatte und welche Verbesserungsmaßnahmen eingelei-tet 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 unse-ren 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 Manage-ment-Prozesse gestaltet und eingeführt haben, bedarf es eines regelmäßi-gen 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 Berei-chen vor. Falls Sie eine Zertifizierung Ihrer IT Service Management-Prozesse durch-führen, wird von der Zertifizierungsorganisation auch geprüft, ob eine Aus- und Weiterbildungsplanung existiert, und mögliche Defizite werden aufgezeigt. Das Top-Management, der Service Manager, die 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.

Das Repor-ting der Kennzahlen muss kunden-orientiert erfolgen

Das Manage-ment hat die Weiterent-wicklung zur Aufgabe

6.4 Kennzahlen

299

Die dokumentierten ITIL Best Practices unterliegen zwar einer stetigen Weiterentwicklung, aber diese geht erst mit einem Zeitverzug in die offi-ziellen Publikationen ein. Auf Kongressen, wie dem ITIL-Forum oder dem Jahreskongress der itSMF Deutschland e.V., wird aktuell über Erfahrun-gen 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-Orga-nisation 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 Pro-zess-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-Organi-sationen 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. Ge-gebenenfalls könnte dies auch von einem Service Manager mit ent-sprechender Schulungserfahrung übernommen werden.

– Sind die theoretischen Aspekte bekannt, so sollten die Prozess-Manager die Mitarbeiter in denjenigen Prozessen schulen, in denen diese eingebunden sind. Hierbei wird insbesondere geschult, wie die jeweiligen Prozesse innerhalb der jeweiligen Organisation des Unternehmens ihre Anwendung finden (von der Theorie zur Praxis).

– Sind die IT Service Management-Prozesse auf Basis der ITIL Best Practices eingeführt, so ist unbedingt darauf zu achten, dass es re-gelmäß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 Pro-zesse kennen und verstehen. Sie müssen sicherstellen, dass dieses Verständnis auch bei neuen Mitarbeitern ausreichend gegeben ist.

Mitarbeiter müssen ge-schult werden


300

Sie werden wahrscheinlich feststellen müssen, dass die Prozesse nach der Implementierung und längerem Betrieb auf Mitarbeiter-Ebene „einschla-fen“. Der bei der Einführung vorhandene Elan geht im Laufe der Zeit ver-loren. Die Aktivitäten erstarren in Routine. Dem Prozess-Manager kommt hier eine weitere wichtige Aufgabe zu. 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 ver-hindern. Besondere Aufmerksamkeit benötigen bereits länger eingeführte Pro-zesse.

Zerschlagen Sie nicht unnötig erfolgreiche Prozesse. Drücken Sie vielmehr Ihre Wertschätzung aus und motivieren Sie Ihre Mitarbeiter, diese Pro-zesse 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 ver-netzt werden. Vermeiden Sie ein unkontrolliertes Davoneilen einzelner Prozesse. Diese Entwicklungen zu kontrollieren und zu steuern ist Auf-gabe 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 ma-chen, sollten Sie Ruhe- und Stabilitätsphasen in der Entwicklung der Pro-zesse einplanen. Ansonsten können in einem permanenten Veränderungs-prozess die Erfolge nicht mehr spürbar gemacht werden. Darüber hinaus fördert das Aufzeigen von Erfolgen in einem Prozess den Wettbewerb unter den Prozess-Managern. Der Service Manager benötigt ein System zur Messung und Verfolgung der Prozess-Fortschritte. Im Beispiel hat sich hierzu ein Ampelsystem be-währt. Damit werden auch für die Prozess-Manager die erzielten Erfolge sichtbar. Die IT Service Management-Prozesse haben eine eindeutige Ausrichtung auf die Geschäftsprozesse Ihres Kunden und müssen daher Bestandteil Ihrer IT-Strategie sein. Diese Anforderung bedeutet nicht nur, dass die IT Service Management-Prozesse aufgrund Ihrer IT-Strategie eingeführt werden, sondern auch, dass sich deren Ziele stets aus der IT-Strategie ableiten.

Der Prozess-Manager sorgt dafür, dass Prozesse gelebt werden

6.4 Kennzahlen

301

Logische Konsequenz hieraus ist, dass sich auch die Kennzahlen und de-ren 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 Management-Prozesse 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 Abteilungs-grenzen 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 Prozess-Manager.

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 Manage-ment von existenzieller Bedeutung und damit auch die organisatorische Verankerung dieser Rolle. Die IT Service Management-Prozesse sollen sicherstellen, dass die IT Servi-ces 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.

Die Balanced Scorecard er-möglicht die Ausrichtung auf die IT-Strategie


302

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 Ver-knü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 IT-Organisationen verfügen. Häufig ist der Service Manager im Bereich der Kundenschnittstelle ange-siedelt 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 angesie-delt 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 Pro-cess 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 be-setzt, 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 Auswir-kungen 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 Rechenzent-rums unseres Beispiels sind die Process Owner Bereichs- und Abteilungs-leiter, die direkt der Geschäftsführung berichten.

6.4 Kennzahlen

303

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ück-sichtigen, 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 IT-Infrastruktur 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 beste-hender Systeme liegen, um so die notwendige Kostenreduzierung sicher-zustellen. 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 Empfeh-lungen, 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 Schwer-punkte und damit die Aktivitäten innerhalb der IT Service Management-Prozesse ändern. Ihre IT Service Management-Prozesse unterliegen damit einem stetigen Wandel. Beispiel: Hat ein Change Manager eine Vorlaufzeit von fünf Tagen für den RfC festgelegt, so muss dieser Ansatz unter Umständen modifiziert wer-den, wenn sich die Organisation in einer sehr starken Wachstumsphase befindet. Logische Konsequenz ist, dass die Business- und IT-Strategie einen Input für den kontinuierlichen Verbesserungsprozess der IT Service Manage-ment-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än-derten Rahmenbedingungen aufmerksam machen. Aufgabe des Prozess-Managers ist es dann, notwendige Maßnahmen abzuleiten, sie mit dem Process Owner und dem Service Manager abzustimmen und schließlich im Prozess umzusetzen.


304

Für die organisatorische Einbindung der IT Service Management-Prozesse ist die Besetzung des Prozess-Managers von großer Bedeutung. Der Pro-zess-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 Prozess-Manager. Sehr oft kommt dem Process Owner die Rolle eines Coaches zu.

305

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 an-bietet. Darüber hinaus versorgt das Unternehmen Patienten in ausgewähl-ten Märkten mit OTC-Medikamenten. Nycomed arbeitet in einer Reihe von Therapiegebieten wie Kardiologie, Gastroenterologie, Osteoporose, Atemwegserkrankungen, Schmerzthera-pie 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 Jahres-umsatz 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 die-ses 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.


306

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äftsanforde-rungen beherrschen zu können. Bei ALTANA Pharma waren hierzu strukturelle Änderungen in der IT-Organisation 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 IT-Betrieb 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 erbrach-ten 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 nationa-le 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 Gesund-heitsbehörde FDA (Food and Drug Administration) aufgestellt wurden, um die Sicherheit und Produktqualität von Medikamenten sicher zu stel-len. Auch der Sarbanes-Oxley Act (SOX) mit seiner Sektion 404 stellt seit 2002 an die IT der ALTANA Pharma hohe Anforderungen, die von an US-Börsen notierten Firmen erfüllt werden müssen.


307

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 Vor-gaben 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 opti-mieren wurde das Projekt SMILE (Service Management ImpLEmentation) 2004 initiiert. Im Vordergrund stand dabei die Ausrichtung der IT-Prozes-se 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 so-

wie 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 Fachbe-reichen von der Firma KESS DV-Beratung GmbH in ITIL geschult worden sind und erfolgreich mit dem Foundation Certificate in IT Service Manage-ment 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


308

Management war dies durch die teilweise papierbasierende Vorgehens-weise 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 Aktivi-täten und Ergebnisse, die bei der Einführung von IT-Systemen durchzu-führen bzw. zu erzielen sind, und Bereiche wie Anforderungen, Umset-zung und Tests zur Qualitätssicherung beinhaltet. Validierung eines com-putergestü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 Produktivschal-tung 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 Verdop-pelung der eingegangenen RfCs die Bearbeitung im Change Management handhabbar geblieben ist.


309

In der zweiten Phase wurde kurz darauf das Incident Management mit dem Service Level Management aktiviert. Nach einer Eingewöhnungspha-se kamen dann schnell die notwendigen Daten zustande, um ein aussage-krä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 Pro-zesse mit den internen Support-Einheiten bespricht. Es dient einer Verbes-serung der Organisation der IPC-Bearbeitung (Organisatorisches Meeting, keine Diskussionsplattform), der Vermittlung des Status Quo an die Team-leiter, 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 überwie-gend 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-


310

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

0

4

8

12

16

20

24

28

32

Mai

2006

Juni

2006

Juli 2

006

Augus

t 200

6

Septem

ber 2

006

Oktobe

r 200

6

Novem

ber 2

006

Dezem

ber 2

006

Janu

ar 2007

Februa

r 200

7

März 2

007

April 2

007

Mai

2007

# of

RfC

s

Abbildung 84: 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 / Priorisie-rung / Service

– Durchlaufzeiten der einzelnen Phasen (Initiierung, Prüfung, Geneh-migung, 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


311

NewAssessedAuthorizedDevelopment CompletedRelease to ProductionTechnically CompletedUser Acceptance

Finished

Rejected

New 2,2%4Assessed 0,6%1Authorized 3,3%6Development Completed 0,6%1Release to Production 3,3%6Technically Completed 1,7%3User Acceptance 1,7%3Finished 72,9%132Rejected 13,8%25Summe: 100,0%181

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


312

Durch die Etablierung des Change Management-Verfahrens wird den Validierungsanforderungen bezüglich der Änderungskontrolle nachge-kommen. 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.

313

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 Millio-nen 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 Au-tobahnkilometer finden Kunden eine Tank- und Raststätte des Unterneh-mens.

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 Auto-bahn-Reisenden sieben Tage die Woche rund um die Uhr zur Verfügung. Bestnoten vor allem in der Wertung Gastronomie und Service in europa-weit durchgeführten Tests des ADAC bestätigen immer wieder die Leis-tungen der Tank & Rast.

Gründe für die Entwicklung eines IT Kennzahlensystems Die Entwicklung der T&R wird von einer Vielzahl technologischer Pro-jekte begleitet. Wesentlichen Einfluss auf den Projekterfolg haben dabei die benötigten IT-Services. Die Herausforderungen für das IT-Manage-ment sind, die verfügbaren Ressourcen und Mittel effektiv und effizient einzusetzen. Dabei stehen Flexibilität, Innovationsstärke und Wirtschaft-


314

lichkeit im Focus der mittel- und langfristigen Ziele. Um dies zu ge-währleisten wurde ein IT-Kennzahlensystem entwickelt, das die Steue-rung des IT-Bereichs nach den genannten Kriterien ermöglicht und gleich-zeitig 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-Manage-ment 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-Kennzahlen-system auf die individuellen Anforderungen eines Unternehmens abge-stimmt 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 umge-setzt und implementiert. Die Umsetzung des Projekts erfolgte in folgenden Schritten:

– Im ersten Step wurden Interviews mit IT-Mitarbeitern aus ausge-wählten IT-Serviceeinheiten geführt. In diesem Kreis erfolgte eine Bestandsaufnahme der vorhandenen IT-Kennzahlen, und die Rele-vanz der einzelnen Kennzahlen für die jeweiligen IT-Serviceeinhei-ten 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 Kennzah-len-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.


315

– 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 Balan-ced 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 Kennzah-len ausgebildet sein. Für das Kennzahlensystem der Tank & Rast wurden folgende Dimensio-nen 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 Berichtswe-sens 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 sinn-vollen Kennzahlen aus den vielen möglichen Werten der bekannten Kenn-zahlensysteme 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 ITIL-Prozesse, insbesondere den Prozess des Service-Level-Managements, un-terstü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 dar-zustellen.

317

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ün-chen 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 Studi-ums der Nachrichtentechnik war M. Zaddach bei Siemens, AEG und debis Systemhaus in verschiedenen Funktionen wie zum Beispiel Systement-wicklung, Product-Line-Management, Projektmanagement und Consul-ting 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 dau-erhafte 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 Infrastruktur-projekten und reagieren damit auf die weiterhin überproportionalen Stei-gerungsraten bei Passagieren, Flugbewegungen und beim Frachtaufkom-


318

men. Im Jahr 2007 beginnen die Arbeiten an einem neuen Speditionsge-bä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 Verkehrssteigerun-gen bewältigen. Der Erfolg des Münchner Flughafens als Drehkreuz des Südens liegt nicht zuletzt in der starken Verzahnung der Flughafen-Kernprozesse mit unter-stützenden IT-Lösungen. So kann dank effizientem IT-Einsatz im Termi-nal 2 eine kürzeste Umsteigezeit von nur 30 Minuten garantiert werden. Um diesen Wert einhalten zu können, werden Passagier- und Gepäck-strö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 Kon-trollzentrale, das HCC (Hub-Control-Center) eingerichtet. Dort laufen alle abfertigungsrelevanten Informationen zusammen und werden über indi-viduelle 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 Hub-Koordination werden so auf ein Minimum reduziert. Neben dem Flugbetrieb spielt aber auch das so genannte Non-Aviation-Business 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-Provi-der für die Flughafengesellschaft, sondern auch für die weiteren am Flug-hafen ansässigen Unternehmen. So zählen heute über 500 Firmen, wie zum Beispiel Airlines, Speditionen, Behörden und viele weitere Dienstleis-tungsunternehmen zu den Kunden des Servicebereichs. Die Forderungen nach Qualität und der professionellen Abwicklung der Leistungen bekom-men dadurch nochmals einen höheren Stellenwert. Mit 180 Mitarbeitern erwirtschaftet der Servicebereich IT einen Gesamt-umsatz von ca. 42 Millionen Euro. Ein Drittel dieser Leistung wird dabei mit Kunden außerhalb der Flughafengesellschaft generiert.


319

Der Servicebereich IT des Flughafens München stellt die IT Services auch für ex-terne 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 dar-gestellt.

Field Service

ITF

Operation & Service

ITO

Interne Services

ITS

ServicebereichIT

Projekte und Entwicklung

ITE

Controlling & Sales

ITK

CIM

ITC

• ITEA - AS Aviation• ITEG - AS Ground-

Handling• ITET - AS Technik• ITEP - AS Personal• ITES - SAP-CCC und

AS Rechnungsw. • ITEV - AS Vertrieb• ITED - CC-Anwendungs-

entwicklung• ITEC - CC Basistools

• ITOS - Systems Management

• ITOP - Plattforms• ITOC - Communications• ITOR - Rollout

Management• ITOI - Internal Services

• Schichtleiter 1• Schichtleiter 2• Schichtleiter 3

Field Service

ITF

Operation & Service

ITO

Interne Services

ITS

ServicebereichIT

Projekte und Entwicklung

ITE

Controlling & Sales

ITK

CIM

ITC

• ITEA - AS Aviation• ITEG - AS Ground-

Handling• ITET - AS Technik• ITEP - AS Personal• ITES - SAP-CCC und

AS Rechnungsw. • ITEV - AS Vertrieb• ITED - CC-Anwendungs-

entwicklung• ITEC - CC Basistools

• ITOS - Systems Management

• ITOP - Plattforms• ITOC - Communications• ITOR - Rollout

Management• ITOI - Internal Services

• Schichtleiter 1• Schichtleiter 2• Schichtleiter 3

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 ca. 2.500 – Aktive LAN-Anschlüsse ca. 12.000 – Telefone 12.500 – FIDS Displays 2.400 – CCTV-Kameras ca. 1.700 – Zentrale Server 240 – Speicherkapazität (brutto) > 100 TB – Applikationen ca. 420


320

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 Auswirkun-gen 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 Ab-wicklung 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ön-nen, wurden ausgehend von den Unternehmenszielen und der Unterneh-mensstrategie des Flughafens München die IT-Ziele definiert und dement-sprechende Umsetzungsmaßnahmen erarbeitet (siehe Abbildung 87). Zur Effizienzsteigerung wurde ein umfangreiches Optimierungspro-gramm durchgeführt, das unter anderem eine Reorganisation des IT-Be-reichs 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 Flug-hafens München.


321

ZielsetzungFMG

ZielsetzungIT

Ideen-findung

MaßnahmenIT Umsetzung

• Strategische Neuausrichtung

• Ergebnisver-besserung

• Neue Organisation

Wie kann die FMG in Zukunft im Wettbewerb wirtschaftlich bestehen ?

Frag

eE

rgeb

nis

Mit welchen Mitteln können wir das gesteckte Ziel erreichen ?

FMG-weit 1000 Ideen aus Workshops

Welche Zielsetzung ergibt sich für den Bereich IT ?

Effizienzsteigerung und Generierung zusätzlicher Erlösezur nachhaltigen Senkung der IT-Kosten um 10% im Konzern

Welche konkreten Maßnahmen sind zur Zielerreichung erforderlich ?

13 Umsetzungs-maßnahmen zur Senkung der

• Kapitalkosten• Fremdleistungen• Personalkostenund Erhöhung der Marktdurchdringung

Wie erfolgt die Umsetzung ?

• Effizienzstei-gerung in den Service-Prozessen

• Verbesserung der Projekt-abwicklung

• Systemkonsoli-dierung

• Stärkung des Vertriebs

ZielsetzungFMG

ZielsetzungIT

Ideen-findung

MaßnahmenIT Umsetzung

• Strategische Neuausrichtung

• Ergebnisver-besserung

• Neue Organisation

Wie kann die FMG in Zukunft im Wettbewerb wirtschaftlich bestehen ?

Frag

eE

rgeb

nis

Mit welchen Mitteln können wir das gesteckte Ziel erreichen ?

FMG-weit 1000 Ideen aus Workshops

Welche Zielsetzung ergibt sich für den Bereich IT ?

Effizienzsteigerung und Generierung zusätzlicher Erlösezur nachhaltigen Senkung der IT-Kosten um 10% im Konzern

Welche konkreten Maßnahmen sind zur Zielerreichung erforderlich ?

13 Umsetzungs-maßnahmen zur Senkung der

• Kapitalkosten• Fremdleistungen• Personalkostenund Erhöhung der Marktdurchdringung

Wie erfolgt die Umsetzung ?

• Effizienzstei-gerung in den Service-Prozessen

• Verbesserung der Projekt-abwicklung

• Systemkonsoli-dierung

• Stärkung des Vertriebs

Abbildung 87: 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 um-fangreiche Maßnahmen zur Optimierung der IT Serviceprozesse durchge-fü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 sys-temorientierten auf eine prozessorientierte Struktur umgestellt, ein 90-Grad-Schwenk in der Organisation und in den Köpfen aller Beteiligten (siehe Abbildung 88).


322

Abbildung 88: Prozessorientierte Sicht des Servicebereichs IT

Der Abschied von den Technik-Silos Die Organisationsänderung war dabei kein Selbstzweck, sondern die logi-sche 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 Enginee-ring, die Betreuung und den Betrieb von "Silo-Technik" ist in Zukunft im-mer weniger erforderlich. Die Verfolgung dieser Strategie der konsequen-ten Standardisierung und Konvergenz bedingt natürlich die Übernahme des Integrationsrisikos und erfordert die entsprechende Integrations-kompetenz. Die beteiligten Mitarbeiter müssen sich also von Silo-Spezialisten zu Integrations-Spezialisten entwickeln. Das Wissen in der Breite und die guten Kenntnisse der Standards werden wichtiger als das extrem tiefe Spezialisten-Know-how für individuelle Systeme.


323

Die Abkehr von den Silo-Systemen bietet enorme Chancen in der effizien-teren Gestaltung der Serviceprozesse. Während früher zum Beispiel die Bereiche Telekommunikation (TK), Anzeigesysteme (FIDS), Video-überwachung, Office-Systeme und Netzwerk eine eigene Auftragsan-nahme und eigenes Störmanagement unterhielten, werden in der neuen Struktur alle Aufträge und Störungen vom zentralen Service Desk ange-nommen und durchgängig bearbeitet. Auch beim Betrieb und bei den Field-Services können erhebliche Syner-gien erschlossen werden. Die Konvergenz der Systeme und die Konzentra-tion auf standardisierte Plattformen werden damit in der Organisations-struktur 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 zeitge-rechte 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 Strate-gie abgeleitet und definiert. Durch die Einhaltung der Prozesse ist sicher-gestellt, 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.


324

Strategische Initiativen

Maßnahmenpläne Ziele (Mitarbeiter)

Ziele (Führungskräfte)

langfristig (3 – 5 Jahre)

langfristig (3 – 5 Jahre)

mittelfristig (1 - 3 Jahre)

kurzfristig (1 Jahr)

kurzfristig (1 Jahr)bezogen auf Meilensteine

der Initiativen

kurzfristig (1 Jahr)

Quartalsreview

Projektmonitoring,Mitarbeitergespräche

Kunde Prozess

Mitarbeite r.Finanz

Kunde Prozess

Mitarbeite r.Finanz

Kunde Prozess

Mitarbeite r.Finanz

Kunde Prozess

Mitarbeite r.Finanz

Kunde Prozess

Mitarbeiter .Finanz

Kunde Prozess

Mitarbeiter .Finanz

Strategische Grundausrichtung

Strategieelemente

Strategieklausurjährlich

Abbildung 89: 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 Mitar-beiter 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 betei-ligen und immer wieder Erfordernisse, angestrebte Ziele und die Verbes-serungspotenziale 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 Gro-ben 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 verantwort-lich, 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 implemen-tierten Service Management-Prozesse entnommen werden.


325

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

chen Verbesserungsprozess ein Die Vorgehensweise zur Inbetriebnahme der Prozesse erfolgte wie folgt:

– Erarbeitung der Prozesse gemäß Vorgaben – Freigabe der Prozessdokumentation durch den IT-Qualitätsbeauf-

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


326

Die Prozesse wurden vom Projektteam so dokumentiert, dass sie die tägli-che Arbeit der Mitarbeiter unterstützten, aber wann immer sinnvoll trotz-dem 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 Serviceorientie-rung 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 ITSM-Portal und können über dieses Portal auf die Prozessdokumentation, Ar-beitsanweisungen, 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 vorge-gebenen Prozess abweichen dürfen. Dann besteht allerdings die Verpflich-tung 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 wichti-ger Input in den kontinuierlichen Verbesserungsprozess (Prozess Impro-vement-Plan).


327

Abbildung 91: Das ITSM-Portal des Servicebereichs IT

Trainings Um die Mitarbeiter in die Lage zu versetzen, die ITIL Prozessanforderun-gen auf den Servicebereich IT zu adaptieren, galt es in einer ersten Trai-ningsphase 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ä-


328

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 prak-tische 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 Un-ternehmen

- Prozesstrainings für alle Prozess-Manager und die weiteren be-troffenen 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 , durchge-führt von den Process Ownern und Prozess-Managern

Die ISO 200000 „IT Service Management“ Obwohl die Zertifizierung nach der ISO 20000 des Servicebereichs IT zu-nächst nicht im Fokus der Zielsetzung stand, hat der klare Zieltermin und der klar definierte Umfang der Zertifizierung allen Beteiligten enorm ge-holfen. Bei einer solch umfassenden Neugestaltung der Prozesslandschaft besteht die Gefahr, dass man sich sonst in den Tiefen der Prozessgestal-tung verliert. Die Zertifizierung hilft in diesem Zusammenhang zur Ein-haltung 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 Zu-sammenarbeit

– 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


329

Effizienzsteigerung des Servicebereichs IT und einer angestrebten Pro-zessorientierung 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 Prozess-steuerung stellt die Festlegung von Kennzahlen (KPIs) und deren Control-ling 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 erho-ben werden muss und auch interpretiert werden will, um als Steuerungs-information 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 Servi-cebereich IT gezeigt, dass die Anzahl der ursprünglich definierten Kenn-zahlen 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 Problem-Records je Prioritätsklasse" für den Process Owner „Problem-Manage-ment“ 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:


330

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

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


331

die Definition von angestrebten Zielzuständen erforderlich; der so ge-nannte Prozess Improvement-Plan (Schema siehe Abbildung 93).

Prozess: Problem-Management Datum: 27.04.2005

Definierte Einschränkungen:

Maßnahmen- und Zeitplan für die Erhöhung des Abdeckungsgrades und zur Verbesserung der inhaltlichen Ausgestaltung:

Freigabe (FK1 / FK2):

• Werden die Zielzeiten bei Incidents überschritten erfolgt noch nicht zwingend die Analyse mittels Problem-Management

Prozess-Owner, Prozess-Manager01.12.2006Vereinfachtes Bearbeiten und Erhöhung der Akzeptanz

Verbesserungen am ARS-Tool und ARS-Masken

Prozess-Owner, Prozess-Manager01.08.2006Sicherstellen daß Known Errors und Workarounds für die Incident-Bearbeitung zur Verfügung gestellt werden

Arbeitsanweisung zum Problem-Management erweitern um Vor-gehen bei Zielzeitüberschreitungen von Incidents zu berücksichtigen

Prozess-Owner, Prozess-Manager01.10.2006Einbindung aller Mitarbeiter in den Prozess Problem-Management

Schulungen aller IT-Mitarbeiter über die Inhalte und Arbeitsanweisungen zum Problem-Management


Ausweitung der Problem-Management Verfahren auf den gesamten Bereich IT

VerantwortlicherZieldatumZielMaßnahme

Prozess-Owner, Prozess-Manager01.12.2006Vereinfachtes Bearbeiten und Erhöhung der Akzeptanz

Verbesserungen am ARS-Tool und ARS-Masken

Prozess-Owner, Prozess-Manager01.08.2006Sicherstellen daß Known Errors und Workarounds für die Incident-Bearbeitung zur Verfügung gestellt werden

Arbeitsanweisung zum Problem-Management erweitern um Vor-gehen bei Zielzeitüberschreitungen von Incidents zu berücksichtigen


Schulungen aller IT-Mitarbeiter über die Inhalte und Arbeitsanweisungen zum Problem-Management


Ausweitung der Problem-Management Verfahren auf den gesamten Bereich IT

VerantwortlicherZieldatumZielMaßnahme

Abbildung 93: Auszug aus dem Service Improvement-Plan des SB IT

In diesem Plan sind für jeden Prozess, die zum Zertifizierungstermin ge-troffenen und bekannten Einschränkungen hinsichtlich der Prozess Imp-lementierung zu beschreiben und der Plan für die Weiterentwicklung der Prozesse mit klaren Zielen, Terminen und Verantwortlichkeiten zu hinter-legen. 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 poten-tielle Gefahr, dass die Messlatte für die angestrebten Ziele zu hoch gelegt wird und nach kurzer Zeit die Enttäuschung einsetzt, weil eine Zielerrei-chung aufgrund von Aufwandslimitierungen nicht möglich ist.


332

Der ITSM-Maßnahmenkatalog Auch nach der Zertifizierung werden viele neue Erkenntnisse in Hinblick auf eine Verbesserung oder Abrundung der definierten Prozesse aufkom-men. Um diese Informationen von Mitarbeitern und weiteren Prozessbe-teiligten 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 Mode-rators ü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 erheb-lich reduziert werden. Die IT-Organisation der Flughafen München GmbH hat als fünftes deut-sches Unternehmen und als erster Flughafen weltweit ein ISO 20000-Zertifikat erhalten und weist damit seine exzellente Servicequalität aus. Speziell für neue Kunden, die die Qualität und Leistungsfähigkeit des Servicebereichs IT noch nicht beurteilen können und den Zusicherungen vertrauen müssen, ist die Zertifizierung und damit Nachweis des Service Managements ein wichtiger Indikator für die Servicequalität. Der Anteil des externen Geschäfts konnte auch in 2006/2007 weiter gestei-gert werden. Aus diesem Grund hat sich der Flughafen entschlossen, in-nerhalb des SB IT eine neue Business-Unit für externes Geschäft zu grün-den, 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.

333

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 organisato-risch 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 Verbin-dungstechnik im internationalen Fahrzeug- und Maschinenbau und ver-steht sich als kompetenter Entwicklungspartner seiner Kunden. Ergebnis der Entwicklungspartnerschaft sind maßgeschneiderte Lösungen der Lei-tungsauslegung, der Leitungsführung und der Verbindungstechnik. Dies gilt für Pneumatik, Hydraulik, Kraftstoff- und Klimasysteme, insbeson-dere 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 über-nimmt damit wesentliche Aufgaben innerhalb der gesamten Hydraulik-systeme. 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


334

wie Messtechnik, Rohrschellen, Kugelhähne, einbaufertige Schlauchlei-tungen, Flanschverbindungen und komplette Kits. Die IT Abteilung ist organisatorisch in der VOSS Automotive GmbH ange-siedelt 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 erreich-ten Verbesserungen in vielen Kontexten einsetzen, z.B. werden die turnus-mäß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 Ver-zahnung von IT-Kennzahlen und ITIL erreicht.

– Das Service Desk liefert wesentliche IT-Kennzahlen. – Ein Cockpitsystem auf der Basis von NAGIOS, das sich in der letz-

ten Phase des Aufbaus befindet, ermittelt die für den IT-Betrieb re-levanten Kennzahlen automatisch und zeigt insbesondere Abwei-chungen 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 Be-richt, den IT Management Report, zur Verfügung, der in der Spra-che der Geschäftsführung die Lage der IT in der VOSS Gruppe dar-stellt.

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 Perfor-mance-Indikatoren, die sich letztlich aus technischen und finanzwirt-schaftlichen IT-Kennzahlen ableiten.


335

Die Struktur unseres IT Management Reports haben wir in Form einer Balanced Scorecard entwickelt, allerdings haben wir diese auf unsere fir-menspezifischen Bedürfnisse erweitert. Diese erfolgt bei uns in fünf Kate-gorien, die nicht nur die Finanzperspektive, sondern auch die Perspektiv-sichten auf Kunden, Leistung, Mitarbeiter und insbesondere die für die Weiterentwicklung der VOSS Gruppe wichtigen IT-Projekte und Innovati-onen 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-Zusammen-hang 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 Darstel-lung gelegt. Die Kennzahlen, die wir verwenden, sind natürlich vertraulich. Wir haben kein „fertiges“ Kennzahlensystem eingesetzt, sondern unser eigenes ent-wickelt, 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 „geschlosse-nes Bild“ der IT. Es wird deutlich, wieso wir bestimmte Dinge, z.B. Virtua-lisierung und Serverkonsolidierungen zu einem bestimmten Zeitpunkt, durchgeführt haben, und wie sie sich auswirken. Wir sehen den IT Management Report als ideales Kommunikationsinstru-ment 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.

337

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

11 Anhang

338

[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

11.1 Quellenverzeichnis

339

[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

11 Anhang

340

[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 Pro-ject 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 IT- Organisation 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


341

Download-Bereich http://www.kess-dv.de/Wir-Ueber-Uns/Beschreibungen- und-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-Mana-

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

11 Anhang

342

[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


343

[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

11 Anhang

344

[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

11.2 Abkürzungsverzeichnis

345

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

ogy 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

11 Anhang

346

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

11.3 Abbildungsverzeichnis

347

11.3 Abbildungsverzeichnis Abbildung 1: ITIL Rahmenstruktur...............................................................8Abbildung 2: Die 10 ITIL-Prozesse und der Service Desk..........................9Abbildung 3: Generisches ITIL-Prozessmodell..........................................10Abbildung 4: Die Ausrichtung der IT Services auf das Business ............14Abbildung 5: Die 5 Phasen des Service Lifecycle nach ITIL V3. ..............17Abbildung 6: Integrierter Ablauf der Lifecycle Elemente.........................18Abbildung 7: Service Lifecycle und Prozesse.............................................21Abbildung 8: Elemente Service Strategy.....................................................22Abbildung 9: Serviceportfolio und die einzelnen Stati .............................24Abbildung 10: Verbindung zwischen IT Service und Business-

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

11 Anhang

348

Abbildung 30: Service Design.........................................................................62Abbildung 31: Service Transition...................................................................72Abbildung 32: Das Service V-Modell.............................................................79Abbildung 33: Service Operation ...................................................................82Abbildung 34: Continual Service Improvement ..........................................90Abbildung 35: 7 Step Improvement-Prozess ................................................91Abbildung 36: IT Service Management-Prozesse der ISO 20000 .............101Abbildung 37: PDCA-Methodik...................................................................103Abbildung 38: COBIT Prozess-Übersicht....................................................106Abbildung 39: Zusammenhang zwischen Control Objectives in

COBIT ....................................................................................108Abbildung 40: Ziele, Prozesse und Metriken in COBIT............................109Abbildung 41: Prozess, Ziele und Kontrollebenen in COBIT...................111Abbildung 42: Mapping der Prozesse in ITIL Version 2 und COBIT .....112Abbildung 43: Wertschöpfungskette nach Porter......................................123Abbildung 44: Zusammenhang zwischen SLAs, OLAs und UCs ...........126Abbildung 45: Beispiel für mehrschichtige SLAs ......................................127Abbildung 46: Allgemeine Balanced Scorecard .........................................138Abbildung 47: Ursache-Wirkungskette.......................................................140Abbildung 48: Stellung der BSC im Unternehmensplanungsprozess ....140Abbildung 49: PDCA-Zyklus........................................................................148Abbildung 50: Exemplarische Darstellung der Bearbeitung eines

Incidents ................................................................................152Abbildung 51: IT-Prozesse und bestehende Aufbauorganisation...........153Abbildung 52: Ausschnitt der RACI-Matrix zum Change

Management (vgl. [OGC, 2007c]) .......................................157Abbildung 53: Definition der IT Services....................................................163Abbildung 54: Definition der IT Services – Service Improvement-

Plan.........................................................................................164Abbildung 55: Definition der Prozessziele – Neue Services.....................165Abbildung 56: Definition der Prozessziele – Kundenanforderungen.....165Abbildung 57: Definition der Prozessziele – IT-Strategie .........................166Abbildung 58: Definition der Prozessziele – Prozess Improvement-

Plan.........................................................................................167

11.3 Abbildungsverzeichnis

349

Abbildung 59: Definition der Prozessziele – Planung und Implementierung..................................................................168

Abbildung 60: Definition der Prozessziele – Service Management-Plan.........................................................................................170

Abbildung 61: Konformität des Managementsystems..............................171Abbildung 62: Prozess-Management – Prozessdesign..............................172Abbildung 63: Prozess-Management – Überprüfung ...............................173Abbildung 64: Prozess-Management – Nutzung von COBIT und

ITIL.........................................................................................174Abbildung 65: Prozess-Management – Konformität .................................175Abbildung 66: Prozess-Management – Prozess Improvement-Plan .......176Abbildung 67: Entwicklung von Kennzahlen ............................................177Abbildung 68: Zusammengesetzte Prozess-Kennzahlen..........................180Abbildung 69: Darstellung der SLAs mit dem Q-Board von Q to be .....180Abbildung 70: Das IT Service Management Kennzahlensystem.............181Abbildung 71: Exemplarischer Prozess-Bericht – Deckblatt zum

Report.....................................................................................182Abbildung 72: Exemplarischer Prozess-Bericht – Darstellung der

Kennzahlen ...........................................................................183Abbildung 73: Darstellung des Management Cockpits von iET

Solutions ................................................................................184Abbildung 74: Beispiel für eine Trenddarstellung.....................................185Abbildung 75: Beispiel 1 für eine Analyse möglicher Ursachen..............186Abbildung 76: Beispiel 2 für eine Analyse möglicher Ursachen..............187Abbildung 77: Schema zur Klassifikation von IT-Kennzahlen ................204Abbildung 78: Key Success-Faktoren im IT Management Report...........207Abbildung 79: Key Success-Faktoren zur Gruppierung von KPIs

und CSIs ................................................................................208Abbildung 80: Beispiele für Lücken zwischen Kunden- und

Providersicht.........................................................................209Abbildung 81: Gaps nach OGC (aus [OGC, 2007e]) ..................................211Abbildung 82: Deming (oder PDCA) Zyklus .............................................282Abbildung 83: 3-Phasen-Modell nach Lewin .............................................285Abbildung 84: Anzahl der RfCs pro Monat (Demo-Daten)......................310

11 Anhang

350

Abbildung 85: Status aller RfCs (Demo-Daten)..........................................311Abbildung 86: Organisationsstruktur Flughafen München,

Servicebereich IT ..................................................................319Abbildung 87: Von den Unternehmenszielen zu der Umsetzung in

der IT......................................................................................321Abbildung 88: Prozessorientierte Sicht des Servicebereichs IT................322Abbildung 89: Ausrichtung der Prozesse an der IT-Strategie..................324Abbildung 90: Die Prozesslandkarte des Servicebereichs IT ...................325Abbildung 91: Das ITSM-Portal des Servicebereichs IT............................327Abbildung 92: Auszug der ersten Ebene der Kennzahlen des SB IT ......330Abbildung 93: Auszug aus dem Service Improvement-Plan des SB

IT.............................................................................................331

11.4 Glossar

351

11.4 Glossar In diesem Glossar werden die in der ITIL V3 verwendeten Begriffe erläu-tert. 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 An-wender verantwortlich ist. Das Access Management bietet Unterstützung beim Schutz der Vertrau-lichkeit, Integrität und Verfügbarkeit von Assets, indem sichergestellt wird, dass nur berechtigte An-wender 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.

Asset Bezeichnung für jede Ressource oder Fähigkeit. Die Assets eines Service Providers umfassen alle Ele-mente, die zur Erbringung eines Service beitragen können. Assets können folgende Typen einschlie-ßen: Management, Organisation, Prozess, Wissen, Mitarbeiter, Informationen, Anwendungen, Infra-struktur 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 Con-figuration Management.


Der Prozess, der für die Definition, Analyse, Pla-nung, Messung und Verbesserung sämtlicher As-pekte in Bezug auf die Verfügbarkeit von IT Servi-ces 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.

11 Anhang

352

Balanced Scorecard

Ein Management-Hilfsmittel, das von Dr. Robert Kaplan (Harvard Business School) und Dr. David Norton entwickelt wurde. Mit einer Balanced Score-card kann eine Strategie in Key Performance Indica-tors 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 Organi-sation genauer untersucht.

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

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

Business Case Rechtfertigung für einen umfassenden Ausgaben-posten. Beinhaltet Informationen zu Kosten, Nut-zen, Optionen, offenen Punkten, Risiken und mögli-chen Problemen.

Business Continuity Management

Der Business-Prozess, der für den Umgang mit Risi-ken verantwortlich ist, die zu schwerwiegenden Auswirkungen auf das Business führen können. Das BCM sichert die Interessen der wichtigsten Stake-holder, das Ansehen, die Marke und die wertschöp-fenden 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

11.4 Glossar

353

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ängig-keiten können zwischen Suppliern, Mitarbeitern, anderen Business-Prozessen, IT Services etc. beste-hen. Die BIA definiert die Wiederherstellungsanfor-derungen 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 Ressour-cen, die für die Erbringung von IT Services erforder-lich sind, sowie Pläne für kurz-, mittel- und langfris-tige Business-Anforderungen berücksichtigt.

Change Advisory Board

Eine Gruppe von Personen, die den Change Mana-ger bei der Bewertung, Festlegung von Prioritäten und zeitlichen Planung in Bezug auf Changes bera-ten. Dieses Gremium setzt sich in der Regel aus Ver-tretern 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 Lebenszyk-lus aller Changes verantwortlich ist. Wichtigstes Ziel des Change Management ist es, die Durchfüh-rung von lohnenden Changes bei einer minimalen Unterbrechung der IT Services zu ermöglichen.

CMDB Eine Datenbank, die verwendet wird, um Configu-ration Records während ihres gesamten Lebenszyk-lus zu speichern. Das Configuration Management System verwaltet eine oder mehrere CMDBs, und jede CMDB speichert Attribute von CIs sowie Be-ziehungen zu anderen CIs.

11 Anhang

354

COBIT Control Objectives for Information and related Tech-nology (COBIT) bietet Anleitungen und Best Practi-ces 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, Aus-lastung 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. Infor-mationen zu den einzelnen CIs werden in einem Configuration Record innerhalb des Configuration Management Systems erfasst und über den gesam-ten Lebenszyklus hinweg vom Configuration Ma-nagement verwaltet. CIs unterstehen der Steuerung und Kontrolle des Change Management. CIs umfas-sen vor allem IT Services, Hardware, Software, Ge-bä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, Proble-men, Known Errors, Changes und Releases und kann auch Daten zu Mitarbeitern, Suppliern, Stand-orten, Geschäftsbereichen, Kunden und Anwendern beinhalten. Das CMS umfasst Hilfsmittel zum Sammeln, Speichern, Verwalten, Aktualisieren und Präsentieren von Daten zu allen Configuration I-tems und deren Beziehungen. Das CMS untersteht der Zuständigkeit des Configuration Management und wird von allen IT Service Management-Prozessen eingesetzt.

Critical Success Factor

Ein Bestandteil, das für einen erfolgreichen Prozess, (ein erfolgreiches) Projekt, Plan oder IT Service er-forderlich ist. Um das Erreichen eines CSF zu mes-sen, 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-

11.4 Glossar

355

ringerung der Changes, die Incidents verursachen, in Prozent“ etc. gemessen werden.


Eine Phase im Lebenszyklus eines IT Service und Titel einer der ITIL-Kernpublikationen. Das Conti-nual Service Improvement ist verantwortlich für die Verwaltung von Verbesserungen in IT Service Ma-nagement-Prozessen und IT Services. Dabei werden die Performance des IT Service Providers kontinu-ierlich 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ülti-gen und genehmigten Versionen aller Software Con-figuration 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 strategi-scher Ebene kann das Demand Management die Analyse von Business-Aktivitätsmustern und An-wenderprofilen 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, Pro-zesse etc. in die Live-Umgebung verantwortlich ist. Das Deployment ist Teil des Release and Deploy-ment Management-Prozesses.

11 Anhang

356

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 Akti-vitä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 Inci-dent zu lösen oder ein Sicherheits-Patch zu installie-ren. 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 fortgefah-ren 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 ei-nen IT Service, ein Configuration Item oder ein Mo-nitoring Tool. Bei Events müssen in der Regel die Mitarbeiter des IT-Betriebs aktiv werden, und häu-fig 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 Aktivi-täten des IT-Betriebs.


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

11.4 Glossar

357

Governance Sicherstellen, dass Richtlinien und Strategien auch tatsächlich implementiert werden und erforderliche Prozesse korrekt eingehalten werden. Die Gover-nance umfasst die Definition von Rollen und Ver-antwortlichkeiten, 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 bis-herige Auswirkungen auf einen Service ist ein Inci-dent. Beispiel: Ein Ausfall einer oder mehrerer Fest-platten in einer gespiegelten Partition.

Incident Management

Der Prozess, der für die Verwaltung des Lebenszyk-lus aller Incidents verantwortlich ist. Wichtigstes Ziel des Incident Management ist eine schnellstmög-liche Wiederherstellung des IT Service für die An-wender.

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 Aufga-benbereich des IT Service Providers hinausgeht, und berücksichtigt die Verwaltung papierbasierter Do-kumente, 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 Stan-dards. Die ISO ist eine regierungsunabhängige Or-ganisation, die aus einem Netzwerk nationaler Standardisierungsinstitute aus 156 Ländern besteht. Weitere Informationen zu ISO finden Sie unter http://www.iso.org/.

11 Anhang

358

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 Informations-technologie und unterstützt die Business-Prozesse des Kunden. Ein IT Service besteht aus einer Kom-bination von Personen, Prozessen und Technologie und sollte in einem Service Level Agreement defi-niert werden.

IT Service Continuity Management

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


Die Implementierung und Verwaltung von quali-tätsbasierten IT Services, die den Anforderungen des Business gerecht werden. Das IT Service Mana-gement 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 Mitglie-derorganisation mit Vertretern aus zahlreichen Ländern weltweit (itSMF Verbände). Das itSMF und

11.4 Glossar

359

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


Der Prozess, der für die Sammlung, die Analyse, das Speichern und die gemeinsame Nutzung von Wissen und Informationen innerhalb einer Organi-sation verantwortlich ist. Wichtigster Zweck des Knowledge Management ist eine gesteigerte Effi-zienz, indem bereits vorhandenes Wissen nicht er-neut 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 Lebens-dauer eines IT Service, Configuration Item, Incident, Problems, Change etc. Der Lebenszyklus definiert die Statuskategorien sowie die erlaubten Statusüber-gänge. Beispiel: Der Lebenszyklus einer Anwen-dung umfasst: Anforderungen, Design, Build, Deployment, Betrieb und Optimierung. Der erwei-terte Incident-Lebenszyklus umfasst: Erkennung, Antwort, Diagnose, Reparatur, Instandsetzung und Wiederherstellung. Der Lebenszyklus eines Servers kann Folgendes umfassen: Bestellt, Erhalten, Test-phase, Live-Phase, Entsorgt etc.

11 Anhang

360

Monitoring Wiederholte Beobachtung eines Configuration Item, IT Service oder Prozesses, um Events zu ermitteln, und sicherzustellen, dass der aktuelle Status be-kannt 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 Be-reitstellung der Beschaffungsplanung für die briti-sche Regierung unterstützt, indem ein gemein-schaftlicher Ansatz für Beschaffungsmöglichkeiten und die Steigerung der Fähigkeiten für die Beschaf-fung 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 Pro-vider und einem anderen Teil derselben Organisa-tion. Ein OLA unterstützt die Bereitstellung von IT Services durch den IT Service Provider für den Kun-den. 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 Ein-kaufsabteilung, um Hardware innerhalb vereinbar-ter 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 Prozessmanage-ment, 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.

11.4 Glossar

361

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 Lebenszyk-lus 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 Verant-wortlichkeiten des Process Owners gehören das Sponsorship, das Design, das Change Management sowie die kontinuierliche Verbesserung des Prozes-ses 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 In-puts 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 Anforderun-gen 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 Verantwort-lichkeiten des Prozess-Managers gehören die Pla-nung und die Koordination aller Aktivitäten, die zur Ausführung, dem Monitoring und der Berichtser-stellung in Bezug auf einen Prozess erforderlich sind. Es können mehrere Prozess-Manager für einen Prozess vorhanden sein, z. B. regionale Change Ma-nager 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-

11 Anhang

362

ren Organisationen können diese Rollen jedoch se-parat zugewiesen sein.

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

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

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

Release Eine Zusammenstellung von Hardware, Software, Dokumentation, Prozessen oder anderen Kompo-nenten, die für die Implementierung eines oder mehrerer genehmigter Changes an IT Services er-forderlich sind. Die Inhalte jedes Releases werden als eine Einheit verwaltet, getestet und implemen-tiert.

Release and Deployment Management

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

Release Manage-ment

Der Prozess, der für die Planung, den zeitlichen Ablauf und die Steuerung des Übergangs von Re-leases in Test- und Live-Umgebungen verantwort-lich ist. Das wichtigste Ziel des Release Management ist es, sicherzustellen, dass die Integrität der Live-Umgebung aufrechterhalten wird und dass die rich-tigen 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 Re-lease Unit könnte z. B. ein Desktop-PC mit Hard-ware, Software, Lizenzen, Dokumentation usw. sein. Eine weitere Release Unit könnte die gesamte An-

11.4 Glossar

363

wendung für die Lohnbuchhaltung sein, einschließ-lich IT-Betriebsverfahren und Anwendertrainings

Request for Change

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

Request Fulfilment Der Prozess, der für das Management des Lebens-zyklus 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 Netto-wert 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 Kun-den angestrebten Ergebnisse erleichtert oder geför-dert 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 Ma-nagement als auch das Asset Management verant-wortlich ist.

Service Capacity Management

Dient der Gewinnung von Erkenntnissen zur Perfor-mance und Kapazität von IT Services. Die Ressour-cen, 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. Ser-vice Design umfasst eine Reihe von Prozessen und Funktionen. Gleichzeitig ist es der Titel einer ITIL-Kernpublikation.

Service Desk Der Single Point of Contact für die Kommunikation

11 Anhang

364

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 Improve-ment-Plan (SIP)

Ein formeller Plan zur Implementierung von Ver-besserungen 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 Lebenszyk-lus von IT Services benötigt.

Service Level Messbare und nachweisbare Ergebnisse, die im Hin-blick auf ein oder mehrere Service Level-Ziele er-reicht werden. Der Begriff „Service Level“ wird im Sprachgebrauch auch als Synonym für Service Le-vel-Ziel verwendet.

Service Level Agreement

Eine Vereinbarung zwischen einem IT Service Pro-vider und einem Kunden. Das SLA beschreibt den jeweiligen IT Service, dokumentiert Service Level-Ziele und legt die Verantwortlichkeiten des IT Ser-vice Providers und des Kunden fest. Ein einzelnes SLA kann mehrere IT Services oder mehrere Kun-den abdecken.

Service Level Requirement

Eine Kundenanforderung für einen Aspekt eines IT Service. SLRs basieren auf Business-Zielen und wer-den zur Aushandlung vereinbarter Service Level-Ziele eingesetzt.


Der Prozess, der für das Verhandeln von Service Level Agreements sowie deren Einhaltung verant-wortlich 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 Berichter-stattung in Bezug auf Service Level sowie für die regelmäßige Durchführung von Kunden-Reviews

11.4 Glossar

365

zuständig. Service Level-Ziel Eine Verpflichtung, die in einem Service Level

Agreement dokumentiert ist. Service Level-Ziele ba-sieren auf Service Level Anforderungen und sollen die Zweckmäßigkeit des Designs eines IT Service sicherstellen. Service Level-Ziele sollten SMART (Spezifisch, Messbar, Akzeptabel, Realistisch, Termi-niert) 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 gesam-ten Lebenszyklus von einem oder mehreren IT Ser-vices 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 Relati-onship Manager, Prozess-Manager, Account Mana-ger oder leitende Manager verwendet, die allgemein für IT Services verantwortlich sind.

Service Operation Eine Phase im Lebenszyklus eines IT Service. Ser-vice 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 bestimm-ten IT Service verantwortlich ist.

Service Portfolio Management

Der Prozess, der für das Management des Service-portfolios verantwortlich ist. Beim Service Portfolio Management steht der Wert der Services im Vor-dergrund, 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 abge-sprochen 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

11 Anhang

366

beispielsweise um das Zurücksetzen eines Pass-worts oder die Bereitstellung standardmäßiger IT Services für einen neuen Anwender handeln. Ser-vice Requests werden in der Regel von einem Ser-vice Desk bearbeitet und erfordern üblicherweise nicht die Einreichung eines RfC.

Service Strategy Der Titel einer der ITIL-Kernpublikationen. Im Rah-men der Service Strategy wird eine umfassende Strategie für IT Services und für das IT Service Ma-nagement entworfen.

Service Transition Eine Phase im Lebenszyklus eines IT Service. Ser-vice 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 verantwort-lich ist. Service Validation and Testing stellt sicher, dass der IT Service den jeweiligen Designspezifika-tionen entspricht und den Bedürfnissen des Busi-ness gerecht wird.

Servicekatalog Eine Datenbank oder ein strukturiertes Dokument mit Informationen zu allen Live IT Services, ein-schließ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 Servicekata-log enthält Angaben zu Lieferergebnissen, Preisen, Bestellungen und Anfragen sowie Kontaktinforma-tionen.

Serviceportfolio Die Gesamtheit aller Services, die von einem Service Provider verwaltet werden. Das Serviceportfolio wird für das Management des gesamten Lebenszyk-lus aller Services genutzt. Es umfasst drei Katego-rien: Servicepipeline (beantragt oder in der Entwick-lung), Servicekatalog (Live oder bereit zum Deploy-ment) und außer Kraft gesetzte Services. Siehe Ser-vice Portfolio Management und Vertragsportfolio.

Single Point of Contact

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

11.4 Glossar

367

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

(Supplier and Contract Database, SCD). Eine Daten-bank oder ein strukturiertes Dokument, das verwen-det wird, um Supplier-Verträge während ihres ge-samten 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 Plan-ning and Support

Der Prozess, der für die Planung aller Service Tran-sition-Prozesse und die Koordinierung der hierfür benötigten Ressourcen verantwortlich ist. Zu diesen Service Transition-Prozessen zählen Change Man-agement, Service Asset and Configuration Man-agement, 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 Un-derpinning Contract definiert Ziele und Verant-wortlichkeiten, 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üh-ren. Die Verfügbarkeit wird durch Aspekte in Bezug auf Zuverlässigkeit, Wartbarkeit, Servicefähigkeit, Performance und Sicherheit bestimmt. Die Verfüg-barkeit wird in der Regel als Prozentwert ausge-drückt, der häufig basierend auf der vereinbarten Servicezeit und der Ausfallzeit berechnet wird. Ge-mäß der Best Practice wird die Verfügbarkeit mithil-

11 Anhang

368

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 bein-haltet 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ön-nen.

Workaround Die Reduzierung oder Beseitigung der Auswirkun-gen von Incidents oder Problemen, für die noch keine vollständige Lösung verfügbar sind, z. B. durch den Neustart eines ausgefallenen Configura-tion 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 do-kumentiert.

11.5 Sachwortverzeichnis

369

11.5 Sachwortverzeichnis —A—Access Management 87, 262 Asset 59 Asset Management 75 Availability Management 8, 56,

66, 228 —B—Balanced Scorecard 3, 5, 135 Benchmark 208 Best Practice 1, 3 Business Case 59 Business Continuity

Management 56, 68 Business-Servicekatalog 63 —C—Capacity Management 55, 65,

225 Change Management 53, 54, 74,

239 COBIT 2, 5, 103 Configuration Management 53,

75 Continual Service Improvement

15, 42, 90, 265 Controls on Demand 212 Critical Success Factor 110, 159 —D—Definitive Media Library 247 Demand Management 47, 61,

220 —E—Evaluation 80, 247

Event Management 82, 250 —F—Financial Management 55, 59,

217 —G—Governance 12, 104 —I—Improvement Prozess 90 Incident 53 Incident Management 6, 52, 84,

151, 252 Information Security

Management 69, 147, 232 ISO 20000 3, 4, 5, 97, 99, 101, 102,

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

Management 56, 68, 231 IT Service Management 5, 52 IT Service Provider 13, 42, 124,

125, 133, 134 IT-Controls 212 ITIL 1, 2, 3, 5, 7, 11, 16, 22, 47 ITIL Best Practice 130 ITIL Refresh 298 —K—Kennzahlen 1, 7, 11, 52, 57, 102,

135, 147, 161, 171, 178, 188, 189, 191, 203, 214, 291

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

11 Anhang

370

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

Knowledge Management 81, 237, 248

Kontinuierlicher Verbesserungsprozess 281

—L—Lifecycle 6, 15, 16 —M—Metriken 113 Monitoring 119 —O—Operational Level Agreement 56,

124, 222 Outsourcing 273, 306 —P—PDCA-Zyklus 147 Plan-Do-Check-Act 102 Problem Management 53, 86,

111, 114, 120, 260 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 Release Management 54, 245 Reporting 119 Request for Change 53, 120

Request Fulfilment 85, 101, 215, 258

Return on Investment 96, 136, 267

Risiko Management 16 —S—Security Management 56, 113,

119 Service 12 Service Asset 75 Service Asset and Configuration

Management 75, 215, 237, 243 Service Catalogue Management

63, 221 Service Design 15, 27, 62, 221 Service Desk 9, 53, 68, 89, 114,

263 Service Improvement-Plan 102,

163, 169, 181, 287 Service Level 38 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 Service Portfolio Management

47, 60, 63, 219 Service Reporting 94, 265

11.5 Sachwortverzeichnis

371

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

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

Service Transition 15, 32, 47, 72, 237

Service Validation and Testing 78, 237

Servicekatalog 22, 63, 128 Serviceportfolio 22, 60, 63, 219 Single Point of Contact 263 Supplier Management 71, 235 System Management 191

—T—Technischer Servicekatalog 63 The 7 Step Improvement Process

265 Transition Planning and Support

72, 237 —U—Underpinning Contract 56, 124,

222 —V—Verification and Audit 242 —W—Workaround 129

Education

Manageme It