Sie sind auf Seite 1von 311

Ralf Buchsein

Frank Victor
Holger Gnther
Volker Machmeier

IT-Management
mit ITIL V3

Edition CIO
Herausgegeben von Andreas Schmitz und Horst Ellermann

Der Schlssel zum wirtschaftlichen Erfolg von Unternehmen liegt heute mehr
denn je im sinnvollen Einsatz von Informationstechnologie. Nicht ob, sondern
WIE die Informationstechnik der Motor fr wirtschaftlichen Erfolg sein wird, ist
das Thema der Buchreihe. Dabei geht es nicht nur um Strategien fr den
IT-Bereich, sondern auch deren Umsetzung um Architekturen, Projekte,
Controlling, Prozesse, Aufwand und Ertrag.
Die Reihe wendet sich an alle Entscheider in Sachen Informationsverarbeitung,
IT-Manager, Chief Information Officer kurz: an alle IT-Verantwortlichen bis
hinauf in die Chefetagen.
Konsequente Ausrichtung an der Zielgruppe, hohe Qualitt und dadurch ein
groer Nutzen kennzeichnen die Buchreihe. Sie wird herausgegeben von der
Redaktion der IT-Wirtschaftszeitschrift CIO, die in Deutschland seit Oktober 2001
am Markt ist und in den USA bereits seit 19 Jahren erscheint.
Chefsache Open Source
Von Theo Saleck
Chefsache IT-Kosten
Von Theo Saleck
IT-Controlling realisieren
Von Andreas Gadatsch
Outsourcing realisieren
Von Marcus Hodel, Alexander Berger und Peter Risi
Von der Unternehmensarchitektur zur IT-Governance
Von Klaus D. Niemann
Optimiertes IT-Management mit ITIL
Von Frank Victor und Holger Gnther
Management von IT-Architekturen
Von Gernot Dern
Fhren von IT-Service-Unternehmen
Von Kay P. Hradilak
IT-Management mit ITIL V3
Von Ralf Buchsein, Frank Victor, Holger Gnther und Volker Machmeier

www.vieweg.de

Ralf Buchsein
Frank Victor
Holger Gnther
Volker Machmeier

IT-Management
mit ITIL V3
Strategien, Kennzahlen, Umsetzung
Mit 77 Abbildungen

Bibliografische Information Der Deutschen Nationalbibliothek


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

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk


berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne
von Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wren und daher von
jedermann benutzt werden drfen.
Hchste inhaltliche und technische Qualitt unserer Produkte ist unser Ziel. Bei der Produktion und
Auslieferung unserer Bcher wollen wir die Umwelt schonen: Dieses Buch ist auf surefreiem und
chlorfrei gebleichtem Papier gedruckt. Die Einschweifolie besteht aus Polythylen und damit aus
organischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffe
freisetzen.

1. Auflage 2007
Alle Rechte vorbehalten
Friedr. Vieweg & Sohn Verlag | GWV Fachverlage GmbH, Wiesbaden 2007
Lektorat: Gnter Schulz / Andrea Broler
Der Vieweg Verlag ist ein Unternehmen von Springer Science+Business Media.
www.vieweg.de
Das Werk einschlielich aller seiner Teile ist urheberrechtlich geschtzt. Jede
Verwertung auerhalb der engen Grenzen des Urheberrechtsgesetzes ist
ohne Zustimmung des Verlags unzulssig und strafbar. Das gilt insbesondere
fr Vervielfltigungen, bersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Umschlaggestaltung: Ulrike Weigel, www.CorporateDesignGroup.de
Druck und buchbinderische Verarbeitung: MercedesDruck, Berlin
Gedruckt auf surefreiem und chlorfrei gebleichtem Papier.
Printed in Germany
ISBN 978-3-8348-0270-5

Vorwort
ITIL als Basis fr eine neue Sicht auf die IT hat sich in den letzten Jahren
rasant in deutschen Unternehmen verbreitet und das mit anhaltendem
Erfolg. Der Grund liegt daran, dass ITIL in der Version 2 gut verstndlich
ist und so die Grundideen des IT Service Managements leicht transportierbar sind.
Seit Juni 2007 ist nun ITIL in der Version 3 am Markt verfgbar. Es scheint
so, als sehe nun vieles anders aus als in Version 2, da das Gesamtwerk
vllig neu strukturiert worden ist und neue Inhalte hinzugekommen sind.
Wir haben fr Sie die ersten Erfahrungen gemacht und sind berzeugt,
dass die ITIL Version 3 keineswegs komplizierter ist als ITIL Version 2,
dafr aber in wesentlichen Aspekten genauer und im Gesamtbild viel integrativer.
Unser Buch gibt Antworten auf zwei Fragen, die in der Praxis fr den
Erfolg einer modernen IT entscheidend sind:
Welche Kennzahlen und Kennzahlensysteme sollte man in der IT
einsetzen?
Welche Strategien sind zur Umsetzung und Steuerung von IT
Service Management Prozessen geeignet?
Sie werden sich vielleicht fragen, wieso wir gerade diese beiden Themen
in einem Buch behandeln. Die Antwort ist: Das sind die Themen, die aktuell in der Praxis relevant sind und Hunderte von Unternehmen nicht nur
in Deutschland beschftigen. Das Erstaunliche ist, dass die beiden Themen eng zusammenhngen und sich gegenseitig beeinflussen. Das Erfreuliche ist, dass mit ITIL V3, COBIT 4 und ISO 20000 ein Best Practice Werkzeugkasten zur Verfgung steht, mit dem man einen Groteil der Herausforderungen an die IT in den Griff bekommt.
Kurzum wir sahen den Bedarf, ein Praxisbuch fr IT-Manager, CIOs,
CTOs, Prozess und Service Manager sowie fr IT-Berater herauszubringen,
das die Lcke zwischen ITIL und Kennzahlen sowie zwischen Theorie und
Praxis schliet. Dabei setzen wir Grundkenntnisse des IT Service Managements und Fachbegriffe voraus.
Die Beispiele, die wir aufgenommen haben, basieren auf unseren Erfahrungen als auch auf Referenz- und Kundenprojekten, die wir begleitet
haben.

Vorwort
Ein Buch, wie dieses, entsteht nur, wenn ausgezeichnete Leute dazu beitragen. Besonders bedanken mchten wir uns bei

Frau Dr. Manuela Claen, Victor GmbH, Bonn


Herrn Jrgen Esterle, Mnchen
Herrn Flavio Gaj, Mailand
Herrn Gerhard Gttert, 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, Mnchen
Herrn Mirko Seithe, Bonn
Herrn Gottfried Weibler, VOSS Automotive GmbH, Wipperfrth
Herrn Michael Zaddach, Flughafen Mnchen GmbH

Fr Ann-Kathrin

Ralf Buchsein
Hagen, im Juni 2007

Fr Manuela, Christina und Luisa

Frank Victor
Bonn, im Juni 2007

Fr meine Eltern, Inge und Heinz

Holger Gnther
Aachen, im Juni 2007

Fr Anna Elisabeth und Gustav

Volker Machmeier
Mailand, im Juni 2007

Haben Sie Fragen zum IT Service Management oder zu Kennzahlen?


Wir helfen Ihnen gerne persnlich weiter:
http://www.KESS-DV.de

info@KESS-DV.de

http://www.VictorGmbH.de

info@VictorGmbH.de

Copyrights
ITIL is a Registered Trade Mark, and a Registered Community Trade Mark of
the Office of Government Commerce, and is registered in the U.S. Patent and
Trademark Office.
COBIT Copyright 1996-2007 by the IT Governance Institute (ITGI)

VI

Inhaltsverzeichnis
1 Einfhrung und berblick ..............................................................................1
2 IT Service Management ...................................................................................5
2.1 Management Summary ............................................................................5
2.2 ITIL und ISO 20000....................................................................................5
2.3 Die Struktur gem ITIL Version 2.........................................................7
2.3.1

Das Service Management auf Basis der ITIL Version 2...........7

2.3.2

Der prozessorientierte Ansatz von ITIL Version 2...................8

2.4 Die Struktur gem ITIL Version 3.......................................................11


2.4.1

ITIL und der Service Lifecycle ..................................................14

2.4.2

Service Strategy...........................................................................15

2.4.3

Service Design.............................................................................18

2.4.4

Service Transition .......................................................................19

2.4.5

Service Operation .......................................................................21

2.4.6

Continual Service Improvement...............................................22

2.4.7

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

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse.....................27


2.5.1

Ausgewhlte Kennzahlen der ITIL Version 2.........................27

2.5.2

Ausgewhlte Kennzahlen der ITIL Version 3.........................32

2.6 ISO 20000 ..................................................................................................50


2.6.1

Die Geschichte der ISO 20000 ...................................................51

2.6.2

Der Aufbau der ISO 20000.........................................................51

2.6.3

Die Inhalte der ISO 20000 ..........................................................53

2.6.4

Die ISO 20000 und Kennzahlen ................................................54

2.7 COBIT........................................................................................................56
2.7.1

Entwicklung von COBIT ...........................................................57

2.7.2

Struktur von COBIT ...................................................................57

2.7.3

Prozess-Management gem COBIT .......................................59

2.7.4

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

2.7.5

Metriken fr IT Service Management-Prozesse .....................66

2.7.6

COBIT Metriken fr IT Service Management-Prozesse ........66

VII

Inhaltsverzeichnis
2.8 Monitoring und Reporting von SLAs ...................................................72
2.8.1

Definition und Interpretation des Begriffs IT Service........73

2.8.2

Service Level Agreements .........................................................77

2.8.3

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

2.8.4

Der Aufbau von SLAs ................................................................79

2.8.5

Die Inhalte von SLAs..................................................................81

2.8.6

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

2.8.7

Abgrenzung der Kennzahlen....................................................88

2.9 Integrationsinstrument: Balanced Scorecard .......................................88


2.9.1

Kernideen.....................................................................................89

2.9.2

Anwendung auf den IT-Bereich ...............................................94

2.9.3

Ausprgungen der Balanced Scorecard ..................................95

2.10 Konsequenzen........................................................................................97
3 IT Prozess-Management ..............................................................................101
3.1 Management Summary ........................................................................101
3.2 PDCA-Zyklus.........................................................................................101
3.3 Etablierung des Prozess-Managements..............................................104
3.3.1

Der Charakter von IT-Prozessen ............................................105

3.3.2

Rollen im Prozess-Management .............................................109

3.4 Definition der Prozessziele und -Kennzahlen ...................................115


3.4.1

Definition der Prozessziele......................................................115

3.4.2

Definition der Prozess-Kennzahlen .......................................124

3.4.3

Dokumentation der Prozess-Kennzahlen..............................130

3.4.4

Reporting der Prozess-Kennzahlen........................................131

3.5 Von der Kennzahl zur Verbesserungsmanahme ............................137


3.6 Kennzahlen mssen reifen ...................................................................140
3.7 Der Umgang mit Kennzahlen ..............................................................141
4 IT Kennzahlensysteme.................................................................................143
4.1 Management Summary ........................................................................143
4.2 Ziele .........................................................................................................144
4.3 berblick.................................................................................................147
4.3.1 SVD 1980 ...........................................................................................148

VIII

Inhaltsverzeichnis
4.3.2 Diebold 1984.....................................................................................149
4.3.3 Kargl 1996 .........................................................................................150
4.3.4 Van der Zee 1996 .............................................................................151
4.4 Bewertung ..............................................................................................152
4.5 Konsequenzen........................................................................................153
5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen .......155
5.1 Management Summary ........................................................................155
5.2 Klassifikationsschema fr IT-Kennzahlen .........................................155
5.2.1

Key Success Factors..................................................................157

5.2.2

Key Performance und Customer Satisfaction.......................160

5.2.3

IT-Controls und Controls on Demand...................................164

5.3 Prozess-Kennzahlen ..............................................................................166


5.3.1

Service Strategy.........................................................................169

5.3.2

Service Design...........................................................................173

5.3.3

Service Transition .....................................................................189

5.3.4

Service Operation .....................................................................202

5.3.5

Continual Service Improvement.............................................217

6 Lessons learned: Empfehlungen und Ratschlge ....................................221


6.1 Management Summary ........................................................................221
6.2 ITIL-Einfhrung ....................................................................................222
6.2.1

Analyse der bestehenden Prozesse ........................................222

6.2.2

Prozess-Einfhrungen..............................................................226

6.2.3

Die Organisation gewinnen ....................................................229

6.2.4

Rollenbeschreibungen..............................................................230

6.3 Kontinuierlicher Verbesserungsprozess.............................................233


6.3.1

KVP der bestehenden Prozesse ..............................................234

6.3.2

KVP der neuen Prozesse..........................................................236

6.3.3

Wettbewerb der Prozesseinfhrung ......................................241

6.3.4

Reifegradanalyse der Prozesse im laufenden Betrieb..........242

6.4 Kennzahlen.............................................................................................243
6.4.1

IT-Prozesse am Tagesgeschft ausrichten .............................244

6.4.2

ITIL abgestimmt auf die Business- und IT-Strategie ...........247

IX

Inhaltsverzeichnis
6.4.3

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

7 Praxisbeispiel: ALTANA Pharma AG .......................................................257


8 Praxisbeispiel: Autobahn Tank & Rast GmbH .........................................265
9 Praxisbeispiel: Flughafen Mnchen...........................................................269
10 Praxisbeispiel: VOSS Gruppe....................................................................285
11 Anhang.........................................................................................................289
11.1 Quellenverzeichnis ..............................................................................289
11.2 Abkrzungsverzeichnis.......................................................................297
11.3 Abbildungsverzeichnis .......................................................................299
11.4 Sachwortverzeichnis ...........................................................................302

1 Einfhrung 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 cant have one without the other.

ITIL und
Kennzahlen:
You cant
have one
without the
other.

Ein halbes Jahrhundert spter mag sich einiges im gesellschaftlichen Leben


gendert haben. Fr ein modernes und erfolgreiches IT-Management gehren jedoch (mindestens) zwei Dinge zusammen: ITIL und Kennzahlen:
You cant have one without the other.
Kennzahlen dienen im Allgemeinen zur Steuerung von Bereichen und
Prozessen. Fr die IT sind von jeher IT-Controls als auch Prozess-Kennzahlen vorgeschlagen und eingesetzt worden.
ITIL als Best Practice Ansatz untersttzt explizit die Steuerung der IT-Prozesse auf der Basis von Kennzahlen. In ITIL V3 werden fr jeden Prozess
die Key Performance Indicators bzw. Metrics genannt.
Verwendet man die Kennzahlen des IT Service Managements, so ergnzt
man einerseits die Steuerung der IT um wichtige Stellgren, andererseits
hat man auch eine viel grere Anzahl von Kennzahlen zu erheben, um
diese in Reports darzustellen.
Sie werden sich fragen: Und, ist das schlimm?
In unseren Projekten haben wir die interessante Beobachtung gemacht,
dass fast alle IT-Organisationen ber eine beachtliche Anzahl von Kennzahlen verfgen. In einem kleinen mittelstndischen Unternehmen haben
wir die Kennzahlen bei der Ist-Aufnahme einfach einmal gezhlt: In der
IT-Organisation mit 12 Personen wurden in der Tat monatlich ca. 500 (!)
Kennzahlen gemessen und an den CIO weitergegeben. Dieses Phnomen
haben wir in fast allen Unternehmen gesehen und schlieen daraus: Es
gibt kaum eine Organisationseinheit, die ber so viele Kennzahlen verfgt
wie die IT. Dies liegt vor allen Dingen daran, dass die IT es gewohnt ist,
mit Kennzahlen zu arbeiten hier vor allen Dingen mit technischen Kennzahlen aus dem System- und Netzmanagement.
Vielleicht denken Sie, man knne auf die Mehrzahl der Kennzahlen verzichten?
Da mssen wir Sie enttuschen: 95 % der Kennzahlen sind notwendig und sinnvoll. Sie mssen erhoben werden! Aber wie kann man sie in dieser Komplexitt
managen und beherrschbar machen?

ITIL V3
enthlt
ProzessKennzahlen.

1 Einfhrung und berblick


Das A und O ist und dies gilt fr alle komplexen Systeme , dass man
sich Gedanken ber das Design des Systems macht. Mchte man ein ITKennzahlensystem entwickeln und einfhren, so sollte man im Vorfeld die
richtigen Fragen stellen:

top down
Verfahren zur
Entwicklung
von ITKennzahlensystemen.

Welche Ziele verfolgen wir mit dem Kennzahlensystem?


Welche Kennzahlensysteme sind fr meine IT relevant?
Wen adressiert das Kennzahlensystem?
Welche Kennzahlen knnen (nicht) gemessen werden?
Welchen Aufwand darf das Kennzahlensystem verursachen?

Die Beantwortung dieser oder hnlicher Fragen fhrt zu einem top down
Ansatz fr IT-Kennzahlensysteme, den wir oft in Praxisprojekten eingesetzt haben. Aber dies ist nur die eine Seite der Medaille: Fr die reale
Einfhrung eines IT-Kennzahlensystems ist es enorm wichtig, die ITOrganisation dort abzuholen, wo sie steht. Hier bietet sich ein bottom upVerfahren an, durch das ermittelt wird, welche Kennzahlen bereits in verschiedenen Bereichen erhoben und genutzt werden.
In unserem Buch beschreiben wir diesen Ansatz in einem Praxisleitfaden, der
beide Aspekte enthlt.

bottum up
Verfahren zur
Erhebung von
Kennzahlen.

Die Frage, ob man mit der Entwicklung eines IT-Kennzahlensystems auf


der grnen Wiese beginnt, stellt sich in der Praxis nicht! Es gibt keine
kennzahlenlose IT.

ITKennzahlensysteme sind
Guidelines.

Die Quintessenz: IT Kennzahlensysteme sagen, was man messen knnte,


aber nicht, was man messen sollte! Sie sind damit Guidelines nicht mehr
und nicht weniger!

Wir haben ca. 15 IT-Kennzahlensysteme identifiziert, die verffentlicht


worden sind und in der Praxis eingesetzt werden. Herauszustellen ist,
dass COBIT 4 die grte berdeckung mit IT Service Management-Anstzen, wie ITIL, liefert. Aus der Tradition der IT-Revision heraus und zum
Nachweis von Compliance-Anforderungen seitens der Wirtschaftsprfer
wird COBIT in sehr vielen Unternehmen eingesetzt. In unseren Projekten
haben wir uns allerdings nie nur auf COBIT und ITIL beschrnkt, sondern
immer verschiedene Kennzahlensysteme nebeneinander gelegt. Auffallend dabei ist, dass der berdeckungsgrad der Kennzahlensysteme eher
gering ist: Jedes Kennzahlensystem liefert neue Aspekte!

Im Wesentlichen hngt diese Tatsache davon ab, dass ein Kennzahlensystem sich in der Praxis aus dem Zielsystem der IT ableiten muss und daher
strategische und taktische Dimensionen hat.

1 Einfhrung und berblick


Eine IT-Organisation ist gut beraten, ihr eigenes IT-Kennzahlensystem
aufzubauen und es nicht nur zur reinen Steuerung der IT einzusetzen,
sondern ber das Kennzahlensystem Teile der IT-Strategie umzusetzen.1
In diesem Zusammenhang verstehen wir Kennzahlensysteme etwas
berspitzt formuliert als mgliche 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 Untersttzung der Business Prozesse und Anforderungen zu berichten.
Im Buch stellen wir die wichtigsten Kennzahlensysteme kurz vor und zeigen auf,
wie man zu einem eigenen Kennzahlensystem kommt. Hierbei spielt die Balanced Scorecard eine tragende Rolle.

Wir glauben, dass das IT Service Management einen der wichtigsten Meilensteine fr die IT darstellt. Wir glauben auch, dass IT Service Management ohne IT-Kennzahlen, und IT-Kennzahlen ohne IT Service Management keinen Sinn machen. Unser Buch ist gedacht als Brcke zwischen
diesen beiden Anstzen.
Ein wesentlicher Teil unserer Ausfhrungen beschftigt sich daher mit
Steuerungsmechanismen, die von ITIL, COBIT und ISO 20000 bereitgestellt werden, so wie mit den Kernideen des ITIL-basierten ProzessManagements.
Die in ITIL V3 verfgbaren IT-Kennzahlen werden in entsprechende Zusammenhnge eingeordnet und nach ihrem Einsatz in der Praxis klassifiziert.

Unser Buch fllt damit in den ersten 5 Kapiteln eine Toolbox, die ITVerantwortliche zum Aufbau eines Kennzahlensystems einsetzen knnen.
Insbesondere mit der ITIL Version 3 werden die Best Practices fr das IT
Service Management in Richtung Business Integration beschrieben. Damit
steht das Management hufig vor der Herausforderung, in einer bestehenden Organisation die Prozesse zu verankern und die Mitarbeiter von den
notwendigen Vernderungen zu berzeugen.
Wir haben die Erfahrung gemacht, dass keine noch so gut ausgestattete
Toolbox ein Garant fr den Erfolg eines Projekts ist. Unabdingbar ist die
Tatsache, dass man die Menschen mitnimmt.
In den Projekten, die wir begleitet haben, waren ngste, Hoffnungen, persnliche Schicksale, Prferenzen, Einstellungen, Interessen, Flexibilitt und

Kaplan und Norton haben dies als Translating Strategy into Action bezeichnet (vgl. [Kaplan et al., 1996]).

Michael
Hammer:
The
Balanced
Scorecard
A Landmark
Achievement

1 Einfhrung und berblick


Fhigkeiten einzelner Personen wesentliche Determinanten fr Erfolg oder
Misserfolg.
Die Qualitt und Ausprgung der Vernderungs- und berleitungsprozesse und
das damit verbundene Vorgehen sind wichtige kritische Erfolgsfaktoren fr IT
Service Management und Kennzahlen-Projekte.
Change und
Vernderungs-Prozesse sind wesentliche
Bestandteile
des Vorgehensmodells.

Unser Buch beschftigt sich mit diesem sensiblen und interessanten Thema im 6. Kapitel, das wir mit Lessons learned berschrieben haben.
Basierend auf unseren Projekterfahrungen stellen wir ein Vorgehensmodell vor, mit dem die notwendigen Vernderungs- und berleitungsprozesse auch im Hinblick auf einen kontinuierlichen Verbesserungsprozess besser und erfolgreicher gesteuert werden knnen.

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 bemht,
die Kapitel weitgehend unabhngig voneinander zu formulieren.
Springen Sie einfach in ein Kapitel, das Sie interessiert:
Kapitel 2: IT Service Management und verwandte Themen aus
Sicht der Praxis mit ISO 20000, ITIL V3, COBIT 4, SLAs und Balanced Scorecard.
Kapitel 3: IT Prozess-Management mit Rollen, Zielen, Kennzahlen
und kontinuierlichem Verbesserungsprozess.
Kapitel 4: Die wichtigsten IT-Kennzahlensysteme in der Praxis
und die Konsequenzen hinsichtlich der Fragestellung: Welche ITKennzahlen setzen wir ein?
Kapitel 5: Praxisleitfaden zur Entwicklung von IT-Kennzahlensystemen mit Klassifikationsschemata und Prozess-Kennzahlen aus
ITIL V3 und unseren Projekterfahrungen.
Kapitel 6: Wie geht man am besten in IT Service Management Projekten vor? Empfehlungen aus unseren Projekten fr Transition und
Change Prozesse.
Praxisbeispiele:
Kapitel 7: IT Service Management im regulierten Umfeld am
Beispiel der ALTANA Pharma AG
Kapitel 8: Autobahn Tank & Rast GmbH mit einem Kennzahlensystem, das gemeinsam mit dem Controlling entwickelt wurde.
Kapitel 9: IT Service Management beim Flughafen Mnchen
Kapitel 10: IT Management Report in der VOSS Gruppe.

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 Anstze heute als Best Practice. Dabei weisen COBIT und
ITIL eine groe berstimmung hinsichtlich der IT Service ManagementProzesse auf, whrend die Balanced Scorecard als Integrationsinstrument
prdestiniert ist.
In diesem Kapitel gehen wir auf diese Best Practices ein und stellen heraus,
wie die einzelnen Anstze im Hinblick auf die Entwicklung von Kennzahlensystemen zu positionieren sind. Bezglich der Kennzahlen nehmen wir
die Beschrnkung vor, dass wir nur die behandeln, die aus unserer Sicht
eine hohe Praxisrelevanz haben.
Die Fragestellung, welcher Ansatz der geeignete zum Aufbau eines Kennzahlensystems ist, fhrt im Allgemeinen nicht zum Ziel. Es geht vielmehr
darum, herauszufinden, wie die Komponenten der verschiedenen Anstze
in einem Puzzle zusammengefgt werden knnen, um das bestmgliche
Kennzahlensystem fr die jeweilige IT-Organisation aufzubauen.
Wichtige Voraussetzung ist dabei immer, dass es definierte Ziele fr die
jeweiligen IT Service Management-Prozesse gibt und dass das Prozessund IT-Management das Kennzahlensystem als Fhrungsinstrument versteht und aktiv einsetzt.

2.2 ITIL und ISO 20000


ITIL und ISO 20000 IT Service Management sind zwei international bewhrte Practices zur erfolgreichen Etablierung eines IT Service Managements. Die Zielsetzung eines IT Service Managements besteht in der Bereitstellung von IT-Leistungen (IT Services) zur Untersttzung der Geschftsprozesse. Hierzu sind die notwendigen Leistungen zu planen, bereitzustellen, zu berprfen und bei Bedarf zu optimieren.

2 IT Service Management
Um die Ziele des IT Service Managements zu erreichen, haben sich in den
letzten Jahren IT-Prozesse etabliert, die ein wirksames Management sicherstellen und grundstzlich in allen IT-Organisationen etabliert werden
knnen. Diese IT Service Management-Prozesse sind in den ITIL Best Practices sowie der ISO 20000 dokumentiert.
Der Ansatz von ITIL Version 2 bestand in der Bereitstellung von Best Practices zur Gestaltung, Implementierung, Betrieb und Optimierung der notwendigen IT Service Management-Prozesse. Mit der Verffentlichung der
ITIL Version 3 wurden die Ausrichtung und der Inhalt umfangreich erweitert. ITIL deckt nun den Service Lifecycle ausgehend von der Strategie
bis zu einer stndigen Verbesserung des Service Managements ab. Hierzu
werden nicht nur Prozesse beschrieben, sondern vollstndige Modelle fr
den Service und das Service Management.
ITIL beinhaltet ein generisches Prozessmodell und bewhrte Vorgehensweisen zur Einfhrung und zum Management des Service Management
und dessen Integration in das Business. Die ISO 20000 enthlt dagegen die
Anforderungen an ein IT Service Management. Daher ergnzen sich ITIL
und die ISO 20000 ideal. Whrend die ISO 20000 die Mindestanforderungen an ein IT Service Management definiert, liefert ITIL hierzu Best Practices fr den Aufbau des organisationsspezifischen IT Service Managements.
Die Prozessorientierung von ITIL und der ISO 20000 stellt eine weitgehende Unabhngigkeit 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 ermglichen unter
anderem die berprfung der Prozesse hinsichtlich ihrer Wirksamkeit.
Das Verstndnis der Prozessziele ist die wichtigste Grundvoraussetzung
fr die richtige Interpretation von Kennzahlen. Ohne ausreichende Kenntnisse der Prozessziele und der damit verbundenen Prozessaktivitten besteht die Gefahr einer Fehlinterpretation von Kennzahlen.
Als Beispiel hierfr soll der Prozess des Incident Managements dienen.
Das Ziel des Incident Managements besteht in der schnellstmglichen
Wiederherstellung des vereinbarten Service fr den Geschftsablauf. Hierzu wird in der Regel als Kennzahl Anzahl der Strungen oder Dauer
bis zur Wiederherstellung des Service gemessen. Steigt die Anzahl von
Strungen oder die Dauer bis zur Wiederherstellung des Service an, so
wre es eine Fehlinterpretation, das Incident Management hierfr verantwortlich zu machen. Die Kennzahl Anzahl von Strungen wird zwar in

2.3 Die Struktur gem ITIL Version 2


diesem Prozess gemessen, aber die Identifizierung von Strungsursachen
und deren nachhaltige Behebung liegen nicht in der Verantwortung des
Incident Management-Prozesses. Daher hat das Incident Management den
Anstieg der Strungen nicht zu verantworten.
Die Definition und Interpretation von Kennzahlen fr IT Service ManagementProzesse setzt voraus, dass die Prozessziele dokumentiert und insbesondere dem
Management bekannt sind.

ITIL Version 2 und ITIL Version 3


Innerhalb der ITIL Best Practices sind bewhrte Umsetzungsmanahmen
fr die Einfhrung, Etablierung und Optimierung der IT Service Management-Prozesse dokumentiert.
ITIL ist ein De-facto-Standard fr das IT Service Management, da die meisten IT-Organisationen nach ITIL ausgerichtet sind.
Heute muss man 2 Versionen von ITIL unterscheiden:
ITIL Version 2 (wurde am 1. Juni 2007 durch die Version 3 abgelst)
ITIL Version 3
Im Folgenden stellen wir die Struktur dieser beiden Versionen vor. Gehen
aber schwerpunktmig auf Version 3 ein, da ITIL Version 2 den meisten
Lesern bekannt sein drfte und Anfang Juni 2007 durch die Version 3 abgelst wurde.

2.3 Die Struktur gem ITIL Version 2


2.3.1

Das Service Management auf Basis der ITIL Version 2

Die wichtigsten Aspekte der ITIL Best Practices in der Version 2 sind in
sieben Publikationen dokumentiert. Dabei beinhalten die Publikationen
Service Support, Service Delivery und Security-Management die
relevanten IT Service Management-Prozesse.
Die Rahmenstruktur in Abbildung 1 aus [OGC, 2005a] beschreibt die ITIL
Best Practices auf Basis des Standardwerks Best Practice Einfhrung in
ITIL.
An dieser Stelle mchten wir auf ein sehr gutes Buch verweisen. In Optimiertes IT Management mit ITIL [Victor et al., 2005] werden die wesentlichen Aspekte von ITIL 2 und ein Einfhrungsleitfaden beschrieben.

2 IT Service Management

Planning to Implement Service Management


T
h
e
B
u
s
i
n
e
s
s

T
h
e

Service Management
Service Support
The
Business
Perspective

Service Delivery

ICT
Infrastructure
Management

Security
Management

Application Management

Abbildung 1:

T
e
c
h
n
o
l
o
g
i
e

ITIL Rahmenstruktur

Abbildung 2 stellt einen berblick ber die 10 ITIL Prozesse der Version 2
dar.

2.3.2

Der prozessorientierte Ansatz von ITIL Version 2

Bei den ITIL Best Practices handelt es sich um einen prozessorientierten


Ansatz. Fr das IT Service Management sind in den ITIL-Publikationen
der ITIL V2 Service Support, Service Delivery und Security-Management hierzu insgesamt elf erforderliche IT-Prozesse dokumentiert.
Gem ITIL ist ein Prozess eine zusammenhngende Folge von Aktivitten mit
dem Ziel, einen gegebenen Input in einen definierten Output zu transformieren.

Der Output eines Prozesses muss aus der geschftlichen Zielsetzung abgeleitet werden und kann Input fr einen anderen Prozess darstellen. So
nimmt zum Beispiel der Prozess des Capacity Managements in enger Zusammenarbeit mit dem Service Level Management (SLM) die Kundenanforderungen an einen IT Service auf. Insofern ist das SLM der Anfang des
ITIL Prozessmodells und steht in enger Verbindung mit dem Kunden.
Die Anforderungen bezglich der Verfgbarkeit sind der Input fr das
Availability Management zur Planung und berprfung der IT-Verfgbarkeit. Jeder IT Service Management-Prozess hat eine charakteristische Ziel-

2.3 Die Struktur gem ITIL Version 2


richtung und trgt im Zusammenwirken mit den anderen IT Service Management-Prozessen dazu bei, dass dem Kunden die notwendigen IT Services zur wirkungsvollen Untersttzung seiner Geschftsprozesse geliefert
werden.
Die ITIL Best Practices beinhalten Prozessbeschreibungen mit wechselseitigen
Aktivitten.

Service Level
Management
Continuity
Management

Service
Delivery

Financial
Management

Capacity
Management

Availability
Management

Incident
Management
Configuration
Management

Release
Management
Abbildung 2:

Service
Support

Problem
Management

Change
Management

Die 10 ITIL-Prozesse und der Service Desk

Gem der ITIL Best Practices ist die Aufgabe der Prozesssteuerung bzw.
des Prozess-Managements
der Prozess der Planung und Regelung; mit dem Ziel, einen Prozess in einer
effektiven und effizienten Weise durchzufhren.

Hierzu sind in einem generischen Prozessmodell die wichtigsten Aufgaben beschrieben (siehe Abbildung 3, aus Best Practice Einfhrung in
ITIL, [OGC, 2005a]).

2 IT Service Management
Ziele des
Prozesses

ProzessOwner
Qualittsparameter
und KPIs
Prozessmanagement

Aktivitten und
Subprozesse

Input

Output

Prozessausfhrung

Ressourcen

Rollen

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

Generisches ITIL-Prozessmodell

Auf Basis der vom Prozess Owner vorgegebenen Prozessziele gilt es, die
notwendigen Aktivitten und Subprozesse der jeweiligen IT Service Management-Prozesse zu designen und zu implementieren. Angesichts der
Komplexitt der Prozessdurchfhrung in IT-Organisationen muss eine
formelle berprfung der Zielerreichung sichergestellt werden. Dazu
dienen die definierten Qualittsparameter und Leistungsindikatoren (Key
Performance Indicators, KPIs).
Zielsetzung von ITIL war die Beschreibung von (weitgehend) organisationsneutralen Best Practices. Daher werden zur Durchfhrung von Prozessaktivitten Rollen definiert, die mit den erforderlichen Ressourcen zu
untersttzen sind. Die Leistungsindikatoren (KPIs) dienen auch zum Management der eingesetzten Ressourcen.
Ohne Qualittsparameter und Leistungsindikatoren (KPIs) ist ein wirksames
Prozess-Management unmglich.

Um ein wirksames Prozess-Management zu erreichen, muss kontinuierlich


berprft werden, ob die definierten Prozessziele wirkungsvoll erreicht
werden (Effektivitt) und mit welchem Aufwand dieses Ergebnis erzielt
wird (Effizienz).

10

2.4 Die Struktur gem ITIL Version 3


ITIL und insbesondere die ISO 20000 fordern, fr jeden IT Service Management-Prozess ein wirksames Prozess-Management zu etablieren.
Bei der Definition von ITIL Kennzahlen gilt es, IT Service Management-Prozesse
zu messen und so die Voraussetzung fr deren Management zu schaffen.

Die ITIL Best Practices sind als Guidelines fr 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
Manahmen konkret umzusetzen sind, ist Aufgabe des Prozessdesigns.
Die Umsetzung erfolgt immer organisationsspezifisch, in Abhngigkeit
von den Geschftsanforderungen der Kunden und unter Bercksichtigung
sozialer Belange.
Demzufolge liefert ITIL generische Empfehlungen fr das IT Service Management, aber die Prozesse mit ihren konkreten Zielen und Aktivitten
sind immer auf die spezifischen Belange der IT-Organisation auszurichten.
Diese Philosophie hat auch Auswirkungen auf die ITIL Best Practices fr
Kennzahlen.
Die ITIL Best Practices fr Kennzahlen sind Guidelines. Die Definition von ITIL
Kennzahlen muss immer auf die organisationsspezifischen Prozesse mit ihren
Zielen und Aktivitten ausgerichtet sein. Die ungeprfte bernahme von empfohlenen Kennzahlen ist nicht zielfhrend.

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 geringfgige Abweichungen in den
ausgewiesenen Leistungsindikatoren (KPIs) festzustellen.

2.4 Die Struktur gem ITIL Version 3


Mit der Publikation von ITIL Version 3 richten sich die ITIL Best Practices
noch strker auf die Business-Anforderungen aus. Speziell mit der zentralen Publikation Service Strategy wird ein wichtiger Betrag zum IT Governance geliefert.
Die Zielsetzung von ITIL mit der Version 3 besteht in der Business Integration.

Mit der neuen Version von ITIL ist nicht mehr die Abkrzung fr IT
Infrastructure Library verbunden, sondern ITIL ist nun ein Synonym fr
Service Management.

11

ITIL
Kennzahlen
sind lediglich
Empfehlungen.

2 IT Service Management
Hierzu definiert die ITIL Version 3 den Begriff ITIL wie folgt:
A set of Best Practice guidance for IT Service Management. ITIL is owned by the
OGC and consists of a series of publications giving guidance on the provision of
Quality IT Services, and on the Processes and facilities needed to support them.

Mit der Herausgabe der ITIL Version 3 hat sich auch der Fokus des Service
Managements erweitert. Whrend in der frheren Version von ITIL das
Service Management noch als das zur Erfllung der Kundenanforderungen erforderliche Management definiert wurde, lautet die Definition jetzt
wie folgt (vgl. Service Strategy, [OGC, 2007a]):
Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services.

Sinngem wrde dies bedeuten: Service Management ist die Gesamtheit


spezialisierter organisatorischer Fhigkeiten, um den Kunden in Form von
Services einen Wert zu liefern.
Den Service definiert ITIL (Version 3) als:
Service:
A means of delivering value to customers by facilitating outcomes customers
want to achieve without the ownership of specific costs and risks.

Sinngem bedeutet damit der Begriff Service:


Ein Service ist eine Dienstleistung, die einen Nutzen fr den Kunden
bringt und die Ergebnisse liefert, die er erwartet.
Dabei kann er sich entspannen, denn die durch den Service verursachten
Kosten und Risiken liegen im Allgemeinen nicht bei ihm sondern beim
Service Provider."
Innerhalb der Publikation Service Strategie wird der Bezug eines Service
zu den Geschftsprozessen des Business deutlich herausgestellt. Letztendlich stellen die Services die Geschftsprozesse des Business sicher bzw.
stellen zum Teil den Service aus Sicht des Kunden dar (Abbildung 4, aus
Service Strategy, [OGC, 2007a]).
Damit verbunden ist auch die Erweiterung der Definition fr den IT Service (aus Service Strategy, [OGC, 2007a]):
IT Service:
A Service provided to one or more Customers by an IT Service Provider. An IT
Service is based on the use of Information Technology and supports the
Customer's Business Processes. An IT Service is made up from a combination of
people, processes and technology and should be defined in a Service Level
Agreement."

12

2.4 Die Struktur gem ITIL Version 3

Business
Service

Business
Service

Business Prozesse

Zerlegung

Abstraktion und Zusammensetzung

Services

Services

Ressourcen und Fhigkeiten


Internet

Personal
Abbildung 4:

Die Ausrichtung der Services auf das Business

Sinngem lsst sich der IT Service wie folgt definieren.


IT Services werden von einem IT Service Provider fr einen oder
mehreren Kunden bereitgestellt.
IT Services nutzen die Informationstechnologie und untersttzen
die Business Prozesse der Kunden.
IT Services definieren sich aus Personen, Prozessen und Technologien.
IT Services sind in Service Level Agreements zu definieren.

13

2 IT Service Management
IT Services bestehen in der Regel aus verschiedenen Systemen und Teilleistungen mit unterschiedlichen Verantwortungen und Zustndigkeiten.
Da dies in der Vergangenheit zu Kompetenzproblemen gefhrt hat, wird
in ITIL Version 3 auch die Rolle des Service Owners spezifiziert (vgl. [OGC,
2007e]):
Der Service Owner ist verantwortlich fr einen spezifischen Service, unabhngig
davon, wo innerhalb der Organisation die zugrundeliegenden technologischen
Komponenten, Prozesse oder professionellen Fhigkeiten angesiedelt sind.

In der ITIL Version 3 sind nicht nur Prozesse fr das Service Management
beschrieben, sondern der gesamte Service Lifecycle. Angefangen von der
Strategie (Service Strategy), ber das Design (Service Design), der berfhrung in den Betrieb (Service Transition) und der operationelle Betrieb (Service Operation). Diese Phasen und damit verbundenen Aktivitten unterliegen einem kontinuierlichen Verbesserungsprozess (Continual Service
Improvement). Hierzu werden nicht nur Service Management-Prozesse beschrieben, sondern zum Beispiel auch die strategische Ausrichtung der IT,
Methoden oder notwendige Aufgaben wie das Risiko Management.
ITIL mit der Version 3 ist mehr als eine Sammlung von Prozessen. ITIL Version 3
ist ein ganzheitlicher integrierter Ansatz von Best Practices fr das Service
Management.

2.4.1

ITIL und der Service Lifecycle

Die ITIL Library besteht aus den folgenden Komponenten:


Der ITIL Core als Leitfaden fr alle Organisationen, die Dienstleistungen anbieten.
Die ITIL Complementary Guidance als ergnzender Leitfaden fr industrielle Bereiche, Organisationstypen, Betriebsmodelle und technologische Architekturen.
Die ITIL Web Support Services mit Zusatzprodukten, Prozessmodellen, Templates und Studien.
Der ITIL Core besteht aus fnf 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])

Ergnzt werden diese Publikationen um eine allgemeine Einfhrung The


Official Introduction to Service Lifecycle ([OGC, 2007e]).

14

2.4 Die Struktur gem ITIL Version 3


Die fnf Core Publikationen bilden die Phasen eines iterativen und mehrdimensionalen Lifecycles fr die Services. Lernen und Reifen der Organisationen sollen ermglicht werden. Ziele sind: Struktur, Stabilitt und
Strke auf der Basis dauerhafter Prinzipien, Methoden und Werkzeuge.
Dies soll dem Schutz von Investitionen dienen. Was hier angestrebt wird
ist ein Kreislauf aus Messen, Lernen und Verbesserung.
Abbildung 5 verdeutlicht das Zusammenspiel dieser 5 Phasen.

Continual
Service
Improvement
Service
Transition

Service
Strategy
Service
Design

Abbildung 5:

2.4.2

Service
Operation

Die 5 Phasen des Service Lifecycles nach ITIL V3.

Service Strategy

Im Zentrum des dargestellten Service Lifecycles steht die Phase Service


Strategy (vgl. [OGC, 2007a]). Hier werden die strategischen Entscheidungen getroffen. Es gut um das Design, die Entwicklung und Implementierung des Service Managements nicht nur im organisatorischen sondern
vielmehr im strategischen Sinne.
Service Management Richtlinien (Policies), Anleitungen und Prozesse ber
den gesamten ITIL Service Lebenszyklus hinweg werden hier entwickelt
und untersttzt. Service Strategy bildet im Kern des Kreislaufs das zentrale

15

2 IT Service Management
strategische Fundament fr die Phasen Service Design, Service Transition,
Service Operation und den alles umfassenden permanenten Verbesserungskreislaufs des Continual Service Improvement.
Ausgangspunkt der Phase Service Strategy sind die Identifizierung, Auswahl und Priorisierung von Geschftschancen und Marktpltzen. Betrachtungen und Analysen der Marktentwicklung und die Definition von Zielen und Erwartungen fhren zur Formulierung von Serviceleistungen
gegenber Kunden und Marktpltzen. Mit Untersttzung des Finanzmanagements wird ein Service Portfolio definiert und die Entwicklung eines
Service Katalogs vorbereitet. Auch Themen wie Organisationsentwicklung
sowie Kosten- und Risikobetrachtungen im Hinblick auf das Service Portfolio werden angegangen. Neben dem Faktor operationelle Effizienz geht
es entscheidend um ganzheitliche, nachhaltige und effektvolle Entscheidungen und Leistungen und deren Entwicklung. Strategische Reviews
helfen, Fhigkeiten zu verbessern tragen zum weiteren Ausbau von Geschftsstrategien und -chancen bei.
Das Fazit in einem kurzen Satz wre wohl folgendermaen zu formulieren: Erst das WAS, dann das WIE!
Im gesamten Service Lifecycle wird eines sehr deutlich: die Ausrichtung
der Services an den Anforderungen und am wirklichen Bedarf des Kunden und seines Geschftes. Dieses Ziel wird stringent verfolgt. Services der
Lieferanten werden auf die Business Services fokussiert, damit deren Leistungen zur direkten Untersttzung der Geschftsziele dienen. Business Service Management liefert hierfr ein Modell mit den entsprechenden Metriken (vgl. Abbildung 6).
Business Service Management is the ongoing practice of governing, monitoring
and reporting on the IT and the business services it impacts.

16

2.4 Die Struktur gem ITIL Version 3

Business Service

IT Service

C
D

Business Prozesse
Informationen

Management

Personen

Workflow

Applikationen

Infrastruktur

Knowledge

ermglicht

lose
Koppelung

Service Plattform
Availability
Continuity

Informationen

Workflow

Capacity
Security

Gewhrleistung

Applikationen

Infrastruktur

Knowledge

Nutzen

A
Schliet
ein

Management

Personen

Nutzen

IT Applikationen

Service Plattform
Availability
Continuity

Capacity
Security

Gewhrleistung

A Bndelung Business Prozess und IT Applikation zu einem Service.


B Bereitstellung einer Service- Schnittstelle und sicherstellen, dass der Service fr die
Nutzung verfgbar ist, mit einer adquaten Kapazitt, Kontinuitt und Sicherheit.
C Verbessern der Business Prozesse um den Nutzen fr die Business Service zu verbessern.
D Verbessern der IT Applikationen um die Gewhrleistung der IT Services zu steigern.
Abbildung 6:

Verbindung zwischen IT Service und Business Service

Wurde das Service Management bisher als taktische oder operative Aufgabe angesehen, so stellt das Service Management jetzt einen geschlossenen Regelkreis dar, wobei die Phase Service Strategie die Basis bildet (siehe Abbildung 7, aus Service Strategy, [OGC, 2007a]).

17

2 IT Service Management

Strategie Implementierung
Service
Design
Anforderungen
Service
Strategy
Service Portfolio
Service Katalog

Service
Transition
Anforderungen

Service
Design

Service
Transition

Service
Operation
Service
Operation
Anforderungen

Abbildung 7:

2.4.3

Messung
und
Bewertung

Continual
Service
Improvement

Messung
und
Bewertung

Service Strategy Prozesse

Service Design

Die Phase Service Design (vgl. [OGC, 2007b]) dient dem Design und der
Entwicklung von Services und Service Management-Prozessen.
Ausgehend von den strategischen Zielen, die in der Phase Service Strategy
definiert wurden, findet hier die Transformation zu einem Portfolio von
Services statt. Wichtigstes Ergebnis dieser Stufe ist das Design einer effektiven und effizienten Service-Lsung. Die sich stndig verndernden Anforderungen des Business und der IT erfordern eine stndige Interaktion
mit allen anderen Bereichen und Prozessen.
Abbildung 8 verdeutlicht dies. Beim Design werden diese Bereiche und
Prozesse in den Service Design Aktivitten bercksichtigt, um alle ServiceLsungen mit existierenden Lsungen konsistent und kompatibel zu gestalten.
Dies beinhaltet auch nderungen und Verbesserungen, die notwendig
werden, um sowohl den Wert der Services fr den Kunden ber den Lebenszyklus der Services hinweg zu erhalten, als auch die Kontinuitt der
Services, das Erreichen der Service Qualitt (Level) und die Konformitt
zu Standards und Regeln.

18

2.4 Die Struktur gem ITIL Version 3


Siehe hierzu Abbildung 8, die Service Design Prozesse aus Service Design, [OGC, 2007b].

Betrieb
Neue Anforderungen

Neue Anforderungen

Service
Strategy

Strategie und
Bedingungen

Analyse
Anforderungen,
dokumentieren
& vereinbaren

Service Design
Package

Bereitstellung
vorgezogene
Lsung

Beurteilung
alternativer
Lsungen

Design Service
Lsung

Service
Transition

Entwicklung
der Lsung

Service
Operation

Service
Design

Architekturen
Messmethoden

Service
Portfolio

Service
Katalog

Key Service
Design Prozesse
SLM:
Policy, Plne,
SIP, SLRs, SLAs,
OLAs, Reports

Service
Katalog M.

Capacity:
Policy, Plne,
CIMS,Reports,
Sizing, Forecast

Service Level
Management

Availability:
Policy, Plne,
Designkriterien,
AMIS, ..

Capacity
Management

IT SCM:
Policy, Plne,
BCPs, IT SCPs,
Risiko-Analyse, ..

Availability
Management

Security:
Policy, Plne,
Controls, Reports,
Klassifizierung, .

ITSC
Management

Security
Management

Supplier:
Policy, Plne,
contracts, SCD,
Reports.

Supplier
Management

Input aus anderen Bereichen wie Incidents, Probleme, Request Fulfillment, Access, Change, Configuration,
Knowledge, Release Planning, Risk Evaluation, Testing,

Abbildung 8:

2.4.4

Service Design Prozesse

Service Transition

Die Phase Service Transition (vgl. [OGC, 2007c]) umfasst das Management
und die Koordination von Prozessen, Systemen und Funktionen, um ein
Release zu paketieren, zu bauen, zu testen, auszuliefern und in die Produktion zu bernehmen und die durch Kunden und Stakeholder spezifizierten Anforderungen umzusetzen.

19

2 IT Service Management
Hierzu werden die Anforderungen aus den Phasen Service Stategy und
Service Design fr einen effektiven Service Betrieb realisiert.
Hier findet das Management komplexer nderungen bei den Services und
Service Management-Prozessen und die Verhinderung unerwnschter
Konsequenzen statt: Risiken sollen kontrollierbar bleiben; gleichzeitig der
Versuch, Raum zu lassen fr Innovation.
Ein wesentlicher Aspekt ist auch die kontrollierte bergabe von Verantwortung fr Services vom Service-Lieferanten zum Kunden.
Die Aufgaben der Phase Service Transition sind Abbildung 9 zu entnehmen
(Service Transition, [OGC, 2007c]).
Continual Service Improvment

Change Management
RFC1

RFC2

RFC3

RFC4

RFC5

RFC6

Service Asset and Configuration Management


BL

BL

BL

BL

BL

BL

BL

Service Transition Planning and Support


Oversee Management of Organisation and Stakeholder Change
Evaluation of a Change or Service
E1
Service
Strategy

Service
Design

Plan and
prepare
Release

Build
and
Test

E3

E2
Service
Plan and
Testing and Prepare for
Pilots
Deployment

Release and Deployment


Management

Transfer,
Deploy,
Retire

Review and
Close Service
Transition

Service
Operation

Early Life Support

Service Validation and Testing


Knowledge Management

other ITIL
Core Book

ITIL process in this


Book that supports
the whole service
Life Cycle
Abbildung 9:

20

Focus of Activity
Related to
Service Transition

Service Transition Prozesse

Ex = Point to Evaluate
RFCx = Request f. Change
BL = Capture Baseline

2.4Die Struktur gem ITIL Version 3

2.4.5

Service Operation

In dieser Phase geht es um das Management des Service Betriebs (Service


Operation). Sie enthlt Anleitungen fr effektive und effiziente Lieferung
und Support der Services, um den gewnschten W
ert fr die u
Knden und
den Service-Lieferanten sicherzustellen. Die strategischen Ziele werden in
dieser letzten Stufe letztendlich durch Service Operation realisiert, was seine
kritische Bedeutung erkennen lsst.
Angestrebt wird ein stabiler Service Betrieb, um nderungen an Design,
Skalierung, Inhalt und Service Level zu erlauben.
Inhalte sind u. a.:

Management der Service-Verfgbarkeit


Anforderungsmanagement und -K
ontrolle
Optimierung der K
apazittsnutzung
Einplanung und Scheduling von Betriebsoperationen
Problemlsung
Untersttzung des Betriebs durch neue Modelle und Architekturen
(z. B. Shared Services, Utility o
Cmputing, eW
b Services und Mobile
o
Cmputing)
fortlaufendes Management der zugrunde liegenden Technologien
tgliche berwachung der Leistungsparameter und -werte (Monitoring).
Auch in dieser Phase des Service Lifecycle steht nach wie vor im Vordergrund, die Services am Bedarf des Business auszurichten. Hierzu mssen
Aktivitten und Prozesse so koordiniert und ausgefhrt werden, dass die
vereinbarten Service Level eingehalten werden.
Das Zusammenwirken der Service Operation Prozesse ist in der Abbildung
10 aus [K
ESS, 2007c] dargestellt.

21

2 IT Service Management
Problem
Management

Event
Management

Filter

Change
Management

Request
Fulfilment

Self Help

Incident
Management

Access
Management

Prozess aus Service Transition

Abbildung 10:

2.4.6

Deployment

Service Operation Prozesse

Continual Service Improvement

ITIL fordert IT Service Provider nicht nur dazu auf, konsistente und wiederholbare Prozessaktivitten anzustreben, um Service Qualitt zu demonstrieren, sondern geht darber hinaus und fordert als Teil der angestrebten Service Qualitt einen Prozess permanenten Strebens nach Verbesserungen.
Primrer Zweck des Continual Service Improvement (CSI) (vgl. [OGC,
2007e]) ist die kontinuierliche Anpassung der IT Services an die sich stndig verndernden Anforderungen aus den Geschftsprozessen. Ziel ist es,
sowohl Prozess-Effektivitt und -Effizienz als auch Kosten-Effektivitt zu
verbessern.
Insofern geht es um die Aufrechterhaltung und Verbesserung des Business Value fr den Kunden im Hinblick auf Design, Einfhrung und
Betrieb der Services.
Fr eine optimale Untersttzung der Geschftsprozesse mssen die IT
Service Management-Prozesse nach klar definierten Zielen und mit relevanten Messsystemen implementiert, verwaltet und untersttzt werden.

22

2.4 Die Struktur gem ITIL Version 3


Hierfr ist es auerordentlich kritisch und wichtig, zu verstehen, was gemessen und warum es gemessen werden muss, und Erfolgsfaktoren sorgfltig zu definieren.
Siehe hierzu die bergreifende Aufgabenstellung des Continual Service
Improvement auf Basis der Darstellung in Continual Service Improvement, [OGC, 2007e] (siehe Abbildung 11).

Business / Kunden

Anforderungen

Service
Strategy

Service
Portfolio

Service
Design

Service
Transition
Service
Katalog

Service
Operation
Continual
Service
Improvement

Abbildung 11:

2.4.7

Operationelle
Services

Improvement
Plne u. Aktionen

Continual Service Improvement

Der prozessorientierte Ansatz von ITIL Version 3

Mit der aktuellen ITIL Version 3 hat sich nicht nur der Scope des Service
Managements erweitert, sondern auch die Anzahl der beschriebenen Service Management-Prozesse. Diese Erweiterung der bestehenden Prozesse
betrifft insbesondere die Phase Service Transition.
Bei den ITIL-Publikationen der Version ITIL Version 3 sind dies in den
Publikationen Service Design, Service Transition, Service Operation und Continual Service Improvement insgesamt 26 IT Service Management-Prozesse vgl. [OGC, 2007b-e]). Hinzu kommen aus der Phase
Service Strategy noch die Aufgaben des Financial Managements, des

23

2 IT Service Management
Service Portfolio Managements und des Demand Managements , die
ebenfalls als Prozesse anzusehen sind.
Diese umfangreiche Erweiterung mag den Leser vielleicht zunchst erschrecken, dabei darf aber nicht auer Acht gelassen werden, dass ein Teil
dieser Prozesse in ITIL Version 2 bereits in anderen weniger beachteten
Publikationen, wie zum Beispiel Applikation Management oder ICT
Infrastructure Management beschrieben waren. Andererseits sind nun
Prozesse dokumentiert, die in vielen Organisation bereits so implementiert
sind, wie zum Beispiel das Event Management zur Entdeckung und
Interpretation von Ereignissen, die ber entsprechend Tools generiert und
behandelt werden.
Mit der ITIL Version 3 werden das notwendige Prozess-Management und
die damit verbundenen Aspekte strker hervorgehoben. Als Prozess wird
definiert (vgl. Service Design, [OGC, 2007b]):
Ein Prozess ist eine strukturierte Folge von Aktivitten, die geplant werden, um
ein bestimmtes Ziel zu erreichen. Ein Prozess bentigt einen oder mehrere definierte Inputs und transformiert diese Inputs zu definierten Outputs. Ein Prozess
beinhaltet die notwendigen Rollen, die Verantwortlichkeiten, die Tools und die
Management Controls, um den Output zu liefern. Ein Prozess definiert dazu die
notwendigen Grundstze (Policies), Standards, Richtlinien, Aktivitten und Arbeitsanweisungen.

Prozesse weisen gem ITIL Version 3 die folgenden Merkmale auf:


Messbar:
Die Prozesse sind in einer relevanten Art zu messen. Prozesse sind
leistungsgetrieben. Manager wollen Kosten, Qualitt und andere
Variable messen, whrend sich die Ausfhrenden mit Dauer und
Produktivitt beschftigen.
Spezifizierte Ergebnisse:
Prozesse existieren, um ein bestimmtes Ergebnis zu liefern: Dieses
Ergebnis muss individuell identifizierbar und zhlbar sein.
Kunden:
Jeder Prozess liefert einem Kunden oder einer Interessengruppe
seine Ergebnisse. Der Prozess muss den Erwartungen der internen
oder externen Kunden entsprechen.
Reagieren auf bestimmte Ereignisse:
Da ein Prozess fortlaufend oder sich wechselseitig beeinflussend
sein kann, sollte er zu einem spezifischen Trigger verfolgbar sein.
Mit der ITIL Version 3 wurde das bestehende Prozessmodell umfassender
beschrieben und dargestellt (im Hauptteil des Buches und nicht im Anhang) vgl. Service Design, [OGC, 2007b] (siehe Abbildung 12).

24

2.4 Die Struktur gem ITIL Version 3


ProzessOwner

ProzessDokumentation
Trigger

ProzessZiele
ProzessPolicy

ProzessFeedback

Prozess-Steuerung

ProzessAktivitten

ProzessInput

ProzessProzeduren

ProzessRollen

ProzessMetriken
Prozess-Arbeits
-anweisungen

ProzessImprovement

Prozess-Durchfhrung

ProzessOutput
inklusive
Prozess-Reports
und -Reviews

Prozess-Bedingungen
ProzessRessourcen

Abbildung 12:

ProzessBefhigungen

ITIL Version 3 Prozessmodell

Die Betrachtungsbereiche Prozess-Steuerung (Process Control), Prozess-Durchfhrung (Process) und Prozess-Bedingungen (Process Enablers) sind zwar gegenber der Version 2 grundstzlich gleich geblieben,
aber die zugehrigen Aspekte wurden detaillierter ausgewiesen.
Die Definition, Steuerung und Verbesserung des Prozesses erfolgt innerhalb des Bereichs der Prozess-Steuerung. ITIL Version 3 definiert diesen
Aufgabenbereich wie folgt (vgl. Service Design, [OGC, 2007b):
Die Prozess-Steuerung ist die Aktivitt, einen Prozess zu planen und zu regulieren, mit dem Ziel, den Prozess effektiv, effizient und in einer einheitlichen Art
und Weise auszufhren.

Sobald die Prozesse definiert sind, werden deren Dokumentation und


Steuerung erforderlich. Hierzu sind entsprechende Metriken zu entwickeln und als Messpunkte in den Prozess zu integrieren. Mithilfe der implementierten Messpunkte werden Kennzahlen generiert, die in ProzessReports einflieen und eine Steuerung des Prozesses sicherstellen.

25

2 IT Service Management
ITIL Version 3 sieht in den Prozessen entsprechende Metriken vor, die als Prozesskennzahlen in Service-Reports enthalten sind und ein Feedback zur ProzessDurchfhrung liefern.
Effektivitt
und Effizienz
eines
Prozesses

Der Output eines Prozesses muss den betrieblichen Anforderungen entsprechen, die aus den Geschftszielen abgeleitet sind. Werden diese Anforderungen hinsichtlich des Outputs erreicht, so ist die Effektivitt des
Prozesses sichergestellt. Werden die damit verbundenen Aktivitten mit
einem minimalen Ressourceneinsatz durchgefhrt, so ist die notwendige
Effizienz gegeben.
Prozessanalysen, Metriken und Prozessergebnisse sind in ManagementReports darzustellen und bieten die Basis fr gegebenenfalls notwendige
Verbesserungsmanahmen.
Die mit der ITIL Version 3 beabsichtigte Business-Integration findet sich ausdrcklich in den Prozesszielen wieder. So wird in ITIL herausgestellt, dass der
erforderliche Output eines Prozesses aus den Geschftszielen abgeleitet wird.

Um diese Ziele zu erreichen, mssen die notwendigen Rollen definiert


und die Verantwortlichkeiten in der Organisation zugewiesen werden.
Hierzu stellt die ITIL Version 3 folgende Anforderungen (vgl. Service
Design, [OGC, 2007b):
Jedem Prozess ist ein Prozess Owner zugeordnet, der fr die Zielereichung und
die Verbesserung verantwortlich ist. Die Prozessziele sind in messbarer Hinsicht
zu definieren und stehen in Bezug mit den Vorteilen fr das Business und der
zugrunde liegenden Unternehmensstrategie.
Prozess
Owner und
Prozess
Manager

Whrend in der ITIL Version 2 keine exakte Definition und Beschreibung


fr den Prozess Owner und Prozess Manager existieren, werden in der
ITIL Version 3 diese Rollen definiert und unterschieden:
Die Prozess Owner ist dafr verantwortlich, dass ein Prozess zweckmig ist. Die
Verantwortung des Prozess Owners schliet die Untersttzung, das Design, das
Change Management und die bestndige Verbesserung des Prozesses und der
damit verbunden Messsysteme ein.
Die Prozess Manager ist fr das operationelle Managements des Prozesses
verantwortlich. Die Verantwortung des Prozess Managers umfasst die Planung
und Koordinierung aller Aktivitten, deren Monitoring und deren
Berichterstattung. In greren Organisationen kann es durchaus mehrere
Prozess Manager fr einen Prozess geben, wie zum Beispiel regionale Change
Manager pro Niederlassung.

26

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


In kleineren Organisationen bernimmt der Prozess Owner auch die Aufgaben des Prozess Managers.

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Mit der verffentlichten Version 3 der ITIL Best Practices befindet sich das
IT Service Management in einer bergangsphase. Unternehmen, die bereits IT Service Management-Prozesse implementiert haben, nutzen hierzu
die Version 2. Eine Aktualisierung dieser implementierten Prozesse wird
kontinuierlich erfolgen, aber nicht kurzfristig umzusetzen sein. Unternehmen, die vor der Implementierung stehen, werden dahingehend wahrscheinlich die Version 3 als Basis fr das IT Service Management heranziehen.
Um beiden Interessengruppen gerecht zu werden, werden in diesem Buch
ausgewhlte Kennzahlen aus beiden Versionen dargestellt.
Die in diesem Kapitel dargestellten Kennzahlen sind beispielhafte Kennzahlen und erheben keinen Anspruch auf Vollstndigkeit. Sie sollen die
Inhalte der Version 2 bzw. Version 3 beispielhaft wiedergeben. Innerhalb
des Kapitels 5 Entwicklung von IT-Kennzahlensystemen geben wir
Kennzahlen an, die sich in der Praxis bewhrt haben und gehen insbesondere darauf ein, wie diese Kennzahlen in ein bergeordnetes Kennzahlensystem zu integrieren sind.
Aufgrund des generischen Ansatzes werden in ITIL mgliche Leistungsindikatoren und Metriken aufgezeigt. Die konkrete Ausgestaltung der
Metrik mit detaillierter Spezifikation und Bedeutung fr das ProzessManagement ist Aufgabe des Prozessdesigns.
In ITIL und COBIT sind viele Kennzahlen dokumentiert. Wir beschrnken
uns in diesem Kapitel aber auf die, die im Rahmen unserer Projekterfahrung eine wichtige Rolle spielen bzw. gespielt haben. Spter werden diese
Praxis-Kennzahlen nher spezifiziert und ihre Bedeutung wird fr den
jeweiligen Prozess dargestellt.

2.5.1

Ausgewhlte Kennzahlen der ITIL Version 2

Incident Management
Ziel des Incident Managements ist die schnellstmgliche Wiederherstellung
des normalen Service-Betriebs bei minimaler Strung des Geschftsbetriebs.
Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:

27

In ITIL und
COBIT sind
viele Kennzahlen dokumentiert

2 IT Service Management
Anzahl der aufgetretenen Strungen
Durchschnittliche Zeitdauer bis zur Behebung oder Umgehung der
Strung in Relation zur Prioritt
Anteil der Strungen, die innerhalb der vereinbarten Reaktionszeit
bearbeitet wurden
Hhe der durchschnittlichen Kosten pro Strung
Lsungsrate von Strungen im Service Desk
Anzahl der bearbeiteten Strungen pro Arbeitsplatz im Service
Desk
Anzahl und Anteil der Strungen die remote ( ohne Vor-Ort-Support) behoben werden konnten
Bei der Auswertung entsprechender Leistungsindikatoren ist zu beachten,
dass ITIL Incident als Oberbegriff fr Strungen und Service-Requests
nutzt. Im Incident Management-Prozess werden daher auch Service-Requests erfasst und bearbeitet. Fr die Aussagekraft der obigen Kennzahlen
mssen daher im Rahmen der Kennzahlenermittlung Strungen und Service-Requests differenziert betrachtet werden.

Problem Management
Das Problem Management hat die Stabilisierung der IT Services durch die
Vermeidung von Incidents zum Ziel.
Hierzu werden vom Prozess reaktive und proaktive Aktivitten durchgefhrt. Zu den reaktiven Aufgaben zhlen die Aktivitten von der Identifizierung von Problemen bis zu einer mglichen Umsetzung ber das Change Management. Die proaktiven Aktivitten sollen dagegen sicherstellen,
Strungen zu verhindern bevor sie auftreten.
Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:
Anzahl der vom Problem Management erffneten RFCs (Request for
Change) und Auswirkung dieser RFCs
Durchschnittlicher Zeitaufwand fr die Feststellung von Bekannten
Fehlern (Known Error); Zeitdauer vom Auftreten eines entsprechenden Problems bis zur Identifizierung des Bekannten Fehlers
Anzahl und Auswirkung von Strungen bevor das zugrunde liegende Problem gelst ist
Hufigkeit der Probleme unterteilt nach Status, IT Service, Auswirkung, Kategorie und Kunde
Durchschnittliche und maximale Zeitdauer bis zum Abschluss des
Problems

28

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse

Configuration Management
Das Configuration Management dient der Definition, Kontrolle, Pflege und
Verifizierung der Service- und Infrastrukturkomponenten sowie der Verwaltung korrekter Konfigurationsinformationen.
Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:
Anteil der Konfigurationen, die nicht dem autorisierten Zustand
entsprechen
Anteil fehlerhafter Changes aufgrund falscher Daten in der CMDB
(Configuration Management Database)
Bearbeitungsdauer bis zur Aktualisierung der CMDB
Anteil und Anzahl nicht genutzter Lizenzen
Anteil nicht autorisierter IT-Komponenten
Darber hinaus werden unter anderem die folgenden Berichte an das Management empfohlen:
Anzahl der erfassten CIs (Configuration Item) aufgeschlsselt nach
Kategorien, Typ und Status
Dokumentationsqualitt der CIs
Angaben zum Wachstum des CI-Bestandes
Wert der CIs

Change Management
Das Ziel des Change Managements ist es, sicherzustellen, dass durch standardisierte Methoden und Verfahren durchzufhrende nderungen effizient und schnellstmglich umgesetzt werden. Dabei ist darauf zu achten,
dass die nderungen mglichst geringe Auswirkungen auf die Qualitt
der IT Services haben.
Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:
Anzahl durchgefhrter nderungen, als Summe und gegliedert in
IT Service, CI-Typ usw.
Anteil zurckgewiesener RFCs
Anteil erfolgreicher nderungen
Anteil termingerechter nderungen
Anteil Backouts (Fallback; zurckgesetzte nderungen)
Anteil nderungen innerhalb des geplanten Budgets

Release Management
Das Release Management hat die Bereitstellung, Verteilung und Verfolgung
eines oder mehrerer Changes in einem Release in der Produktionsumge-

29

2 IT Service Management
bung zum Ziel und soll durch die Anwendung formeller Verfahren und
Prfungen die Produktionsumgebung schtzen.
Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:

Anteil eingehaltener Release-Termine


Anteil eingehaltener Release-Budgets
Anteil zurckgesetzter Releases (Backout)
Anzahl von Problemen aufgrund neuer Releases
Gre und Kapazitt der DSL (Definierte Softwarebibliothek)

Service Level Management


Das Ziel des Service Level Managements ist es, Servicequalitt zu sichern
und kontinuierlich zu verbessern. Dies erfolgt in einem fortlaufenden Zyklus von Definition, Verhandlung, Vereinbarung, Messung, Berichterstattung und Reviews der IT Services.
Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:

Anzahl bzw. Anteil von Services mit SLAs


Anteil von SLAs mit OLAs und UCs
Anteil eingehaltener SLAs
Kundenzufriedenheit
Einhaltung von Review-Terminen

Financial Management fr IT Services


Ziel des Financial Managements fr IT Services ist die kostenwirksame
Verwaltung der IT-Komponenten, die fr die Erbringung der IT Services
bentigt werden.
Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:
Die Budgetplne werden termingerecht erstellt
Die monatlichen, vierteljhrlichen und jhrlichen finanziellen Geschftsziele 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 ITKapazitten zu vertretbaren Kosten, um den aktuellen und zuknftigen
Geschftsanforderungen des Kunden gerecht zu werden.

30

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:
Anteil von Strungen durch nicht ausreichende Kapazitten
Anteil von SLA-Verletzungen aufgrund mangelnder Performance
Anzahl der Kapazittsanforderungen, die nicht im Kapazittsplan
enthalten sind
Reduzierung von berkapazitten

IT Service Continuity Management


Das Ziel des IT Service Continuity Managements ist die Untersttzung 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 Mngel am IT Service Continuity-Plan
Zeitspanne zwischen nderungen mit Auswirkungen auf den IT
Service Continuity-Plan und der Aktualisierung des Plans
Anzahl durchgefhrter bungen / Tests des IT Service ContinuityPlans

Availability Management
Zielsetzung des Availability Managements ist die Gewhrleistung der Service-Verfgbarkeit, um die Verpflichtungen gegenber dem Business erfllen zu knnen.
Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:
Anzahl von Strung aufgrund der Nicht-Verfgbarkeit
Abweichung zwischen geplanter und tatschlicher Verfgbarkeit
Dauer der Nichtverfgbarkeit

Security Management
Ziel des Security Managements ist es, einen definierten Grad an Sicherheit
fr die Informationen und IT Services zu gewhrleisten. Hierzu zhlt einerseits die Erfllung der Sicheranforderungen aus den SLAs und anderer
externer Anforderungen. Andererseits ist ein definierter Grundschutz zu
schaffen.
Die Publikation ITIL Best Practice fr Security-Management spezifiziert
fr diesen Prozess keine Leistungsindikatoren (vgl. [OGC, 2006a]).
Die ITIL Best Practices zum Security-Management verfolgen das Konzept,
dass die Sicherheitsanforderungen, bestehend aus Verfgbarkeit, Vertrau-

31

2 IT Service Management
lichkeit und Integritt, als Service Level innerhalb der SLAs mit dem Kunden vereinbart werden. Diese Sicherheitsanforderungen gehen ein in die
OLAs (Operational Level Agreements) und UCs (Underpinning Contracts).
Die Leistungsindikatoren des Security-Managements entsprechen demzufolge den brigen Service Level eines SLA / OLA / UC und sind eine Ausprgung der Service-Berichte.
Aus der Prozessaktivitt Berichtswesen knnen folgende Leistungsindikatoren abgeleitet werden:
Anteil von SLAs, OLAs und UCs mit Sicherheitsverletzungen
Anzahl von Security-Incidents
Reaktionszeit auf Security-Incidents

2.5.2

Ausgewhlte Kennzahlen der ITIL Version 3

Wenn man sich mit den Kennzahlen der ITIL Version 3 beschftigt, spielen
die 5 Phasen des Service Lifecycle mit ihren entsprechenden Prozessen die
grundlegende Rolle. Die aus der ITIL Version 2 bekannten Prozesse haben
wir in Abbildung 13 hervorgehoben. Dabei wird deutlich, dass einige Prozesse der ITIL Version 2 teilweise hinsichtlich der Ziele und Aufgabenstellung verndert wurden. So werden zum Beispiel die Service Requests
nicht mehr im Incident Management aufgenommen oder Aufgaben des
Service Level Managements aus der ITIL Version 2 finden sich in anderen,
neuen Prozessen wieder.
Diese durchgefhrten Anpassungen gegenber der ITIL Version 2 haben
auch Auswirkungen auf die damit verbundenen Kennzahlen und Metriken, deren Definition und deren Vergleichbarkeit.

32

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse

Service
Transition

Continual
Service
Improvement

Service Asset
and Configuration M.

Release and
Deployment M.

Service Validation
and Testing

Change Management

Evaluation

Transition Planning
and Support
Service
Level
Management

Supplier M.
Information
Security M.

Knowledge
Mgmt.

Service
Portfolio
M.

Demand
M.

Service Level M.

Abbildung 13:

Request
Fulfilment

Financial
Management

Capacity M.

Service
Catalogue M.

Service
Reporting

Incident
Management

Strategy

Availability M.

The
Business
Questions
for CSI

Event
Management

Service

Service
Continuity M.

Service
Design

The 7 Step
Improvement
Process

Service
Operation

Problem M.
Access Management
Service Desk

Service
Measurement

Return on
Investment
(ROI) for CSI

Die 5 Phasen des Service Lifecycles und ihre Prozesse

Im Folgenden werden die 5 Phasen des Service Lifecycle mit ihren Prozessen vorgestellt und die seitens der ITIL Best Practices dokumentierten Key
Performance Indikatoren beispielhaft beschrieben.

33

2 IT Service Management

2.5.2.1 Service Strategy

Service
Portfolio
M.

Demand
M.

Service

Strategy
Financial
Management

Abbildung 14:

Service Strategy

Die Publikation Service Strategy ([OGC, 2007a]) weicht von den brigen
vier Publikationen dahingehend ab, dass sie kein Kapitel Prozesse enthlt. Im Rahmen des Kapitels Service Economics werden Aspekte beschrieben, die einen Charakter von Prozessen haben. Als Prozesse sind
dabei das Financial Management, das Service Portfolio Management und das Demand Management anzusehen.

Financial Management
Financial Management quantifiziert IT Services, ihre zugrunde liegenden
Assets und sogar operationelle Vorhersagen mit Metriken aus der FinanzTerminologie. Die Frage, die hier im Raum steht, ist die nach dem Wert fr
das Business und die IT. Es gibt einen Wandel in der Wahrnehmung der
IT und ihres Wertes fr das Business. Financial Management hilft bei der
Identifizierung, Dokumentation und Akzeptanz des Wertes der erhaltenen
Serviceleistungen und ermglicht die Modellierung und das Management
von Service-Anforderungen.

Service Portfolio Management


Ein Service Portfolio beschreibt die Services eines Providers im Hinblick auf
deren Wert fr die Geschftsprozesse (Business Value). Service Portfolio
Management formuliert die geschftlichen Anforderungen und die Antwort des IT Service Providers auf diese Bedrfnisse.

34

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse

Demand Management
Demand Management (Anforderungsmanagement) behandelt kritische Aspekte des Service Managements: Unsicherheiten bei der Anforderungsaufnahme bergen Risiken fr IT Service Provider, wie berkapazitten oder
ungengende Kapazitten mit Auswirkung auf die Qualitt der Services.
Service Level Agreements, Vorhersagen, Planung und feste Koordination
mit dem Kunden knnen die Unsicherheiten bei den Anforderungen reduzieren, diese aber nicht vollstndig eliminieren.

2.5.2.2 Service Design

Supplier M.
Information
Security M.
Service
Continuity M.
Availability M.

Service
Design

Capacity M.
Service Level M.
Service
Catalogue M.

Abbildung 15:

Service Design

Service Catalogue Management


Ziel des Prozesses Service Catalogue Management (SCM) ist die Erstellung
und Pflege eines Service Katalogs mit genauen Informationen ber alle
aktuellen und geplanten operationalen Services. Hierzu werden die vom
Service Portfolio Management definierten Services entsprechend spezifiziert
und sind als Teilmenge bzw. konkrete Ausprgung des Service Portfolios
anzusehen.

35

2 IT Service Management
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
die Anzahl der aufgenommenen und verwalteten Services innerhalb
des Service Katalogs als Prozentsatz der Services, die ausgeliefert
und bergeben wurden und sich in der Live-Umgebung befinden
die Anzahl von Abweichungen zwischen den Informationen im Service Katalog und der realen Welt.

Service Level Management


Der Service Level Management Prozess definiert und vereinbart fr alle aktuellen und zuknftigen IT Services die damit verbundenen Service Level
und die erreichbaren Zielwerte (Service Level Targets). Auerdem stellt er
sicher, dass Services auf diesem Level ausgeliefert werden. Proaktive Messungen und Reports helfen bei den notwendigen Verbesserungen zur Zufriedenheit der Kunden.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
prozentuale Verringerung nicht erfllter SLA-Ziele
prozentuale Verringerung bedrohter SLA-Ziele
prozentualer Anstieg der Kunden-Wahrnehmung und -Zufriedenheit von SLA-Leistungen via Service Reviews und Kunden Zufriedenheits-Befragungen
prozentuale Verringerung von SLA-Verletzungen, die durch Unterauftragnehmer verletzt wurden.

Capacity Management
Das Capacity Management (Kapazittsmanagement) stellt sicher, dass ITKapazitten zu gerechtfertigten Kosten jederzeit in allen IT-Bereichen existieren und rechtzeitig die abgestimmten aktuellen und zuknftigen Anforderungen des Business abdecken.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
akkurate Business Vorhersagen (Vorhersagen ber Arbeitsauslastungen in der Produktion; prozentuale Genauigkeit der Vorhersagen von Business Trends, etc.)
Wissen ber aktuelle und zuknftige Technologien (Fhigkeit, Performance und Durchsatz aller Services und Komponenten zu monitoren; rechtzeitige Ausrichtung und Implementierung neuer Technologien, abgestimmt auf die Business-Anforderungen, etc.)

36

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Fhigkeit, Kosten-Effektivitt zu demonstrieren (eine Verringerung
von Kufen in letzter Minute fr die Behebung dringender Performance-Probleme; Verringerung von berkapazitten der IT, etc.)
Fhigkeit zur Planung und Implementierung der angemessenen ITKapazitten zur Befriedigung der Business-Anforderungen (prozentuale Verringerung der Anzahl von Incidents, die durch schlechte
Performance ausgelst werden; prozentuale Verringerung verlorener Geschftschancen aufgrund unzulnglicher Kapazitten, etc.).

Availability Management
Der Availability Management-Prozess (Verfgbarkeitsmanagement) stellt
sicher, dass die Verfgbarkeit aller ausgelieferten Services die aktuellen
und zuknftigen Anforderungen kosteneffektiv befriedigt oder bertrifft.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
prozentuale Verringerung in der Nichtverfgbarkeit von Services
und Komponenten
prozentualer Anstieg in der Verlsslichkeit von Services und Komponenten
effektives Review und Verfolgung aller Verletzungen bei SLAs,
OLAs und UCs
prozentuale Verbesserung in der allumfassenden end-to-end Verfgbarkeit von Services.

IT Service Continuity Management


Das IT Service Continuity Management (ITSCM) untersttzt den allumfassenden Business Continuity Management Prozess. Es stellt sicher, dass die
IT-technischen Betriebsmittel und Services (einschlielich Rechnersysteme,
Netzwerke, Anwendungen, Datenbestnde, Telekommunikationsanlagen,
technischer Support und Service Desk) nach einem Ausfall oder einer Strung innerhalb der erforderlichen und vereinbarten Zeitgrenzen wieder in
Betrieb gehen und verfgbar sind.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
regelmige Audits der ITSCM Plne, um das Erreichen der vereinbarten Wiederherstellungsanforderungen des Business sicherzustellen
alle Service-Wiederherstellungsziele sind in SLAs vereinbart und
dokumentiert und sind erreichbar innerhalb der ITSCM-Plne
regelmige und umfassende Tests der ITSCM-Plne

37

2 IT Service Management
regelmige, mindestens jhrliche Reviews der Business- und IT
Continuity-Plne mit den Geschftsbereichen.

Information Security Management


IT Sicherheit muss auf das Sicherheitsbedrfnis des Business abgestimmt
werden. Information Security Management verfolgt dieses Ziel ber ein effektives Management der Informations-Sicherheit in allen Services und
Service Management-Aktivitten.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
prozentuale Verringerung der im Service Desk berichteten Sicherheits-Verletzungen
prozentuale Verringerung bei den Auswirkungen von SicherheitsVerletzungen und Incidents
prozentualer Anstieg der SLA-Konformitt zu den Sicherheitsbestimmungen
Abnahme der Anzahl von Abweichungen des Information Security
Management-Prozesses von Business Security-Policy und -Prozess.

Supplier Management
Supplier Management ist das Management von Lieferanten und ihren Services, um dem Business die vereinbarte Service-Qualitt zukommen zu lassen und sicherzustellen, dass Ausgaben bei den Lieferanten wieder eingenommen werden knnen.

Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
Anstieg der Anzahl von Lieferanten, die vertraglich vereinbarte Ziele einhalten
Anstieg der Anzahl der mit Lieferanten durchgefhrten Serviceund Vertrags-Reviews
Reduzierung der Anzahl von durch Lieferanten verursachten Service-Verletzungen
Anstieg der Anzahl von Lieferanten mit ernanntem Lieferanten-Manager.

38

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse

2.5.2.3 Service Transition


Service
Transition
Release and
Service Asset
and Configuration M. Deployment M.
Service Validation
Change Management
and Testing
Evaluation
Transition Planning
and Support
Knowledge
Mgmt.

Abbildung 16:

Service Transition

Transition Planning and Support


Transition Planning and Support plant und koordiniert Ressourcen fr eine
effektive Realisierung der in Service Strategy definierten und in Service
Design entwickelten und umgesetzten Anforderungen. Potentielle Risiken
und Strungen der Transitions-Aktivitten werden identifiziert und kontrolliert.

Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
die Anzahl implementierter Releases, die im Hinblick auf Kosten,
Qualitt, Scope und Release-Zeitplan die mit dem Kunden vereinbarten Anforderungen erfllen
Reduzierung von Abweichungen der aktuellen gegen die vorhergesagten Werte Inhalt (Scope), Qualitt, Kosten und Zeit
gestiegene Kunden- und Anwender-Zufriedenheit mit Plnen und
der Kommunikation, die das Business in die Lage versetzen, seine
Aktivitten mit den Service Transition Plnen in Einklang zu bringen
Reduzierung der Anzahl von Problemen, Risiken und Verzgerungen, die durch unzulngliche Planung verursacht werden.

Change Management
Die Anforderungen im Business des Kunden verndern sich fortlaufend.
Change Management reagiert auf diese nderungsanforderungen und maximiert den Wert fr den Kunden, whrend gleichzeitig Incidents, Strungen und berarbeitungen reduziert werden. Die Reaktionen auf die n-

39

2 IT Service Management
derungsanforderungen des Business und der IT sorgen fr eine Ausrichtung der Services am Bedarf des Business.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
Anzahl der nderungen (Changes) an den Services, die die mit den
Kunden vereinbarten Anforderungen z. B. hinsichtlich Qualitt/Kosten/Zeit erfllten (ausgedrckt als Prozentsatz an allen nderungen)
der Nutzen der nderungen, ausgedrckt als Wert der durchgefhrten Verbesserungen + verhinderte oder beendete negative
Auswirkungen, verglichen mit den Kosten des nderungsprozesses
Reduzierung der Anzahl von Strungen am Service, Mngel und
berarbeitungen, die durch nicht exakte Spezifikation oder schlechte/unvollstndige Bewertung der Auswirkungen verursacht wurden.
Reduzierung der Anzahl nicht autorisierter nderungen
Reduzierung des Rckstands von nderungsantrgen.

Service Asset and Configuration Management


Service Asset und Configuration Management liefert ein logisches Modell der
IT Infrastruktur und stellt falls erforderlich den Zusammenhang zwischen den IT Services mit notwendigen IT-Komponenten her.

Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
prozentuale Verbesserung bei der Zeitplanung fr Wartungsarbeiten eines Assets (nicht zu viel, nicht lange)
Grad der Abstimmung zwischen untersttzter Wartung und Business Support
als Ursache von Service-Ausfllen identifizierte Assets
verbesserte Geschwindigkeit fr das Incident Management zur Identifizierung fehlerhafter Cis und die Wiederherstellung des Service
Auswirkung von Incidents und Fehlern mit Bezug auf bestimmte
CI-Typen, z. B. von bestimmten Lieferanten oder Entwicklungsgruppen.

Release and Deployment Management


Das Ziel von Release und Deployment Management ist die Auslieferung und
berfhrung von Releases in die Produktion. Hier werden die Services

40

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


den Kunden zur Verfgung gestellt und sichergestellt, dass die Services
sinnvoll und produktiv genutzt werden knnen.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
Abweichung von der vom Kunden geforderten Service Performance
(Service Leistung)
Anzahl von Incidents bzgl. des Service
Reduzierter Einsatz von Ressourcen und Kosten fr die Diagnose
und die Behebung von Incidents und Problemen in Entwicklung
und Produktion
Verstrkte Umstellung des Service Transition Common Framework auf
Standards, wiederverwendbare Prozesse und Support.

Service Validation and Testing


Service Validation and Testing berprft und sichert den Wert der Services
fr die Kunden und ihr Business.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
Vertrauen, dass ein Release die erwarteten Ergebnisse und den Wert
fr die Kunden innerhalb der projektierten Kosten, Kapazitten und
Beschrnkungen liefert
Die Besttigung, dass ein Service seinen Zweck und die geforderte
Performance ohne unerwnschte Beschrnkungen erfllt
Sicherstellen, dass ein Service bestimmte Spezifikationen innerhalb
der spezifizierten Rahmen- und Nutzungsbedingungen erfllt
Besttigung, dass Anforderungen der Kunden und Stakeholder fr
neue oder vernderte Services korrekt definiert sind und die Beseitigung jeglicher Fehler oder Abweichungen mglichst frh im Service
Lebenszyklus erfolgt, da dies betrchtlich billiger ist als die Fehlerbeseitigung in der Produktion.

Evaluation
Evaluation bewertet Performance-Vernderungen bei einer Service-nderung. So knnen Abweichungen zu gewnschten und vorhergesagten
Performance-Werten entsprechend behandelt werden.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:

Abweichung der Service Performance


Anzahl von Incidents bzgl. des Service
Anzahl fehlerhafter Designs, die berfhrt wurden
Zykluszeit fr die Durchfhrung der Evaluation.

41

2 IT Service Management

Knowledge Management
Knowledge Management liefert die Grundlage fr fundierte Entscheidungen.
Die im Verlauf des Lebenszyklus der Services gewonnenen Informationen
und Daten werden bereitgestellt.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
Incidents und verlorene Zeiten, kategorisiert als Mangel an Anwender-Wissen
durchschnittliche Diagnose- und Reparatur-Zeit fr Fehler, die inhouse behoben werden
Incidents bzgl. neuer oder vernderter Services, die durch Referenz
auf die Wissensbasis behoben wurden.

2.5.2.4 Service Operation

Event
Management
Incident
Management
Request
Fulfilment
Problem M.

Service
Operation

Access Management
Service Desk

Abbildung 17:

Service Operation

Event Management
Event Management befhigt zur Entdeckung und Interpretation von Ereignissen (Events) und ermglicht deren Steuerung. Deshalb ist Event Management die Basis fr Operational Monitoring and Control.

42

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
Anzahl von Ereignissen je Kategorie
Anzahl von Ereignissen nach Signifikanz
Anzahl und Prozentsatz an Ereignissen, die menschliche Intervention erforderten und ob dies durchgefhrt wurde
Anzahl und Prozentsatz an Ereignissen, die in Incidents oder nderungen resultierten.

Incident Management
Das primre Ziel des Incident Management-Prozesses ist die schnelle Wiederherstellung des Service Betriebs mit der Qualitt, wie sie in den Service
Level Agreements (SLA) vereinbart wurde. Hierbei soll die Auswirkung
des Incidents auf die Geschftsprozesse minimiert werden.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
Gesamtzahl der Incidents (als Kontroll-Wert)
Aufschlsselung der Incidents in jeder Stufe (z. B. aufgezeichnet, in
Bearbeitung, geschlossen)
Rckstand aktueller Incidents
Anzahl und Prozentsatz schwerwiegender (major) Incidents
mittlere Ablaufzeit bis zur Lsung/Wiederherstellung oder Umgehungslsung, aufgeschlsselt nach Auswirkung (impact code).

Request Fulfilment
Request Fulfilment ist der fr die Behandlung der Service Requests verantwortliche Prozess. Er stellt definierte Informationskanle fr die Anwender bereit, mit denen Anforderungen gestellt und Services entgegengenommen werden knnen. Darber hinaus werden Informationen ber die
Verfgbarkeit von Services und Prozeduren fr deren Nutzung bereitgestellt. Standardleistungen, wie z. B. Lizenzen und Software-Medien, werden beschafft und ausgeliefert.

Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
Gesamtzahl an Service Requests
Aufschlsselung der Service Requests auf die einzelnen Stufen (z. B.
aufgezeichnet, in Bearbeitung, geschlossen)
Rckstand bei der Bearbeitung von Service Requests
mittlere Ablaufzeit bei der Behandlung der verschiedenen Typen
von Service Requests.

43

2 IT Service Management

Problem Management
Der Prozess Problem Management ist verantwortlich fr den Lebenszyklus
aller Probleme1. Das Problem Management hat hierzu die Ursachen zu identifizieren und sicherzustellen, dass die erarbeiteten Lsungen ber die
Control Prozesse hauptschlich Change Management implementiert
werden.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
Gesamtzahl der Probleme (als Kontroll-Wert)
Prozentsatz von Problemen, die innerhalb der SLA-Ziele gelst bzw.
nicht gelst wurden
Anzahl und Prozentsatz von Problemen, die ihre maximalen Lsungszeiten berschritten haben
der Rckstand 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 fr die Ausfhrung der im Securityund Availability Management definierten Richtlinien und Aktionen zustndig.

Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
Gesamtzahl der Zugriffsanforderungen (Service Request, RFC, etc.)
Instanzen gewhrter Zugriffe, nach Service, Anwender, Abteilung,
etc.
Instanzen gewhrter Zugriffe nach Abteilung oder individuellen
Zugriffsrechten
Anzahl an Incidents, die ein Zurcksetzen der Zugriffsrechte erfordern.

Service Desk
Beim Service Desk handelt es sich um keinen Prozess, sondern um eine
organisatorische Anforderung an die Organisation.

44

Ein Problem bezeichnet in der ITIL-Terminologie die Ursache fr einen oder


mehrere Incident. Die Ursache ist normalerweise bei der Erffnung eines Problems nicht bekannt. Der Prozess des Problem Managements ist fr die weitere
Untersuchung der Ursache verantwortlich.

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Der Service Desk als Anforderung an die Organisation ist im Kapitel Organizing Service Operation beschrieben.
Primres Ziel des Service Desk ist die Wiederherstellung des normalen
Service so schnell wie mglich (siehe auch Incident Management). Dies
kann neben der Behebung eines technischen Fehlers ebenso die Erfllung
eines Service Requests bzw. grundstzlich alles sein, was erforderlich ist,
damit der Anwender seine Arbeit wieder so erledigen kann, wie dies sein
Geschftsprozess erfordert. Zur Verantwortung des Service Desk gehrt
auch die Dokumentation eingehender Incidents und Service Requests,
deren Kategorisierung und Priorisierung, die Durchfhrung einer ersten
Diagnose und Eskalationsschritte, falls vereinbarte Zeitgrenzen berschritten werden.
Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel:
Prozentsatz von Calls (Anrufen), deren Requests bzw. Strungen sofort whrend des ersten Kontaktes am Service Desk gelst werden
konnten
Prozentsatz gelster Calls ohne die Untersttzung anderer Gruppen
Prozentsatz gelster Calls mit Untersttzung anderer Gruppen.

45

2 IT Service Management

2.5.2.5 Continual Service Improvement

Continual
Service
Improvement

The 7 Step
Improvement
Process

Service
Reporting

Service
Level
Management

The
Business
Questions
for CSI

Abbildung 18:

Service
Measurement

Return on
Investment
(ROI) for CSI

Continual Service Improvement

The 7 Step Improvement Process


Hier werden Fragen gestellt nach den Business Treibern hinter der ITILImplementierung, der finanziellen Bewertung von IT-Investitionen, dem
Reifegrad, der Effektivitt und Effizienz aktueller Prozesse, den Gaps und
Problemen bei der Bereitstellung von Services, der Bewertung von Ressourcen (Time and Budget) zum Schlieen der Lcken und schlielich
nach den Ergebnissen der Aktivitten beim Streben nach Service Improvement ROI.
Der 7 Step Improvement Process umfasst die folgenden Forderungen:

46

1.

Definieren, was gemessen werden soll

2.

Definieren, was gemessen werden kann

3.

Daten sammeln

4.

Daten bearbeiten

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


5.

Daten analysieren

6.

Informationen prsentieren und nutzen

7.

Korrekturen durchfhren

Abbildung 19 aus Continual Service Improvement (vgl. [OGC, 2007e])


veranschaulicht diesen Prozess:
Identifiziere:
Vision
Strategie
Taktische Ziele
Operative Ziele

1. Definiere,
was Du
messen solltest
2. Definiere,
was Du
messen kannst

7. Implementiere
Korrekturmanahmen

Ziele
6. Prsentiere
und nutze die
Informationen

3. Sammle
Daten

5. Analysiere
Daten
Abbildung 19:

4. Bearbeite
Daten

7 Step Improvement Prozess

Key Performance Indikatoren sind zu diesem Prozess nicht ausgefhrt,


sondern allgemeine Anforderungen an die Metriken. Dabei wird unterschieden zwischen technischen Metriken und Metriken fr Prozesse und
Services.
Technische Metriken sind hufig mit den eingesetzten Komponenten und
Applikationen verbunden und betrachten technische Aspekte wie Performance, Verfgbarkeit etc.
Prozess Metriken erfassen CSFs, KPIs und Messgren fr Ttigkeiten der
Service Management-Prozesse. Diese Metriken ermglichen eine Beurteilung der Prozesse. Die Metriken sollten die vier Aspekte Qualitt, Performance, Nutzen und Compliance abdecken.
Service Metriken sind das Ergebnis einer end-to-end Betrachtung der
Services.

47

2 IT Service Management
Innerhalb The 7 Step Improvement sind allgemeine Fragestellungen hinsichtlich der Definition von KPIs dokumentiert:

Was sagt uns der KPI ber die Zielerreichung aus?


Wie leicht ist es, den KPI zu interpretieren?
Wann brauchen wir die Information? Wie oft? Wie rasch sollte die
Information verfgbar sein?
In welchem Ma ist der KPI stabil und genau? Ist er von externen
unkontrollierbaren Einflssen abhngig?
Wie leicht ist es, den KPI selbst zu ndern? Wie leicht ist es, das
Masystem an sich verndernde Umstnde anzupassen oder nderungen in Bezug zu den Zielen durchzufhren?
Wer ist der Owner des KPIs? Wer ist verantwortlich fr das Sammeln und die Analyse der Daten? Wer ist fr Verbesserungen basierend auf den gewonnenen Informationen verantwortlich?

Service Reporting
Das Service Reporting liefert die notwendigen korrekten Berichte, die den
Kundenerwartungen entsprechen. Aus der Vielzahl der vorliegenden Daten sind hierzu die Daten so aufzubereiten, dass das Business die notwendigen Informationen erhlt. Dazu gehrt auch die Berichterstattung der
letzten Periode.
Key Performance Indikatoren sind zu diesem Prozess nicht ausgefhrt.

Service Measurement
Das Service Measurement stellt sicher, dass die Services bezglich der Aspekte der Verfgbarkeit (Availability), Zuverlssigkeit (Reliability) und
Performance gemessen werden knnen. Dabei ist die Kundensicht auf den
Service ( end-to-end) von groer Bedeutung, da hiervon die Geschftsprozesse des Business abhngig sind.
Als Key Performance Indikatoren fr das Service Management werden aus
Kundensicht demzufolge herausgestellt:
Verbesserte Verfgbarkeit (durch Service / Systems / Applikationen)
Verringerung der Service Level Verletzungen (durch Service / Systems / Applikationen)
Verringerung mean time to repair (gemessen anhand von Prioritten)
Verringerung Major Incidents

48

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse

Return on Investment (ROI) for CSI


Um die Aufgabe des Return on Investments (ROI) fr das Continual Service
Improvement (CSI) erfllen zu knnen, sind viele Faktoren in Betracht zu
ziehen. Auf der einen Seite sind dies die Kosten fr die Durchfhrung
dieser Phase des Service Lifecyle, bestehend zum Beispiel aus den Personalkosten, Tools, Beratungskosten, etc. Auf der anderen Seite ist zu bewerten, welche geschftlichen Vorteile durch diese Ttigkeiten erzielt werden.
Letztlich geht es um eine geschftliche ROI Betrachtung. Daher sind die
Vorteile auch nicht nur aufseiten der IT zu bewerten, sondern primr aus
Sicht des Business. Eine mgliche Betrachtung wre zum Beispiel die Kosten von Ausfallzeiten auf der Seite des Business.
Key Performance Indikatoren sind zu diesem Prozess nicht ausgefhrt

The Business Questions for CSI


Die Business Integration von ITIL Version 3 wird auch dadurch zum Ausdruck gebracht, dass das Business in das Continual Service Improvement
einzubinden ist. Mgliche Verbesserungen sind dahingehend zu bewerten,
welche Manahmen den grten Vorteil fr das Business mit sich bringen.
Hierzu ist zu bewerten Wo stehen wir heute? und gemeinsam zu definieren Was wollen wir?
Key Performance Indikatoren sind zu diesem Prozess nicht ausgefhrt.

Service Level Management


Service Level Management ist ein fr das CSI kritischer und wichtiger Prozess. Das Service Level Management entscheidet darber, was gemessen
wird, welche Anforderungen an die berwachungen gestellt werden, wie
das Erreichen von Service Level berichtet wird und wo mit dem Business
bei neuen Service Requests oder nderungen an existierenden Services
zusammengearbeitet wird. So werden die Aktivitten des CSI untersttzt
und Verbesserungsprojekte priorisiert.

Das Service Level Management stellt einen wichtigen Trigger fr den Service Plan (SIP) dar.
Key Performance Indikatoren sind zu diesem Prozess nicht ausgefhrt.

49

2 IT Service Management

2.6 ISO 20000


Nach der umfassenden Akzeptanz und Verbreitung der ITIL Best Practices
innerhalb von IT-Organisationen geht das Thema Professionelle Serviceorientierung in der IT in die nchste Runde. Mit der seit dem
15. Dezember 2005 gltigen ISO 20000 Information Technology - Service
Management haben IT-Organisationen nun erstmalig die Mglichkeit,
ihre IT Service Management-Prozesse durch eine unabhngige Auditierungs-Organisation auf der Basis einer internationalen Qualittsnorm zertifizieren zu lassen.
Mit dieser Norm wird dem steigenden Bedarf des Nachweises eines wirksamen IT Service Managements Rechnung getragen. In diesem Zusammenhang muss nochmals die Zielsetzung von ITIL herausgestellt werden.
Innerhalb der IT Infrastructure Library sind bewhrte Vorgehensweisen
(Best Practices) dokumentiert. Sie sind als Leitfaden (Guidelines) fr die
Implementierung von IT Service Management-Prozessen gedacht. Dabei
bleibt es den Organisationen berlassen, wie und in welchem Mae dieser
Leitfaden zur Gestaltung der unternehmensspezifischen IT Service Management-Prozesse genutzt wird. Aufgrund der steigenden internationalen
Anerkennung und Nutzung wird ITIL auch als De-facto-Standard fr das
IT Service Management bezeichnet und zum Teil irrtmlich als Standard
im Sinne einer Norm verstanden.
ITIL ist kein Standard im Sinne einer Norm.
Eine ITIL
Zertifizierung
fr Organisationen ist
nicht mglich.

Demzufolge knnen die implementierten IT Service Management-Prozesse


einer IT-Organisation nicht nach ITIL zertifiziert werden. Nur Personen
knnen 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
dafr, dass die IT Service Management-Prozesse tatschlich implementiert
sind und den Mindestanforderungen gengen, zumal in den ITIL Best
Practices keine Mindestanforderungen spezifiziert sind.
Daher wurde mit der ISO 20000 IT Service Management eine gemeinsame internationale Referenz (Norm) fr alle IT-Organisationen bereitgestellt, die IT Services fr interne oder externe Kunden erbringen.

50

2.6 ISO 20000


Die ISO 20000 beinhaltet smtliche Aspekte, die fr IT-Organisationen
gltig sind und die es umzusetzen gilt. Die ISO 20000 kann so als international definierte Mindestanforderung an das IT Service Management angesehen werden.
Mit der ISO 20000 existiert seit dem 15. Dezember 2005 eine international anerkennte Norm fr das IT Service Management. Auf der Basis dieser Norm ist eine
Zertifizierung der implementierten IT Service Management-Prozesse einer Organisation mglich.

Eine
Zertifizierung
von Organisationen ist nur
auf Basis der
ISO 20000
mglich

In einer Analyse kommt Gartner zu dem Ergebnis, dass "bis Ende 2008
mindestens 60 % der relevanten Beschaffungsvorhaben der ffentlichen
Hand und mindestens 30 % des privaten Sektors in entwickelten Volkswirtschaften eine ISO 20000-Zertifizierung verlangen werden" (vgl. [Gartner, 2006]).

2.6.1

Die Geschichte der ISO 20000

Die im September 2005 verffentliche ISO 20000 geht zurck auf einen
British Standard, den BS 15000 (vgl. [BS 15000-1, 2002] und [BS 15000-2,
2002]). Bereits auf der Basis des BS 15000 konnte das IT Service Management einer IT-Organisation zertifiziert werden.
Die erste Version des BS 15000 wurde im November 2000 verffentlicht.
An der Definition dieses Standards haben die Autoren der ITIL Best Practices mageblich mitgewirkt. Dadurch ist eine weitgehende berstimmung zwischen den ITIL Best Practices fr 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 Anstze internationale Anerkennung finden
sollten, wurde der BS 15000 in die ISO 20000 bergeleitet. Die dabei
durchgefhrten nderungen waren sehr gering, sodass die ISO 20000
weitestgehend dem BS 15000 entspricht.

2.6.2

Der Aufbau der ISO 20000

Die ISO 20000 besteht aus den beiden Dokumenten ISO 20000-1 und
ISO 20000-2.
Der erste Teil der Norm ISO 20000-1: Specification (vgl. [ISO 20000-1,
2005]) enthlt die formelle Spezifikation des Standards. In der ISO 20000-1
sind die Vorgaben dokumentiert, die eine Organisation einhalten, sicherstellen und nachweisen muss, um die Zertifizierung zu erhalten. Die

51

ISO 20000-1
enthlt die
Muss-Anforderungen

2 IT Service Management
ISO 20000-1 enthlt die Muss-Kriterien des Standards und umfasst inklusive Deckblatt und Inhaltsverzeichnis insgesamt 36 Seiten.
ISO 20000-2
enthlt die
Soll-Anforderungen

Teil zwei der Norm ISO 20000-2: Code of Practice (vgl. [ISO 20000-2,
2005]) ergnzt die Anforderungen des ersten Teils um Erluterungen. Die
ISO 20000-2 bietet die Leitlinien und die Empfehlungen fr IT Service Management-Prozesse im Rahmen des formellen Standards. Die ISO 20000-2
umfasst 44 Seiten.
Anhand des Umfangs der Dokumentation kann die Zielsetzung der
ISO 20000 leicht nachvollzogen werden. Die Norm definiert Anforderungen an die Prozesse (ISO 20000-1) und Umsetzungsempfehlungen
(ISO 20000-2), liefert aber keine generischen Prozessbeschreibungen, wie
sie durch die ITIL Best Practices zur Verfgung gestellt werden.
Als Beispiel hierzu soll das Service Level Management dienen. Die
ISO 20000-1 fordert fr das Service Level Management unter anderem, die
IT Services mittels SLAs zu definieren und zu vereinbaren (vgl. [ISO
20000-1, 2005], Kapitel 6.1 Service Level Management): Each service
provided shall be defined, agreed and documented in one or more service level
agreements (SLAs). Die ISO 20000-2 enthlt Empfehlungen zu den Inhalten der SLAs (vgl. [ISO 20000-2, 2005], Kapitel 6.1.2 Service Level Agreements): The minimum content that should be in an SLA or that can be directly
referenced from an SLA is: brief service description; validity period and/or SLA
change control mechanism; authorization details..
Die ITIL Best Practices beschreiben dagegen die Prozessaktivitten zur
Definition und Vereinbarung von SLAs (vgl. [OGC, 2005b], Kapitel 3.4.3
Planen der SLA-Struktur): muss das Service Level Management eine
SLA Struktur planen, die am besten geeignet ist, sicherzustellen, dass alle Services .

ITIL und
ISO 20000 stehen nicht im
Wettbewerb,
sondern ergnzen sich
zweckmig

Wie das Beispiel zeigt, stehen die ITIL Best Practices und die ISO 20000
nicht in Konkurrenz zueinander, sondern ergnzen sich zweckmig. Ungeachtet einer mglichen Zertifizierung liefern die ITIL Best Practices Guidelines zum Aufbau der IT Service Managements. Die notwendigen IT
Service Management-Prozesse werden beschrieben, Rollen definiert, Dokumente wie SLAs, RFCs werden beschrieben, kritische Erfolgsfaktoren
identifiziert und mgliche Leistungsindikatoren beschrieben. Mithilfe von
ITIL knnen Organisationen wirkungsvoll und mit einer greren Planungssicherheit ihr IT Service Management etablieren. IT-Organisationen,
die die ITIL Best Practices als Leitfaden zum Design ihrer IT Service Management-Prozesse nutzten, haben so eine gute Basis fr eine ISO 20000
Zertifizierung geschaffen. Die ISO 20000 definiert Mindestanforderungen
und hilft dadurch, sich zunchst auf die Mindestanforderungen zu konzentrieren. Hierzu die Presseerklrung des Flughafens Mnchen zur er-

52

2.6 ISO 20000


folgreichen ISO 20000 Zertifizierung um die Prozessneugestaltung mit der
erforderlichen Motivation durchzufhren, wurde die Zertifizierung des Servicebereichs nach BS15000 (jetzt ISO 20000) als Meilenstein definiert. Die Zertifizierung als erste Zielmarke zu definieren, um einerseits das Augenmerk des Bereichsmanagements und aller betroffenen Mitarbeiter klar zu fokussieren, andererseits die Bearbeitungstiefe in den Prozessen zu begrenzen und eine pragmatische
'Flughhe' zu halten, erwies sich dabei als sehr hilfreich und gab allen beteiligten
Mitarbeitern eine klare Zielorientierung (vgl. [KESS, 2006a]).
Die ITIL Version 2 ist nicht mit der ISO 20000 gleichzusetzen. Es lassen
sich strukturelle Unterschiede zwischen den ITIL Best Practices der Version 2 und der ISO 20000 feststellen, wie zum Beispiel das bergeordnete
Managementsystem.
Mit der Herausgabe der ITIL Version 3 werden mit dem bergeordneten
Management (Service Strategy) und dem Continual Service Improvement
wesentliche Managementprozesse abgedeckt, die in der ISO 20000 gefordert werden. Allerdings sind in der ITIL Version 3 die Prozesse gegenber
der ISO 20000 erweitert worden, wie zum Beispiel durch die Aufteilung
des alten Incident Managements in Incident Management und Request Fulfilment. Ungeachtet dieser geringfgigen Unterschiede lassen
sich die Anforderungen der ISO 20000 mit der ITIL Version 3 einfacher
umsetzen.
Die ISO 20000 definiert die Mindestanforderungen an das IT Service Management, die ITIL Best Practices liefern hierzu generische Prozessbeschreibungen.

2.6.3

Die Inhalte der ISO 20000

In der ISO 20000-1 (Specification) und der ISO 20000-2 (Code of practice)
sind die zu implementierenden IT Service Management-Prozesse sowie
die bergeordneten Prozesse und Aufgaben dokumentiert. Insbesondere
mit den Anforderungen an ein bergeordnetes Managementsystem enthlt die ISO 20000 eine wichtige Ergnzung zu ITIL Version 2. Mit der ITIL
Version 3 ist mit der Service Strategy und dem Continual Service Improvement das bergeordnete Managementsystem ebenfalls beschrieben.
Explizit fordert die ISO 20000 einen strategischen Planungsprozess fr das
IT Service Management. Er soll unter anderem kurz-, mittel und langfristige Planungen miteinander vereinen. Damit wird die Integration des IT
Service Managements in die IT-Strategie sichergestellt.
Innerhalb der folgenden Abbildung 20 werden die geforderten IT Service
Management-Prozesse, ergnzt um das bergeordnete Managementsystem der ISO 20000, dargestellt (vgl. [ISO 20000-1, 2005]).

53

2 IT Service Management

Anforderungen an ein Management System


Planung und Implementierung des Service Managements
Planen und Implementieren neuer oder genderter Services
Service Delivery Prozesse
Capacity Management
Service Continuity
and Availability
Management

Release
Prozesse

Service Level Management


Service Reporting

Control Prozesse
Configuration Management
Change Management

Resolution Prozesse
Release
Management

Abbildung 20:

Information Security
Management

Incident Management
Problem Management

Budgeting and
accounting for IT
services

Relationship
Prozesse
Business Relationship
Management
Supplier Management

IT Service Management-Prozesse der ISO 20000

Unternehmen, die eine ISO 20000-Zertifizierung anstreben, mssen smtliche dargestellten Prozesse implementieren. Eine Zertifizierung fr einzelne Prozesse ist nicht mglich. Dagegen knnen einzelne IT-Bereiche
zertifiziert werden, sofern in diesen Bereichen smtliche Prozesse verantwortlich durchgefhrt werden.

2.6.4

Die ISO 20000 und Kennzahlen

Innerhalb der ISO 20000 werden keine Kennzahlen fr die IT Service Management-Prozesse vorgeben bzw. empfohlen.
Die ISO 20000 verlangt allerdings eine Etablierung der Prozessverantwortung und das Prozess-Management (Management Control) fr smtliche
IT Service Management-Prozesse. Es ist innerhalb der eigenen Organisation fr alle Prozesse der ISO 20000 nachzuweisen:

54

Kenntnis und Steuerung des Inputs


Kenntnis, Nutzung und Interpretation des Outputs
Festlegung und Bewertung von Metriken
Objektiver Nachweis ber die Prozessfunktionalitt in bereinstimmung mit der Norm ISO 20000

2.6 ISO 20000


Bestimmung, Messung und Prfung von Prozessverbesserungen
(Service Improvement Plan)
Die geforderte Kenntnis des Inputs / Outputs sowie die Festlegung und
Bewertung von Metriken hat zur Folge, dass fr smtliche IT Service Management-Prozesse Kennzahlen zu definieren sind.
Hinzu kommt, dass der kontinuierliche Verbesserungsprozess integraler
Bestandteil der ISO 20000 ist. Hierzu wird in der Norm die Plan-DoCheck-Act-Methodik beschrieben (aus [van Bon, 2006], vgl. Abbildung 21).
GeschftsAnforderungen

Management von Services

KundenAnforderungen

Management von
Verantwortlichkeiten

Anforderungen
neue/genderte
Services

KundenZufriedenheit
Neue oder
genderte
Services

PLAN
Planen des
Service Managements

Weitere Prozesse, z.B.


Geschfts-, Lieferanten-,
Kundenprozesse

DO

ACT

Service Desk

Implementieren des
Service Managements

Kontinuierliche
Verbesserung

CHECK

Weitere Teams,
z.B. Security,
IT-Betrieb

Abbildung 21:

GeschftsErgebnisse

berwachung, Messen
und Review

Weitere Prozesse, z.B.


Geschfts-, Lieferanten-,
Kundenprozesse
Zufriedenheit im
Team und bei den
Beteiligten insgesamt

PDCA-Methodik

Dieser kontinuierliche Verbesserungsprozess ist nicht nur fr die bergeordneten Managementaufgaben, sondern auch fr die einzelnen IT Service
Management-Prozesse zu etablieren.
Wie in Kapitel 3 IT Prozess-Management ausgefhrt, ist die Messung
von Prozessen die unabdingbare Voraussetzung dafr, deren Wirksamkeit
sicherzustellen (vgl. [van Bon, 2006]):
You cannot control what you cannot measure.

55

2 IT Service Management
Im Rahmen
einer ISO 20000
Zertifizierung
werden Prozesskennzahlen berprft.

Im Rahmen einer ISO 20000-Zertifizierung muss dieser Nachweis fr


smtliche IT Service Management-Prozesse sowie fr das bergeordnete
Managementsystem erbracht werden. Dabei wird von der Zertifizierungsorganisation auch berprft, wie die ermittelten Kennzahlen mit den Zielen korrespondieren und welcher Handlungsbedarf aus den Kennzahlen
abgeleitet werden kann.
Die Anforderungen und Empfehlungen der ISO 20000 hinsichtlich Monitoring und Reporting von SLAs beschreiben wir in Kapitel 2.8.6 Monitoring und Reporting von SLAs, OLAs und UCs.

2.7 COBIT
Je bedeutender und kritischer die IT-Untersttzung fr die Geschftsprozesse einer Organisation ist, umso wichtiger ist der Einsatz eines geeigneten Steuerungsinstruments fr die Aktivitten der IT. Vor diesem Hintergrund wurde COBIT (Control Objectives for Information and Related
Technology) als Steuerungsmodell der gesamten IT konzipiert.
Ursprnglich wurde COBIT von der Information Systems Audit and
Control Foundation (ISACF) entwickelt, dem Forschungsinstitut der Information Systems Audit and Control Association (ISACA). Wie der Organisationsname bereits verrt, war COBIT speziell fr den Einsatz bei
Wirtschaftsprfern vorgesehen. Aufgrund der Ausrichtung an der Auditierung liegen die Strken von COBIT naturgem in den definierten Steuerungszielen, und insbesondere in der damit verbundenen berprfung
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 ausdrcklich betont, dass die praktische Ausgestaltung organisationsspezifisch und durch die Integration mit anderen eingesetzten Methoden und
Verfahren erfolgen sollte (vgl. [COBIT, 2005]).
Hufig wird COBIT im Zusammenhang mit IT Governance genannt. Es
existiert keine einheitliche Definition des Begriffs IT Governance. Allgemein werden unter dem Thema IT Governance Grundstze, Verfahren
und Manahmen zusammengefasst, die sicherstellen, dass mit Hilfe der
eingesetzten IT die Geschftsziele abgedeckt, die Ressourcen verantwortungsvoll eingesetzt und Risiken angemessen berwacht werden. COBIT,
aber auch die ITIL Best Practices, sollen diese Magaben der IT Governance sicherzustellen.
ITIL Version 3 definiert den Begriff IT Governance und bezieht sich
dabei auf eine Definition des IT Governance Instituts (vgl. [OGC, 2007e]):

56

2.7 COBIT
IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership, organizational structures and processes that ensure that the organizations IT sustains and extends the organizations strategies and objectives.
(Board Briefing on IT Governance, 2nd Edition, 2003, IT Governance Institute
ITGI)

2.7.1

Entwicklung von COBIT

Auslser fr die Entwicklung von COBIT war der Wunsch, eine gemeinsame Basis fr die Auditierung von IT-Organisationen innerhalb von Prfungsorganisationen zu schaffen. Hierzu wurden analog zu der Entwicklung von ITIL entsprechende Best Practices von Experten unterschiedlicher Organisationen zusammengefhrt und dokumentiert.
Die erste Version von COBIT wurde bereits 1996 verffentlicht. Mit der
strkeren Ausrichtung auf die IT Governance wurde die Weiterentwicklung im Jahr 1999 an das unabhngige 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]) bercksichtigt, sodass diese verschiedenen Best Practices besser aufeinander abgestimmt sind.
Speziell im Zusammenhang mit der Nachweispflicht des Sarbanes-Oxley
Acts (SOX)2 (vgl. [COBIT, 2006]) fr an der amerikanischen Brse notierte
Unternehmen hat die Nutzung von COBIT zugenommen.
Bis zum Jahr 2008 soll die COBIT Version 5 entwickelt werden, wobei strategische Betrachtungen grere Bercksichtigung finden sollen als bisher.
So ist unter anderem die Zusammenfassung von IT-Prozessen in einem
Bereich (Domain) IT Governance geplant.
Die im folgenden Kapitel beschriebenen Prozesse und Kennzahlen basieren auf der COBIT Version 4.0.

2.7.2

Struktur von COBIT

Analog zu ITIL definiert COBIT Best Practices, die sicherstellen, dass die
eingesetzte IT die Geschftsziele untersttzt, dass Ressourcen verantwortungsvoll eingesetzt und Risiken angemessen berwacht werden.
2

Der Sarbanes-Oxley Act wurde benannt nach seinen Verfassern, dem Senator
Paul S. Sarbanes und dem Abgeordneten Michael Oxley, die ein Gesetz zur
Verschrfung der Rechnungslegungsvorschriften in Folge der Bilanzskandale
von Unternehmen wie Enron oder Worldcom erlieen.

57

COBIT sind
Best Practices.

2 IT Service Management
Speziell beim Aufbau eines internen Steuerungssystems in der IT und bei
der Messung der Zielerreichung soll COBIT die zuvor genannten Aufgaben der IT Governance untersttzen.
COBIT identifiziert und dokumentiert insgesamt 34 Prozesse, die fr ein
erfolgreiches Management der IT erforderlich sind. Diese 34 IT-Prozesse
werden in vier bergeordneten Domains gruppiert, die einen geschlossenen Lebenszyklus (Life Cycle) bilden (vgl. [COBIT, 2005], Abbildung 22):
Prozesse
- berwache und bewerte
IT-Performance
- berwache und bewerte
interne Controls
- Stelle die angeordnete
Compliance sicher
- Sorge fr IT-Governance

Geschftsziele

ME:
Monitor and
Evaluate

Prozesse
- Def. u. Manage Service Level
- Manage Services von Dritten
- Manage Performance
und Kapazitten
DS: Deliver
- Manage kontinuierliche and Support
Services
- Stelle Systemsicherheit sicher
- Identifiz. u. verrechne Kosten
- Schule u. trainiere Anwender
- Manage Service Desk
und Incidents
- Manage die Konfigurationen
- Manage Probleme
- Manage Daten
- Manage technisches Umfeld
- Manage den Betrieb
Abbildung 22:

58

PO:
Plan and
Organise

AI:
Acquire
and
Implement

COBIT Prozess-bersicht

Prozesse
- Definiere stragischen IT-Plan
- Def. Informationsarchitektur
- Def. technolog. Ausrichtung
- Definiere die IT-Prozesse,
Organisation, Beziehungen
- Manage IT-Investitionen
- Kommuniziere Ziele und
Ausrichtung des Mgmts.
- Manage IT-PersonalRessourcen
- Manage die Qualitt
- Beurteile und Manage
die Risiken
- Manage Projekte

Prozesse
- Identifiziere automatisierte Lsungen
- Beschaffe und warte
Anwendungssoftware
- Beschaffe und warte
technische Infrastruktur
- Ermgliche Betrieb und
Nutzung
- Beschaffe IT-Ressourcen
- Manage Changes
- Installiere u. genehmige
Lsungen und Changes

2.7 COBIT
Fr jeden der 34 IT-Prozesse dokumentiert COBIT die jeweilige Best Practice in folgender Form:

Generische Prozessbeschreibung
Prozessziele
Wichtigste Aktivitten
Input und Output des Prozesses
Mgliche organisatorische Verantwortlichkeiten
Wichtigste Metriken
Verknpfte IT-Ziele

Zustzlich bietet COBIT die Mglichkeit, den Reifegrad dieser Prozesse zu


bestimmen. Hierzu sind zu jedem Prozess die Reifegradanforderungen
spezifiziert.

2.7.3

Prozess-Management gem COBIT

In COBIT sind fr jeden Prozess Control Objectives definiert. COBIT


versteht Control Objectives als Minimalanforderungen fr ein wirkungsvolles Prozess-Management (vgl. [COBIT, 2005]).
Control wird hufig mit Kontrolle bersetzt, wodurch die eigentliche Bedeutung
der Steuerung bzw. des Managements verflscht wird. Aus diesem Grund wird
im Folgenden der englische Begriff verwendet.

Die Control Objectives dokumentieren das Ziel oder den Zweck eines Prozesses und definieren so die Mindestanforderung, die zu erreichen ist. Pro
Prozess existiert immer ein bergeordnetes Control Objective.
Die Prozesse sind so bezeichnet, dass sich das bergeordnete Control Objective direkt aus dem Prozessnamen ergibt. Zu jedem Prozess stellt
COBIT eingangs das bergeordnete Control Objective gemeinsam mit den
wichtigsten Prozesszielen und Metriken dar.
Zustzlich sind anschlieend zu jedem Prozess mehrere daraus abgeleitete,
detaillierte Control Objectives beschrieben. Diese detaillierten Control
Objectives knnen als Best Practice fr das Management des jeweiligen
Prozesses angesehen werden. Es sind Minimalanforderungen, die die Zielerreichung sicherstellen.
Beispiel Manage Changes (AI6 Manage Changes):
Innerhalb des bergeordneten Control Objective wird als Zielsetzung fr
das Manage Changes gefordert, dass smtliche Changes an der Infrastruktur und den Applikationen in der produktiven Umgebung nach
standardisierten Methoden und Verfahren vorgenommen werden. Zu
diesen Changes zhlen auch Notfall-Changes und Patches. Jeder Change
muss vor der Implementierung aufgezeichnet, bewertet und autorisiert

59

Control
Objectives
dienen der
Steuerung,
nicht der
Kontrolle

2 IT Service Management
sowie nach der Implementierung anhand der geplanten Ergebnisse berprft werden. Diese Aktivitten schlieen Changes an Verfahren, an Prozessen, an Systemen und an Services ein. Durch diese Aktivitten sollen
die Risiken von Changes minimiert werden, die sich negativ auf die Stabilitt und Integritt der Produktivumgebung auswirken.
COBIT definiert fr den Prozess Manage Changes insgesamt 6 detaillierte Control Objectives. Ein detailliertes Control Objective lautet Notfall
Changes (AI6.3: Emergency Changes).
Dieses Control Objective fordert, einen Prozess fr die Definition, Aufnahme, Beurteilung und Genehmigung von Notfall-Changes zu erstellen.
Dokumentationen und Tests knnen unter Umstnden auch nach der Implementierung erfolgen.
Die folgende Abbildung 23 (textuell angelehnt an [COBIT, 2005]) stellt die
detaillierten Control Objectives fr den Prozess Manage Changes dar.

AI6: Manage Changes

AI6.1: Standard-Changes und Prozeduren


AI6.2: Bewertung von Auswirkungen, Priorisierung und Freigabe
AI6.3: Notfall-Changes
AI6.4: Statusverfolgung und Reporting
AI6.5: Abschluss und Dokumentation
Abbildung 23:

Zusammenhang zwischen Control Objectives in COBIT

Die COBIT Control Objectives sind den Prozesszielen und Prozessaufgaben der
ITIL Best Practices gleichzusetzen.

Durch definierte Prozessaktivitten soll sichergestellt werden, dass die


Control Objectives erreicht werden, was gleichbedeutend damit ist, dass
der Prozess die gewnschten Zwecke erfllt.

60

2.7 COBIT
Whrend ITIL die Leistungsindikatoren der Prozesse pauschal als Key
Performance Indikators (KPIs) bezeichnet, betrachtet COBIT die Leistungsmessung der Prozesse als Performance Messung und unterscheidet bei den Metriken zwischen den Key Goal Indicators (KGIs) und den
Key Performance Indicators (KPIs).
Mit den KGIs wird gemessen, ob ein Prozess seine definierten Ziele erreicht (Effektivitt). KGIs sind daher an dem jeweiligen Prozess-Output
orientiert.
Mit den KPIs wird dagegen die Leistungsfhigkeit eines Prozesses in Relation zu den eingesetzten Ressourcen gemessen (Effizienz). Der Fokus der
KPIs liegt also auf einer Messung der prozessinternen Aktivitten.
Die KGIs sind demzufolge die wichtigeren Kennzahlen fr die Bewertung
eines Prozesses, da sie dem Management aufzeigen, ob ein Prozess die
definierten Anforderungen erfllt.
Die KGIs messen die Effektivitt eines Prozesses, whrend die KPIs die Effizienz
betrachten. Hauptaugenmerk sollte zunchst auf den KGIs liegen.

COBIT beschreibt aber nicht nur Metriken fr die einzelnen IT-Prozesse,


sondern legt auch Ziele und Metriken fr den gesamten IT-Bereich fest.
Dabei werden die Ziele und Metriken von den Geschftsanforderungen
bestimmt. Die Vorgehensweise erfolgt top down. Aus den Geschftsanforderungen ergeben sich die Ziele fr den IT-Bereich. Diese bergeordneten Ziele bestimmen dann die jeweiligen Prozessziele und mit den Prozesskennzahlen (KGIs, KPIs) erfolgt die Messung, ob die Prozesse die Zielsetzungen erfllen.
Prozessziele und Kennzahlen fr Prozesse werden top down definiert. Sie ergeben sich aus den IT-Zielen aus den Geschftsanforderungen.

Die Messgren fr 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 fr die
Prozessmessung ein KPI fr 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 fr den Prozess Manage
Changes. Fr das zugeordnete IT-Ziel Reduziere Mngel und Nacharbeiten bei Lsungen und dem Servicebetrieb ist diese Kennzahl dagegen
ein KPI.

61

COBIT
gliedert die
PerformanceMessung in
Kriterien fr
Effektivitt
und Effizienz

2 IT Service Management
COBIT definiert KPIs und KGIs auf Ebene der Prozesse und der IT-Ziele. Dabei
wird aus einem KGI der Prozessebene ein KPI auf Ebene der IT-Ziele.

Die Metriken und deren Ebenen stellen sich in COBIT wie folgt dar (hier
verdeutlicht am Beispiel Manage Changes, vgl. [COBIT, 2005], siehe
Abbildung 24):

Ziel der Aktivitten

Ziel des Prozesses

Definition und
Kommunikation der
Verfahren fr Changes
inklusive
Notfallnderungen patches

Fhre genehmigte
nderungen an der
IT-Infrastruktur und
Anwendungen durch
Bewerte die
Auswirkungen der
Changes auf die ITInfrastruktur,

Ziel der IT

Werden gemessen durch

Werden gemessen durch

KPI

% der nicht
erfolgreichen
nderungen der
Infrastruktur, die
durch ungeeignete
nderungsspezifikationen
hervorgerufen sind

Metriken fr Prozesse

62

Anzahl der
Unterbrechungen
oder Datenfehler, die
durch ungenaue
Spezifikation oder
unvollstndige
Beurteilung der
Auswirkungen
hervorgerufen ist

KGI

KPI
Abbildung 24:

IT Key Goal Indicators


treiben

% der aufge-zeichneten
und mit
automatisierten Tools
verfolgten nderungen
% der nderungen, die
formale
nderungskontrollpro
zesse befolgen

Reagiere auf
Geschftsanforderungen in
bereinstimmung
mit der Unternehmensstrategie
Reduziere Mngel
und Nacharbeit bei
Lsungen

Werden gemessen durch

Key Goal Indicators

Key Performance Indicators


treiben

Messung der Zielerreichung

Definierte Ziele

Metriken fr IT-Ziele

Ziele, Prozesse und Metriken in COBIT

KGI

2.7 COBIT
Whrend COBIT Version 3.0 (vgl. [COBIT, 2000]) fr die einzelnen Prozesse noch die kritischen Erfolgsfaktoren (Critical Success Factors, CSFs)
dokumentierte, werden die CSFs in der Version 4.0 nicht mehr gesondert
ausgewiesen. Die CSFs wurden aufgeteilt in die Input-Beschreibung (was
bentige ich von anderen) und in die Aktivittenbeschreibung (was
muss ich in meinem Prozess durchfhren).
COBIT enthlt darber hinaus generelle Anforderungen an das Management von Prozessen. Die folgenden Kriterien sind fr jeden Prozess zu
erfllen:
Fr jeden Prozess ist der Prozess Owner und dessen Verantwortung
zu definieren
Jeder Prozess muss wiederholbar sein
Fr die Prozesse sind klare Ziele und Vorgaben zu definieren
Die Rollen, Aktivitten und Verantwortlichkeiten sind zu definieren
Die Prozesse sind hinsichtlich ihrer Zielerreichung zu messen
Die dokumentierten, berprften, aktuellen und unterzeichneten
Grundstze (Policy), Plne und Verfahren sind allen Beteiligten zu
kommunizieren.
Die hier beschriebenen Best Practices von COBIT fr das Prozess-Management stellen sich wie folgt dar (siehe Abbildung 25):
Anforderung
Prozessmanagement

Control
Objectives

KPI

KGI

Prozess

Input

Ziele

Output

Aktivitten

Abbildung 25:

Prozess, Ziele und Kontrollebenen in COBIT

63

2 IT Service Management

2.7.4
Mit der Version 4.0 hat
sich COBIT
strker an den
ITIL Best
Practices
ausgerichtet.

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

COBIT und die IT Service Management-Prozesse

COBIT enthlt relevante Prozesse und Metriken fr den gesamten IT-Bereich. Die Prozesse, die innerhalb der ITIL Best Practices fr das IT Service
Management beschrieben sind, knnen 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 Verffentlichung von COBIT Version 4.0 hat sich COBIT den ITIL
Best Practices sogar noch weiter angenhert. Whrend in lteren Versionen von COBIT zum Beispiel das Incident und Problem Management in
einem gemeinsamen Prozess beschrieben wurden, hat COBIT Version 4.0
die ITIL Prozessstruktur mit getrennten Prozessen fr das Incident und
Problem Management bernommen.
Es geht daher nicht um den Wettstreit konkurrierender Best Practices,
sondern vielmehr darum, wie die verschiedenen Best Practices konvergieren und gewinnbringend genutzt werden knnen.
Die Vorteile und Strken von ITIL liegen zum einen in der generischen
und sehr ausfhrlichen Beschreibung von Prozessaktivitten und in den
Empfehlungen zur Gestaltung und Umsetzung der Prozesse. Zum anderen erhht die enge Verbindung zur ISO 20000 die praktische Relevanz
des ITIL Ansatzes.
Bei der Prozessbeschreibung begngt sich COBIT hingegen mit einer kurzen Aufzhlung von Aktivitten. Fr den Prozess Manage Changes beispielsweise sind die Prozessaktivitten in fnf Stzen dokumentiert. COBIT liefert jedoch im Gegensatz zu ITIL, gute Anstze fr die Definition von Metriken, die zum Teil Wirtschaftsprfern bekannt sind und
bei einer Auditierung hilfreich sind.
Whrend die Vorteile von ITIL in den Prozessbeschreibungen und Empfehlungen fr die Umsetzung liegen, bietet COBIT gute Anstze fr Metriken. Die Prozesse fr das IT Service Management stimmen in den Best Practices grundstzlich berein, sodass aus beiden Anstzen die Strken zusammengefhrt werden
knnen.

Eine Analyse der COBIT Best Practice und der IT Service ManagementProzesse auf Basis der ITIL Best Practices zeigt eine groe berstimmung
von Prozessen und deren Ziele bzw. Aktivitten (vgl. [Kurth, 2006]).
Die bereinstimmenden IT Service Management-Prozesse zwischen den
ITIL Best Practices Version 2 und COBIT wurden seitens des IT Governance Institute analysiert und dokumentiert (vgl. [COBIT, 2007]). Der fol-

64

2.7 COBIT
genden Abbildung 26 knnen diese bereinstimmenden Prozesse fr das
IT Service Management entnommen werden.
Innerhalb des dokumentierten Mappings zwischen ITIL und COBIT wird
der Prozess DS 5 Stelle Systemsicherheit sicher nicht als bereinstimmend ausgewiesen. Im Rahmen der ISO 20000 ist aber das Security Management als Prozess des IT Service Managements definiert. Daher wurde in
der folgenden Darstellung aus [COBIT, 2007] (Abbildung 26) der Prozess
DS 5 Stelle Systemsicherheit sicher ebenfalls hervorgehoben.
Prozesse
- berwache und bewerte
IT-Performance
- berwache und bewerte
interne Controls
- Stelle die angeordnete
Compliance sicher
- Sorge fr IT-Governance

Geschftsziele

ME:
Monitor and
Evaluate

Prozesse
- Def. u. Manage Service Level
- Manage Services von Dritten
- Manage Performance
und Kapazitten
DS: Deliver
- Manage kontinuierand Support
liche Services
- Stelle Systemsicherheit sicher
- Identifiz. u. verrechne Kosten
- Schule u. trainiere Anwender
- Manage Service Desk
und Incidents
- Manage die Konfigurationen
- Manage Probleme
- Manage Daten
- Manage technisches Umfeld
- Manage den Betrieb
Abbildung 26:

PO:
Plan and
Organise

AI:
Acquire
and
Implement

Prozesse
- Definiere stragischen IT-Plan
- Def. Informationsarchitektur
- Def. technolog. Ausrichtung
- Definiere die IT-Prozesse,
Organisation, Beziehungen
- Manage IT-Investitionen
- Kommuniziere Ziele und
Ausrichtung des Mgmts.
- Manage IT-PersonalRessourcen
- Manage die Qualitt
- Beurteile und Manage
die Risiken
- Manage Projekte

Prozesse
- Identifiziere automatisierte Lsungen
- Beschaffe und warte
Anwendungssoftware
- Beschaffe und warte
technische Infrastruktur
- Ermgliche Betrieb und
Nutzung
- Beschaffe IT-Ressourcen
- Manage Changes
- Installiere u. genehmige
Lsungen und Changes

Mapping der Prozesse in ITIL Version 2 und COBIT

65

2 IT Service Management
Mit der ITIL Version 3 wird eine noch grere Abdeckung erreicht. Ein
entsprechendes Mapping ist aber zurzeit noch nicht publiziert.

2.7.5

Metriken fr IT Service Management-Prozesse

Zu jedem Prozess sind in Klammern die Originalbezeichnung, die bergeordnete Domain, sowie die Nummer innerhalb der Domain dargestellt.
Die Bezeichnungen der Domains lauten folgendermaen:
-

Plan and Organise (PO)

Acquire and Implement (AI)

Deliver and Support (DS)

Monitor and Evaluate (ME).

Aufgrund des generischen Ansatzes werden in COBIT zweckmige KGIs


und KPIs aufgezeigt. Die konkrete Ausgestaltung der Metriken mit detaillierten Spezifikationen und die Bedeutung fr das Prozess-Management
sind dagegen nicht in COBIT dokumentiert. Diese Festlegungen und Ausgestaltungen sind Aufgabe des Prozessdesigns.
In Kapitel 5 sind die Best Practices auf der Basis von ITIL, COBIT,
ISO 20000 und unserer Projekterfahrungen dokumentiert.
Fr die Definition von Metriken hat COBIT pragmatische Anforderungen:
Es ist ein gutes Verhltnis zwischen Aussagekraft und Aufwand zur
Generierung der Messdaten sicherzustellen.
Es ist besser, wenige gute Metriken zu etablieren, als umfangreiche
Kennzahlen mit einer niedrigen Qualitt.
Die Kennzahlen sollten extern vergleichbar sein.
Die Kennzahlen sollten intern vergleichbar sein
Im folgenden Abschnitt werden die in COBIT dokumentierten Prozessziele und die daraus resultierenden KPIs und KGIs ausgewiesen (vgl.
[COBIT, 2005]).

2.7.6

COBIT Metriken fr IT Service Management-Prozesse

Manage Service Desk und Incidents (Manage Service Desk and Incidents: DS8)
Zielsetzung dieses Prozesses ist die wirkungsvolle Nutzung der IT-Systeme durch die Lsung und Analyse von Anwenderanfragen und Incidents. Zur Zielerreichung ist die Etablierung eines Service Desks und eines
Incident Managements notwendig.
Die in COBIT dokumentierten KPIs sind:

66

2.7 COBIT
Anzahl der pro Mitarbeiter im Service Desk stndlich bearbeiteten
Anrufe (Calls)
Anteil der Incidents, die einen Vor-Ort-Support bentigen
Arbeitsrckstand ungelster Anfragen
Die in COBIT dokumentierten KGIs sind:
Durchschnittliche Bearbeitungszeit nach Gewichtung (severity)
Anteil wieder geffneter (reopen) Incidents
Durchschnittliche Reaktionszeit
Die in COBIT dokumentierten IT Key Goal Indicators sind:
Anwenderzufriedenheit mit dem Service Desk
Anteil der innerhalb der vereinbarten Zeit gelsten Incidents

Manage Probleme (Manage Problems: DS10)


Das Ziel des Problem Managements ist die Gewhrleistung der Anwenderzufriedenheit und die Reduzierung von Mngeln an Services. Dies soll
durch die Ermittlung der zugrunde liegenden Ursachen fr alle wichtigen
Probleme und durch die Definition von Lsungen fr die identifizierten
Probleme erreicht werden.
Die in COBIT dokumentierten KPIs sind:
Durchschnittliche Dauer zwischen Problemerfassung und der Identifizierung der Ursache
Anteil der Probleme, fr die eine Ursachenanalyse betrieben wurde
Hufigkeit der Berichte oder Aktualisierung ber anhaltende Probleme, basierend auf deren Gewichtung (severity)
Die in COBIT dokumentierten KGIs sind:
Anteil der Probleme, die innerhalb der vorgeschriebenen Zeit gelst
wurden
Mittelwert und Standardabweichung der Zeitdauer zwischen der
Identifizierung und der Problemlsung
Mittelwert und Standardabweichung der Zeitdauer zwischen der
Problemlsung und dem Abschluss
Die in COBIT dokumentierten IT Key Goal Indicators sind:
Anzahl der wiederkehrenden Probleme mit Auswirkung auf das
Business
Anzahl der Geschftsunterbrechungen aufgrund operationeller Probleme

67

2 IT Service Management

Manage die Konfigurationen (Manage the configuration: DS9)


Das Configuration Management hat die Optimierung der IT-Infrastruktur,
der Ressourcen und Kapazitten sowie den Nachweis der IT-Anlagen zum
Ziel. Basis hierfr ist die fehlerfreie und vollstndige Erfassung und Speicherung der Konfigurationsattribute der IT-Anlagen und der Baselines,
sowie die Prfung, ob sie mit den tatschlichen Konfigurationen bereinstimmen.
Die in COBIT dokumentierten KPIs sind:
Anzahl der Abweichungen in Bezug auf unvollstndige oder fehlende Konfigurationsinformationen
Durchschnittliche Zeitdauer zwischen der Identifizierung einer Abweichung und deren Korrektur
Die in COBIT dokumentierten KGIs sind:
Anzahl der Abweichungen zwischen den gespeicherten und tatschlichen Konfigurationsdaten
Anteil der erworbenen Lizenzen und der nicht in der Datenbank gespeicherten Lizenzen
Die in COBIT dokumentierten IT Key Goal Indicators sind:
Anteil der Compliance Probleme aufgrund unzulssiger Konfigurationen von IT-Anlagen

Manage Changes (Manage Changes: AI6)


Das Ziel des Manage Changes ist, nderungen innerhalb der Produktivumgebung auf eine formell gesteuerte Art und Weise durchzufhren.
Zu Changes zhlen neben nderungen an der Infrastruktur und an bestehenden Anwendungen auch Notfall-Changes und Patches.
Die in COBIT dokumentierten KPIs sind:
Verhltnis zwischen den akzeptierten und den abgelehnten RFCs
Anzahl und Art der Notfall-Changes
Anzahl und Art der Patches
Die in COBIT dokumentierten KGIs sind:
Anteil der Notfall-Changes am gesamten Change-Aufkommen
Reduzierter Aufwand und Zeitaufwand zur Durchfhrung von
Changes
Anteil nicht erfolgreicher Changes, aufgrund von untauglichen
Change-Spezifkationen
Die in COBIT dokumentierten IT Key Goal Indicators sind:

68

2.7 COBIT
Anteil der Serviceunterbrechungen durch ungenaue Spezifikationen
oder fehlerhafte Beurteilung der Auswirkungen

Installiere und genehmige Lsungen und Changes (Install and accredit


solutions and changes: AI7)
Dieser Prozess hat das Ziel, sicherzustellen, dass neue oder genderte Systeme nach der Installation ohne grere Probleme betrieben werden knnen. 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 whrend des Qualittsmanagement-Reviews
bei der Installations- und Zulassungsprfung gefunden werden
Anzahl der beim Post-Implementation-Review erkannten Verbesserungen
Anteil der Projekte mit dokumentierten und genehmigten Testplnen
Die in COBIT dokumentierten KGIs sind:
Anteil der Installations- und Zulassungsfehler, die whrend Audits
gefunden werden
Nacharbeiten nach der Implementierung, die auf ungengende Akzeptanztests zurckzufhren sind
Ausfallzeiten der Anwendung, die durch ungengende Tests hervorgerufen werden
Die in COBIT dokumentierten IT Key Goal Indicators sind:
Anteil der Interessenvertreter, die mit der Daten-Integritt der neuen Systeme zufrieden sind

Definiere und Manage Service Level (Define and manage service levels: DS1)
Das Service Level Management hat die Ausrichtung der wesentlichen IT
Services an der Geschftsstrategie zum Ziel. Hierzu sind Serviceanforderungen zu identifizieren, die Service Level sind zu vereinbaren und deren
Einhaltung ist zu berwachen.
Die in COBIT dokumentierten KPIs sind:
Anzahl der jhrlichen SLA-Reviews mit dem Business
Anteil der berichteten Service Level
Anteil der automatisch berechneten Service Level
Die in COBIT dokumentierten KGIs sind:
Anzahl der erbrachten Services, die nicht im Katalog enthalten sind

69

2 IT Service Management
Anteil der eingehaltenen Service Level
Anteil der gemessenen Service Level
Die in COBIT dokumentierten IT Key Goal Indicators sind:
Anteil der Interessenvertreter, die mit den erreichten Service Level
zufrieden sind

Identifiziere und verrechne Kosten (Identify and allocate cost: DS6)


Dieser Prozess soll die Transparenz und das Verstehen von IT-Kosten
gewhrleisten und auf der Basis dieser Informationen eine Steigerung der
Kosteneffizienz durch kostenbewusste Verwendung der IT Services erreichen. Hierzu sind die IT-Kosten vollstndig 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
Hufigkeit der berprfung 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 fr IT Services

Manage die IT-Investitionen (Manage the IT-Investment PO5)


Innerhalb dieses Prozesses ist ein System zum Management der Investitionsplanung zu etablieren und zu betreiben. Dieses Managementsystem
umfasst die Betrachtung der Kosten, des Nutzens und der Priorisierung
von Investitionen innerhalb des geplanten Budgets.
Die in COBIT dokumentierten KPIs sind:
Prozent der Projekte mit einem definierten Nutzen
Prozent der Projekte, fr die ein Review nach dem Abschluss
durchgefhrt werden
Die in COBIT dokumentierten KGIs sind:
Anzahl von Budgetabweichungen

70

2.7 COBIT
Prozentuale Darstellung der Budgetabweichung gegenber 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
Geschftsnutzen erzielen oder bertreffen
Prozent der IT-Werttreiber, abgebildet auf die Business-Werttreiber

Manage Performance und Kapazitten (Manage performance and capacity DS3)


Das Ziel des Capacity Managements liegt in der Performanceoptimierung
der IT-Infrastruktur, der Ressourcen und Kapazitten in bereinstimmung mit den Geschftsanforderungen. Hierzu sind die im SLA vereinbarten Antwortzeiten einzuhalten, die Ausfallzeiten zu minimieren und
eine kontinuierliche Verbesserung der IT-Perfomance und Kapazitten
durch Monitoring und Messungen sicherzustellen.
Die in COBIT dokumentierten KPIs sind:
Hufigkeit der Performance- und Kapazittsprognosen
Anteil der Anlagen, die in Kapazitts-Reviews betrachtet werden
Anteil der Anlagen, die durch zentrale Systeme berwacht werden
Die in COBIT dokumentierten KGIs sind:
Lastspitzen und Auslastungsrate
Anteil der Spitzenlastzeiten, die ber die Zielauslastung hinausgehen
Anteil der Antwortzeiten, die nicht den SLAs entsprechen
Die in COBIT dokumentierten IT Key Goal Indicators sind:
Anzahl der Ausfallstunden pro Anwender und Monat aufgrund unzureichender Kapazittsplanung

Manage kontinuierliche Services (Ensure continuous service: DS4)


Dieser Prozess soll sicherstellen, dass mgliche Ausflle der IT Services
minimale Auswirkungen auf die Geschftsprozesse haben.
Die in COBIT dokumentierten KPIs sind:
Zeitdauer zwischen den Tests aller Bestandteile des IT-Kontinuittsplans
Hufigkeit der Reviews des IT-Kontinuittsplans
Anteil der kritischen IT-Komponenten mit automatisierter Verfgbarkeitsberwachung

71

2 IT Service Management
Die in COBIT dokumentierten KGIs sind:
Anteil der SLAs, die die Verfgbarkeitszeit erfllen
Anteil der erfolgreichen Tests der IT-Kontinuittsplne
Hufigkeit der Serviceunterbrechung bei kritischen Systemen
Die in COBIT dokumentierten IT Key Goal Indicators sind:
Anzahl der Ausfallstunden pro Anwender und Monat aufgrund ungeplanter Unterbrechungen

Stelle Systemsicherheit sicher (Ensure system security: DS5)


Das Security Management hat die Aufrechterhaltung der Integritt von
Informationssystemen und die Minimierung der Auswirkungen von Sicherheitsschwachstellen und Security Incidents zum Ziel.
Die in COBIT dokumentierten KPIs sind:
Hufigkeit und Art der gemeldeten Security Incidents
Anzahl und Art von veralteten Benutzerkonten
Anzahl der Zugriffsberechtigungen, die autorisiert, widerrufen, gelscht oder gendert wurden
Die in COBIT dokumentierten KGIs sind:
Anzahl und Art der vermuteten und tatschlichen Zugangsverste
Anzahl und Art von verhinderten bsartigen 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 gegenwrtigen und zuknftigen Anforderungen des Unternehmens und seiner Kunden auszurichten, die Qualitt der erbrachten
IT Services zu verbessern sowie die langfristigen Kosten der ServiceTtigkeit zu reduzieren (vgl. [itSMF, 2001]). Um diese Ziele zu erreichen,
haben sich international anerkannte Best Practices fr IT-Prozesse durchgesetzt. Diese sind in ITIL und COBIT dokumentiert.
Es handelt sich dabei jedoch nicht um die Best Practices einzelner isolierter
Prozesse, sondern vielmehr um einen integrierten Prozessansatz. Die dokumentierten Prozesse sind ber definierte Schnittstellen und gemeinsame
Dokumente und Daten miteinander verknpft. Der Output eines Prozesses dient als Input fr einen anderen Prozess. Dieses Grundprinzip kann
anhand der Prozesse des Problem und Change Managements verdeutlicht

72

2.8 Monitoring und Reporting von SLAs


werden: Werden innerhalb des Problem Managements notwendige Manahmen zur Behebung von Problemen bzw. Fehlern identifiziert, so erstellt der Problem Management-Prozess als Output einen RFC (Request for
Change), der dem Change Management als Input dient und von diesem
Prozess weiter bearbeitet wird.
Die volle Leistungsfhigkeit der ITIL und COBIT Best Practices ergibt sich erst
dann, wenn smtliche Prozesse umgesetzt werden. Daher verlangt die ISO 20000
auch die nachweisliche Implementierung aller dokumentierten Prozesse mit ihren in der ISO 20000-1 definierten Mindestanforderungen.

In der ersten Version von ITIL, die Ende der 80er Jahre herausgegeben
wurde, erfolgte die Betrachtung der Best Practices fr das IT Service Management noch aus IT-Sicht. Diese Sichtweise wandelte sich mit der Herausgabe der ITIL Version 2, bei der sich die ITIL Best Practices auf die
Ausrichtung des IT Service Managements und die Gestaltung der entsprechenden Prozesse im Hinblick auf die bestmgliche Untersttzung der
Geschftsziele einer Organisation konzentrieren. Mit der vorliegenden
Version 3 wird diese Entwicklung konsequent in Richtung der Business
Integration und des Service Lifecycle fortgesetzt.
Die Prozesse des IT Service Managements stellen mit ihren jeweiligen Prozesszielen und ihrer unternehmensspezifischen Ausrichtung sicher, dass
die geschftlich notwendigen IT Services wirkungsvoll erbracht werden
und so die Ziele des IT Service Managements erreicht werden knnen.
Das Hauptaugenmerk der Kunden liegt auf der Lieferung der geschftlich
notwendigen und mit der IT-Organisation vereinbarten IT Services. Die
Betrachtung der damit verbundenen IT-Prozesse ist fr den Kunden sekundr. Sie ist primr an deren Output im Rahmen der gelieferten IT Services und der Sicherstellung von internen und externen Anforderungen
(Compliance) orientiert.
Demzufolge ist die Definition der IT Services und deren Sicherstellung
eine Schlsselfunktion fr eine professionelle IT-Organisation.
Technologische Lsungen knnen ausgetauscht und ersetzt werden. Aber das
Verstndnis 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 zunchst auf die Bereitstellung von technischen
Systemen. Diese Systeme, zum Beispiel eine auf dem Host implementierte

73

Der Fokus der


Kunden liegt
auf den IT
Services.

2 IT Service Management
Applikation, untersttzten die Durchfhrung geschftlicher Aktivitten.
Mit der steigenden Komplexitt der Applikationen und deren zunehmender Bedeutung fr einen reibungslosen Geschftsprozess wurde offensichtlich, dass die ausschlieliche Betrachtung des technischen Betriebs
eines Systems nicht mehr ausreichend ist. Hieraus hat sich zum Beispiel
der Aufbau eines Service Desk als Untersttzungssystem fr den Anwender entwickelt. Mit der Weiterentwicklung innerhalb der InformationsTechnologie greifen eine Vielzahl von einzelnen Systemen ineinander, um
die Durchfhrung von Geschftsprozessen des Kunden zu gewhrleisten.
Damit wandelte sich auch die Sicht des Kunden auf die IT. Der Kunde
sieht nur den Output der miteinander in Verbindung stehenden Systeme.
Hierzu fhrt ITIL aus Bei der Erbringung von Services steht die Wahrnehmung des Kunden im Mittelpunkt (vgl. [OGC, 2005a]).
Die heutige Interpretation des IT Service-Begriffes konzentriert sich demzufolge auf die konsequente Ausrichtung der IT und ihrer Prozesse auf die
Untersttzung der Geschftsprozesse eines Unternehmens. ITIL,
ISO 20000 und COBIT stellen ausdrcklich heraus, dass die beschriebenen
Prozesse die Geschftsziele der Organisation und die Kundenanforderungen zu untersttzen 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 primr der Bereitstellung von IT Services bzw. der notwendigen IT-Untersttzung
zur Erfllung der Geschfts- und Kundenanforderungen dienen.
Von der
System- zur
ServiceOrientierung.

Die IT ist in vielen Branchen und Bereichen zu einem wichtigen, teilweise


zum wichtigsten Produktionsfaktor geworden. Zum Teil laufen heute
einzelne Geschftsprozesse vollstndig IT-gesttzt ab und bentigen keinerlei manuelle Eingriffe mehr, wie zum Beispiel das Online-Banking.
Um sich der Bedeutung der IT fr die geschftlichen Ttigkeiten eines
Unternehmens bewusst zu werden, ist die Frage was wrde beim Ausfall
der IT-Systeme geschehen sehr hilfreich. Damit die geschftlichen Aktivitten entsprechend untersttzt werden knnen, ist in der Regel das Zusammenwirken verschiedener IT-Systeme notwendig. In IT-Organisation
herrscht heute aber zum Teil noch eine technologische Betrachtung vor.
Systemspezialisten fokussieren sich auf ihr System. Dieses System stellt
aber nur ein Rdchen im Getriebe dar und die Funktionalitt des Gesamtsystems ist fr die Untersttzung der Geschftsprozess entscheidend. Die
IT-Organisation muss erkennen, dass der Systembetrieb keinen Selbstzweck darstellt, sondern zweckdienliche Geschftsprozesse mit der notwendigen IT-Untersttzung fr den Unternehmenserfolg entscheidend
sind.

74

2.8 Monitoring und Reporting von SLAs


Fr das Selbstverstndnis der IT ist es wichtig zu erkennen, dass die Bereitstellung der IT Services in erster Linie der Untersttzung der betrieblichen Primraktivitten bzw. der Kerngeschftsprozesse dient und damit ber den Erfolg
eines Unternehmens entscheidet.

So fhrt Porter3 in seinem Wertschpfungsdiagramm aus, dass die primren Aktivitten eines Unternehmens die Kundenanforderungen bedienen
und die Wertschpfung eines Unternehmens sicherstellen. Die untersttzenden Prozesse oder sekundren Aktivitten untersttzen die Durchfhrung der primren Aktivitten bzw. Geschftsprozesse. Die IT gehrt in
der Regel zu den untersttzenden Aktivitten und muss demzufolge in
erster Linie die bergeordneten Wertschpfungsprozesse sicherstellen (vgl.
Abbildung 27).
IT Service Management
Unternehmensinfrastruktur

IT-Service

Personalwirtschaft

IT-Service

IT-Service

IT-Service

Beschaffung

Produktion

= Primre Prozesse / Aktivitten

Wertschpfung

IT-Service

IT-Service

Marketing &
Vertrieb

KundenService

= sekundre Prozesse / Aktivitten


= geforderte und gelieferte IT-Untersttzung
(IT-Service)

Abbildung 27:

Wertschpfungskette nach Porter

Michael E. Porter, Professor fr Wirtschaftswissenschaften an der Harvard


Business School und einer der fhrenden konomen auf dem Gebiet des
strategischen Managements.

75

2 IT Service Management
ITIL stellt den
IT Service in
direkten
Bezug zum
Geschftsprozess

Aus Sicht der IT gibt es eine Vielzahl von unterschiedlichen Business- und
Kundenanforderungen, die aus den primren und sekundren Prozessen
bzw. Aktivitten resultieren. Die erforderliche IT-Untersttzung fr die
Geschftsprozesse definiert ITIL Version 2 prgnant als einen IT Service;
der IT Service ist ein oder mehrere IT-Systeme, die einen Geschftsprozess
ermglichen (vgl. [OGC, 2006b]). Mit ITIL Version 3 wird der Kundenbezug des Service noch strker herausgestellt (vgl. [OGC, 2007a]):
IT Service Management ist eine Menge von spezialisierten organisatorischen Fhigkeiten, um den Kunden einen Nutzen fr das Business in Form von IT Services zu liefern.

Innerhalb der IT wird der Begriff des Systems hufig mit einem technischen System gleichgesetzt. Ein System ist vielmehr ein integrierter Komplex, der eine oder mehrere Komponenten, zum Beispiel Prozesse, Hardware,
Software, Einrichtungen und Personen umfasst und das Erfllen bzw. Erreichen
einer erklrten Anforderung bzw. Zielsetzung ermglicht (vgl. [OGC, 2006b]).
Hiermit wird deutlich, dass der IT Service aus ein oder mehrere Prozessen,
Hardware, Software, Einrichtungen und Personen besteht, die einen Geschftsprozess ermglichen.
Innerhalb des Glossars wird diese Gesamtsicht zum IT Service nochmals
deutlich herausgestellt; Die Erbringungskriterien der IT Service Organisation
aus Sicht der Kunden, die Services, umfassen nicht nur die Bereitstellung von
Computerressourcen zur Verwendung durch die Kunden (vgl. [OGC, 2006b]).
Ein IT Service ergibt sich aus der Sicht des Kunden und untersttzt die optimale
Durchfhrung von Geschftsprozessen. Dazu ist ein bestmgliches Zusammenwirken von Personen, Produkten, Prozessen und Partnern erforderlich.

Diese Anforderungen an einen IT Service unterscheiden sich in Abhngigkeit der Bedeutung der Geschftsprozesse fr das Unternehmen stark in
ihrer Art der Leistung und Qualitt. Das Kundeninteresse liegt primr in
der notwendigen Untersttzung der Geschftsprozesse. Damit nimmt der
Kunde die IT-Organisation mit den geleisteten IT Services als mageblichen Output wahr. Die damit verbundenen IT Service Management-Prozesse sind in der Regel eine interne Betrachtung der IT-Organisation.
Die Kunden- und Geschftssicht ist bei der Definition der notwendigen
IT-Untersttzung entscheidend. Die geleisteten IT Services sind der magebliche
Output und bestimmen die Wahrnehmung der IT.

76

2.8 Monitoring und Reporting von SLAs

2.8.2

Service Level Agreements

Das Service Level Management hat die Kundeanforderungen an einen IT


Service aufzunehmen. Diese Anforderungen werden in Service Level Requirements (SLRs, Service Level Anforderungen) dokumentiert.
Auf der Basis dieser Anforderungen wird vom IT Service Provider die
Mglichkeit der Leistungserbringung geprft. Mit dem Kunden werden
daraufhin Verhandlungen gefhrt und es kommt zu einem iterativen Prozess, in dem die Kundenanforderungen auf die zu erbringende Servicequalitt abgestimmt werden. Letztendlich wird zwischen dem Kunden
und dem IT Service Provider eine Vereinbarung getroffen und in einem
Service Level Agreement (SLA) dokumentiert.
Die ITIL Best Practices definieren einen SLA als eine schriftliche Vereinbarung zwischen einem Service-Anbieter und einem Kunden, in der vereinbarte
Service Level fr einen Service dokumentiert sind. (vgl. [OGC, 2006b] und
[OGC, 2007b]):
Ein IT Service stellt die notwendige, ganzheitliche IT-Untersttzung fr einen
Geschftsprozess des internen oder externen Kunden sicher. Die Qualitt eines
IT Service und somit das Ma der gewnschten IT-Untersttzung des Geschftsprozesses werden in einem SLA (Service Level Agreement) dokumentiert.

Zur Absicherung des SLAs werden intern Operational Level Agreements


(OLAs) und extern Lieferantenvertrge (Underpinning Contracts, UCs)
abgeschlossen. Die Struktur und die mglichen Inhalte von SLA, OLA und
UC werden im nchsten Kapitel erlutert.
Sowohl in ITIL, als auch in COBIT wird die Aufgabe der Erstellung und
Pflege der erforderlichen Dokumente, bestehend aus Service Katalog, Service Level Agreement (SLA), Operational Level Agreement (OLA) und
Underpinning Contract (UC) dem Prozess des Service Level Managements
zugewiesen.
COBIT nimmt bei der Definition von Control Objectives und Leistungsindikatoren (KGI, KPI) Bezug auf den Service Katalog, die SLAs, die OLAs
und die UCs. Aber: Anforderungen an deren inhaltliche Gestaltung sind in
COBIT nicht dokumentiert. So weist lediglich das Control Objective
DS1.3 Service Level Agreement darauf hin, dass die Rahmenbedingungen fr Verfgbarkeit, Performance, Verlsslichkeit, Wachstumsfhigkeit, Support-Level, Kontinuittsplanung, Sicherheit und Nachfrage im
SLA zu bercksichtigen sind.
Dagegen umfassen ITIL und die ISO 20000 die Best Practices zu den notwendigen Inhalten von SLAs. Diese Inhalte werden in Kapitel 2.8.5 beschrieben.

77

ITIL und
ISO 20000
enthalten Best
Practices fr
die Inhalte
von SLAs.

2 IT Service Management
Die ITIL Best Practices und die ISO 20000-2 enthalten Empfehlungen fr die inhaltliche Gestaltung der SLAs. Weiterhin sind Anforderungen an deren Messung
sowie an das Reporting beschrieben.

2.8.3

Das Zusammenwirken von SLAs, OLAs und UCs

In einem SLA werden die Geschftsanforderungen an einen IT Service


zwischen dem Kunden und dem IT Service Provider vereinbart. Der Kunde ist der Auftraggeber des IT Service. Der IT-Provider ist der fr die Bereitstellung des IT Service verantwortliche Auftragnehmer.
Die ISO 20000 definiert ein Service Level Agreement (SLA) als written agreement
between a service provider and a customer that documents services and agreed service
levels.

Um die mit dem Kunden vereinbarte IT Servicequalitt dauerhaft sicherstellen zu knnen, bedient sich das Service Level Management weiterer
Absicherungsvertrge wie OLAs (mit internen Erbringungseinheiten) und
UCs (mit externen Lieferanten). Die Summe der vereinbarten OLAs und
UCs sichern die SLAs.
Die folgende Abbildung 28 dient der Erluterung und zeigt, wie zum Beispiel fr einen IT Service Gehaltsabrechnung die Anforderungen an die
Verfgbarkeit in einzelne OLAs und UCs einflieen knnten.

78

2.8 Monitoring und Reporting von SLAs


SLA Gehaltsabrechnung

OLA HR / Server

Leistungsgegenstand:
Beschreibung der
Funktionalitt des IT-Service

Leistungsgegenstand:
Bereitstellung Server fr
Modul SAP-HR

Leistungsumfang: SAP-HR
inkl. Lizenzen fr 25 Benutzer,
Support und Anpassungen

Verfgbarkeit: 99,8% p.W.

Servicezeit: gem.
Betriebskalender
7:00 18:00 Uhr
Verfgbarkeit: 96% p.W. am
Arbeitsplatz
Kontinuitt: max. 2 Stunden
Totalausfall
Lsungszeiten Prio 1: 80% in 2
Stunden
Abbildung 28:

2.8.4

OLA HR / LAN
Leistungsgegenstand:
Bereitstellung LAN
Verfgbarkeit: 99,6% p.W.
UC HR / WAN
Leistungsgegenstand:
Anbindung Niederlassung X
Verfgbarkeit: 99,4% p.W.

Zusammenhang zwischen SLAs, OLAs und UCs

Der Aufbau von SLAs

Es ist wichtig zu betonen, dass die Inhalte und die Struktur der IT Services
und der damit verbundenen SLAs unternehmensspezifisch sind. Es gibt
nicht den SLA, der fr jede Organisation passend ist. Dies vorzugeben
ist nicht die Intention der ITIL Best Practices. ITIL stellt ausdrcklich heraus: ... es ist nicht leicht, generelle Aussagen zu machen, da jede Situation einzigartig ist. (vgl. [OGC, 2006b]).

Die Struktur
der SLAs ist
unternehmens
spezifisch.

Vor dem Aufbau und der inhaltlichen Gestaltung von SLAs gilt es zunchst, die bestehenden Kundenanforderungen aufzunehmen sowie das
existierende Leistungsportfolio, also die bestehenden IT Services zu erfassen und zu strukturieren (vgl. [Victor et al., 2005]).
Erst im Anschluss, das heit wenn die Strukturierung der IT Services vorliegt, sollten die einzelnen SLAs mit den Kunden vereinbart werden. IT
Services entsprechen der Sicht der Kunden bzw. der zu untersttzenden
Geschftsprozesse auf die notwendige IT-Untersttzung. IT Services mssen sich daher ber (bestehende) organisatorische und systemtechnische
Grenzen innerhalb der IT-Organisation hinwegsetzen.

79

IT Services
werden System- und organisationsbergreifend
erbracht.

2 IT Service Management
Die ISO 20000-2 dokumentiert die Vorgehensweise aus Kunden- und
Geschftssicht wie folgt: the customers business needs and budget should be
the defining force for the content, structure and targets of the SLA.
Von entscheidender Bedeutung fr die Definition der IT Services und fr die
Vereinbarung von SLAs, OLAs und UCs ist die Serviceorientierung eines IT Service im Sinne der ITIL-Definition. Die ISO 20000-2 empfiehlt darber hinaus,
dass die Kundenanforderungen nicht nur die Ziele und den Inhalt, sondern auch
die Struktur der SLAs bestimmen sollten.

Im Einklang mit der ISO 20000 empfiehlt ITIL vor der Vereinbarung von
SLAs die notwendige SLA-Struktur zu planen. Hierzu wird in ITIL eine
serviceorientierte und kundenbasierte und eine mehrschichtige SLAStruktur beschrieben.
SLA-Strukturen reduzieren Aufwendungen.

Um die Aufwendungen fr das Monitoring und Reporting zu reduzieren,


bietet eine mehrschichtige SLA-Struktur viele Vorteile (siehe Abbildung
29). Hinzu kommen weitere Vorteile wie zum Beispiel geringere Aufwendungen fr die Aktualisierung und die Reduzierung von Inkonsistenzen.

- Unternehmens-Ebene:
-

Unternehmensweite SLAVereinbarungen
Allgemeine Definitionen
und Regelungen zum
Monitoring

- Kunden-Ebene:
-

Kundenbezogene SLAVereinbarungen

- Unterstes Level:
-

Servicebezogene SLAVereinbarungen
Ausgestaltung des auf
Unternehmens-Ebene
definierten Monitoring

Abbildung 29:

Beispiel fr mehrschichtige SLAs

Mehrschichtige SLAs bilden ein hierarchisches System. Auf der obersten


Ebene werden allgemeine Regelungen getroffen, die fr das gesamte Un-

80

2.8 Monitoring und Reporting von SLAs


ternehmen gltig sind. Damit werden Redundanzen und Widersprche
vermieden, wie zum Beispiel mehrfache, unterschiedliche Definitionen
von Verfgbarkeit. In der nchsten Ebene der SLA-Struktur knnen dann
zum Beispiel bergreifende Vereinbarungen mit den einzelnen Kunden
beschrieben werden, um dann auf der dritten Ebene die einzelnen IT Services zu vereinbaren.
Bei mehrschichtigen SLAs knnen auf der obersten Ebene, der Unternehmens-Ebene, allgemeine Regelungen fr das Monitoring und Reporting
der IT Services vereinbart werden. So kann zum Beispiel beschrieben werden, wie generell die Verfgbarkeit von Applikationen gemessen wird.
Zustzlich kann auch das einzusetzende Messwerkzeug definiert werden.
Auf Ebene der einzelnen IT Services sind dann nur noch die konkreten
Messkriterien, die Messpunkte und die Messtermine mit dem Kunden zu
vereinbaren.

Messwerkzeuge und
einheitliche
Messverfahren sollten
einheitlich
vorgegeben
werden.

Durch diese Struktur wird sichergestellt, dass die SLAs nach einheitlichen
Messverfahren und mit standardisierten Messwerkzeugen gemessen werden. Dies reduziert nicht die Aufwendungen fr die konkreten Messungen,
stellt aber die Vergleichbarkeit der einzelnen IT Services sicher.

2.8.5

Die Inhalte von SLAs

2.8.5.1 Vorgaben / Empfehlungen der ISO 20000


Die ISO 20000-1 beschreibt die Mindestanforderungen an die Dokumentation von IT Services mittels SLAs. So fordert die ISO 20000-1: Der gesamte
Umfang der gelieferten Services mit den zugehrigen Service Levesl und Auslastungs-Kriterien mssen zwischen den Parteien vereinbart und aufgezeichnet
werden oder Jeder gelieferte Service muss in einem oder mehreren SLAs definiert, vereinbart und dokumentiert werden. (vgl. [ISO 20000-1, 2005]).
Vorgaben zur inhaltlichen Gestaltung der SLAs macht die ISO 20000-1
nicht.
Die ISO 20000-1 enthlt Mindestanforderungen an die Verwendung von SLAs.
Im Fokus stehen dabei die Anforderungen an den Prozess des Service Level Managements.

Innerhalb der ISO 20000-2 wird dagegen auf die inhaltliche Gestaltung der
notwendigen Dokumente eingegangen. So sind Best Practices zum Service
Katalog und ein Leitfaden fr die inhaltliche Gestaltung der SLAs dokumentiert. Im Zusammenspiel zwischen Service Katalog und SLA empfiehlt
die ISO 20000-2, eine Referenzierung vom SLA zum Service Katalog aufzubauen.

81

Service Level
und Auslastungs-Kriterien sind zu
vereinbaren
und aufzuzeichnen.

2 IT Service Management
Die ISO 20000-2 empfiehlt die folgenden Inhalte fr einen SLA:

Kurze Beschreibung des Service


Gltigkeitsdauer und / oder Change-Mechanismen
Detaillierte Vollmachten
Kurzbeschreibung der Kommunikation inklusive des Reportings
Nhere Angaben ber Ansprechpartner, die dazu bevollmchtigt
sind, in Notfllen zu handeln und die bei Incidents, Problembehebungen, Recovery und Workarounds mitwirken
Servicezeiten (zum Beispiel 09:00 - 17:00 Uhr), festgelegte kritische
Geschftszeiten (zum Beispiel Wochenenden, gesetzliche Feiertage
und Ferien), Ausnahmen und untersttzter Systembetrieb
Geplante und vereinbarte Unterbrechungen, inklusive festgelegter
Ankndigungsprozedur 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 fr Auswirkungen und Prioritten (Zuordnung)
Eskalations- und Benachrichtigungsprozess
Beschwerdeverfahren
Service-Ziele (Service Targets)
Workload-Begrenzungen, zum Beispiel die Fhigkeit, eine vereinbarte Anzahl von Anwendern / Arbeitsvolumen / Systemdurchsatz
zu untersttzen
bergeordnete Finanzinformationen, zum Beispiel Kostenschlssel
etc.
Notwendige Aktionen im Fall einer Serviceunterbrechung
Organisatorische Ablufe
Begriffsdefinitionen
Untersttzte und zugeordnete Services
Jede Ausnahme zu den angegebenen Bedingungen des SLA

Die ISO 20000-2 dokumentiert international anerkannte Best Practices fr das IT


Service Management. Eine Organisation ist daher gut beraten, die in der
ISO 20000-2 beschriebenen Inhalte fr ein Service Level Agreement (SLA) umzusetzen.

Die ISO 20000-2 beinhaltet die Definition von Service-Zielen (Service


Targets). Service-Ziele machen die vereinbarten Ziele fr einen Service
Level messbar. Mgliche Service-Ziele knnten zum Beispiel eine Verfgbarkeit von x % pro Woche oder eine Erstlsungsquote von x % pro
Woche sein.

82

2.8 Monitoring und Reporting von SLAs


Die Einhaltung von Service Level und SLAs wird mittels vereinbarter ServiceZiele definiert, berwacht und berichtet.

Zur Definition der Service-Ziele empfiehlt die ISO 20000-2: The targets,
against which the delivered service should be measured, should be defined from a
customer perspective. (vgl. [ISO 20000-2, 2005]). Daraus resultiert die Anforderung, die SLAs und insbesondere die Service Level und Service-Ziele
in einer Sprache zu verfassen, die der Kunde versteht und die seiner Perspektive entspricht. So sollten zum Beispiel in einem SLA Begriffe wie
Buchungsvorgnge und Anzahl gespeicherter Artikel verwendet werden. Messgren wie CPU-Auslastung oder Datenbankgre entsprechen dagegen in der Regel nicht der Kundenperspektive und sind zu vermeiden.

Service-Ziele
sind aus der
Kundenperspektive zu
definieren.

Es knnen nicht alle Geschfts- und Kundenanforderungen in einem SLA


vereinbart werden. Insbesondere wenn innerhalb einer Organisation noch
keine Erfahrungen mit SLAs vorliegen, sollte man sich zunchst auf die
wichtigsten Aspekte begrenzen, Erfahrungen sammeln und diese Erfahrungen bei der nchsten Version umsetzen. Hinzu kommt, dass SLAs
verwaltet werden mssen. Die Einhaltung muss gemessen und berichtet
werden. Diese Aktivitten fhren zu Aufwendungen und Kosten fr den
IT Service. Die ISO 20000-2 empfiehlt daher: The SLAs should include only
an appropriate subset of the targets to focus attention on the most important aspects of the service.

Konzentration
auf die wesentlichen
Service Level

In einem SLA sollte eine angemessene Anzahl der wichtigsten Aspekte eines IT
Service enthalten sein.

2.8.5.2 Empfehlungen der ITIL Best Practices


Die ITIL Best Practices zur Gestaltung von SLAs sind dem Prozess Service
Level Management zu entnehmen.
Die Inhalte der ISO 20000 sind an den Prozessbeschreibungen der ITIL
Best Practices ausgerichtet und ergnzen diese komplementr (zum Teil
wurden die Texte von den gleichen Autoren verfasst). Daher sind die in
ITIL und die in der ISO 20000-2 dokumentierten Empfehlungen weitestgehend deckungsgleich. Allerdings sind die Beschreibungen in den ITIL Best
Practices umfangreicher gegenber denen aus der ISO 20000-2.
ITIL definiert die gebruchlichen Inhalte eines SLA wie folgt:
Einleitung
- Parteien der Vereinbarung
- Bezeichnung und Kurzbeschreibung der Vereinbarung
- Unterzeichnende

83

2 IT Service Management
-

84

Datumsangaben: Anfang, Ende, Review


Geltungsbereich der Vereinbarung, was wird zugesichert
und was ist ausgenommen
- Pflichten des IT Service Providers und des Kunden
- Beschreibung des zugesicherten IT Service
Service-Zeiten
- Die Zeiten, in denen der Service gewhnlich bentigt wird
- Vereinbarungen fr die Anforderung von ServiceErweiterungen, inklusive der erforderlichen Mitteilungszeiten
- Besondere Zeiten (zum Beispiel Feiertage)
- Service-Kalender
Verfgbarkeit
- Verfgbarkeits-Ziele whrend der vereinbarten Zeiten
- Normalerweise als Prozentsatz definiert
- Festgeschriebene Messperioden und -verfahren
Zuverlssigkeit
- Wird blicherweise als Anzahl der Service-Unterbrechungen oder als MTBF (Mean Time Between Failures) bzw. als
MTBSI (Mean Time Between System Incidents) ausgedrckt
Support
- Support-Zeiten (sofern diese nicht mit den Service-Zeiten
identisch sind)
- Vereinbarungen fr die Anforderung von SupportErweiterungen, inklusive der erforderlichen Mitteilungszeiten
- Besondere Zeiten (zum Beispiel Feiertage)
- Ziel fr die Reaktionszeit
- Ziel fr die Lsungszeiten, abgestuft nach den Prioritten
der Incidents
Durchsatz
- Angaben des voraussichtlichen Datenvolumens und
Durchsatzaktivitten (zum Beispiel Anzahl der Transaktionen, die Anzahl der gleichzeitig aktiven Anwender)
Antwortzeitverhalten
- Zielvorgaben fr durchschnittliche oder maximale Antwortzeiten am Arbeitsplatz (zum Beispiel 95 % innerhalb
von 2 Sekunden)
Batch-Bearbeitungszeiten
- Zeiten fr die Lieferung von Input und Output und Ort
fr die Lieferung des Outputs

2.8 Monitoring und Reporting von SLAs


Changes
- Zielvorgaben fr die Genehmigung, Bearbeitung und
Implementierung von RFCs; blicherweise bezogen auf
Kategorie oder Dringlichkeit/Prioritt
Kontinuitt und Sicherheit der IT Services
- Eine kurze Benennung des IT Service Continuity Plans
und wie er aktiviert wird
- Ausfhrungen zu Sicherheitsfragen, insbesondere Verantwortungen des Kunden (zum Beispiel Backup von nicht
angebundenen PCs, Passwort-nderungen)
- Einzelheiten zu verminderten oder genderten ServiceZielen fr den Katastrophenfall (falls kein separates SLA
fr solche Situationen existiert)
Leistungsverrechnung
- Einzelheiten zum Verteilungsschlssel und zu den Zeitrumen der Leistungsverrechnung (sofern die Leistungen
in Rechnung gestellt werden)
Service-Berichte und Reviews
- Der Inhalt, die Hufigkeit und Verteilung der Service-Berichte
- Die Hufigkeit der Service-Review Besprechungen
Leistungs-Anreize / Strafen
- Einzelheiten zu Vereinbarungen ber finanzielle Anreize
oder Strafen in Abhngigkeit der Service Level

2.8.6

Monitoring und Reporting von SLAs, OLAs und UCs

Der Prozess Service Level Management ist nicht nur fr die Vereinbarung
der IT Services mit den Kunden und der Absicherung dieser SLAs durch
entsprechende OLAs und UCs verantwortlich. Weiterhin gehren auch die
Aufgaben des Monitorings und des Reporting in die Verantwortung des
Service Level Managements. Dabei werden die SLAs und die damit in
Verbindung stehenden OLAs und UCs gemessen und die Ergebnisse den
jeweiligen Organisationsbereichen berichtet.
In der ISO 20000-1 heit es hierzu: Service Level sind zu berwachen und
gegenber den vereinbarten Zielen (Service Targets) zu berichten. (vgl.
[ISO 20000-1, 2005]).
Die in den SLAs, OLAs und UCs spezifizierten Vereinbarungen sind hinsichtlich
der Zielerreichung vollstndig zu berwachen und die Ergebnisse sind zu berichten.

Um das Monitoring der SLAs, OLAs und UCs sicherzustellen, mssen


smtliche beschriebenen Service Level messbar sein (siehe Kapitel 2.9.5.1

85

2 IT Service Management
und 2.9.5.2). Werden im SLA zum Beispiel Regelungen fr Changes, wie
etwa Genehmigungszeiten getroffen, so sind diese Bearbeitungszeiten zu
messen und zu berichten.
In einem SLA werden Service-Ziele fr einen IT Service vereinbart und
sind im Rahmen des Monitorings zu messen. Um die daraus resultierenden Anforderungen an die Messbarkeit zu verstehen, erfolgt hier nochmals die Darstellung der Kundensicht auf den IT Service. Der Kunde bentigt die IT Services zur Durchfhrung seiner geschftlichen Aktivitten
dort, wo die Aufgaben durchzufhren sind. Er erwartet, dass zum Beispiel
die Finanzverwaltungsaktivitten am Arbeitsplatz seines Mitarbeiters
durchgefhrt werden knnen. In der Regel ist dieser Arbeitsplatz der PC
des Mitarbeiters.
Service Level
sind dort zu
messen, wo
der Service
wahrgenommen wird.

Diese Anforderung mag an dieser Stelle trivial und selbstverstndlich


klingen, aber welcher IT Service Provider garantiert dem Kunden heute
die Bereitstellung des IT Service mit garantierten Service Level am PCArbeitsplatz?
Den Kunden interessiert es nicht, ob die Applikation am Server verfgbar
ist. Sie muss am Arbeitsplatz seines Mitarbeiters verfgbar und nutzbar
sein. Welche verschiedenen IT-Systeme dazu betrieben werden mssen
und ineinander greifen, sollte fr den Kunden nicht von Belang sein. Der
Kunde bentigt eine ganzheitliche IT-Untersttzung zur Durchfhrung
seiner Aktivitten und nicht ein Puzzle von Einzelvereinbarungen.
Es ist sinnlos, Service Level und Service-Ziele zu definieren, wenn diese
nicht berprfbar sind. So ist zum Beispiel die Zusicherung eines Service
Level mit dem Ziel einer Verfgbarkeit von 95 % berflssig, wenn die
Verfgbarkeit nicht gemessen werden kann. Daher muss die IT berlegen,
wie geeignete Messungen vorgenommen werden knnen. Zum Beispiel
knnten Messroboter eingesetzt werden, die an vereinbarten Lokationen
und zu vereinbarten Zeiten die Verfgbarkeit des IT Service messen. Die
festgelegten Messverfahren und Messkriterien sind dem Kunden zu erlutern und als Anlage zum SLA zu vereinbaren.
Ist ein Service Level nicht messbar, stellt sich die Frage, ob dieser Service
Level berhaupt wichtig ist. Wre der Service Level wichtig, so wrden
auch Anstrengungen unternommen diese Messung sicherzustellen bzw.
den Service Level so zu spezifizieren, dass die Messung mglich 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, mgen noch keine Probleme auftreten. Aber wenn der Kunde unzufrieden ist

86

2.8 Monitoring und Reporting von SLAs


und den Nachweis der Einhaltung der Service-Ziele einfordert, ist der
Streit vorprogrammiert.
Bei der Messbarkeit von SLAs darf nicht auer Acht gelassen werden, dass
Kunden und Anwender die IT in der Regel nur dann bemerken, wenn sie
ausfllt. Diese Ausflle bestimmen daher hufig das Erscheinungsbild der
IT. Durch das Monitoring und Reporting kann der IT Service Provider
dazu beigetragen, diese negative Kundenwahrnehmung der IT zu verndern. Das Monitoring und Reporting der Service Level und der Nachweis
der Einhaltung der Service-Ziele tragen zur Steigerung der Kundenzufriedenheit bei.
Das Monitoring und das Reporting der Service Level und der eingehaltenen Service-Ziele muss im Eigeninteresse des IT Service Providers liegen. Daher sind die
SLAs, OLAs und UCs eindeutig zu formulieren, drfen keine mehrdeutigen Interpretationen zulassen und sind gegenber den festgelegten Service-Zielen zu
messen.

In der ISO 20000-1 wird aber nicht nur verlangt, dass die Service Level zu
messen und gegenber den Service-Zielen zu berichten sind, sondern die
Forderung wird fortgefhrt: showing both current and trend information.
The reasons for non-conformance shall be reported and reviewed. (vgl.
[ISO 20000-1, 2005]).
Aus dieser Empfehlung ergeben sich weitere Anforderungen an die Aufzeichnung und das Reporting von SLAs.
Die erreichten Service Level sind chronologisch aufzuzeichnen und im
Rahmen der Service-Berichte als Trend darzustellen. Die Qualitt eines IT
Service kann so an der Einhaltung der definierten Service-Ziele und anhand des Trends bewertet werden. Die Trenddarstellung macht es fr die
Beteiligten offensichtlich, ob die Qualitt gleich bleibend, steigend oder
unter Umstnden sinkend ist.
Die ISO 20000-1 erfordert eine Trenddarstellung der erreichten Service Level
gegenber den Service-Zielen.

Darber hinaus fordert die ISO 20000-1 eine Darstellung der Ursachen,
wenn die vereinbarten Service-Ziele nicht erreicht werden. Diese Ursachen
sind im Service-Bericht darzustellen und zu bewerten.
Eine weitere Anforderung der ISO 20000-1 besteht in der Darstellung und Bewertung der Ursachen fr die Nichterreichung ( Unterschreitung) der festgelegten Service-Ziele.

87

Die ISO 20000


verlangt auch
die Darstellung von
Trends.

2 IT Service Management

2.8.7

Abgrenzung der Kennzahlen

Die SLAs mit den Service Level und den entsprechenden Service-Zielen
definieren die vereinbarte IT-Untersttzung fr die Aktivitten und Geschftsprozesse einer Organisation. Sie stellen die Auensicht auf die ITOrganisation dar. Das Kundeninteresse besteht in der Einhaltung der zugesicherten Service-Ziele. Eine Betrachtung der IT-internen Prozesse steht
nicht im Fokus des Kunden.
Im Auenverhltnis berichtet die IT-Organisation ber die Einhaltung der definierten Service Level und der Auslegungskriterien. Die Einhaltung dieser Kriterien und des Trends sind vom IT Service Provider nachzuweisen. Hierzu werden
entsprechende Service-Ziele im SLA definiert.

Innerhalb der IT ist ein Management der IT Service Management-Prozesse


erforderlich. Mittels Kennzahlen wird berprft, ob die Prozesse die definierten Ziele hinsichtlich der Effektivitt und Effizienz erreichen. So wird
zum Beispiel die Effektivitt des Prozesses Service Level Management
mittels der Kennzahl Anteil eingehaltener Service Level gemessen.
Im Innenverhltnis bentigt das Management Kennzahlen, um die IT-Prozesse
zu steuern. Hierzu dienen die jeweiligen Key Goal Indicators (KGIs) und die Key
Performance Indicators (KPIs).

2.9 Integrationsinstrument: Balanced Scorecard

Die Balanced
Scorecard ist
ein Kennzahlen- und
ManagementSystem.

Die von Robert S. Kaplan und David P. Norton Anfang der 90er Jahre
entwickelte Balanced Scorecard 4 ist nicht nur ein Messsystem, sondern
vielmehr ein exzellentes Management- und Steuerungssystem. Sie kann in
unterschiedlichen Unternehmensbereichen eingesetzt werden. Nach unserer Erfahrung eignet sie sich besonders gut als Management- und Reporting-Instrument fr IT-Organisationen bzw. deren Bereiche.
Wir verwenden die Balanced Scorecard als Integrationsinstrument, das in
der Lage ist, Kennzahlen aus unterschiedlichen Systemen zusammenzufhren, zu verknpfen und fr entsprechende Adressatenkreise geeignet
darzustellen. In den Projekten, die wir in IT-Organisationen unterschiedlicher Gren und Branchen durchgefhrt haben, hat sich immer wieder
gezeigt, dass es durch Anwendung der Balanced Scorecard mglich ist, die
Lage der IT in ihrem jeweiligen Geschftsumfeld realittsnah, transparent
und korrekt darzustellen. Richtig eingesetzt, hlt die Balanced Scorecard
damit nicht nur das operative IT-Geschft sondern insbesondere die stra-

88

Hufig abgekrzt als BSC, fr den IT-Bereich als IT-BSC.

2.9 Integrationsinstrument: Balanced Scorecard


tegische Ausrichtung der IT-Organisation bis hin zum IT-Marketing in der
Balance.

2.9.1

Kernideen

Die Kernideen der Arbeiten von Robert S. Kaplan und David P. Norton
sind einfach und faszinierend. Liest man die ersten Seiten aus [Kaplan et
al., 1996], fllt 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: Im surprised to see you are operating the plane with only
a single instrument. What does it measure?
Answer: Air speed. Im really working on air speed this flight.
Question: Thats good. Air speed certainly seems important. But
what about altitude. Wouldnt an altimeter be helpful?
Answer: I worked on altitude for the last few flights and Ive gotten
pretty good on it. Now I have to concentrate on proper air speed.
Question: But I noticed you dont even have a fuel gauge. Wouldnt
that be useful?
Answer: You are right: fuel is significant, but I cant concentrate on
doing too many things well at the same time. So, on this flight Im
concentrating on air speed.
-- Zitatende -Die Frage, ob man nach diesem Gesprch hier mitfliegen wrde, lsst sich
leicht beantworten: Unabhngig vom Knnen des Piloten und unabhngig
von der Qualitt des Flugzeugs bleibt der fade Nachgeschmack, dass eine
einzige Kennzahl, dir zur Steuerung der Maschine reported wird, nicht
ausreicht selbst wenn der Pilot mit dieser Methode in der Vergangenheit
gute Erfahrungen gemacht hat.
Ein Ansatzpunkt der Balanced Scorecard ist gerade die Kritik an der tradierten strategischen Unternehmensfhrung, die sich im Wesentlichen an
finanziellen Kennzahlen (z. B. Return on Investment oder Eigenkapitalrentabilitt) orientiert. Diese Kennzahlen werden als eindimensional und
vergangenheitsorientiert kritisiert. Sie wrden auerdem zu einer kurzfristig orientierten Investitionspolitik fhren, da Zukunftsmanahmen, z. B.
im Bereich Forschung und Entwicklung, sich kurzfristig in der Erfolgsrechnung nur auf der Kostenseite niederschlagen.
Die Balanced Scorecard in der von Kaplan und Norton vorgestellten Form
ergnzt daher die traditionelle finanzielle Perspektive um drei weitere

89

2 IT Service Management
Perspektiven. Auf diese Weise erhlt man ein 4-dimensionales Modell,
dass ein und dasselbe Objekt, z. B. einen Unternehmensteilbereich, aus
verschiedenen Blickwinkeln beleuchtet und bewertet.
Die von Kaplan und Norton vorgeschlagene Balanced Scorecard ist 4-dimensional. Sie enthlt die 4 Perspektiven: Finanzen, Kunden, Prozesse5 und Potenziale6.
Die Balanced
Scorecard ist
ein mehrdimensionales
und ausgewogenes Zielsystem.

Neben der Mehrdimensionalitt des Zielsystems basiert die Balanced Scorecard auf einer weiteren Idee, die sich leicht im tglichen Leben wiederfinden lsst. Der Begriff balanced sagt aus, dass die Perspektiven ausgeglichen bzw. ausgewogen sein mssen. Bemht man weitere wrtliche
bersetzungen des Begriffs, so bietet sich die technische Interpretation
ausgewuchtet an, die verdeutlicht, dass das Gesamtsystem der Scorecard nur dann Sinn macht, wenn die einzelnen Komponenten richtig auf
einander abgestimmt sind.
Nach dem Prinzip der Balanced Scorecard macht es keinen Sinn, eine Perspektive in den Vordergrund zu schieben und dafr andere zu vernachlssigen. Es handelt sich um ein Zielsystem, in dem die Mehrdimensionalitt
nicht nur als Option enthalten ist sondern explizit gefordert und garantiert
wird.
Wendet man die Balanced Scorecard auf den IT-Bereich an, so hat dies eine gravierende Konsequenz: Die alleinige Bewertung der IT anhand von Kostenzahlen
ist nicht mehr state of the art.

Es geht nicht
um kurzfristige Gewinne
sondern um
Kontinuitt.

Die Balanced Scorecard bercksichtigt insbesondere strategische Aspekte.


Ein wesentliches Ziel ist in diesem Zusammenhang die Garantie des mittel- und langfristigen Erfolgs der zu betrachtenden Unternehmenseinheit.
Es geht damit weniger um kurzfristig realisierbare Unternehmensgewinne
sondern mehr um Kontinuittsgesichtspunkte.
Die Balanced Scorecard versucht, Wertschpfungsprozesse mit dem richtigen
Augenma zu bewerten und herauszufinden, welche Faktoren fr den langfristigen Erfolg des Unternehmens ausschlaggebend sind.

Die Balanced
Scorecard ist
ein top downInstrument
zur Strategieumsetzung.

Wichtigstes Ziel der Balanced Scorecard ist die Umsetzung von Unternehmenszielen auf allen Ebenen. Dies wird dadurch erreicht, dass sich, ausgehend von der Vision, die Strategie des Unternehmens ableiten lsst und
sich daraus konkrete Ziele definieren lassen.
Der Aspekt der Vision und Strategie steht damit im Mittelpunkt einer
jeden Balanced Scorecard. In [Kaplan et al., 1996] wird dies mit den
5

Die Prozessperspektive wird im Original Interne Geschftsprozesse genannt.

Die Potenzialperspektive wird im Original Lernen und Entwicklung genannt.

90

2.9 Integrationsinstrument: Balanced Scorecard


Schlagworten translating strategy into action und measures that drive
(future) performance herausgestellt.
Um den Kern von Vision und Strategie ranken sich vier Betrachtungsweisen (vgl. Abbildung 30):
Finanzielle Ziele: Wie soll das Unternehmen gegenber Teilhabern
und Kapitalgebern auftreten, um finanziellen Erfolg zu erreichen?
Kundenbezogene Ziele: Wie soll das Unternehmen gegenber Kunden auftreten, um seine Vision zu verwirklichen?
Prozessbezogene Ziele: In welchen Geschftsprozessen muss das
Unternehmen an der Spitze stehen, um seine Teilhaber und Kunden
zu befriedigen?
Mitarbeiter- und Innovationsbezogene Ziele: Wie kann das Unternehmen Vernderungs- und Wachstumspotenziale frdern, um seine Vision zu verwirklichen?
Finanzperspektive
Ziel

Kenn- Vorzahl gabe

Manahme

Kundenperspektive
Ziel

Kennzahl

Vorgabe

Prozessperspektive

Vision
und
Strategie

Manahme

Ziel

Kenn- Vorzahl gabe

Manahme

Protenzialperspektive
Ziel

Abbildung 30:

Kenn- Vor- Mazahl gabe nahme

Allgemeine Balanced Scorecard

91

2 IT Service Management
Diese Ziele lassen sich beispielsweise folgendermaen detaillieren:7

Finanzielle Ziele
Kostenreduktion
Strategische Ausrichtung von Investitionen
Umsatzsteigerung

Kundenbezogene Ziele
Gewinnung neuer Kundensegmente
Umsatzerhhung pro Kunde
Festigung der Kundentreue

Prozessbezogene Ziele
Lean Management realisieren
Best of breed Technologien einsetzen
Grundideen des Business Process Re-engineering umsetzen

Mitarbeiter- und Innovationsbezogene Ziele


Erhhung der Mitarbeiterzufriedenheit
Etablieren eines Unternehmenswerte-Systems
Durchfhrung von Qualifikationsmanahmen
Die Verknpfung der Unternehmensstrategie und der operativen Manahmenplanung erfolgt ber Ursache-Wirkungsketten (siehe Abbildung
31).
In der Praxis knnen diese Wirkungszusammenhnge sehr kompliziert, ja
sogar konfliktr sein.
In [Kaplan et al., 1996] sind die Schritte dargestellt, die notwendig sind,
um ein Balanced Scorecard Konzept zu erstellen. Dabei sind 10 Teilaufgaben zu lsen, ausgehend von Aufgabe 1: Select the appropriate organizational
unit bis zu Aufgabe 10: Finalize the implementation plan.
Es sollen nicht mehr als 25 Kennzahlen (4 bis 7 je Perspektive) verwendet
werden. Die Kennzahlen sollen Vergangenheit, Gegenwart und Zukunft
messen. Vor allen Dingen sollen die Kennzahlen strategisch dimensioniert
sein, denn das Konzept der Balanced Scorecard dient der beschleunigten
Strategieumsetzung.

92

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

2.9 Integrationsinstrument: Balanced Scorecard

Finanzperspektive

Kundenperspektive

Prozessperspektive

Potentialperspektive
Abbildung 31:

Finanzielles Ergebnis
(Gewinn, Rentabilitt, ...)
Kundenzufriedenheit
Kosten der
Prozesse

Kundentreue

Qualitt der
Prozesse

Qualifizierte
Mitarbeiter

Geschwindigkeit
der Prozesse

Motivierte
Mitarbeiter

Ursache-Wirkungskette

Dass sich die Balanced Scorecard immer aus den Unternehmenszielen und
der Strategie ableitet, verdeutlicht Abbildung 32 aus [Preiner, 2006].

Unternehmensziele
Strategien

Kundenperspektive
Finanzperspektive

interne Prozessperspektive
Lern- & Entwicklungsperspektive

operative Umsetzung
Erfolgskontrolle
Abbildung 32:

Stellung der BSC im Unternehmensplanungsprozess

93

2 IT Service Management

2.9.2

Anwendung auf den IT-Bereich

Die Anwendung der Balanced Scorecard Methode in IT-Bereichen ist inzwischen weitgehend akzeptiert. Der Nutzen im Hinblick auf Performance-Steigerung und Strategie-berprfung liegt auf der Hand. Es geht
darum, die IT-Organisation als Ganzes ber ihre verschiedenen Funktionen hinweg zu steuern. Es geht darum, dass dies konform mit der ITStrategie geschieht und darum, dass diese aus der Geschftsstrategie abgeleitet ist.
So ist es nicht verwunderlich, dass die Balanced Scorecard als empfohlenes
Werkzeug explizit Eingang in ITIL V3 gefunden hat, da ITIL V3 gerade die
Verzahnung von Business und IT sowie der Beitrag der IT zur Wertschpfung des Unternehmens am Herzen liegen.
Auch ITIL V3 liefert natrlich keine Balanced Scorecard fr die IT, die eins
zu eins in einer IT-Organisation einsetzbar ist und damit auch kein
Kennzahlensystem, das diesen Zweck erfllt. Nach [Ktz, 2007] kann es
wegen der Vielzahl der Steuerungsobjekte in der IT und Verschiedenheit
der Rahmenbedingungen ein Standard-Kennzahlensystem nicht geben ...
Umfang und Ausprgungen mssen dann im konkreten Fall spezifisch
erarbeitet werden.
ITIL V3 kommt jedoch mit seinem erweiterten und modifizierten Prozessmodell dem Ziel der Vereinheitlichung von IT Service-Prozessen8 einen gewaltigen Schritt nher. Dies wird zumindest zu einer weiteren Vereinheitlichung von IT-Kennzahlensystemen fhren.
ITIL V3 schlgt in Anlehnung an Kaplan und Norton vier Perspektiven fr
eine IT Balanced Scorecard vor (vgl. [OGC, 2007e]):
-- Zitatanfang --

Financial: As customers how do we view the costs of IT provision?


Customer: What do we as customers expect of IT provision?
Innovation: Does our IT infrastructure enable us to continue to improve the business?
Internal: What must our IT providers (internally) excel at?
-- Zitatende --

Die Grundidee von ITIL V3 ist richtig und besttigt unsere Arbeiten in
vielen Projekten, in denen es darum ging, Kennzahlensysteme zur Steuerung und zum Reporting einzusetzen:

94

Hier ist insbesondere die Vereinheitlichung im Sinne der Etablierung eines


allgemein akzeptierten Sprachstandards gemeint.

2.9 Integrationsinstrument: Balanced Scorecard


Es gibt viele Mglichkeiten, Perspektiven fr eine IT Balanced Scorecard zu definieren.

Allerdings wird sich in der Praxis beweisen mssen, ob die in ITIL V3


genannten vier Perspektiven fr die IT die geeigneten sind und ob es nicht
mehr oder weniger als vier sind.

2.9.3

Ausprgungen der Balanced Scorecard

Mit der Fragestellung, was die geeigneten Perspektiven der Balanced Scorecard fr den IT-Bereich sind und welche Kennzahlen man fr jede dieser
Perspektiven erhebt, haben sich einige Anstze beschftigt.
In der lesenswerten Masterarbeit von Jakob Bung werden einige dieser
Anstze gegenbergestellt [Bung, 2006]. Wir gehen hier nicht auf die Details ein, sondern geben das Ergebnis in Form einer Tabelle an (siehe folgende Seite, in Anlehnung an [Bung, 2006], Seite 27).
Die Gegenberstellung der verschiedenen Anstze zeigt, dass es schwerfllt, einen allgemein gltigen Ansatz zur Strukturierung der Perspektiven
einer Balanced Scorecard anzugeben. Es fllt auf, dass es keinen Sprachstandard gibt.
Mchte man in der Praxis eine Balanced Scorecard fr den IT-Bereich entwickeln9, so bietet es sich an, das Beste aus allen Welten zu nehmen. Dies
verdeutlichen wir spter in unserem Kennzahlenmodell und in den Praxisbeispielen.

Wir sprechen hier immer von einer (!) Balanced Scorecard, um den Sprachgebrauch einfach zu halten. Fr IT-Bereiche knnen auch mehrere Balanced
Scorecards existieren, die gegebenenfalls zusammenhngen.

95

2 IT Service Management

Entwicklungsstufen zur IT Balanced Scorecard

Ansatz
von

Perspektiven

Jahr

Anmerkung

Kaplan
und
Norton

1996

Kein expliziter Bezug


zur IT.

Van
Grembergen
und
Saull

Beitrag zum Kerngeschft


Kundenorientierung
Operative Leistungen
Zukunftsorientierung

2001

Die Kundenorientierung
wird beibehalten, drei
neue Perspektiven werden vorgeschlagen, insb.
die Bestimmung des
Added Values der IT.

Ktz

Finanzmanagement
Kundenmanagement
Prozess-Management
Innovationsmanagement
Mitarbeitermanagement
Lieferantenmanagement

2003

Zustzlich wird die Lieferantenperspektive


eingefhrt. Die Potenzialperspektive wird in
Mitarbeiter- und Innovationsmanagement aufgeteilt.

Wiggers,
Kok und
de Boerde Wit

Finanzen
Kunden
Geschftsprozesse
Lernen u. Entwicklung

2004

Enthlt die gleichen


Perspektiven wie Kaplan
et al., diese werden allerdings inhaltlich an die
IT angepasst.

SchmidKleemann

Unternehmensbeitrag
Kunden
IT-Leistungserstellung
IT-Einsatz
Zukunft

2004

Auch hier der Versuch,


den Wertbeitrag der IT
zu bestimmen. Die Zukunftsperspektive und
der IT-Einsatz leiten sich
aus der Potenzialperspektive ab.

ITIL 2

Finanzen
Kunden
Interne Prozesse
Innovation (bzw. Lernen
und Entwicklung)

2000
und
2007

4 Perspektiven, die mit


denen der Original BSC
bereinstimmen. Die
Beschreibung der Perspektiven ist in V 3 wesentlich differenzierter
als in V 2.

und
ITIL V3

96

Finanzen
Kunden
Geschftsprozesse
Lernen u. Entwicklung

2.10 Konsequenzen

2.10 Konsequenzen
Die Auswahl der richtigen Kennzahlen ist in der Praxis ein schwieriger
und mehrstufiger Prozess. Die Fragestellung, welcher Ansatz10 der geeignete zum Aufbau eines Kennzahlensystems ist, fhrt im Allgemeinen nicht
zum Ziel. Es geht vielmehr darum, herauszufinden, wie verschiedene
Komponenten der Best Practices als Puzzle zusammengefgt werden knnen, um das bestmgliche durchgngige Kennzahlensystem fr die jeweilige Organisation aufzubauen.
ITIL fhrt 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 Fhigkeiten
der eigenen Organisation.

Kennzahlen (KGIs und KPIs) und der Aufbau eines Kennzahlensystems


sind kein Selbstzweck. Die Kennzahlen sind nicht zu definieren und zu
berichten, weil COBIT und ITIL entsprechende KPIs bzw. KGIs beinhalten.
Es geht auch nicht darum diese Kennzahlen zu definieren, weil es die
ISO 20000 verlangt. COBIT und ITIL empfehlen bzw. die ISO 20000 verlangt vielmehr die Definitionen von Kennzahlen fr jeden IT Service Management-Prozess, weil die Kennzahlen unentbehrliche Informationen fr
das Management von Prozessen darstellen. Das Prozess-Management
(Service Manager, Prozess Owner und Prozess Manager) und das gesamte
IT-Management mssen diese Kennzahlen als Fhrungsinstrument verstehen und dieses Werkzeug aktiv nutzen.
Ziel des Prozess-Managements ist es, die Prozesse so zu gestalten und zu
steuern, dass die definierten Ziele erreicht werden. Die Kennzahlen liefern
dem gesamten Management die notwendigen Informationen darber, ob
die zuvor definierten Prozess-Ziele erreicht werden. Demzufolge mssen
sich die Kennzahlen an den Prozesszielen ausrichten.
Voraussetzung fr die Definition von Kennzahlen sind definierte Ziele fr die
jeweiligen IT Service Management-Prozesse.

Die beschriebenen Best Practices sind daher als Guidelines fr mgliche


Kennzahlen zu verstehen. Ihre Nutzung oder die gegebenenfalls notwendige Definition ergnzender und anderer Kennzahlen muss immer in Bezug auf die spezifischen Prozess-Ziele einer IT-Organisation erfolgen.

10

Beispielsweise ITIL oder COBIT, aber auch andere.

97

Kennzahlen
sind fr ein
wirksames
ProzessManagement
unabdingbar.

2 IT Service Management
Die in ITIL und COBIT spezifizierten KGIs und KPIs stellen kein unumstliches
Dogma dar. Sie sind Best Practice Empfehlungen und liefern einen Input fr die
Definition von Kennzahlen. Es empfiehlt sich, die in ITIL und COBIT dokumentierten KPIs und KGIs zu bercksichtigen. Sie sollten aber grundstzlich hinsichtlich ihrer Anwendbarkeit fr die jeweilige IT-Organisation bzw. fr die Prozessziele kritisch hinterfragt und nicht ungeprft bernommen werden. Bei Bedarf ist die Definition abweichender oder zustzlicher Kennzahlen notwendig.

Bei der Definition von KGIs und KPIs ist auch zu prfen, ob die notwendigen Informationen vorliegen, mit welchem Aufwand die Kennzahlen gewonnen bzw. generiert werden knnen und welche Datenqualitt die
Ausgangsinformationen haben.
Werden COBIT, ITIL, ISO 20000 und die BSC gem ihres konzeptionellen
Ansatzes als Best Practice verstanden und wird die groe berstimmung
der IT Service Management-Prozesse zwischen COBIT und ITIL erkannt
(vgl. [Kurth, 2006]), so knnen diese Anstze hinsichtlich ihrer Vorteile
und Nutzungsmglichkeit 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 Anstze zu verbinden.
Es gilt, die
jeweiligen
Strken von
ITIL und
COBIT zu
nutzen.

COBIT und ITIL haben aufgrund ihrer Entwicklungsgeschichte und Betrachtungsbereiche unterschiedliche Strken und Schwchen. Es gilt, die
jeweiligen Vorteile beider Best Practices zu nutzen. Eine Festlegung auf
einen der Best Practice-Anstze ignoriert die Strken des anderen Ansatzes
und ist nicht zielfhrend.
Werden die IT-Ziele aus der BSC abgeleitet, so knnen die Prozessziele
und die damit in Verbindung stehenden Kennzahlen in die BSC integriert
werden. Damit erhlt eine Organisation ein durchgngiges Kennzahlensystem.
ITIL, ISO 20000 und COBIT sind als Bausteine fr ein bergreifendes Steuerungssystem zu verstehen. Die jeweiligen Strken der einzelnen Best Practices knnen
so optimal fr die eigene Organisation genutzt werden. In einem durchgngigen
Managementsystem knnen die Prozess-Ziele aus der BSC abgeleitet und mit
Best Practices KPIs/KGIs aus ITIL und COBIT hinterlegt werden.

98

2.10 Konsequenzen

Eine IT
Balanced
Scorecard
kann verschiedene
Anstze
integrieren.

ITIL

ISO 20000

COBIT

IT-BSC

Prozessbeschreibung

Detaillierte
(generische)
Prozessbeschreibungen

Enthlt keine
Prozessbeschreibungen,
sondern Mindestanforderungen an die
ITSM-Prozesse

Enthlt
keine detaillierten Prozessbeschreibungen

Enthlt keine
Prozessbeschreibungen

Bekanntheitsgrad

Seit Mitte der


80er Jahre
nachhaltig
steigende
Bekanntheit
und Beliebtheit

Erfhrt zunehmende Bedeutung, insbesondere fr IT


Service Provider

Bekanntheitsgrad
weiter steigend, insbesondere
durch SOX

Bekanntheitsgrad weiter
steigend

Anerkennung

ITIL Zertifizierung relevant


bei Stellenbesetzung; noch
verlangte
ITIL Konformitt wird
durch
ISO 20000
abgelst

Als internationaler Standard


weltweit anerkannt, einzige
Mglichkeit
einer Zertifizierung

In den USA
bei Wirtschaftsprfern weit
verbreitet
und zunehmend auch
in Europa

Weltweit anerkannter Managementansatz zur


Strategieumsetzung

Templates

Enthlt Best
Practices fr
SLA, RFC,
IncidentRecord etc.

Enthlt Best
Practices fr
SLA-Inhalte

Enthlt Best
Practices fr
IT-Prozesse

Enthlt Best
Practices fr
Kennzahlensysteme

Kennzahlen

Schwache
generische
Beschreibung
der ProzessKennzahlen

Enthlt Anforderungen an
Vorhandensein
von Kennzahlen, gibt keine
vor

Kennzahlen
(-systematik)
auch in der
Praxis effektiv

Integrationswerkzeug fr
Kennzahlen

99

3 IT Prozess-Management
3.1 Management Summary
Die Best Practice-Anstze von COBIT und ITIL sowie der ISO 20000 IT
Service Management sind Anstze fr ein prozessorientiertes Management. In diesem Kapitel nun werden die damit verbundenen Anforderungen und Voraussetzungen an das Prozess-Management beschrieben.
Von wesentlicher Bedeutung ist dabei die Verankerung des Service Managements und der damit verbundenen IT Service Management-Prozesse in
das IT-Management. Wirksame Prozessziele und die damit verbundenen
Kennzahlen sowie deren Zielwerte knnen nur in einem top down-Ansatz
definiert und verfolgt werden. In diesem Kapitel wird ein praxisbewhrtes
und konzeptionelles Vorgehen bei der Definition vorgestellt.
Die Etablierung von Prozessen erfordert darber 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 Bercksichtigung finden knnen.

3.2 PDCA-Zyklus
ITIL Version 3 geht innerhalb der Publikation Continual Service Improvement expliziert auf ein Regelsystem zur kontinuierlichen Verbesserung
von Prozessen und Services ein. Normen, wie die ISO 20000 IT Service
Management, die ISO 27001 Information Security Management oder
die ISO 9001 Qualitts-Management beinhalten die Anforderungen an
ein integriertes Managementsystem. Die in diesen Normen und Best Practices beschriebenen Qualitts-Managementsysteme gehen zurck auf die
Managementlehren des amerikanischen Wissenschaftlers W. Edwards
Deming1 zum PDCA-Zyklus (Plan, Do, Check, Act), der als Deming-Zyklus international bekannt geworden ist. Deming selbst wies jedoch darauf
hin, dass Walter A. Shewhart2 diesen Zyklus als Erster beschrieben hatte.

William Edwards Deming, 1900 - 1993

Walter Andrew Shewhart, amerikanischer Wissenschaftler, 1891 - 1967

101

3 IT Prozess-Management
Daher wird der PDCA-Zyklus gelegentlich auch als Shewhart-Zyklus
bezeichnet (siehe Abbildung 33).

Act
Verbessern

Plan
Planen

Stndige
Verbesserung
Check
berprfen

Abbildung 33:

Do
Ausfhren

PDCA-Zyklus

Der PDCA-Zyklus basiert auf einem prozessorientiertem Managementansatz, der aus den folgenden Phasen besteht (vgl. [ISO 20000-1, 2005]):
Plan (Planen):
Die Phase dient der Einfhrung der Prozesse und der damit verbundenen Ziele, die notwendig sind, um Ergebnisse entsprechend
den Kundenanforderungen und den geschftspolitischen Zielen zu
liefern.
Do (Ausfhren):
Innerhalb der zweiten Phase erfolgt die Durchfhrung (initial die
Implementierung) der geplanten Prozesse.
Check (berprfen):
Die dritte Phase dient der berwachung und Messung der Prozesse
und Services gegenber den geschftspolitischen Zielen und den

102

3.2 PDCA-Zyklus
einzelnen Prozess-/Service-Zielen und Anforderungen, sowie zur
Berichterstattung der Ergebnisse.
Act (Verbessern):
Liegen Ergebnisse aus der berprfung vor, so sind diese zu analysieren und geeignete Manahmen zu ergreifen, um die Leistungsfhigkeit der Prozesse nachhaltig zu verbessern.
Diese identifizierten Verbesserungen finden wiederum Eingang in Plan.
Dadurch ist kontinuierliche Verbesserung sichergestellt. Prozess-Management ist eine fortgehende, nicht endende Managementaufgabe. Hierzu hat
Deming bereits herausgestellt, dass es kein Optimum gibt und demzufolge
immer Verbesserungen identifiziert werden knnen.
Von besonderer Bedeutung ist beim PDCA-Zyklus, dass es ein System ist, welches nicht nur der Prozesseinfhrung dient, sondern als Managementsystem der
kontinuierlichen Verbesserung und so mittel- und langfristig einen wesentlichen
Beitrag zum Unternehmenserfolg liefert.

Diese Schritte werden stndig wiederholt, um eine kontinuierliche Prozessverbesserung zu erreichen. Daher wird der PDCA-Zyklus auch als
Regelzyklus bezeichnet.
Die Kennzahlen fr IT Service Management-Prozesse stellen eine uerst
wichtige Informationsbasis fr die Phase Check dar. Ohne Kennzahlen
kann eine berprfung der Ergebnisse und Ziele nicht erfolgen und ohne
berprfung ist eine Verbesserung der Prozesse nicht mglich.
Die Kennzahlen fr IT Service Management-Prozesse sind fr die stetige Prozess-Optimierung ein unerlssliches Werkzeug.

Die im Folgenden beschriebene Vorgehensweise mag zum Teil theoretisch


klingen oder auch als selbstverstndlich angesehen werden, sie hat aber
grundlegende Bedeutung fr den Erfolg von IT Service ManagementProzessen.
Es muss zum Selbstverstndnis des Service Managers, Prozess Owners und Prozess Managers werden, dass die Kennzahlen ein unverzichtbares Werkzeug im
Rahmen des Prozess-Managements sind. Ohne Kennzahlen ist letztendlich keine
Prozessoptimierung und letztendliche Leistungssteigerung mglich. Es ist ein
Irrglaube, Kennzahlen aus bestehenden Best Practices bedenkenlos bernehmen
zu knnen. Es geht um die Sicherstellung der Ziele der Organisation und ihrer
Kunden. Kennzahlen mssen dementsprechend ausgerichtet und abgebildet
werden.

103

3 IT Prozess-Management

3.3 Etablierung des Prozess-Managements


Die Gewinnung von Kennzahlen fr IT Service Management-Prozesse
setzt die Etablierung einer entsprechenden Prozessstruktur voraus. Bevor
die Prozessziele definiert und die daraus abgeleiteten Kennzahlen gewonnen werden knnen, sind die IT Service Management-Prozesse in der Organisation zu verankern.
Dazu ist es nicht ausreichend, einzelne in den ITIL Best Practices dokumentierten Aktivitten umzusetzen oder ausgewhlte Control Objectives
aus COBIT sicherzustellen. Vielmehr mssen die Prozesse mit einem Prozess-Management in der Organisation etabliert werden. Dazu sind die
damit verbundenen Verantwortlichkeiten und Zustndigkeiten fr die IT
Service Management-Prozesse zu definieren. Dieser organisatorische Akt,
der sich in der Praxis hufig als problematisch darstellt, ist fr die Einfhrung der IT Service Management-Prozesse ein uerst kritischer Erfolgsfaktor.
Bestehende
Strukturen in
der IT orientieren sich an
den eingesetzten Komponenten.

In der Regel sind die bestehenden IT-Organisationen hierarchisch strukturiert, wobei sich deren Struktur stark an den eingesetzten Hardware-Systemen bzw. an Software/Applikationen orientiert. So gibt es Organisationsbereiche, die das LAN, die Datenbanken, die Applikationen oder die Sicherheitskomponenten planen, implementieren und betreuen. Diese Struktur ist historisch gewachsen und hat sich durch die stetig steigende Komplexitt der eingesetzten IT-Komponenten ergeben. Der Einsatz der ITKomponenten setzt entsprechendes Spezialwissen der IT-Mitarbeiter voraus. Zum wirkungsvollen Management dieser Spezialisten werden die ITMitarbeiter thematisch in der Organisationsstruktur zu entsprechenden
Gruppen, Abteilungen und Bereichen zusammengefasst. Diese Struktur
fhrt hufig dazu, dass die Mitarbeiter innerhalb der IT-Organisation auf
den Betrieb Ihrer Systeme ausgerichtet sind und ihr Handeln darauf
konzentrieren. Die Kunden- und Servicesicht ist noch nicht in allen ITOrganisation etabliert. Wie im vorhergehenden Kapitel bereits ausgefhrt,
werden unter dem IT Service ein oder mehrere IT-Systeme verstanden, die
einen Geschftsprozess untersttzen. In der Regel sind damit die Leistungen von mehreren Abteilungen verbunden. Fr die IT Services muss es
eine Gesamtverantwortung geben, die die Einhaltung der Service Level
Agreements sicherstellt. Der Ansatz fhrt dazu, dass es organisationsbergreifende Verantwortungen geben muss.
Analog wie IT Services organisationsbergreifend sichergestellt werden
mssen, verhlt es sich mit den IT Service Management-Prozessen. Auch
diese Prozesse knnen nur dann wirkungsvoll sein, wenn die Prozesse
und damit verbundenen Verantwortlichkeit nicht an Abteilungsgrenzen
enden.

104

3.3 Etablierung des Prozess-Managements


Mit dem fortschreitenden Out-Tasking wird das notwendige Spezialwissen teilweise durch externe Lieferanten beigestellt. Die Einscheidung fr
ein Out-Tasking wird einerseits getroffen, wenn das notwendige Wissen
innerhalb der eigenen IT-Organisation nicht vorhanden ist. Andererseits
werden Entscheidungen fr ein Out-Tasking hufig aus finanziellen Grnden getroffen. Bei der Integration von externen Lieferanten muss deren
Einbindung in die bestehenden IT-Prozesse sichergestellt werden. Diese
Festlegung muss vor dem Vertragsschluss erfolgen.
In diese Struktur gilt es die IT Service Management-Prozesse nachhaltig zu
etablieren.

3.3.1

Der Charakter von IT-Prozessen

Ein Prozess kann wie folgt definiert werden (vgl. Service Design, [OGC,
2007b]):
Ein Prozess ist eine strukturierte Folge von Aktivitten, die geplant werden, um
ein bestimmtes Ziel zu erreichen. Ein Prozess bentigt ein oder mehrere definierte Inputs und transformiert diese Inputs zu definierten Outputs. Ein Prozess
beinhaltet die notwendigen Rollen, die Verantwortlichkeiten, die Tools und die
Management Controls, um den Output zu liefern. Ein Prozess definiert dazu die
notwendigen Grundstze (Policies), Standards, Richtlinien, Aktivitten und Arbeitsanweisungen.

Am Beispiel des Incident Managements soll diese Begriffsdefinition veranschaulicht werden.


Die Zielsetzung des Incident Managements besteht darin, den normalen
Service-Betrieb so schnell wie mglich wiederherzustellen und die nachteiligen
Auswirkungen auf den Geschftsbetrieb auf ein Minimum zu begrenzen (vgl.
[OGC, 2005b]). Ein Input des Incident Managements ist die detaillierte
Strungsbeschreibung. Um den Output behobene Strung und abgeschlossene Strungsvorgnge zu erreichen, sind im Prozess des Incident
Managements definierte Aktivitten durchzufhren. Dazu zhlen unter
anderem die Registrierung der Strung und deren Untersuchung und
Diagnose.
In einer bestehenden IT-Organisation werden einzelne Aktivitten des
Prozesses hufig in unterschiedlichen Organisationseinheiten, zum Teil
auch in unterschiedlichen Organisationen durchgefhrt. So wird die Strung im Service Desk registriert, whrend die notwendige Strbehebung
durch den 2nd oder 3rd Level Support in einzelnen Fachgruppen mit Spezialwissen bernommen wird. Dies hat zur Konsequenz, dass die ITProzesse organisationsbergreifend durchgefhrt werden.

105

3 IT Prozess-Management
IT-Prozesse durchdringen die gesamte IT-Organisation, schlieen gegebenenfalls
externe Lieferanten ein und enden demzufolge nicht an bestehenden organisatorischen Grenzen.

Die mgliche Bearbeitung eines Incidents knnte wie folgt abgewickelt


werden (Abbildung 34):
Organisation
und EDV

Incident
Service Desk

Client Systeme

Daten und
Systeme

Serversysteme

Netze und
Kommunikation

Datenbanken

LAN

WAN

Externer
Onsite Support

Abbildung 34:

Exemplarische Darstellung der Bearbeitung eines Incidents

In dem abgebildeten Beispiel wird der Incident dem Service Desk gemeldet und dort registriert. Nach einer ersten Untersuchung leitet der
Service Desk den Incident-Record zur weiteren Bearbeitung an die Gruppe
LAN weiter. In dieser Gruppe wird festgestellt, dass das LAN keine
Strung 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 zustndigen externen Onsite Support mit deren Behebung. Nach der erfolgten Behebung
wird der Service Desk entsprechend informiert.
Dieses Beispiel einer einfachen Bearbeitung im Incident Management verdeutlicht, dass die IT-Prozesse die gesamte IT-Ogranisation durchdringen
und zum Teil externe Lieferanten sowie Kunden einbeziehen.

106

3.3 Etablierung des Prozess-Managements


Die Aufgabe des Prozess-Managements ist es sicherzustellen, dass der
Prozess die definierten Ziele erfllt. Hierzu definiert ITIL die Prozesssteuerung wie folgt (vgl. Best Practice Service Design, [OGC, 2007b):
Die Prozess-Steuerung ist die Aktivitt, einen Prozess zu planen und zu regulieren, mit dem Ziel, den Prozess effektiv, effizient und in einer einheitlichen Art
und Weise auszufhren.

Die damit verbundene Verantwortung der effektiven und effizienten Prozessdurchfhrung liegt beim Prozess-Management des jeweiligen Prozesses. Auf die einzelnen Rollen im Prozess-Management wird an spterer
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 unerlssliche Prozesse.
Das fhrt dazu, dass die bestehende hierarchische IT-Organisation
querschnittlich von IT-Prozessen durchdrungen wird (Abbildung 35).
Organisation
und EDV

Incident Management
Problem Management

Service Desk

Daten und
Systeme

Netze und
Kommunikation

Change Management
Release Management

Client Systeme

Service Level
Management
Capacity Management

Serversysteme

Datenbanken

LAN

Externer
Onsite Support

Security Management

Abbildung 35:

IT-Prozesse und bestehende Aufbauorganisation

Damit ergibt sich letztendlich eine Matrixorganisation mit den bekannten


strukturellen Problemen. Die Mitarbeiter sind einerseits einer Linienorga-

107

WAN

3 IT Prozess-Management
nisation zugehrig und unterstellt, andererseits haben sie Aktivitten innerhalb von einem oder mehreren IT Service Management-Prozessen
durchzufhren, wofr jeweils ein Prozess Owner bzw. Prozess Manager
verantwortlich ist.
Diese doppelte Zugehrigkeit zur Linienorganisation und zu den jeweiligen IT Service Management-Prozessen stellt nicht nur die Mitarbeiter der
IT-Organisation in ein Spannungsfeld, sondern auch das IT-Management.
Ein IT Service Management mit den erforderlichen IT-Prozessen kann nur dann
erfolgreich etabliert werden, wenn die Verantwortlichkeiten zwischen Linienorganisation und Prozess-Management festgelegt werden.

Die angestrebte Transparenz fhrt nicht nur zu ngsten bei Mitarbeitern


sondern auch bei der verantwortlichen Linienorganisation. Denn wer
mchte schon transparent sein? Wenn eine IT-Organisation es nicht schafft
diese Probleme zu lsen, zum Beispiel durch ein begleitendes Vernderungs-Management und die aktive Beteiligung der Betroffenen, so werden die IT Service Management-Prozesse nicht wirkungsvoll sein. Die
notwendige und als Ziel gesetzte Transparenz hinsichtlich der Leistungsfhigkeit und des Optimierungspotenzials der Prozesse und der IT Services wird dann ggf. als Bedrohung empfunden und kann nicht erreicht
werden. Fehlt die notwendige Untersttzung, so werden die ermittelten
Kennzahlen unter Umstnden ein fehlerhaftes Bild darstellen und letztendlich wenig zielfhrend sein.
So wie ein Vernderungsmanagement und die berzeugung notwendig
sind, so muss aber andererseits auch sichergestellt werden, dass die festgelegten Prozesse und Aktivitten auch einzuhalten sind. Wird festgestellt,
dass diese Vorgaben nicht eingehalten werden, so mssen damit sprbar
Konsequenzen verbunden sein. Auch die Durchsetzung dieser Konsequenzen gehrt zur Managementverantwortung.
Im Einzelfall kann es durchaus vorkommen, dass vom Prozess abweichend gehandelt werden musste. Dies wird bei der Implementierung neuer Prozesse durchaus vorkommen. Dann muss aber sichergestellt werden,
dass die notwendige Abweichung kommuniziert wird und zum Input fr
eine Prozessanpassung wird (im Sinne des PDCA-Zyklus).
Ein IT Service Management mit den erforderlichen IT-Prozessen verlangt das
Commitment des gesamten Managements. Es liegt in der Verantwortung des
gesamten Managements, zum Erfolg des IT Service Managements aktiv beizutragen. Dies erfolgt sowohl durch ein begleitendes Vernderungs-Management, als
auch durch Konsequenzen bei der Nichteinhaltung von getroffenen Vorgaben.

Damit das IT Service Management erfolgreich innerhalb einer hierarchischen Organisationsstruktur betrieben werden kann, sind die Verantwort-

108

3.3 Etablierung des Prozess-Managements


lichkeiten eindeutig zu definieren. Diese Definition betrifft einerseits die
Abgrenzung zwischen der Linien- und Prozessverantwortung. Andererseits sind auch fr das IT Service Management die Verantwortlichkeiten
festzulegen. Dazu sind die wahrzunehmenden Rollen im ProzessManagement zu spezifizieren.

3.3.2

Rollen im Prozess-Management

Die hier verwendeten Begriffe sind in IT-Organisation zum Teil mit anderen Aufgaben und Verantwortlichkeiten hinterlegt. Es ist daher im Rahmen der Implementierung zu prfen, ob fr die folgenden Rollen bestehende Begriffsdefinitionen bzw. die hier dokumentierten Rollenbezeichnungen anzupassen sind.
Analog zu den ITIL Best Practices stellen die folgenden Rollenschreibungen Empfehlungen dar, deren Umsetzung von der jeweiligen Situation
abhngig ist. So wird eine kleine IT-Organisation nicht einen Prozess Manager und einen Prozess Owner etablieren, sondern diese Aufgaben zusammenfhren.
Die hier beschrieben Rollen entsprechen den ITIL Best Practices (vgl.
[OGC, 2007b) bzw. der ISO 20000 (vgl. [ISO 20000-2, 2005):

3.3.2.1 Service Manager


Obwohl es bereits seit vielen Jahren eine offizielle Ausbildung und eine
international anerkannte Zertifizierung zum ITIL Service Manager (vgl.
[KESS, 2007a]) gibt, war diese Rolle in der ITIL Version 2, abgesehen von
der Publikation Business Perspective Volume 2, nicht explizit beschrieben. In einigen Textpassagen wurde zwar auf einen Service Manager hingewiesen, aber eine Rollenbeschreibung hierfr lag nicht vor.
In der ITIL Version 3 ist auch die Rolle des Service Managers beschrieben
(vgl. [OGC, 2007e]):
Der Service Manager ist eine wichtige Rolle fr die Entwicklung, Implementierung, Evaluation und das fortlaufende Management neuer und existierender
Produkte und Services. Seine Verantwortung umfasst die Entwicklung der Geschfts-Strategie, Markt- und Kunden-Analyse, Lieferanten-Management, Inventarisierung, Kosten Management und insbesondere das Auslieferungs- und
Lebenszyklus-Management von Produkten und Services.

Die ISO 20000 empfiehlt, dass ein Mitglied des oberen Managements (senior level) die Verantwortung fr den Service Management-Plan und
dessen Umsetzung bernehmen sollte (vgl. [ISO 20000-2, 2005]). Innerhalb
dieses Service Management-Plans wird die Zielsetzung und Ausgestaltung
des IT Service Managements beschrieben.

109

3 IT Prozess-Management
Daraus folgt, dass es eine den einzelnen Prozess Ownern und Prozess
Managern vorgesetzte Instanz gibt und diese dem oberen Management
angehrt.
Das IT Service Management und die damit verbundenen Prozesse dienen
keinem Selbstzweck, sondern sind in die IT-Planung und -Strategie einzubinden. Letztendlich leiten sich die konkrete Ausrichtung der Prozesse
und ihre Zielsetzung aus den Business-Anforderungen und der ITStrategie ab.
Dabei kann sich die konkrete Ausprgung in Abhngigkeit von den aktuellen Business-Anforderungen und der IT-Strategie durchaus ndern. So
besteht zum Beispiel die Zielsetzung des Capacity Managements gem
ITIL darin, dass ... die aktuellen und zuknftigen geschftlichen Anforderungen im Hinblick auf Kapazitten und Performance auf wirtschaftliche Weise erfllt werden .... Befindet sich eine Organisation in einer starken Wachstumsphase, so wird das Capacity Management auf die Bereitstellung der
erforderlichen Kapazitten fokussiert sein. Muss die Organisation dagegen
primr Kosten einsparen, so gewinnt die Wirtschaftlichkeit der Bereitstellung in der Regel ein greres Gewicht. Die grundstzliche Zielsetzung an
ein Capacity Management ndert sich zwar nicht, aber die konkrete Ausgestaltung der Ziele ist abhngig von den Geschftsanforderungen.
Daher bentigen die Prozess Owner und Prozess Manager entsprechende
Vorgaben, die in die Prozessziele eingehen und letztendlich auch Auswirkungen auf das Kennzahlensystem haben. Diese Vorgaben werden vom
oberen Management getroffen und liegen in der Verantwortung des Service Managers.
Eine weitere Aufgabe des Service Managers besteht darin, eine Eskalationsebene fr die Prozess Owner und Prozess Manager zu bieten, da die
einzelnen IT Service Management-Prozesse durchaus konkurrierende Ziele verfolgen knnen.
Der Service Manager kann mit einem Stdteplaner verglichen werden,
whrend die Prozess Owner und Prozess Manager die Architekten und
die Bauaufsicht darstellen.

3.3.2.2 Prozess Owner


Der Prozess Owner ist fr die Zielerreichung des jeweiligen Prozesses
verantwortlich. Der Prozess Owner hat demzufolge die Ergebnisverantwortung fr den jeweiligen Prozess.
Eine Mglichkeit, die Verantwortlichkeiten fr Aktivitten bersichtlich
darzustellen, besteht mittels einer RACI-Matrix. Dabei leitet sich der Name
aus den vier Verantwortlichkeiten Responsible, Accountable, Con-

110

3.3 Etablierung des Prozess-Managements


sulted und Informed ab. Dabei wird Responsible als Verantwortung
fr die Durchfhrung verstanden. Accountable ist dagegen die Person, die
die Gesamt- und letztendlich die Ergebnisverantwortung trgt.
Bei der Darstellung in Form der RACI-Matrix werden in einer Matrix Rollen gegenber Aktivitten aufgetragen (Abbildung 36). Durch Eintragen
der Buchstaben R, A, C und I werden die Aktivitten den Rollen zugeordnet. Diese Form zur Darstellung der Prozessaktivitten und Rollen (Funktionen innerhalb der Organisation) wird von ITIL und COBIT genutzt.
Role Responisibility

Change

Change en-

Change

Change

sponsor,

abler, e.g.

agent, e.g.

target, e.g.

e.g. busi-

process own-

team leader

individual

ness and IT
leaders

ers, service
owners

instructing
change

performing
the change

Articulate a vision for the


business and service
change in their domain
Recognize and handle
resistance to change

A/R

A/R

A/R

A/R

A/R

A/R

A/R

Initiate change, understand the levers for


change and the obstacles
Manage change and
input to change plan

Abbildung 36:

Ausschnitt der RACI-Matrix zum Change Management (vgl.


[OGC, 2007c])

Die Definition der zu erreichenden Ziele wird mit dem Service Manager
abgestimmt und entsprechend dokumentiert.
In der ITIL Version 3 wird die Rolle des Prozess Owners wie folgt definiert
(vgl. [OGC, 2007b):
Der Prozess Owner ist dafr verantwortlich, dass ein Prozess zweckmig ist. Die
Verantwortung des Prozess Owners schliet die Untersttzung, das Design, das
Change Management und die bestndige Verbesserung des Prozesses und der
damit verbunden Messsysteme ein.

Auf Basis der definierten Ziele legt der Prozess Owner gemeinsam mit
dem Prozess Manager die damit verbundenen Kennzahlen fest. Erst mithilfe dieser Kennzahlen kann gesichert festgestellt werden, ob der Prozess

111

Die Definition von


Kennzahlen
setzt definierte Prozessziele voraus

3 IT Prozess-Management
die definierten Ziele hinsichtlich der erwarteten Effektivitt und Effizienz
erreicht.
Die Kennzahlen (KGI, KPI) sind top down zu entwickeln. Aus den BusinessAnforderungen und der IT-Strategie ergeben sich die jeweiligen Prozessziele.
Mittels der definierten Kennzahlen erfolgt dann das Management der Prozesse,
um die geforderte Effektivitt und Effizienz zu erreichen. Die Kennzahlen signalisieren dem Prozess Owner, ob die definierten Ziele erreicht werden.

Es hat sich bewhrt, dass der Prozess Owner dem IT-Management angehrt. So ist einerseits die Abstimmung mit den Business-Anforderungen
sowie mit der IT-Strategie sichergestellt. Anderseits erfhrt der Prozess die
notwendige Managementuntersttzung. Es kann durchaus vorgekommen,
dass der Prozess Manager innerhalb der Organisation auftretende Widerstnde berwinden muss. Hier kann ihm ein Prozess Owner aus dem ITManagement die notwendige Untersttzung bieten. Auerdem wird damit ein wichtiges Signal fr alle Mitarbeiter gegeben: IT Service Management wird von unserem Management aktiv gefrdert.
Dies setzt aber selbstverstndlich voraus, dass das IT-Management die
Prozesse aktiv vorlebt und sich selbst an diese Prozesse hlt.

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 fr die Durchfhrung des Prozesses verantwortlich.
In der ITIL Version 3 wird die Rolle des Prozess Managers wie folgt definiert
(vgl. [OGC, 2007b):
Der Prozess Manager ist fr das operationelle Management des Prozesses verantwortlich. Die Verantwortung des Prozess Managers umfasst die Planung und
Koordinierung aller Aktivitten, deren Monitoring und deren Berichterstattung.
In greren Organisationen kann es durchaus mehrere Prozess Manager fr einen Prozess geben, wie zum Beispiel regionale Change Manager pro Niederlassung.

In kleineren IT-Organisationen erfolgt keine Unterteilung zwischen Prozess Owner und Prozess Manager. Die Ergebnis- und Durchfhrungsverantwortung wird dann gemeinsam wahrgenommen.
Im Rahmen der Durchfhrungsverantwortung gestaltet der Prozess Manager den Prozess und definiert die durchfhrenden Aktivitten. Er stellt
sicher, dass der Prozess mit den notwendigen Ressourcen untersttzt wird.
Der Prozess Manager hat dazu die kritischen Erfolgsfaktoren (CSF: Critical

112

3.3 Etablierung des Prozess-Managements


Success Factors) zu identifizieren und durch geeignete Manahmen abzusichern (= Plan im PDCA-Zyklus).
Mgliche Schwachstellen im Prozess sind vom Prozess Manager zu analysieren und durch geeignete Verbesserungsmanahmen nachhaltig zu beseitigen (= Act im PDCA-Zyklus).
Angesichts der Komplexitt der Prozesse und der verschiedenen Beteiligten in unterschiedlichen Organisationseinheiten bentigt der Prozess Manager hierzu eine gesicherte Informationsbasis, er bentigt Prozesskennzahlen (= Check im PDCA-Zyklus).
Die Prozess-Kennzahlen sind Indikatoren. Sie informieren ber die Zielerreichung bzw. ber das Verlassen eines Zielbereichs. Unter der weiteren
Bercksichtigung 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 Lsungszeiten fr Incidents
nicht eingehalten werden, oder dass die Implementierung von Changes zu
Incidents fhrt. Ein Indikator zeigt aber nicht an, warum etwas passiert ist.
Die Kennzahlen sind fr den Prozess Manager ein uerst wichtiges Management-Werkzeug. Sie signalisieren was im Prozess passiert und in Verbindung
mit Trenddaten wie sich der Prozess entwickelt. Nur mit entsprechenden
Kennzahlen kann der Prozess Manager seiner Verantwortung nachkommen.

Um feststellen zu knnen, warum etwas passiert ist, muss der Prozess


Manager einzelne Kennzahlen in Zusammenhang bringen. Zum Beispiel
knnte geprft werden, ob neue Services eingefhrt wurden und damit
erklrbar wird, warum die Lsungszeiten den vorgegeben Wert nicht
mehr erreichen. Der Prozess Manager muss hierzu die Einflussfaktoren
identifizieren, Zusammenhnge zuordnen und letztendlich die eigentlichen Ursachen analysieren (= Check im PDCA-Zyklus).
Die IT Service Management-Prozesse sind gekennzeichnet durch wechselseitige Aktivitten. Der Prozess Manager bentigt daher nicht nur das
Know-how fr seinen eigenen Prozess, sondern muss auch ber Grundlagenwissen zu den anderen Prozessen verfgen. 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 Strungen, die auf nderungen zurckgefhrt wurden. Die Generierung dieser Kennzahl bentigt demzufolge Informationen aus dem Incident Management. Hierzu muss der Prozess Manager um das beschriebene Grundlagenwissen zu allen IT Service Management-Prozessen verfgen. Andererseits muss er die Ermittlung bzw. Nutzung der bentigen
Daten mit einem anderen Prozess Manager abstimmen.

113

Kennzahlen
sind die Arbeitsinstrumente des
Prozess
Managers.

3 IT Prozess-Management
Der Prozess Manager bentigt Grundlagenwissen zu allen IT Service Management-Prozessen. Bei der Gestaltung des Prozesses und der Definition der Kennzahlen ist eine enge Zusammenarbeit mit den anderen Prozess Managern von
groer Bedeutung.

3.3.2.4 Prozess-Mitarbeiter
Die Prozess-Mitarbeiter sind fr bestimmte Aktivitten in einem Prozess
verantwortlich und berichten dem Prozess Manager. Sie fhren die Aktivitten im Prozess durch, die ihrer fachlichen Qualifikation entsprechen.
Neben der entsprechenden theoretischen Schulung bentigen die Mitarbeiter auch das Wissen um die konkrete Zielsetzung des Prozesses. Hierzu
empfiehlt es sich, zunchst auch die Prozess-Mitarbeiter in den ITIL
Grundlagen zu schulen und anschlieend die Prozessschulungen durchzufhren.
Mit der Einfhrung von Prozessen ndern sich hufig bestehende Ablufe
und durchzufhrende Aktivitten. Kennzahlen untersttzen hierbei das
notwendige Vernderungsmanagement. Anhand von Kennzahlen kann
den Prozess-Mitarbeitern dargestellt werden, wie wirksam der Prozess ist
und wie ihre Leistungen sowie die vernderten Arbeitsweisen zum erzielten Erfolg beitragen.
Nach Mglichkeit sollten die Kennzahlen nicht nur dem Management zur Verfgung stehen. Auch die IT-Mitarbeiter sollten hierauf Zugriff haben.

3.3.2.5 Betriebs- und Personalrat


Abschlieend muss an dieser Stelle auf den Betriebs- bzw. Personalrat
eingegangen werden.
Die Kennzahlen zu den einzelnen Prozessen werden hufig aus operativen
Systemen, wie zum Beispiel den Daten eines IT Service Management-Tools,
generiert. Damit greifen die Kennzahlensysteme auf Daten zurck, die die
Mglichkeit zur Leistungsbeurteilung von Mitarbeitern erffnen.
Kennzahlen
sind informations- und/
oder mitbestimmungspflichtig

Innerhalb Deutschlands ist fr die Erfassung und Auswertung derartiger


Daten die Zustimmung des Betriebs- bzw. Personalrats erforderlich.
Die geplanten Kennzahlen zur Beurteilung der IT Service Management-Prozesse
sollten frhzeitig mit dem Betriebs- bzw. Personalrat abgestimmt werden. Insbesondere sollte dem Betriebs- bzw. Personalrat dargelegt werden, dass das System
der Beurteilung von Prozessen dient und nicht der Beurteilung von Mitarbeitern.

114

3.4 Definition der Prozessziele und -Kennzahlen

3.4 Definition der Prozessziele und -Kennzahlen


3.4.1

Definition der Prozessziele

Die hier dargestellte Vorgehensweise der Zieldefinition und die daraus


abgeleiteten Kennzahlen basieren auf erfolgreich durchgefhrten
ISO 20000-Projekten. Im Rahmen dieser Projekte wurden mit dem im Folgenden beschriebenen Konzept die ISO 20000 Anforderungen an das
bergeordnete Managementsystem sichergestellt, und so die Basis fr eine
erfolgreiche Zertifizierung gelegt. Ungeachtet einer ISO 20000 Zertifizierung empfiehlt es sich jedoch generell, diese Vorgehensweise bei der Einfhrung von IT Service Management-Prozessen zu nutzen.
Diese Vorgehensweise entspricht auch der ITIL Version 3 mit dem beschriebenen Service Lifecycle und der Service Strategy als Mittelpunkt
bzw. Ausgangspunkt des Service Lifecycle.
Die hier beschriebene Vorgehensweise stellt sicher, dass die IT Service Management-Prozesse den Geschftsanforderungen entsprechen, in die IT-Strategie eingebunden sind und die definierten Ziele mit endlichen Ressourcen wirkungsvoll
erreicht werden knnen.

Die Kennzahlen und deren Zielwerte sind unmittelbar mit den Prozesszielen verbunden. Daher knnen die Kennzahlen und deren Zielwerte erst
dann definiert werden, wenn die konkreten Prozessziele spezifiziert sind.
Mithilfe von COBIT und ITIL kann dann geprft werden, welche Best
Practice Kennzahlen sich hierfr anbieten. In Projekten mussten darber
hinaus aufgrund der Prozessziele zum Teil Kennzahlen definiert werden,
die in COBIT und ITIL nicht spezifiziert sind.
Mgliche KPI, KGI aus COBIT und ITIL auszuwhlen, ohne die Prozessziele zuvor definiert zu haben, ist nicht zielfhrend. 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 Geschftsprozesse. Die Anforderungen aus den Geschftsprozessen beziehen sich in erster Linie auf
die bereitzustellenden IT Services. In der Regel liegen die damit verbundenen (internen) IT Service Management-Prozesse der IT nicht im Blickpunkt
des Kunden. Der Kunde bentigt die IT Services zur Durchfhrung seiner
Geschftsprozesse und die IT hat dies gem den getroffenen Vereinbarungen sicherzustellen. Wie diese Bereitstellung bestmglich erfolgt, ber-

115

3 IT Prozess-Management
lsst der Kunde der IT-Organisation, in deren Verantwortung die entsprechende Umsetzung grundstzlich liegen sollte.
Die Anforderungen an die IT Services werden mittels SLAs spezifiziert
(siehe Abbildung 37). Daraus abgeleitet werden die OLAs sowie die UCs
verhandelt und vereinbart. Anhand dieser Vereinbarungen sind die jeweiligen Service Level sowie die Kapazittsanforderungen zu messen, zu berichten und regelmigen Reviews zu unterziehen.
Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

SLA
(OLA/UC)

Kapazitten

Abbildung 37:

Definition der IT Services

Werden Verbesserungsmanahmen identifiziert, sind diese gem ITIL


und der ISO 20000 in einem Service Improvement Plan (SIP) zu dokumentieren. Betreffen diese Verbesserungsmanahmen die implementieren IT
Service Management-Prozesse, so werden sie im Prozess Improvement
Plan (PIP) des jeweiligen Prozesses dokumentiert (siehe Abbildung 38).
In der ISO 20000 werden zwar Reviews in den Prozessen und deren Dokumentation gefordert, aber nicht nher spezifiziert, wo diese Dokumentation zu erfolgen hat. In der Projektpraxis hat sich herausgestellt, dass der
SIP hierfr wenig geeignet ist, da hier eine Vermischung von Informationen erfolgt. Fr die Dokumentation sind daher die PIPs zu definieren.
Dieses Konzept wurde erstmalig erfolgreich bei der ISO 20000 Zertifizierung der badenIT umgesetzt und wird im Folgenden vorgestellt.

116

3.4 Definition der Prozessziele und -Kennzahlen


Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

SLA
(OLA/UC)

Kapazitten
Service
Improvement
Plan
(SIP)
Verbesserungspotenzial

Abbildung 38:

Prozess
Improvement
Plne
(PIP)

Definition der IT Services Service Improvement Plan

Bei Kunden-Anforderungen an neue IT Services und bei vernderten Anforderungen an bestehende IT Services (siehe Abbildung 39) ist zu prfen,
ob die etablierten IT Service Management-Prozesse diesen Anforderungen
gengen oder unter Umstnden die Prozessziele sowie die damit verbundenen Prozessaktivitten anzupassen sind.
Auer den Anforderungen an die IT Services gibt es weitere bergeordnete Kunden- und Geschfts-Anforderungen an die IT-Organisation, die
Auswirkungen auf die IT Service Management-Prozesse haben (siehe
Abbildung 40). Zu den Geschftsanforderungen des Business gehren
zum Beispiel die Forderungen nach einem IT Qualittsmanagement, nachgewiesen durch die ISO 20000 Zertifizierung. Als zweiter Block stehen die
regulativen Anforderungen (Compliance Anforderungen) wie zum Beispiel SOX, Euro SOX, Basel II oder GXP fr Unternehmen in der PharmaBranche.
Diese Anforderungen haben Auswirkungen auf die IT Service Management-Prozesse, deren Zielsetzung und letztendlich auf die damit verbundenen Kennzahlen.

117

3 IT Prozess-Management
Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

Neue oder
vernderte
IT-Services

SLA
(OLA/UC)

Kapazitten
Service
Improvement
Plan
(SIP)
Verbesserungspotenzial

Abbildung 39:

Prozess
Improvement
Plne
(PIP)

Definition der Prozessziele Neue Services

Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

SLA
(OLA/UC)

Neue oder
vernderte
IT-Services

KundenAnforderungen

GeschftsAnforderungen

Kapazitten
Service
Improvement
Plan
(SIP)
Verbesserungspotenzial

Abbildung 40:

118

Prozess
Improvement
Plne
(PIP)

Definition der Prozessziele Kundenanforderungen

3.4 Definition der Prozessziele und -Kennzahlen


Auf Basis der geschftspolitischen Ziele des Unternehmens, die grtenteils bereits in den zuvor genannten Anforderungen beschrieben sind,
wird die IT-Strategie entwickelt (siehe Abbildung 41). Im Rahmen der
Entwicklung und Weiterentwicklung der IT Service Management-Prozesse
sind diese strategischen Ziele ebenfalls zu bercksichtigen.
Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

SLA
(OLA/UC)

Neue oder
vernderte
IT-Services

KundenAnforderungen

GeschftsAnforderungen

ITStrategie

Kapazitten
Service
Improvement
Plan
(SIP)
Verbesserungspotenzial

Abbildung 41:

Prozess
Improvement
Plne
(PIP)

Definition der Prozessziele IT-Strategie

Auch mgliche finanzpolitische Aspekte haben Auswirkungen auf die IT


Service Management-Prozesse und deren Ziele. Dies wird in der ITIL Version dadurch zum Ausdruck gebracht, dass das Financial Management
der Service Strategy zugeordnet ist.
Die Geschftsanforderungen an das Service Management knnen im Rahmen einer bergeordneten Balanced Scorecard und einer daraus abgeleiteten IT Balanced Scorecard vorgegeben werden. Diese Durchgngigkeit von
der Balanced Scorecard zu den Zielen des Service Managements und den
Prozesszielen hat zum Beispiel die badenIT in Freiburg erfolgreich umgesetzt. Im Rahmen der ISO 20000 Zertifizierung wurde dieser Aspekt von
den Prfern besonders positiv hervorgehoben.
Dem Kapitel 6 Lessons learned ist ein weiteres Beispiel fr die Ableitung
der Service Management-Prozess-Ziele aus der IT-Strategie und der BSC
zu entnehmen.

119

3 IT Prozess-Management
Eine weitere Quelle fr die Definition der Prozessziele der IT Service Management-Prozesse, damit deren Kennzahlen und Sollwerte, sind die Ergebnisse der Prozess Improvement Plne (PIPs). In diesen Plnen ist
prozessbezogen der jeweils identifizierte Verbesserungsbedarf der IT Service Management-Prozesse dokumentiert (siehe Abbildung 42). Der Verbesserungsbedarf wird im Rahmen von Audits und Reviews sowie anhand der vorliegenden Prozess-Kennzahlen, deren Sollwerten und der
nachfolgenden Analysen des Prozesses ermittelt.
Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

SLA
(OLA/UC)

Neue oder
vernderte
IT-Services

KundenAnforderungen

GeschftsAnforderungen

ITStrategie

Kapazitten
Service
Improvement
Plan
(SIP)
Verbesserungspotenzial

Prozess
Improvement
Plne
(PIP)
Verbesserungspotenzial

IT Service
ManagementProzesse

Abbildung 42:

Definition der Prozessziele Prozess Improvement Plan

Diese Informationen sind der Input fr die Planung und Implementierung des IT Service Managements (siehe Abbildung 43). Im Rahmen der
Planung und Implementierung des IT Service Managements wird die
Ausgestaltung des gesamten Systems durchgefhrt. Dazu zhlt auch die
Festlegung der Ziele fr die einzelnen Service Management-Prozesse.

120

3.4 Definition der Prozessziele und -Kennzahlen


Diese bergeordnete Management-Aufgabe ist nicht als einmaliger Vorgang zu verstehen, sondern sie ist eine fortlaufende Aktivitt und entspricht dem kontinuierlichen Verbesserungsprozess gem PDCA-Zyklus.
Die Planung und Implementierung des IT Service Managements ist kein Projekt,
sondern ein bergeordneter Management-Prozess.
Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

SLA
(OLA/UC)

Neue oder
vernderte
IT-Services

KundenAnforderungen

GeschftsAnforderungen

ITStrategie

Kapazitten
Service
Improvement
Plan
(SIP)
Verbesserungspotenzial

Planung und
Implementierung
des IT Service
Managements

Prozess
Improvement
Plne
(PIP)
Verbesserungspotenzial

IT Service
ManagementProzesse

Abbildung 43:

Definition der Prozessziele Planung und Implementierung

Mit diesem bergeordneten Management-Prozess wird sichergestellt, dass


die IT Service Management-Prozesse auf die Geschftsziele und daraus
abgeleitete IT-Strategie ausgerichtet sind. Durch die kontinuierliche Anpassung an eine sich ndernde Umgebung und durch die laufende Erfolgsberprfung wird die Nachhaltigkeit der implementierten Prozesse
sichergestellt.
Das Ergebnis der Planung und Implementierung des IT Service Managements sind die Zielvorgaben fr die einzelnen IT Service ManagementProzesse. Diese Vorgaben sind ein Teil des dokumentierten Service Ma-

121

3 IT Prozess-Management
nagement Plans (SMP). Whrend im Service Improvement Plan (SIP) die
identifizierten Serviceverbesserungen definiert sind, enthlt der Service
Management Plan (SMP) die Dokumentation des aktuellen IT Service Management-Systems. Dieser SMP wird als Dokumentation von der
ISO 20000 gefordert.
Zustzlich flieen die Ergebnisse aus Planung und Implementierung des
IT Service Managements in die Prozess-Management Plne (PMPs) ein
(siehe Abbildung 44). Durch die PMPs werden auf Prozessebene die bergeordneten Managementziele fr den jeweiligen Prozess konkretisiert. Der
PMP kann als Prozessdokumentation mit allen notwendigen Informationen wie Prozessbeschreibung, Kennzahlen und deren Zielwerte, etc. angesehen werden.
Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

SLA
(OLA/UC)

Neue oder
vernderte
IT-Services

KundenAnforderungen

GeschftsAnforderungen

ITStrategie

Kapazitten
Service
Improvement
Plan
(SIP)
Verbesserungspotenzial

Planung und
Implementierung
des IT Service
Managements
Anforderungen

Service
Management
Plan
(SMP)

Abbildung 44:

122

Prozess
Improvement
Plne
(PIP)
Verbesserungspotenzial

Anforderungen

IT Service
ManagementProzesse

Prozess
Management
Plne
(PMP)

Definition der Prozessziele Service Management Plan

3.4 Definition der Prozessziele und -Kennzahlen


Der hier beschriebene Managementansatz mag zunchst komplex und
administrativ erscheinen, aber er stellt letztendlich die wirksame Ausrichtung des IT Service Managements sicher und sorgt fr einen zielgerichteten Einsatz der Ressourcen. Die Verantwortung fr diesen bergeordneten
Prozess liegt beim Top-Management der IT-Organisation in der Rolle des
Service Managers.
Der Service Manager fhrt diese Aufgaben durch und stellt das bergeordnete
Management-System sicher.

Ein Prozess-Management fhrt mittel- und langfristig zu Erfolgen. Gegebenenfalls sind Quick-Wins abhngig von der bestehenden Ist-Situation
zu erzielen, sie stehen aber nicht im Fokus eines Prozess-Managements.
Der hier beschriebene konzeptionelle Management-Ansatz erfllt die Anforderungen der ISO 20000.
Dieser Management-Ansatz stellt sicher, dass die konkrete Zielsetzung der einzelnen IT Service Management-Prozesse aus den Geschftsanforderungen stringent abgeleitet wird. Im nchsten Kapitel wird dargestellt, wie die Kennzahlen
und Sollwerte auf Basis der Zielsetzung definiert werden. Damit wird letztendlich sichergestellt, dass die Kennzahlen unmittelbar oder mittelbar mit den Geschftsanforderungen der Kunden korrespondieren.

Die ISO 20000 dokumentiert die Anforderungen an dieses ManagementSystem und kann zum Nachweis der Konformitt herangezogen werden
(siehe Abbildung 45). Die konkrete Umsetzung ist Projektaufgabe.
Es knnen zwar dezentral einzelne Service Management-Prozesse implementiert werden und einzelne beschriebene Aktivitten umgesetzt werden,
aber die Etablierung eines IT Service Managements verlangt unabdingbar
das Management-Commitment und eine Integration in die bestehenden
Management-Prozesse sowie in die IT-Strategie.

123

3 IT Prozess-Management
Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

SLA
(OLA/UC)

Neue oder
vernderte
IT-Services

KundenAnforderungen

GeschftsAnforderungen

ITStrategie

Kapazitten
Service
Improvement
Plan
(SIP)
Verbesserungspotenzial

Konformitt

ISO 20000
IT Service
Management

Anforderungen

Service
Management
Plan
(SMP)

Abbildung 45:

3.4.2
Die Prozessdokumentation stellt die
Leitlinien dar.

Planung und
Implementierung
des IT Service
Managements

Prozess
Improvement
Plne
(PIP)
Verbesserungspotenzial

Anforderungen

IT Service
ManagementProzesse

Prozess
Management
Plne
(PMP)

Konformitt des Managementsystems

Definition der Prozess-Kennzahlen

Auf der Basis der definierten Ziele sind die Control Objectives zu spezifizieren, die Prozessaktivitten zu definieren und die kritischen Erfolgsfaktoren zu ermitteln. Das Prozessdesign erfolgt letztendlich auf der Basis
der zuvor festgelegten Prozessziele (siehe Abbildung 46).
Der Umfang der zu erstellenden Prozessdokumentation ist abhngig von
der jeweiligen Unternehmenskultur. Es ist ein Kompromiss zu finden zwischen der Dokumentation notwendiger Informationen und Vorgaben einerseits und einem ausreichenden Gestaltungsspielraum fr die Mitarbeiter andererseits.
Hier sollte nicht der Anspruch bestehen, dass der erste Entwurf alle Eventualitten abdeckt und fehlerfrei ist. Erfahrungsgem ergibt sich im tglichen Betrieb ein Optimierungsbedarf. Diese Einstellung und Erwartungshaltung sollte auch gegenber den Mitarbeitern kommuniziert werden.

124

3.4 Definition der Prozessziele und -Kennzahlen


Die Mitarbeiter sollten aufgerufen werden, den notwendigen Verbesserungsbedarf zu identifizieren und an den Prozess Manager weiterzugeben.
Es darf nicht an fehlerhaften Ablufen festgehalten werden. Allerdings
sind notwendigen Abweichungen in die richtigen Bahnen zu lenken und
nderungen mssen Einzug in die Prozessdokumentation finden.
Service
Management
Plan
(SMP)

Prozess
Management
Plan
(PMP)

IT Service
ManagementProzesse

Wird sichergestellt durch

Aktivitten
Kritische Erfolgsfaktoren
Control Objectives
Abbildung 46:

Prozess-Management Prozessdesign

Zeitgleich mit dem Prozessdesign und vor der Implementierung sind die
Kriterien festzulegen, die die berprfung des Prozesses sicherstellen.
Zunchst geht es darum zu berprfen, ob die definierten Prozessziele
erreicht werden. Das heit, es wird die Effektivitt des Prozesses berprft.
Darber hinaus gilt es im Rahmen der Prozessdurchfhrung festzustellen,
ob und wie die definierten Prozessaktivitten durchgefhrt werden und
ob die Control Objectives und die kritischen Erfolgsfaktoren sichergestellt
werden.
Diese berprfungen knnen mit Kennzahlen und den zugehrigen Sollwerten, Reviews und Audits durchgefhrt werden. Dabei gehen die Ergebnisse aus den durchgefhrten Reviews und Audits wiederum in Kennzahlen ein (siehe Abbildung 47).
Mit diesen berprfungen wird die Wirksamkeit des Prozesses, betrachtet
in den Dimensionen Effektivitt und Effizienz, sichergestellt.
Die Kennzahlen stehen in einem unmittelbaren Bezug zu den Prozesszielen. Die
Kennzahlen und die damit verbundenen Sollwerte werden aus den Prozesszielen abgeleitet.

125

3 IT Prozess-Management
Service
Management
Plan
(SMP)

IT Service
ManagementProzesse

Prozess
Management
Plan
(PMP)
Wird sichergestellt durch
Aktivitten
Kritische Erfolgsfaktoren
Control Objectives

berprfen /
Verbessern

Kennzahlen
(KPI, KGI)
Abbildung 47:

Reviews/
Audits

Prozess-Management berprfung

Bei der Ausgestaltung (Prozessdesign) der Prozesse und der Definition der
Kennzahlen (KGI, KPI), sowie bei den durchzufhrenden Audits und Reviews untersttzten die Best Practices von COBIT und ITIL (siehe
Abbildung 48). Diesen Publikationen knnen entsprechende praxiserprobte Empfehlungen entnommen werden. Unter Umstnden knnen
aber zu den definierten Prozesszielen keine entsprechenden Kennzahlen
aus COBIT und ITIL entnommen werden. In diesem Falle mssen die entsprechenden Kennzahlen und deren Zielwerte im Rahmen des Prozessdesigns definiert werden.
COBIT und ITIL enthalten dokumentierte Best Practices fr Kennzahlen. Es ist
aber ein Irrglaube, diese Kennzahlen einfach bernehmen zu knnen. Vielmehr
sind zunchst die Prozessziele zu definieren. Aus den Prozesszielen werden
Kennzahlen und Sollwerte abgeleitet. Dabei knnen die Best Practices entsprechend untersttzen und herangezogen werden.

126

3.4 Definition der Prozessziele und -Kennzahlen


Service
Management
Plan
(SMP)

IT Service
ManagementProzesse

Prozess
Management
Plan
(PMP)
Wird sichergestellt durch
Aktivitten
Kritische Erfolgsfaktoren
Control Objectives

berprfen /
Verbessern

Kennzahlen
(KPI, KGI)

Reviews/
Audits

Best Practice

COBIT

Abbildung 48:

ITIL

Prozess-Management Nutzung von COBIT und ITIL

Sind die Kennzahlen und Zielwerte definiert, so empfiehlt es sich, als Qualittscheck zu prfen, ob von der Kennzahl eine unmittelbare oder mittelbare Verbindung zu einem Geschftsziel besteht.

Mchte die IT-Organisation die Konformitt mit der ISO 20000 nachweisen, so knnen der ISO 20000-1 (vgl. [ISO 20000-1, 2005]) die Anforderungen entnommen werden, die vom jeweiligen Prozess sichergestellt und
nachgewiesen werden mssen (siehe Abbildung 49).

127

3 IT Prozess-Management
Service
Management
Plan
(SMP)

IT Service
ManagementProzesse

Prozess
Management
Plan
(PMP)
Wird sichergestellt durch
Aktivitten
Kritische Erfolgsfaktoren
Control Objectives

berprfen /
Verbessern

Kennzahlen
(KPI, KGI)

Reviews/
Audits

Best Practice
Konformitt
ITIL

COBIT

Abbildung 49:

ISO 20000

Prozess-Management Konformitt

Die Kennzahlen und deren laufende berprfung stellen die Basis fr die
gegebenenfalls notwendigen Verbesserungen der Prozesse dar. Ohne ausreichende Messung kann letztendlich keine zielgerichtete Verbesserung
erreicht werden. Die Ergebnisse dieser Verbesserungsphase finden Einzug
in dem Prozess Improvement Plan PIP (siehe Abbildung 50).

128

3.4 Definition der Prozessziele und -Kennzahlen


Service
Management
Plan
(SMP)

Prozess
Improvement
Plan
(PIP)

IT Service
ManagementProzesse

Prozess
Management
Plan
(PMP)
Wird sichergestellt durch
Aktivitten
Kritische Erfolgsfaktoren
Control Objectives

berprfen /
Verbessern

Kennzahlen
(KPI, KGI)

Reviews/
Audits

Best Practice
Konformitt
COBIT

Abbildung 50:

ITIL

ISO 20000

Prozess-Management Prozess Improvement Plan

Der hier beschriebene Managementansatz entspricht der Methode, die in


der ITIL Version 3 empfohlen wird und in Continual Service Improvement
[OGC, 2007e] beschrieben ist. Aus der bergeordneten Vision werden die
Ziele definiert und mittels Kennzahlen gemessen. Dies stellt die nachfolgende Abbildung 51 aus [OGC, 2007e] dar.

129

3 IT Prozess-Management
Vision
Mission
Ziele
Objectives

CSFs

KPIs

Metriken
Messungen
Abbildung 51:

3.4.3

Entwicklung von Kennzahlen

Dokumentation der Prozess-Kennzahlen

Fr die Dokumentation empfiehlt es sich, die Kennzahl mit der entsprechenden Definition, der Messmethode und anderen relevanten Informationen zu dokumentieren. Dazu bietet sich die Dokumentation in Form
eines Kennzahlen-Steckbriefes an.

130

3.4 Definition der Prozessziele und -Kennzahlen

Bestandteil des Steckbriefs

Beschreibung

Kennzahl

Bezeichnung der Kennzahl

IT Service Management-Prozess

Prozess, der diese Kennzahl nutzt

Beschreibung

Beschreibung der Kennzahl, ihrer


Aussagekraft und des mit dieser
Kennzahl zu berprfenden Prozesszieles

Zielwert

Zielwert der Kennzahl, der sich aus


der Zieldefinition fr den Prozess
ergibt

Beziehung zu anderen Prozessen

Prozesse, die diese Kennzahl beeinflussen

Datenquelle

Beschreibung der Quelle fr die


zugrunde liegenden Daten

Formel

Berechnungsmethode
zahl

Erhebungsfrequenz

Festlegung, wann/wie oft die Kennzahl fortgeschrieben wird

Auditfrequenz

Festlegung, wann/wie oft die Kennzahl hinsichtlich ihres Nutzen und


ihrer Verwendung berprft wird

Anmerkungen

Zusatzinformationen

der

Kenn-

Bei Bedarf knnen weitere Informationen wie zum Beispiel Empfnger


der Kennzahl, Risiken, etc. aufgenommen werden.
Im Rahmen der Prozessdokumentation ist zu prfen, wie der KennzahlenSteckbrief zu dokumentieren ist. Es empfiehlt sich, die Beschreibung der
Kennzahlen in den Service Management-Plan (SMP) aufzunehmen.

3.4.4

Reporting der Prozess-Kennzahlen

An der Zieldefinition und der Ausrichtung der IT Service ManagementProzesse sind verschiedene Management-Ebenen beteiligt. In einem top
down-Ansatz erstreckt sich dieser Prozess vom Top-Management bis zum
Prozess Manager.

131

3 IT Prozess-Management
Kennzahlen
mssen ebenengerecht sein.

So unterschiedlich die beteiligten Managementebenen sind, so unterschiedlich ist auch deren Informationsbedarf hinsichtlich der etablierten IT
Service Management-Prozesse und der erbrachten Services. Der Prozess
Manager bentigt im Rahmen seiner Durchfhrungsverantwortung verschiedene Kennzahlen (KGI, KPI), die ihm detaillierte Informationen bezglich der Erreichung der einzelnen Prozessziele und der planmigen
Prozessdurchfhrung aufzeigen.
Das Top-Management mchte dagegen auf einen Blick sehen, ob das IT
Service Management erfolgreich ist, ohne selbst den Zusammenhang aus
verschiedenen Kennzahlen herleiten zu mssen. Das Top-Management
bentigt also eine Gesamtsicht auf die Prozesse und Services.
Die Kennzahlen mssen ebenengerecht aufbereitet und prsentiert werden.

Diese Anforderung des ebenengerechten Reportings lsst sich fr die Rollen des Prozess Managers und zum Teil des Prozess Owners leicht umsetzen. Die fr diese Rollen bentigten Kennzahlen sind die, die im Rahmen
des Prozessdesigns zur berprfung des Prozesses definiert wurden. Die
Kennzahlen hierzu sind als KPIs bzw. KGIs in COBIT und ITIL dokumentiert.
Anders verhlt es sich, wenn eine Gesamtbewertung knapp und przise
erfolgen muss. Dies ist beispielsweise immer der Fall, wenn der Service
Manager eine bersicht bentigt bzw. an das Top (IT-) Management berichtet. Nehmen wir an, die Fragestellung wrde lauten: Hat der Prozess
Change Management seine Zielsetzung erfllt? Dann mssen die ProzessKennzahlen zu einer Kennzahl zusammengefasst werden. Hierfr sind die
einzelnen Kennzahlen zu gewichten und zu aggregieren So ist es fr die
Beurteilung seitens des Service Managers zunchst wichtig, zu erkennen,
ob alle Services und alle Prozesse die Zielsetzung erfllen - ob sie im
grnen Bereich sind.
Am Beispiel des Change Managements knnte sich eine zusammengesetzte Kennzahl zum Prozess durch die Gewichtung der einzelnen Ziele
und der damit verbundenen Kennzahlen wie folgt ergeben (siehe
Abbildung 52):

132

3.4 Definition der Prozessziele und -Kennzahlen


Anteil fehlerfreier
Changes
Anteil termingerechter Changes

60%

20%

Effektivitt
Change Management

Anteil kostengerechter Changes

20%

Anteil zurckgewiesener Changes

40%
Effektivitt
Change Management

Anteil der
Notfall-Changes
Abbildung 52:

70%

Zielerreichung
Change Management

30%

60%

Zusammengesetzte Prozess-Kennzahlen

Es ist zu empfehlen, Gesamtzusammenhnge beispielsweise in Form einer


Ampel darzustellen. Dabei ist es in den meisten Fllen so, dass in die
Ampelbewertung auch qualitative Dinge einflieen.
So knnte sich zum Beispiel eine Gesamtbersicht der Zielerreichung aller
SLAs sich wie folgt (Abbildung 53) darstellen:

Abbildung 53:

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

Die operativen Systeme, wie zum Beispiel die Tool-Untersttzung fr das


Change Management, liefern die notwendigen Basis-Informationen, aus

133

3 IT Prozess-Management
denen durch entsprechende Datenselektionen und Aggregation die
Prozess-Kennzahlen gewonnen werden knnen.
Durch weitere Aggregationen erhalten dann der Service Manager und das
Mittlere sowie das Top Management die notwendigen Informationen.
Dabei sind aber nicht nur Kennzahlen zu den IT Service ManagementProzessen zu kreieren, sondern auch die erfolgreiche Umsetzung der im
Service Management Plan (SMP) und Service Improvement Plan (SIP)
festgelegten Verbesserungsmanahmen zu belegen (siehe Abbildung 54).

Top Management

Prozess
Management

gewichtete
Kennzahlen

ProzessKennzahlen
(KGI, KPI)

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

Service
Service
Improvement Management
Plan
Plan

Das IT Service Management Kennzahlensystem

Generell empfiehlt es sich, auf allen Hierarchieebenen fr das Reporting


auf grafische Elemente zurckzugreifen und Kennzahlen in den Ampelfarben darzustellen, nach dem Motto Ein Bild sagt mehr als tausend Worte.
Hierzu wird der dargestellte Wert in Abhngigkeit der Sollwerte entsprechend farbig dargestellt oder grafisch animiert. Dazu knnen zum Beispiel
Ampelsymbole oder Tachoscheiben herangezogen werden.

134

3.4 Definition der Prozessziele und -Kennzahlen


Werden zu den absoluten Werten noch die Sollwerte und ein Trend ausgewiesen, so knnen die Prozess-Kennzahlen kompakt und dennoch informativ dargestellt werden.
Abbildung 55 und Abbildung 56 zeigen ein anonymisiertes Projektbeispiel
zum Reporting von Prozess-Kennzahlen. Die erste Seite zeigt die Gesamtbetrachtung und den Trend des Prozesses, whrend auf der zweiten Seite
die einzelnen Prozess-Kennzahlen, deren Sollwerte und Trends ausgewiesen werden.

Incident
Management
Berichtsmonat: 04/2007

Prozent
110
105
100
95
90
1

10

11

12

Monat/2007

Zielerreichung in Prozent
Abbildung 55:

Exemplarischer Prozess-Bericht Deckblatt zum Report

135

3 IT Prozess-Management

70

Erstlsungsquote in %

65
60

Soll

Erstlsung

Ist

60% 62%

55
50
1

10

11

12

Monat/2007
Anzahl Major Incidents

8
6
4

Major
Incident

Soll

Ist

0
1

10

11

12

Monat/2007

Lsungszeit Soll
Prio 1 2
Prio 2 4

15

Ist

1,9
4,1

Lsungszeit in Std.

10
5
0
1

10

11

12

Monat/2007

Abbildung 56:

Exemplarischer Prozess-Bericht Darstellung der Kennzahlen

Die Hersteller von Tools haben den Bedarf fr eine bersichtliche, abgestufte Darstellung erkannt und bieten hierzu so genannte ManagementCockpits an. Ein Beispiel gibt die folgende Abbildung 57.

136

3.5 Von der Kennzahl zur Verbesserungsmanahme

Abbildung 57:

Darstellung des Management Cockpits von iET Solutions

3.5 Von der Kennzahl zur Verbesserungsmanahme


Die definierten Kennzahlen mit ihren jeweiligen Zielwerten, beschrieben
als KGI (Key Goal Indicator) oder KPI (Key Performance Indicator), sollen
erkennbar machen, dass ein Zielwert bzw. Prozessziel nicht erreicht wird.
In Verbindung mit Trenddaten soll aufgezeigt werden, dass die Erreichung eines Prozesszieles gefhrdet ist.
Dabei kann der Indikator lediglich etwas aufzeigen. Die eigentliche Ursache ist vom Prozess Manager festzustellen.
So kann dem Prozess Manager zum Beispiel aufgezeigt werden, dass sich
die Erstlsungsquote im Incident Management verschlechtert (siehe
Abbildung 58).

137

3 IT Prozess-Management

Abbildung 58:

Beispiel fr eine Trenddarstellung

Der Prozess Manager hat durch detaillierte Auswertung festzustellen,


warum sich die Erstlsungsquote verschlechtert. Hierzu muss der Prozess
Manager analytisch ttig werden, indem er versucht, verschiedene Einflussfaktoren zu untersuchen, die einen mglichen Einfluss auf die Erstlsungsquote haben. Angenommen, ein neuer IT Service wurde eingefhrt,
knnte die Betrachtung der Erstlsungsquote in Abhngigkeit von dem
durch die aufgetretene Strung betroffenen IT Service sein hilfreich sein
(siehe Abbildung 59).
Hierzu wird die vorherige Auswertung der Erstlsungsquote in Abhngigkeit vom betroffenen Service ausgewertet. In diesem Beispiel zeigt die
Auswertung eine schlechter werdende Erstlsungsquote fr die Services
eMail und Kfz-Dialog.

138

3.5 Von der Kennzahl zur Verbesserungsmanahme

Abbildung 59:

Beispiel 1 fr eine Analyse mglicher Ursachen

In einem weiteren Analyseschritt knnte der Prozess Manager dann zum


Beispiel auswerten, ob sich hierzu die zugrunde liegenden Fehlerursachen
verndert haben (siehe Abbildung 60).
Der Prozess Manager bentigt fr diese weitergehenden Analysen nicht
nur Prozess-Know-how sondern auch umfangreiche Erfahrungen im tglichen Betrieb und das Wissen um mgliche Abhngigkeiten.
Die mglichen Ursachen sind nicht immer offensichtlich, sondern erfordern analytisches Vorgehen Detektivarbeit. Dabei ist eine geeignete
Tooluntersttzung von groem Vorteil. Das eingesetzte Tool sollte ber
variable Drill-Down-Mglichkeiten verfgen, sodass Analysen und deren
Richtung situativ durchgefhrt werden knnen.

139

3 IT Prozess-Management

Abbildung 60:

Beispiel 2 fr eine Analyse mglicher Ursachen

3.6 Kennzahlen mssen reifen


So wie die IT Service Management-Prozesse sich entwickeln und reifen
mssen, so mssen auch die Kennzahlen reifen.
Werden noch keine Prozesse gemessen, so empfiehlt es sich zunchst, die
wichtigsten Prozessziele mit Kennzahlen zu hinterlegen. Mit diesen Kennzahlen kann das Managementsystem aufgebaut werden und es knnen
erste Erfahrungen gesammelt werden.
Liegen noch keine gesicherten Informationen zu einem Prozess vor, so
muss sich der Prozess Manager zunchst einen Eindruck ber das zu bewltigende Volumen im Prozess verschaffen. Welche Inputs hat der Prozess zu bewltigen? Zum Beispiel: Wie viele Incidents sind zu bearbeiten
oder wie viele Changes sind auszufhren? Werden diese Vorgnge fr das
Incident, Problem und Change Management in Kategorien und Prioritten
unterteilt, so liegen bereits erste wichtige Informationen vor.

140

3.7 Der Umgang mit Kennzahlen


Die Informationen zum Umfang des Inputs sind auch fr die spteren
Auswertungen als Referenzgre von groer Bedeutung. Mgliche Vernderungen in den ermittelten Kennzahlen lassen sich hufig auf einen
vernderten Input zurckfhren.
Zunchst gilt es, das Volumen des Inputs (Durchsatz) zu messen. Die Gre ist
auch fr vergleichende Betrachtungen von groer Bedeutung.

Eine weitere wichtige Betrachtung fr den Prozess Manager ist die zeitliche Entwicklung. Trendinformationen knnen frhzeitig Handlungsbedarf aufzeigen und ermglichen es, Manahmen zu ergreifen, bevor die
Sollwerte unter- bzw. berschritten werden.
Damit Trends dargestellt werden knnen, ist eine Stabilitt im Kennzahlensystem notwendig. Sobald Kennzahlen vorliegen, sollten nderungen
der Berechnungsmethoden sorgsam geprft werden.
Die Berechnungsgrundlagen der Kennzahlen sollten nur nach sorgsamer Prfung verndert werden. Ansonsten knnen keine verlsslichen Trends ausgewertet werden.

Die Prozesse sind hinsichtlich ihrer Zielerreichung (Key Goal Indicator =


Effektivitt) und ihrer Leistungsfhigkeit (Key Performance Indicator =
Effizienz) zu messen. Dabei steht die Zielerreichung, die Betrachtung des
Outputs, im Vordergrund. Demzufolge gilt es, sich zunchst auf die Einfhrung dieser Kennzahlen zu konzentrieren.
Im Anschluss knnen diese Kennzahlen um Kennzahlen fr eine Betrachtung der Effizienz erweitert werden.
Die Anzahl genutzter Kennzahlen sollte im eingeschwungenen Zustand pro Prozess bei maximal zwischen 10-15 Kennzahlen liegen.

3.7 Der Umgang mit Kennzahlen


Die Kennzahlen dienen primr als Management-Werkzeug fr den Prozess Manager und den Prozess Owner. Diese knnen anhand der Kennzahlen erkennen, ob die Prozessziele erreicht werden und ob der Prozess
wirkungsvoll durchgefhrt wird. Darber hinaus untersttzen die Kennzahlen den Prozess Manager bei der Identifizierung eines mglichen Verbesserungspotenzials, bei der Darstellung komplexer Sachverhalte und bei
der Begrndung mglicher Vernderungsmanahmen.
Durch die Definition einer Kennzahl stellt das Prozess-Management die Bedeutung der damit verbundenen Aktivitten heraus.

141

3 IT Prozess-Management
Die Organisation wird demzufolge ihr Handeln auf die Erreichung des
festgelegten Sollwerts fr die Kennzahl ausrichten. Dieses Ziel wird jedoch
auch dann angestrebt werden, wenn sich dies fr das Unternehmen
nachteilig auswirken sollte! Wird beispielsweise fr den Service Desk eine
maximale Bearbeitungszeit von 5 Minuten pro Telefonat als Zielwert vorgegeben, so werden die Mitarbeiter sich an dieser Kennzahl orientieren.
Die Telefonate werden innerhalb dieser Zeit abgeschlossen, auch wenn
eine mgliche Strung innerhalb der nchsten 30 Sekunden gelst werden
knnte.
Das Verhalten der Mitarbeiter wird sich an den festgelegten Kennzahlen orientieren.

Der Prozess Manager muss sich dieses Verhaltens bewusst sein. Eine Mglichkeit, dem zu begegnen besteht darin, mit einer anderen Kennzahl negativen Auswirkungen entgegen zu wirken.
Viel wichtiger ist es aber, den Nutzen der Kennzahlen in der Organisation
herauszustellen.
Die Kennzahlen drfen nicht als Bedrohung sondern mssen als Chance verstanden werden.

Werden dem Top-Management einzelne Kennzahlen berichtet, so muss


das Top-Management auch die Prozessziele der damit verbundenen IT
Service Management-Prozesse kennen und verstehen. Ansonsten besteht
die groe Gefahr, dass aus den bermittelten Kennzahlen falsche Schlsse
gezogen werden. Was an dieser Stelle als Selbstverstndlichkeit verstanden werden kann, hat in einigen Organisationen zu erheblichen Schwierigkeiten gefhrt. Die Aufgabe des Problem Managements besteht zum
Beispiel darin, Probleme zu identifizieren. Steigt die Kennzahl der identifizierten Probleme, so ist dies ein Indikator fr einen gut funktionierenden
Problem Management-Prozess. Es wre dagegen fatal, wenn das Management die wachsende Zahl identifizierter Probleme falsch interpretiert
und dem Problem Management negativ anlastet.

142

4 IT Kennzahlensysteme
4.1 Management Summary
Die IT eines Unternehmens lsst sich nur dann erfolgreich steuern, wenn
verlssliches Material ber Zahlen und Fakten verfgbar ist. Zum einen
mssen diese Informationen die Situation der IT-Organisation realittstreu
widerspiegeln, zum anderen mssen Sie Anreize fr die Vernderungen
schaffen.
Dies ist die Aufgabe von Kennzahlensystemen. In der IT gibt es wahrscheinlich so viele Kennzahlen wie in keinem anderen Bereich. Ein nur
durchschnittlich ausgeprgtes Monitoring der IT-Systeme ber System
Management-Werkzeuge stellt mit Leichtigkeit schon Hunderte von
Kennzahlen bereit und das regelmig, in vielen Fllen im Minutentakt.
Wichtig ist es daher, zu hinterfragen, was eine einzelne Kennzahl bezglich der Gesamtsituation aussagt.
Im Allgemeinen bentigt 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 unterschtzende Aufgaben darstellen.
Durch Interessenkonflikte innerhalb von Unternehmen sowie die hufig
asymmetrische Informationsverteilung zwischen den Beteiligten wird die
bentigte Objektivitt zur entscheidenden Herausforderung. Die Kunst
liegt darin, ein IT-Kennzahlensystem zu konstruieren, das einen przisen
und zeitnahen berblick liefert, das sich nicht manipulieren lsst und das
mglichst geringe Kosten verursacht.
Es gibt einige verffentlichte IT-Kennzahlensysteme. Mgen diese auch
noch so exzellent in ihrer Ausprgung, Tiefe und Methodik sein. Eins
bleibt festzuhalten: Kein IT-Kennzahlensystem lsst sich Eins zu Eins von
einer IT-Organisation auf eine zweite bertragen. Der Hauptgrund liegt
darin, dass der Betrieb eines Kennzahlensystems immer auch einen strategischen Effekt erzielt. Dies ist zwangslufig so unabhngig davon, ob
es von Anfang an beabsichtigt war oder nicht.
Die strategische Positionierung der IT hinsichtlich ihrer Auen- und Innenwirkung ist CIO-Sache. Kennzahlensysteme bilden hierfr eine entscheidende Basis, nicht nur als Steuerungs- sondern insbesondere als
Kommunikationsinstrument.

143

4 IT Kennzahlensysteme

4.2 Ziele
Fr Unternehmen steht heute nicht mehr zur Diskussion, dass Effizienz
und Effektivitt ihrer Organisationseinheiten objektiv, przise und zuverlssig ermittelt werden mssen. Dies gilt fr IT-Organisationen im Besonderen. Das frhzeitige Erkennen von Problemen und Verbesserungspotenzialen ist eine wichtige Voraussetzung fr den Erfolg der IT.
An dieser Stelle setzen Kennzahlensysteme an. Sie ermglichen 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 hierfr liegt darin,
dass Kennzahlen, um effektiv zu sein, die folgenden Voraussetzungen
erfllen mssen:
Eine Kennzahl muss objektiv erfassbar sein, um eine zuverlssige
und unverzerrte Darstellung der Situation zu ermglichen. Die
verwendeten Begriffe zur Beschreibung der Kennzahl mssen eindeutig und fr alle Beteiligten verstndlich sein und von diesen akzeptiert werden.
Der Aufwand zur Erfassung einer Kennzahl sollte gering sein, um
eine mglichst hufige, schnelle und preiswerte Ermittlung zu ermglichen. Auch sollte eine zeitnahe Erfassung mglich sein. Idealerweise wird die Kennzahl automatisch erfasst und gespeichert.
Kennzahlen mssen das Entstehen von Fehlanreizen verhindern:
Durch Kennzahlen ausgelste positive Entwicklungen mssen begnstigt und negative sanktioniert werden. Die Kennzahlen sollten
nicht manipulierbar sein.
Kennzahlen, die in einem bestimmten Bereich oder Prozess erhoben
werden, sollten effektiv von diesem Bereich oder Prozess kontrollierbar sein. Andernfalls liefern sie ein falsches Bild der tatschlichen Leistung oder Kosten.

Beispiel: Anwenderzufriedenheit
Viele Unternehmen evaluieren die Anwenderzufriedenheit mit der IT ber
Fragebgen1 oder CAPIs2.
Aber mit welcher Fragestellung lsst sich die Anwenderzufriedenheit ermitteln?

Diese werden auch User Quality Surveys genannt.

CAPI steht fr Computer Assisted Personal Interview.

144

4.2 Ziele
Eine direkte Frage nach der Zufriedenheit mit der IT fhrt zu wenig
brauchbaren Resultaten, da Anwender hufig keinen berblick ber die
Gesamtleistung der IT haben. Stattdessen rcken ungewollte Aspekte in
den Vordergrund.
Die Anwenderzufriedenheit ist durch die IT-Organisation selbst oft
schwer zu beeinflussen, da sie von nicht-kontrollierbaren Dingen abhngen 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 ntzen und
von der IT gegebenenfalls professionell umgesetzt werden, ziehen Sie die
Bewertung der IT nach unten. Hinzu kommt, dass der Anwender hufig
eine andere Erwartung an den IT Service hat als seine Vorgesetzten, die
Vereinbarungen in Form von SLAs mit dem IT Service Provider abgeschlossen haben. Dem Anwender sind zum Teil diese SLAs mit den Service Level Targets gar nicht bekannt. Auch wenn der IT Service Provider
diese Anforderungen vollstndig erfllt, 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 Interpretationsmglichkeiten. Ein Service Desk, der wenig kontaktiert wird, kann eine
hohe Anwenderzufriedenheit im Sinne Alles luft 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 sorgfltig ausgewhlte Kennzahlen gegenseitig ergnzen, um ein mglichst ausgewogenes und przises Gesamtbild zu
liefern.

Genauso wie einzelne Kennzahlen sollte ein gutes Kennzahlensystem Anforderungen erfllen:
Der Informationszugewinn, der aus einem Kennzahlensystem im
Vergleich zu einzelnen Kennzahlen entsteht, hngt davon ab, wie
sehr sich die Kennzahlen voneinander unterscheiden.
Auch die Gre des Kennzahlensystems ist entscheidend. Zunchst
fhrt jede zustzliche Kennzahl zu einem Informationsgewinn, sofern sie optimal eingesetzt wird. Dieser wird aber mit wachsenden

145

4 IT Kennzahlensysteme
Systemen immer geringer. Es kommt also darauf an, das Kennzahlensystem mit optimaler Gre auszulegen.3

Beispiel: Anwenderzufriedenheit (Fortsetzung)


Die beiden Kennzahlen Befragung und die Kontakthufigkeit, die wir
oben vorgeschlagen hatten, sind beide fr sich genommen zur Bestimmung der Anwenderzufriedenheit mit der IT wenig geeignet. Sie sind
entweder nicht przise genug oder knnen negative Effekte bewirken.
Durch die Kombination der beiden Kennzahlen erhlt man aber ein prziseres Ma, das weniger fehler- und zufallsanfllig ist. Auch wird eine Manipulation der resultierenden Kennzahl deutlich schwieriger und aufwendiger.
Durch weitere Kennzahlen liee sich dieses Kennzahlensystem nun
verbessern, bis der gewnschte Kompromiss aus Informationsgehalt und
Kosten des Systems erreicht ist. Doch bei der Auswahl neuer Kennzahlen
ist Vorsicht geboten.
Zunchst liegt der Gedanke nahe, den Mitarbeitern weitere Fragen zu
anderen Aspekten ihrer Zufriedenheit zu stellen. Whrend dies im Einzelfall ntzlich 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 zustzlichen Aufwand
kaum ein Informationsgewinn gegenber.
Als Erfolg versprechend knnte sich hingegen die Analyse des Anwenderverhaltens erweisen. Falls sich beispielsweise deren Produktivitt im
Umgang mit ihrer IT-Umgebung messen liee, so knnte dies auf deren
Zufriedenheit schlieen lassen. Auch eine Aufschlsselung der Kontakthufigkeit mit dem Service Desk nach Ursache (Incident, Service Request,
Request for Change usw.) knnte sich als wertvoll erweisen.

Wegen des Verhltnisses von Grenzkosten und Grenznutzen.

146

4.3 berblick

4.3 berblick
In den letzten 30 Jahren sind einige Vorschlge fr IT-Kennzahlensysteme
entwickelt und verffentlicht 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 Vollstndigkeit, sondern verfolgen vielmehr das Ziel, dem Leser eine grobe Vorstellung ber den Aufbau
von Kennzahlensystemen zu geben.
Jedes Kennzahlensystem folgt einer eigenen Philosophie und ist fr spezifische Anwendungsszenarien besonders geeignet. Die Qualitt und Eignung der vorgestellten Systeme hngt somit immer vom geplanten Einsatz
ab, sodass eine allgemeine Bewertung von Kennzahlensystemen weder
objektiv mglich noch in diesem Text beabsichtigt ist.
Grob unterscheiden kann man zwischen praxisorientierten, konkreten
Systemen, und eher als generisch zu verstehenden Systemen. Whrend
erstere in der Regel aktualisiert und auf die bestehende IT-Infrastruktur
eines Unternehmens abgestimmt werden mssen, erfordern letztere das
Entwickeln eigener, geeigneter Kennzahlen.
Da sich kaum eines dieser Kennzahlensysteme direkt und ohne Anpassungen einsetzen lsst, ist es wichtig, vorab einige Kriterien zu nennen, anhand derer sich der Aufwand einer Implementierung abschtzen lsst:
Stimmt die Zielsetzung des Kennzahlensystems mit den Anforderungen berein? Werden alle IT-Bereiche ausreichend abgedeckt?
Werden die wesentlichen Fragen hinreichend beantwortet? Stimmt
die Gewichtung der Kennzahlen mit der Relevanz berein?
Wie konkret ist das Kennzahlensystem? Lassen sich die genannten
Kennzahlen einfach erheben? Mssen Kennzahlen noch weiter ausformuliert werden?
Wie aufwendig ist die Implementierung des Systems? Werden die
verwendeten Kennzahlen bereits erhoben? Welcher Aufwand wrde die Erhebung der ntigen Kennzahlen verursachen? Wie hufig
wre eine Erhebung mglich?
Im Folgenden machen wir eine kleine Reise durch die Welt der Kennzahlensysteme. Unsere Stopps sind aber nur kurz. Fr lngere Aufenthalte
empfehlen wir einen Blick in die Originalarbeiten oder das sehr empfehlenswerte Buch von Martin Ktz [Ktz, 2007].

147

4 IT Kennzahlensysteme

4.3.1 SVD 1980


Herkunft
Quelle
Idee

Struktur

Schweizerische Vereinigung fr Datenverarbeitung


EDV-Kennzahlen (1980), Bern/Stuttgart
SVD 1980 ist ein kompaktes, relativ allgemein gehaltenes Kennzahlensystem, das 34 nach Adressaten gruppierte Kennzahlen enthlt.
Gruppierung nach Adressat und Art der Kennzahl.
Insgesamt 34 Kennzahlen.
Management

Anwender

IT-Entwicklung

IT-Betrieb

Kosten

Leistungen

Nutzen

Sonstige

Kennzahlen

Beispiele

Fazit

148

IT-Produktivittsindex (Management / Nutzen)


Nutzenpunkte (Anwender / Nutzen)
Anzahl IT-Mitarbeiter (IT-Entwicklung / Sonstige)
Mean Time to Repair (MTTR) (IT-Betrieb / Leistung)
Einige Kennzahlen mssen fr den konkreten Einsatz in
der Praxis spezifiziert werden, z. B. was Nutzenpunkte im Einzelnen sind.

4.3 berblick

4.3.2 Diebold 1984


Herkunft

Diebold Deutschland GmbH

Quelle

Diebold Kennzahlensystem (1984), 3. Auflage, Frankfurt

Idee

Dieses von der Unternehmensberatung Diebold entwickelte Kennzahlensystem stellt eine hierarchische Struktur dar, in die konkrete Kennzahlen eingearbeitet werden knnen.

Struktur

Hierarchische Strukturierung mit insgesamt 19 Untergruppen

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

Beispiele

Anteil IT-Kosten bezogen auf Umsatz (Spitzenkennzahl)


Wirkung des Einsatzes der IT im Hinblick auf die
Unternehmensleistung (A)
... bezogen auf das Gesamtunternehmen (AA)
... je Hauptfunktionsbereich (AB)

Fazit

Diebold stellt ein abstraktes Kennzahlensystem dar, das


fr eine praktische Nutzung stark konkretisiert und
angepasst werden muss.
Es stellt sich auch die Frage, wie sich (durchaus wichtige) Aspekte wie Innovationsverhalten und Zukunftsorientierung praktisch und objektiv messen
lassen.
Die hierarchische Struktur bietet Vorteile dadurch, dass
eine an den jeweiligen Adressaten angepasste Informationstiefe erreicht werden kann. Zu klren ist dabei
allerdings, auf welche Art und Weise die Kennzahlen
einer Gruppe zur jeweils hheren Hierarchiestufe zusammengerechnet werden knnen.

149

4 IT Kennzahlensysteme

4.3.3 Kargl 1996


Herkunft Herbert Kargl
Quelle Controlling im DV-Bereich (1996), Mnchen
Idee Das von Kargl entwickelte Kennzahlensystem bietet eine
groe Flle an einfach zu implementierenden Kennzahlen.
Struktur 5 Koordinationsfelder mit insgesamt 163 Kennzahlen

Beispiele

Strategische IT-Planung (34)


Planung / Durchfhrung von IT-Projekten (30)
Wirtschaftlichkeit (24)
Anwendungsbetrieb und IT-Infrastruktur (52)
Verrechnung von Kosten und Leistungen (23)

Betriebskosten der Anwendungen (Strategische


Planung)
Projektfertigstellungsgrad (Plan / Durchfhrung)
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 grtenteils relativ konkret formuliert, sodass sie sich gut praktisch nutzen und einfach
abwandeln lassen.
Zudem sind einige Kennzahlen enthalten, die ntzliche
Hintergrundinformationen liefern, beispielsweise ber
die Struktur der Leistungserstellung.

150

4.3 berblick

4.3.4 Van der Zee 1996


Herkunft

Han van der Zee

Quelle

In: Search of the Value of Information Technology (1996),


Dissertation, Katholische Universitt 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 fr jede Perspektive
konkrete Ziele formuliert.

Struktur

Aufteilung in 5 Management-Bereiche und jeweils 4 Perspektiven mit insgesamt 200 Kennzahlen:


Kennzahlen

Beispiele

Kundenperspekt.

Interne
Persp.

Innovationspersp.

Finanzpersp.

Leistungsmgmt.

Entwicklungsm.

15

17

Infrastrukturm.

18

33

Kundenmgmt.

15

Anwendersupport

16

Leistungsmanagement, interne Perspektive


Ziel: Ein guter Arbeitgeber sein.

Fazit

Mitarbeiterzufriedenheit
Fluktuationsrate
Wettbewerbsfhigkeit der Gehlter
...

Der einseitige Fokus auf die Kosten- und Finanzperspektive kann zu kurzsichtigem Handeln verleiten. Die Kunden-, Innovations- und Prozessperspektiven sollen helfen, langfristig relevante Werte zu erfassen.
Die Kennzahlen selbst sind zum groen Teil konkret
formuliert. Der enorme Umfang des Systems erfordert
allerdings eine sorgfltige Auswahl.

151

4 IT Kennzahlensysteme

4.4 Bewertung
Die betrachteten Kennzahlensysteme zeigen, dass es verschiedene, gleichermaen schlssige und sinnvolle Anstze gibt, die scheinbar schwer
messbare Leistung der IT zu erfassen.
Zunchst stellt sich die Frage nach der grundstzlichen Struktur eines
Kennzahlensystems. In dieser sollten alle Kernbereiche der IT wieder zu
finden sein. Auch sollte die Abgrenzung mit der tatschlichen Aufteilung
von Aufgaben und Kompetenzen in etwa bereinstimmen. Matrizenfrmige Strukturen erlauben das gleichzeitige Gliedern der Kennzahlen nach
dem Bereich und einem zweiten Kriterium.
Eine (zustzliche) hierarchische Strukturierung der Kennzahlen ist mglich und dann sinnvoll, wenn das System ohne Probleme von mehreren
unterschiedlich stark involvierten Managementstufen benutzt werden soll.
Das Hinzufgen von Zielen oder die Unterteilung nach Prozessen verleiht
dem Kennzahlensystem schlielich eine eigene Philosophie, was sowohl
bei der Erstellung des Systems, als auch bei der Auswertung der spteren
Resultate sinnvoll ist.
Was die Anwendbarkeit der vorgestellten Systeme betrifft, so erfordert
jedes die Anpassung an die konkrete IT-Organisation. Whrend dies bei
relativ konkreten Systemen wie van der Zee 1996 einfach durch die geschickte Auswahl aus einem Kennzahlenpool erfolgen kann 4 , dienen
abstrakte Klassifizierungssysteme wie Diebold 1984 eher als Basis fr 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 enttuschende
Antwort: Keines5.
In der Praxis zeigt sich:
Der berdeckungsgrad der Kennzahlensysteme ist eher gering, jedes Kennzahlensystem liefert neue Aspekte.
Die Anforderung, dass Prozessmodelle des IT Service Managements
zu bercksichtigen sind, liefert nicht weniger, sondern mehr Kennzahlen.
Kein Kennzahlensystem ist ohne Modifikation in der Praxis einsetzbar:
Zu viele Kennzahlen werden genannt.

Dies gilt im brigen auch fr COBIT (vgl. Kapitel 3.3).

Vielleicht etwas hoffnungsvoller, vershnlicher (und diplomatischer): Keines


ohne Modifikation.

152

4.5 Konsequenzen
Kennzahlen werden genannt, die aber im konkreten Unternehmen
nicht reported / gemessen werden knnen oder sollen.
Kennzahlen werden zwar genannt, aber nicht definiert.
Es wird kaum Bezug zur IT-Strategie genommen. Der strategische
Aspekt von Kennzahlensystemen bleibt unbercksichtigt.
IT-Kennzahlensysteme sagen, was man messen knnte, 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 fr IT-Kennzahlensysteme knnen beispielsweise sein:
Steuerung des IT-Bereichs oder
Darstellung des IT-Bereichs
(z. B. um der Geschftsfhrung zu zeigen, wie der IT-Bereich im
Unternehmen dasteht: Lagebericht der IT).
Hieraus lsst sich ein wichtiger Aspekt ableiten:
IT-Kennzahlensysteme haben immer einen bestimmten Adressatenkreis: Top
Management, CIO, Prozess Owner oder Kunden.

4.5 Konsequenzen
Anmerkung: Dies ist das krzeste und wichtigste Kapitel in unserem Buch.
Beantworten Sie die folgenden Fragen:
Wer sind die Adressaten des IT-Kennzahlensystems?
Welche Ziele verfolgen Sie mit der Einfhrung des IT-Kennzahlensystems in Bezug auf die Adressaten?
Welche IT Service Management-Prozesse sollen gemessen werden?
Wie sollte das Kennzahlensystem strukturiert sein?
Welche Kennzahlen knnen bzw. knnen nicht gemessen werden?
Welchen Aufwand darf das Kennzahlensystem verursachen?

Entwickeln Sie Ihr eigenes IT-Kennzahlensystem!

153

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


5.1 Management Summary
In diesem Kapitel gehen wir darauf ein, wie ein praxistaugliches ITKennzahlensystem entwickelt werden kann. Es kommt uns darauf an, zu
zeigen, welche IT-Kennzahlen sich in unseren Praxisprojekten als ntzlich
und sinnvoll erwiesen haben.
In unseren Projekten haben wir die Erfahrung gemacht, dass das Hauptproblem bei der Entwicklung eines IT-Kennzahlensystems darin besteht,
die Komplexitt des Systems zu reduzieren. Daher widmen wir uns diesem Problem gleich am Anfang des Kapitels und zeigen auf, wie man
Kennzahlen in Cluster unterteilen kann, damit ein Mehr-EbenenKennzahlen-System ohne berfrachtung und berforderung der Fhrungsebene entsteht.
Insbesondere sind Kennzahlen hinsichtlich ihres Einsatzes und der strategischen Bedeutung zu verdichten. Dies sollte den entsprechenden ITMitarbeitern bertragen werden. Dabei ist wichtig, dass eine Aggregation
der Daten stattfindet und nicht eine Datenreduktion. Eine Lsung bieten
hier Controls on Demand, die dann herangezogen werden, wenn sie bentigt werden. Fr die Aufbewahrung ist der jeweilige IT-Mitarbeiter verantwortlich. Die IT-Leitung erhlt nur die aggregierten Zahlen zur Steuerung
und Kontrolle, kann aber die Detaildaten jederzeit anfordern.

5.2 Klassifikationsschema fr IT-Kennzahlen


In IT-Organisationen gibt es im Allgemeinen sehr viele Kennzahlen. In
einem durchschnittlichen mittelstndischen Unternehmen (Gre der ITOrganisation 10 Mitarbeiter) haben wir bei der Ist-Analyse mit Leichtigkeit
500 Kennzahlen ermittelt, die alle erhoben und an die IT-Leitung reported
wurden.
Es drngt sich nun der Verdacht auf, diese seien nicht alle notwendig und
man knne auf einen Groteil verzichten.
Dem ist nicht so, denn 95 % dieser Kennzahlen sind sinnvoll und wichtig.
Allerdings nicht so wichtig, dass sie monatlich an den CIO reported werden mssen, geschweige denn an die Geschftsfhrung.

155

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Die Frage Erheben wir die richtigen Kennzahlen? sollte man etwas detaillieren und erweitern: Erheben wir die richtigen Kennzahlen zum richtigen Zeitpunkt fr die richtige Person?
Was richtig oder nicht richtig ist, lsst sich aus den Zielen und der
Strategie ableiten!
Interessanterweise erhlt man hierdurch ein Klassifikationsschema fr
Kennzahlen, das sich pragmatisch in der Praxis anwenden lsst und die
Komplexitt des Systems reduziert.
In der folgenden Abbildung 61 ist dieses Modell zur Klassifikation von ITKennzahlen dargestellt.

Top Management
Geschftsfhrung
Balanced Scorecard (KSFs)

Kennzahlen
einer
ITOrganisation

IT-Management
CIO
KPIs

CSIs

IT-Controls
Controls on Demand

IT - Kunden
SLAs
Abbildung 61:

Schema zur Klassifikation von IT-Kennzahlen

Hierzu die 3 Kernideen des Modells:


Im Wesentlichen lassen sich die Kennzahlen einer IT-Organisationseinheit in drei grere Gruppen einteilen, die sich an den Adressaten der Kennzahlen orientieren: Top Management, IT-Management
und IT-Kunden.
Die meisten Kennzahlen in der Praxis einige hundert fallen im
Umfeld des CIOs an. Ein Teil die IT-Controls ist zur Steuerung
der IT notwendig. Der grte Teil wird nur in bestimmten Situationen bentigt. Diese Kennzahlen sollten als Kennzahlen auf Abruf (Controls on Demand) vorgehalten werden.

156

5.2 Klassifikationsschema fr IT-Kennzahlen


Es gibt viele Alternativen, Kennzahlen darzustellen. Entscheidend
fr den Erfolg eines Kennzahlensystems ist gerade die Fhigkeit,
Strategien zu kommunizieren. Wir halten daher mindestens fr das
Reporting an die Geschftsfhrung die Balanced Scorecard fr unabdingbar.
Lassen Sie uns auf die wesentlichen Kernideen des Klassifikationsschemas
genauer eingehen.

5.2.1

Key Success Factors

ber die Rolle der IT in Unternehmen ist viel diskutiert und geschrieben
worden. Wir sind der Meinung, dass die IT einen wesentlichen Produktionsfaktor fr Unternehmen darstellt. Sie ist wettbewerbsbestimmend, da
sie nicht nur die Systeme am Laufen hlt, sondern gleichzeitig eine bedeutende Innovationskraft fr Unternehmen darstellt. Wodurch soll heute
Wachstum entstehen, wenn nicht durch Innovation?
Nach unserer Ansicht hat die IT heute 2 Aufgaben zu erfllen:
Run the Business:
Die IT ist der Motor fr die Geschftsprozesse. Sie hat die Aufgabe,
die Kosten im Griff zu halten, marktgerecht zu agieren, zu standardisieren, Skaleneffekte auszunutzen und das Risiko zu minimieren.
Grow and Transform the Business:
Die IT ist ein wesentlicher Teil der Entwicklungsabteilung fr Geschftsprozesse. Sie verndert und optimiert die Kernprozesse von
Unternehmen, legt die Basis fr neue Mrkte und ist eine strategische Waffe im Wettbewerb.
Die IT ist damit nicht Selbstzweck, sondern sie trgt messbar zum Business Value des Gesamtunternehmens bei. Eine wesentliche Aufgabe des CIO besteht
darin, den IT-Erfolg dem Top Management und IT-Kunden darzustellen.

Vielen Unternehmen bereitet diese Sicht Schwierigkeiten und daher implementieren sie nur unzureichende Mglichkeiten zur Kommunikation. Dies
ist schade, denn dadurch verpufft einerseits viel Innovationskraft und
andererseits bauen sich leicht Konfliktsituationen auf, die fr das Unternehmen und die IT schdlich sein knnen.
Sehr zu empfehlen ist ein Management Report zur Lage der IT im Unternehmen. Wir haben diese Art des Reportings in vielen Unternehmen
verschiedener Gren und Branchen erfolgreich eingefhrt. In den meisten Fllen wird dieser Report mit Interesse von der Geschftsfhrung entgegengenommen.

157

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Der Report sollte jhrlich erscheinen. Er beschreibt und bewertet die IT im
Hinblick auf ihre Leistungsfhigkeit.
Der IT
Management
Report richtet
sich an das
Top
Management.

Wichtig dabei sind die folgenden Dinge:


Der Management Report muss auf einer mehrdimensionalen Bewertung der IT basieren.
Er muss die Entwicklungstendenzen darstellen. Kennzahlenverlufe
sind fr die letzten 3 bzw. 5 Jahre anzugeben.
Die Bewertung (und die Kennzahlen) mssen fr das Top Management verstndlich sein.
Der Management Report darf Marketingaspekte beinhalten und verfolgen. Er ist eine Selbstdarstellung und dient dem Erreichen strategischer Ziele.
Er muss einen berblick ber die durchgefhrten Projekte enthalten.
Dabei ist herauszustellen, inwiefern die Projekte zum Business Value beigetragen haben. 1
Aus dem Management Report mssen die Ziele fr das nchste 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 Fllen die Balanced Scorecard. Sie ist
nicht nur fr Management Meetings hervorragend geeignet sondern auch
zum Aufbau von Management Reports.
Die Frage, die sich hier stellt ist, welche Zahlen und Ergebnisse interessieren das Top Management? Dies sind sicherlich nicht die technischen Details der IT, die man ja reichlich reporten knnte.
Es geht im Grunde darum, mit Fakten aufzuzeigen, wie erfolgreich die IT
ist. Diese Kennzahlen nennen wir Key Success Faktoren (KSF). Sie setzen
sich im Allgemeinen aus anderen Kennzahlen zusammen und sind damit
selbst mehrdimensional.
Es bietet sich an, die Dimensionen einer Balanced Scorecard als Key Success Faktoren zu nehmen (vgl. Abbildung 62). Die Kennzahlen knnen
Key Performance Indikatoren2 oder Customer Satisfaction Indices aus der
Ebene des IT-Managements sein, die durch Aggregation entstehen. Im
Folgenden geben wir einen Ausschnitt aus einem solchen Kennzahlensystem an:

ROI im Sinne Return on IT.

KPIs im Sinne einer betriebswirtschaftlichen Begriffsbestimmung (vgl. den


Exkurs zum Begriff KPI in Kapitel 5.2.2.)

158

5.2 Klassifikationsschema fr IT-Kennzahlen

KSF: Finanzperspektive
IT-Kosten nach Umsatz
IT-Kosten je Anwender

KSF: Potenzialperspektive
Aus- und Weiterbildungstage
Mitarbeiterzufriedenheit

KSF: Kundenperspektive
Verfgbarkeit der Systeme
Kundenzufriedenheit

IT Management Report 2006


Finanzperspektive
...
Kundenperspektive
Mitarbeiterperspektive
Abbildung 62:

Key Success Faktoren im IT Management Report

Die auszuwhlenden Key Success Faktoren sind nach unserer Erfahrung


fr IT-Organisationen unterschiedlich. Wir haben die Perspektiven einer
Balanced Scorecard bisher nie eins zu eins von einem Unternehmen auf
das andere bertragen knnen. Das liegt unter anderem daran, dass sich
die Key Success Faktoren aus der IT-Strategie ableiten (vgl. Abbildung 63).
Meistens benutzen wir zwischen 5 7 Perspektiven und damit auch 5 7
Key Success Faktoren, die die IT insgesamt darstellen. Nicht zu viel und
nicht zu wenig gerade geeignet, um die Lage der IT dem Top Management transparent zu machen.
Jeder Key Success Faktor sollte mit einem kurzen Text versehen werden,
der den Verlauf der Kennzahlen interpretiert und sich auf die aktuelle

159

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Situation des Unternehmens bezieht. Expandiert das Unternehmen beispielsweise in andere Lnder, so kann dies der Grund fr erhhte ITAufwnde sein. Hat man in den letzten Jahren die IT-Plattformen konsolidiert, so kann dies in den Folgejahren ein Grund fr sinkende Investitionen sein.
Key
Key
Success
Success
Factor
Factor

ITStrategie

Key
Key
Success
Success
Factor
Factor

KPI
KPI

CSI
CSI
KPI
KPI

KPI
KPI
KPI
KPI
KPI
KPI
KPI
KPI
KPI
KPI

Key
Key
Success
Success
Factor
Factor

CSI
CSI

CSI
CSI
KPI
KPI
CSI
CSI
CSI
CSI

Kennzahlen-

system
Abbildung 63:

Key Success Faktoren zur Gruppierung von KPIs und CSIs

Hilfreich ist es auch, fr Kennzahlen Benchmarks anzugeben, falls diese


verfgbar sind. Dies ist in einigen Branchen der Fall. Oft gibt es auch allgemeine Benchmarks, die dem Management zeigen, ob die eigene IT noch
im grnen Bereich liegt. Ein Beispiel ist die Kennzahl IT-Kosten pro
Umsatz, die zwischen 2 und 3 % liegen sollte. Dies ist aber von Branche
zu Branche verschieden und sollte auf die aktuelle Situation des Unternehmens bezogen werden.

5.2.2

Key Performance und Customer Satisfaction

Alle IT Service Management-Anstze sehen IT-Organisationen als IT Service Provider, die Leistungen fr ihre Kunden erbringen. Der Kunde ist in
diesem Zusammenhang derjenige, der fr Leistungen bezahlt. Kunden
werden von Anwendern unterschieden, die lediglich die IT-Infrastruktur nutzen.

160

5.2 Klassifikationsschema fr IT-Kennzahlen


In IT-Kennzahlensystemen sollte die Kundenfokussierung Bercksichtigung finden. Es ist daher nicht nur zu messen und zu bewerten, welche Leistungen die
IT-Organisation an ihre Kunden ausliefert sondern auch, wie der Kunde diese
Leistungen empfindet.

Im Marketing und nicht nur da findet man hierzu den Begriff Customer Satisfaction Index (CSI), der angibt, wie der Kunde einen entsprechenden Service empfindet. Es wird sozusagen die gefhlte Qualitt bewertet. Die CSIs sind von den blichen Key Performance Indikatoren (KPI) zu
unterscheiden, die die Leistungsfhigkeit von Prozessen aus eigener Sicht
bewerten.
In [Zeithaml et al., 1988] werden die Lcken zwischen Kunden- und Providersicht sehr treffend beschrieben. Die nachfolgende Abbildung 64 zeigt
zum einen, wie kompliziert die Wahrnehmungsprozesse sind, und zum
anderen, dass es viele Schnittstellen gibt, an denen die Kunden- und Providersicht unterschiedlich sein kann.

Customer
Satisfaction
Index

Customer
Satisfaction
Index
Abbildung 64:

Beispiele fr Lcken zwischen Kunden- und Providersicht

Wir haben in der Abbildung 64 drei Punkte herausgegriffen, an denen


man CSIs messen kann:
Zwischen Leistungserwartung und Servicewahrnehmung kann es
ein Gap geben. Dies ist in der Praxis oft der Fall, wenn ITMarketingaspekte zu kurz kommen.
Zwischen Leistungserwartung des Kunden und der durch den Provider wahrgenommenen Kundenerwartung kann ebenfalls eine L-

161

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


cke klaffen. Das ist in der Praxis der Fall, wenn das Service Level
Management keine Engagement Funktion hinsichtlich der Kunden wahrnimmt.
Sind die Leistungsspezifikationen schwach ausgeprgt, so ist dies
ebenfalls ein Nhrboden fr Wahrnehmungsstrungen. Wir haben
diesen Fall in der Praxis oft gesehen, wenn SLAs nicht hinreichend
genau formuliert waren und zu groe Interpretationsspielrume zulieen.
In [OGC, 2007e] werden 16 Gaps identifiziert, die sich im Service Lifecycle
in allen mglichen Phasen Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement wiederfinden.
Das Service Management hat dafr Sorge zu tragen, dass diese Lcken
geschlossen werden und muss gegebenenfalls ein entsprechendes Service
Improvement Program (SIP) initiieren.
Die untere Abbildung 65 ist angelehnt an Continual Service Improvement [OGC, 2007e] und stellt diese Gaps dar. Interessant ist, dass sie
beim Kunden, beim Provider und auch zwischen Kunde und Provider
auftreten knnen. Gap 5 beschreibt beispielsweise ein Kommunikationsproblem bzw. eine falsche Erwartungshaltung, die auf Seiten des Kunden
besteht.
Fr IT-Kennzahlensysteme bedeutet dies, dass CSIs auf der Ebene des ITManagements gemessen und reported werden mssen. Sie sind zur Steuerung
der IT genau so wichtig wie die KPIs.

Die Messung der CSIs sollte an all den Stellen erfolgen, wo Kundenkontakte wahrgenommen werden. Der wichtigste Sensor liegt hier sicherlich
beim CIO selbst, der wahrnehmen muss, wie die IT im Unternehmen da
steht. Andere Quellen sind natrlich das Service Level Management, aber
auch der Service Desk sowie das Projekt Management.

162

5.2 Klassifikationsschema fr IT-Kennzahlen


Externe u. interne
Kommunikation,
Einflsse und
Treiber

GAP 1
GAP 3

Was wollen wir?

Was brauchen wir?

GAP 2

Erfahrung
Vergangenheit

GAP 16
GAP 4

Was bekommen wir?


Erwarteter Service
GAP 5

Service Operation

GAP 14

GAP 13

GAP 9
Service Transition

GAP 6

Kommunikation
zum Kunden

Was bekamen wir?


Erhaltener Service

GAP 15

GAP 12

GAP 8
Service Design

GAP 11

GAP 7
Service Strategy
Abbildung 65:

GAP 10

Gaps nach OGC (aus [OGC, 2007e])

Exkurs: Zum Begriff Key Performance Indicator (KPI)


Es sei an dieser Stelle angemerkt, dass der Begriff Key Performance Indicator (KPI) in vielen Zusammenhngen verwendet wird.
Betriebswirtschaft / Management (vgl. [Wikipedia, 2007]):
Key Performance Indicators (KPI) are financial and non-financial metrics
used to quantify objectives to reflect strategic performance of an organization. KPIs are used in Business Intelligence to assess the present state of
the business and to prescribe a course of action. KPIs are typically tied
to an organization's strategy (as exemplified through techniques such as
the Balanced Scorecard).
The KPIs differ depending on the nature of the organization and the organization's strategy.
COBIT (vgl. [COBIT, 2005]):
Hier werden die wesentlichen Leistungsindikatoren als Key Goal Indicators (Effektivitt) bezeichnet, whrend KPIs lediglich die Effizienz beschreiben.

163

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


ITIL definiert KPIs als (vgl. [OGC, 2007c]):
A Metric that is used to help manage a Process, IT Service or Activity. Many
Metrics may be measured, but only the most important of these are defined as
KPIs and used to actively manage and report on the Process, IT Service or Activity. KPIs should be selected to ensure that Efficiency, Effectiveness, and Cost Effectiveness are all managed.

Wenn wir in unserem Klassifikationsschema in diesem Abschnitt von KPIs


reden, verstehen wir darunter KPIs im Sinne der betriebswirtschaftlichen
Definition. Diese Begriffsbestimmung ist allgemeiner, hat sich auch im ITControlling durchgesetzt und kann auch im Zusammenhang mit nichtCOBIT-basierten Frameworks eingesetzt werden. KPIs sind eben auch
wesentlich fr die Umsetzung der IT-Strategie ja, entstehen geradezu aus
dieser und mssen losgelst von Frameworks fr jedes Unternehmen
individuell zusammengestellt werden.
Auf der ITManagementEbene sind
KPIs und
CSIs zu
reporten.

KPIs mssen
die Prozessperformance widerspiegeln. Leistungsgren sind besser
als Aufwandsgren.
Prozesse darstellen und mglichst Kundenbezug haben.
Steuerungsinstrumente des Process Owners und Prozess Managers
sein.
mit den Customer Satisfaction Indicators CSIs verknpft werden
knnen.
Beispiele fr KPIs sind die Erstlsungsrate im Service Desk und ITProjekte in time und in budget.
Beispiele fr CSIs sind die empfundene Kompetenz der Service Desk
Mitarbeiter und die Kundenzufriedenheit mit der IT.

5.2.3

IT-Controls und Controls on Demand

Durch die Vielzahl eingesetzter Monitoring Tools stehen in ITOrganisationen zeitnah immense Datenmengen zur Verfgung, die prinzipiell als Kennzahlen nutzbar sind.
Es macht auf keiner Ebene des Kennzahlensystems weder auf der Geschftsfhrungs- noch auf der IT Management Ebene Sinn, eine unberschaubare Menge von Kennzahlen in ein monatliches Reporting einzubeziehen.
Wir unterscheiden daher IT-Controls und Controls on Demand.
IT-Controls sind Kennzahlen, die kontinuierlich reported werden. Controls on
Demand sind Kennzahlen, die nur in speziellen Situationen aussagekrftig sind.

164

5.2 Klassifikationsschema fr IT-Kennzahlen


Beispiele fr IT-Controls sind:

Personalaufwand monatlich
Abschreibungen auf Sachanlagen
Kapazittsplan
Fehlzeiten
Anzahl von Systemstillstnden 3
Auswertung der Service-Auftrge
Erstlsungsrate (Incident Management)4
Anteil fehlerhafter Changes (Change Management)5

Wie die IT-Controls strukturiert werden, hngt vom Typ und von der
Gre der IT-Organisation ab. Es bieten sich verschiedene Werkzeuge an,
unter anderem die Balanced Scorecard.
Im Gegensatz zum Fall des Reportings an die Geschftsleitungsebene haben wir hier in unseren Projekten eine strkere hnlichkeit der Kennzahlensysteme untereinander erkennen knnen. Die Idee, Cockpits einzusetzen, die diese Kennzahlen automatisch aus den operativen Systemen generieren, setzt sich immer mehr durch. Die Steuerung der IT ber ein Cockpit kann vor allen Dingen zeitnah erfolgen und bedarf nicht der aufwendigen Sammlung und Auswertung von Daten zu einem bestimmten Zeitpunkt.
Controls on Demand werden auf Anforderung reported. Sie mssen zwar
generell zur Verfgung stehen, werden aber nur situationsbedingt eingesetzt, da sie von Ereignissen (oder Projekten) getriggert werden:
Nach einem Angriff muss reported werden, wer auf welche Server
zugegriffen hat.
Nach Ausfall des Web-Servers muss die Trafic-Situation reported
werden.
Beispiele fr Controls on Demand sind:

Betrieb der IT-Infrastruktur

Auslastung Datenbanken
Verfgbarkeit spezieller Server
Web-Server-Statistik
Virenbefall-Statistik

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

Dito.

Dito.

165

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen

Anwendungen
Datensicherungsprotokolle
Anzahl Datenstze in SAP BW

ITIL Prozesse (Prozess Owner Kennzahlen)


Gre und Kapazitt der DSL (Release Management)
Dokumentationsqualitt der CIs (Configuration Management)
Das Beispiel zeigt, dass wir den Bereich der Controls on Demand absolut
inhaltlich ausrichten. Es gibt keine Meta-Ebene, die sich beispielsweise an
der IT-Strategie orientiert. Bei Controls on Demand geht es bei der Klassifizierung in Gruppen nur um eins: Die betreffenden Statistiken zu den
Kennzahlen mssen im Ernstfall schnell gefunden werden knnen.

5.3 Prozess-Kennzahlen
Im Folgenden beschreiben wir ausgewhlte Prozess-Kennzahlen, die sich
in unseren Projekten und auf der Basis unserer Managementerfahrungen
bewhrt haben. Sie basieren zum Teil auf ITIL und COBIT, beinhalten aber
darber hinausgehende Betrachtungen.
Die Struktur der dargestellten Kennzahlen bildet die in der ITIL Version 3
beschriebenen Prozesse und Managementaufgaben. Zustzlich 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 prfen, ob sie
in Verbindung mit den spezifizierten Prozesszielen der IT-Organisation stehen.

Zu den ausgewiesenen Kennzahlen wird deren jeweilige Definition, Messung und Relevanz spezifiziert. Bei der Messung von Kennzahlen ist zu
beachten, dass hierfr keine Standards existieren. So ist zum Beispiel die
Kennzahl Erstlsungsquote weit verbreitet, aber deren Messung weicht
zwischen den einzelnen IT-Organisationen voneinander ab. Daher muss
bei einem Vergleich von Kennzahlen zwischen Organisationen immer
deren spezifische Messung in die Betrachtung einbezogen werden.
Im Rahmen von Benchmarks soll eine gemeinsame Vergleichsbasis sichergestellt
werden.

Die im Folgenden angegebenen Messwerte stammen aus unserer Projekterfahrung. Sie knnen von Fall zu Fall von den implementierten Methoden
in IT-Organisation abweichen.

166

5.3 Prozess-Kennzahlen
Wie bereits im Kapitel Prozess-Management ausgefhrt, stehen die Ziele Ihrer
IT-Prozesse im Vordergrund. Daher sind auch die hier aufgefhrten Prozesse
hinsichtlich deren Relevanz kritisch zu prfen.

Damit die aufgefhrten Kennzahlen die notwendigen Informationen liefern knnen, mssen 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 Erstlsungsquote erst dann
hilfreich, wenn gleichzeitig die Anzahl der eingehenden Strungsmeldungen dargestellt wird.

Kennzahlen
sind als Trend
und Relation
darzustellen.

Durch die Darstellung von Trends fr die im Anschluss beschriebenen Kennzahlen steigt der Informationsgehalt. Bei der Trenddarstellung sind die Sollwerte als
Bezugslinien auszuweisen.

Die Kennzahlen sind nach dem Motto Keep It Simple Stupid


(KISS) - oder In der Krze liegt die Wrze - zu definieren. Einerseits
sollten die Kennzahlen mglichst einfach verstndlich zu sein. Andererseits gilt es auch den Aufwand zu betrachten, der zur Generierung einer
Kennzahl notwendig ist. Hier muss jeweils der Aufwand zur Generierung
mit der Steuerungsrelevanz der Kennzahl und des mglichen Verbesserungspotenzials bewertet werden.
Um Zusatzaufwendungen zu vermeiden, sollten die Kennzahlen mglichst ohne zustzlichen Erfassungsaufwand aus den operativen IT-Systemen gewonnen werden. Speziell die Kennzahlen fr die Prozesse Incident
Management, Request Fulfilment, Problem Management, Access Management, Service Asset and Configuration Management, Change Management
und Release and Deployment Management generieren sich weitestgehend
aus dem eingesetzten IT Service Management-Tool. Kennzahlen werden
zum Teil durch die Verknpfungen von Daten aus verschiedenen Prozessen gewonnen. Dies erfordert eine hohe Integritt der zugrunde liegenden
Datenbasis ber verschiedene Prozesse hinweg.
Auch aus der Betrachtung der Kennzahlengenerierung sollte das eingesetzte
Tool nach Mglichkeit von einem Hersteller stammen.

Es muss sichergestellt werden, dass die automatisch generierten Kennzahlen fehlerfrei sind. Zum Teil werden Daten aus einem anderen Prozess zur
Generierung von Kennzahlen herangezogen. Zum Beispiel lautet eine
Kennzahl zum Change Management Anteil fehlerhafter Changes. Um
diese Kennzahl zu ermitteln, mssen Daten aus dem Incident Management ermittelt werden. Bei zuknftigen nderungen in Prozessen und der
eingesetzten Toolumgebung ist sicherzustellen, dass diese nderungen
keine Auswirkungen auf die daraus generierten Kennzahlen haben.

167

Kennzahlen
sind
mglichst aus
operativen
Systemen zu
generieren.

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


nderungen
im Tool sind
Changes und
als solche zu
behandeln

nderungen im IT Service Management-Tool sind auf mgliche Auswirkungen


hinsichtlich der Kennzahlengenerierung zu bewerten. Daher sollten auch nderungen am IT Service Management-Tool ber das Change Management gesteuert werden.

Die Tool-Untersttzung in den einzelnen IT-Organisationen ist sehr vielfltig. Zum Teil existiert zumindest fr einen Teil der Prozesse des Service Design (frher Service Delivery) und Service Transition (frher Service Support) und Service Operations (frher Service Support) ein einheitliches Tool mit einer zentralen gemeinsamen Datenbank. Bei anderen
IT-Organisationen werden die Service Management-Prozesse von unterschiedlichen Tools und Datenbaken untersttzt. Daher wird in den folgenden Kapiteln der Prozessname als Synonym fr das Tool bzw. den
View in der Datenbank genannt.
Die IT Service Management-Prozesse und die Generierung von Kennzahlen bedingen eine adquate Tool-Untersttzung. Die Kennzahlen werden zum Teil
prozessbergreifend gewonnen. Es empfiehlt sich, die eingesetzten Produkte
von einer geringen Anzahl von Herstellern zu beziehen.
Datenqualitt
im Prozess
kritisch bewerten und
ggf. eine
andere Messung whlen

Eine wichtige Datenbasis fr die Messung von Kennzahlen stellt der Prozess des Incident Managements mit den dokumentierten Incident Records
dar. So kann zum Beispiel die Effektivitt des Change Managements, das
heit 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 Datenqualitt aufweisen. Dazu mssen die Mitarbeiter ber ein ausreichendes Know-how,
aber insbesondere ber ausreichende Zeit und Motivation (Einsicht) fr
die korrekte Erfassung des Incident Records verfgen. Ist diese Datenqualitt nicht gegeben, leidet der Informationsgehalt von Kennzahlen in anderen IT Service Management-Prozessen. Kann hier keine ausreichende Datenqualitt sichergestellt werden, so muss ber eine alternative Messmethode nachgedacht werden. Zum Beispiel, in dem Probleme anstatt der
Incidents ausgewertet werden.
Kennzeichnend fr das IT Service Management sind Prozesse mit wechselseitigen Aktivitten und Schnittstellen. Daher werden hufig Daten aus anderen Prozessen zur Generierung von Kennzahlen genutzt. Eine schlechte Datenqualitt,
wie zum Beispiel von Incident Records, hat Auswirkung auf die Aussagekraft
von Kennzahlen in anderen Prozessen.

168

5.3 Prozess-Kennzahlen

5.3.1

Service Strategy

5.3.1.1 Financial Management


Der Prozess und die Funktionen des Financial Management sind verantwortlich fr 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 fr IT Services.

Relevanz

Die Kundenzufriedenheit zeigt, wie das Kostenmodell und die Preise empfunden werden.

Messwert

Abfrage in der Kundenzufriedenheitsumfrage

Bemerkung

Hier sollten die Fragen auf bestimmte Aspekte,


wie Verstndlichkeit des Kostenmodells oder
Fairer Service-Preis detailliert werden.

Name der Kennzahl

Budgetplanung

Definition

bereinstimmung des geplanten Budgets mit


den tatschlichen Ausgaben.

Relevanz

Eine gute Budgetplanung reduziert die finanziellen Risiken.

Messwert

Gegenberstellung der Plan-Kosten zu den tatschlichen Kosten. Diese sind in der Regel im
ERP-System hinterlegt.

Name der Kennzahl

Ermittlung Service-Kosten

Definition

Ermittlung der vollstndigen Kosten fr den IT


Service

Relevanz

Mittels des IT Service werden die Geschftsprozesse sichergestellt. Hierzu werden servicebezogene IT-Kosten bzw. Preise bentigt.

Messwert

Auswertung der Kosten im Service Katalog.

169

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Name der Kennzahl

Bemngelte Leistungsverrechnung

Definition

Anteil der verrechneten Leistungen, die vom


Kunden hinterfragt bzw. reklamiert werden.

Relevanz

Die Leistungsverrechnung muss fr den Kunden nachvollziehbar und widerspruchsfrei sein.

Messwert

Auswertung der durchgefhrten und dokumentierten Reviews.

Bemerkung

Voraussetzung fr die Messung ist, dass die


Reviews auf diesen Aspekt eingehen.

Name der Kennzahl

Anteil kritischer Services mit BIA

Definition

Anteil der geschftskritischen Services, fr die


eine Business Impact Analyse (BIA) vorliegt.

Relevanz

Mithilfe der BIA knnen die Auswirkungen von


Serviceausfllen auf die Geschftsprozesse bewertet werden und sind Basis fr Forderungen
an die sicherzustellende Qualitt des Service
Managements.

Messwert

Identifizierung kritischer Services aus dem Service Katalog und berprfung auf vorhandene
BIA.

Name der Kennzahl

IT-Kosten am Umsatz

Definition

Anteil der IT-Kosten am Umsatz des Unternehmens.

Relevanz

Dies ist die klassische Kennzahl zur Bewertung


der IT aus Top Management Sicht.

Messwert

Die Messwerte sind nach Branche verschieden.


Ein Benchmark ist das Intervall 1,5 bis 3,00 %.

Bemerkung

Die Kennzahl beschreibt, wie effizient die IT


arbeitet (Kostenaspekt).

170

5.3 Prozess-Kennzahlen

5.3.2.1 Service Portfolio Management


Dieser Prozess ist fr das Management des Service Portfolios verantwortlich. Er bercksichtigt die Services in Bezug auf den fr das Business gelieferten Wert.
Name der Kennzahl

Anzahl Services im Portfolio

Definition

Anzahl der definierten Services im Portfolio

Relevanz

Ist einerseits als Referenzwert notwendig, andererseits zeigt die Kennzahl den Umfang des
Servicespektrums auf.

Messwert

Auswertung der Services im Service Portfolios

Name der Kennzahl

Anteil gelieferter Services

Definition

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

Relevanz

Diese Kennzahl zeigt die Nachfrage der angebotenen Services auf.

Messwert

Auswertung der Services im Service Katalog


und im Service Portfolio.

Name der Kennzahl

Anteil Relationen IT Services zu Geschftsprozessen

Definition

Anteil der abgebildeten Relationen zu den bergeordneten Geschftsprozessen.


Die IT Services dienen der Untersttzung der
Geschftsprozesse. Vorflle und Manahmen
innerhalb der IT knnen so direkt einem Geschftsprozess zugeordnet werden.

Messwert

Auswertung des Service Portfolios.

Name der Kennzahl

Anteil Vernderungen im Service Portfolio

Definition

Anteil der im Service Portfolio vorgenommenen


Vernderungen an den enthaltenen Services.

Relevanz

Die Kennzahl ist ein Kennzeichen fr die Dynamik der geplanten und angebotenen Services.

Messwert

Auswertung des Service Portfolios.

171

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Name der Kennzahl

Status der Services im Service Portfolio

Definition

Status der Services im Service Portfolio

Relevanz

Die Kennzahl zeigt den Anteil der produktiven


Services in Relation zu den in Entwicklung/
berfhrung sowie den in Aussonderung befindlichen Services.

Messwert

Auswertung des Service Portfolios und Gruppierung anhand des Status.

Bemerkung

Die Services knnen den folgenden Status annehmen Service Katalog, Service Pipeline (Service noch nicht produktiv) und Retired Services

5.3.1.3 Demand Management


Das Demand Management hat die Kundenanforderungen an die IT Services aufzunehmen und zu beeinflussen, sodass die notwendigen Kapazitten bereitgestellt werden knnen, die diesen Forderungen entsprechen.
Name der Kennzahl

Anzahl der Kundenneuprojekte

Definition

Anzahl der vom Kunden gewnschten Neuprojekte in einer speziellen Applikationsdomain,


einem Applikationsbereich etc.

Relevanz

Festlegung der Prioritt in der Umsetzung von


Applikationsprojekten. Festlegung der IT Ressourcenauslastung mit dem Kunden.

Messwert

Anzahl der IT Projektanmeldungen pro Applikationsbereich und Zeitraum

Bemerkung

Transparenz zwischen Kunde und IT bzgl. der


IT Ressourcenauslastung.

Name der Kennzahl

Anzahl kurzfristiger Kapazittsanpassungen

Definition

Anzahl kurzfristiger Anpassungen der bereitzustellenden Kapazitten

Relevanz

Kurzfristige Anpassungen der Kapazitten fhren zu Zusatzkosten. Entweder entstehen ungenutzt berkapazitten oder Zusatzkapazitten
sind kurzfristig daher in der Regel teuer zu
beschaffen. Hufig auftretende Anpassungen

172

5.3 Prozess-Kennzahlen
sind ein Indiz fr Probleme beim Demand Management.
Messwert

5.3.2

Ergebnisse aus dem Review des Capacity Managements

Service Design

5.3.2.1 Service Catalogue Management


Das Service Catalogue Management soll sicherstellen, dass ein Servicekatalog entwickelt und gewartet wird, der genaue Information ber alle aktuellen und geplanten operationellen Services enthlt.
Name der Kennzahl

Service aus dem Service Katalog

Definition

Anzahl und Anteil der im Betrieb befindlichen


Services, die im Service Katalog beschrieben
sind.

Relevanz

Der Service Katalog soll alle im Betrieb befindlichen Services enthalten. Diese Kennzahl zeigt
die Qualitt und Aktualitt des Service Katalogs
auf.

Messwert

Vergleich der SLAs mit dem Service Katalog.

Bemerkung

Bei der Messung wird vorausgesetzt, dass fr


alle im Betrieb befindlichen Services SLAs existieren.

Name der Kennzahl

Inhaltliche Abweichungen zum Service Katalog

Definition

Anteil der inhaltlichen Abweichungen der im


Betrieb befindlichen Services gegenber den
Spezifikationen im Service Katalog.

Relevanz

Der Service Katalog dient auch der Standardisierung von Services. Weichen die tatschlichen
Services von den Beschreibungen im Service
Katalog ab, so wird diese Standardisierung
nicht erreicht.

Messwert

Vergleich der SLAs mit dem Service Katalog.

Bemerkung

Bei der Messung wird vorausgesetzt, dass fr


alle im Betrieb befindlichen Services SLAs existieren.

173

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen

5.3.2.2 Service Level Management


Der Prozess Service Level Management (SLM) ist fr das Verhandeln von
Service Level Agreements verantwortlich und hat sicherzustellen, dass
diese SLAs eingehalten werden. Das SLM hat sicherzustellen, dass alle IT
Service Management-Prozesse, Operational Level Agreements (OLAs) and
Underpinning Contracts (UCs) den vereinbarten Service Level Zielen (Service Level Targets) entsprechen. Das SLM fhrt hierzu ein Monitoring und
Reporting der Service Level sowie regelmige Reviews mit den Kunden
durch.
Name der Kennzahl

Kundenzufriedenheit Service Level Management

Definition

Ergebnis der Kundenzufriedenheit mit dem


Service Level Management.

Relevanz

Die Kundenzufriedenheit mit dem Service Level


Management ist mehr als die (messtechnische)
Einhaltung der SLAs. Dazu gehrt unter anderem auch die Flexibilitt des IT Service Providers.

Messwert

Abfrage in der Kundenzufriedenheitsumfrage.

Bemerkung

Zustzlich kann dieser Aspekt auch innerhalb


einer Anwenderzufriedenheitsumfrage abgefragt werden.

Name der Kennzahl

Einhaltung der SLAs

Definition

Anteil der SLAs, deren Vereinbarungen eingehalten werden.

Relevanz

Die Einhaltung von SLAs stellt die vereinbarte


IT-Untersttzung der Geschftsprozesse sicher.
Im externen Kunden-Lieferanten-Verhltnis
sind mit der Einhaltung Preis-Regelungen verbunden.

Messwert

Hier sollte auf ein professionelles SLM-Tool


zurckgegriffen werden, mit dessen Hilfe die
einzelnen SLAs gemessen und die Ergebnisse
berichtet werden knnen.

Bemerkung

Hierzu muss definiert werden, wann ein SLA


als eingehalten zhlt. Zum Beispiel, wenn alle

174

5.3 Prozess-Kennzahlen
einzelnen Service Level eines SLAs eingehalten
werden.
Name der Kennzahl

Anzahl der SLA-Reviews

Definition

Anteil der durchgefhrten SLA-Reviews.

Relevanz

Die Reviews untersttzten eine bessere Zusammenarbeit zwischen Kunde und IT Service Provider. Im Rahmen von Reviews werden u. a.
notwendige Service-Verbesserungen diskutiert.

Messwert

Auswertung der dokumentierten Reviews.

Bemerkung

Die Anzahl der Reviews knnen auch im SLA


vereinbart werden.

Name der Kennzahl

Kundenerlsprioritt im Unternehmen

Definition

Welche Erlse werden mit welchem Kunden,


welchem Fachbereich, welcher Unternehmenseinheit gettigt.

Relevanz

Fokussierung auf die wichtigsten Kunden der


IT.

Messwert

Erls-Summe aller SLAs fr einen bestimmten


Kunden.

Bemerkung

Eine fr die IT relevante Kennzahl, um im Sinne


der ABC Technik festzulegen, wie intensiv ein
Kunde betreut wird. Kunden mit hohen IT Erlsen werden bevorzugt betreut. Diese Kennzahl
ist auch im Sinne des Gesamtunternehmens von
hoher Bedeutung, da sie auf die Unternehmensbereiche mit hohen IT Erlsen fokussiert.

Name der Kennzahl

Anteil SLA Verletzungen durch UCs

Definition

Anteil der SLA-Verletzungen, die aufgrund


nicht eingehaltener UCs entstanden sind.

Relevanz

Knnen SLAs nicht eingehalten werden, weil


der Lieferant seine Zusagen nicht einhlt, so
mssen entsprechende Folgeaktivitten eingeleitet werden.

Messwert

Hier sollte auf ein professionelles SLM-Tool

175

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


zurckgegriffen werden, mit dessen Hilfe die
einzelnen SLAs und UCs gemessen und die
Ergebnisse berichtet werden knnen.
Name der Kennzahl

Anteil SLA Verletzungen durch OLAs

Definition

Anteil der SLA-Verletzungen, die aufgrund


nicht eingehaltener OLAs entstanden sind.

Relevanz

Knnen SLAs nicht eingehalten werden, weil


interne Einheiten ihre Zusagen nicht einhalten,
so mssen entsprechende Folgeaktivitten eingeleitet werden.

Messwert

Hier sollte auf ein professionelles SLM-Tool


zurckgegriffen werden, mit dessen Hilfe die
einzelnen SLAs und OLAs gemessen und die
Ergebnisse berichtet werden knnen.

Name der Kennzahl

Anzahl ausstehender Manahmen im SIP

Definition

Anzahl der im Service Improvement Plan (SIP)


enthaltenen Manahmen, die nicht wie geplant
umgesetzt wurden.

Relevanz

Der SIP enthlt notwendige Verbesserungsmanahmen fr die IT Services. Diese Kennzahl


zeigt, ob die identifizierten Manahmen planmig umgesetzt wurden.

Messwert

Auswertung der offenen Manahmen im SIP,


deren Umsetzungstermin berschritten ist.

Name der Kennzahl

Anzahl Manahmen im SIP

Definition

Anzahl der im Service Improvement Plan (SIP)


enthaltenen Manahmen.

Relevanz

Der SIP enthlt notwendige Verbesserungsmanahmen fr IT Services. Diese Kennzahl zeigt


den Umfang der noch offenen Manahmen
bzw. der umgesetzten Manahmen.

Messwert

Auswertung der offenen Manahmen im SIP.

Bemerkung

Die Manahmen sollten im Plan mit einem Status versehen werden. Dadurch knnen offene

176

5.3 Prozess-Kennzahlen
Manahmen, in der Umsetzung befindliche
oder bereits umgesetzte Manahmen dargestellt
werden.

5.3.2.3 Capacity Management


Das Capacity Management stellt sicher, dass die bereitgestellten Kapazitten fr die IT Services und die IT Infrastruktur gem den vereinbarten
Service Level Zielen kostengnstig und rechtzeitig bereitgestellt werden.
Das Capacity Management bercksichtigt alle geforderten Ressourcen zur
Bereitstellung des IT Service und plant auf Basis der kurz-, mittel- und
langfristigen Geschftsanforderungen.
Name der Kennzahl

Anzahl SLA-Verletzungen aufgrund fehlender


Kapazitten

Definition

Anzahl der Verletzungen von SLAs aufgrund


der nicht sichergestellten Kapazitten.

Relevanz

Werden die vereinbarten Kapazitten nicht


bereitgestellt, so fhrt dies in der Regel zu Geschftsausfllen.

Messwert

Die Ist-Kapazitten werden in der Regel aus


dem System-Management oder mit Robotern
(Antwortzeiten) ermittelt und den Soll-Werten
gegenbergestellt.

Bemerkung

Die SLA-Verletzungen sind pro SLA auszuweisen.

Name der Kennzahl

Lastspitzen und Gesamtauslastungsrate

Definition

Darstellung der Lastspitzen und Gesamtauslastung pro SLA.

Relevanz

Zielsetzung des Capacity Managements ist die


Einhaltung der Service Level, aber auch der
Wirtschaftlichkeit. Daher sollte sich die Auslastung - in Abhngigkeit der IT-Strategie - dem
Soll-Wert annhern. Lastspitzen knnen ggf.
Zusatzbedarf oder die Notwendigkeit von Verlagerungen aufzeigen

Messwert

Die Auslastungen werden in der Regel aus dem


System-Management oder zum Beispiel mit
Robotern (Antwortzeiten) ermittelt.

177

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Name der Kennzahl

Prozentsatz unzureichender Antwortzeiten

Definition

Prozentsatz der Antwortzeiten, die dem SLA


nicht entsprechen.

Relevanz

Schlechte Antwortzeiten fhren dazu, dass der


Service als nicht verfgbar angesehen und nicht
mehr genutzt wird. Geschftsausflle und Kundenunzufriedenheit sind die Folge.

Messwert

Die Antwortzeiten werden in der Regel aus dem


System-Management oder zum Beispiel mit
Robotern ermittelt.

Name der Kennzahl

Qualitt des Capacity Plans

Definition

bereinstimmung der im Capacity Plan dokumentierten Vernderungen gegenber den tatschlichen Vernderungen.

Relevanz

Eine gute Planung ist wichtig fr das Financial


Management. Eine gute Planung verhindert
kurzfristige und in der Regel teurere Beschaffungsmanahmen.

Messwert

Gegenberstellung der Planungsdaten gegenber den Daten des Configuration Management


Systems.

Bemerkung

Es knnen auch Emergency Changes aus dem


Capacity Managements ermittelt werden. Diese
sind ein Indiz fr einen kurzfristigen Handlungsbedarf.

Name der Kennzahl

Anzahl und Anteil berwachter Systeme

Definition

Anzahl und Anteil der zentralen Systeme, die


mittels eines Monitoring berwacht werden.

Relevanz

Das Monitoring ist Voraussetzung fr eine gute


Planung und berwachung der eingesetzten
Systeme.

Messwert

Die Anzahl ist dem System Management zu


entnehmen, ggf. auch dem Configuration Management. Die Anzahl der zentralen Systeme kann
dem Configuration Management System entnommen werden.

178

5.3 Prozess-Kennzahlen
Name der Kennzahl

Kosteneinsparung durch das Capacity Management pro Bereich oder Technologie

Definition

Einsparungssumme in Euro, die durch optimaleren Einsatz von Technik (z. B. Verdichtung
von Applikationen durch Virtualisierung) eingespart werden kann.

Relevanz

Capacity wird in immer mehr Unternehmen


nicht nur in der Prognose von Kapazittswachstum gesehen, sondern auch zur effektiveren
Nutzung der Ressourcen

Messwert

Kosteneinsparung durch optimalere Nutzung


der Technologien in Euro; z. B. im Bereich der
Security wurden 100.000 Euro Invest eingespart,
indem Lizenzen aus dem Abbau von Clients im
Bereich xyz wiederverwendet wurden.

Bemerkung

Vermeidung von Invest durch Technologieoptimierungen sichert die Mglichkeit, in innovative IT Bereiche zu investieren

Name der Kennzahl

Capacity Management pro Technologie zum


Beispiel Anzahl der Mails In and Out pro Tag

Definition

Vergleich der eingehenden zu den ausgehenden


Mails. Je nach Unternehmen ist diese Kennzahl
unterschiedlich, liegt aber in der Regel bei ca. 1
zu 2 (ausgehend zu eingehend). Sollte der eingehende Wert stark ansteigen ist dies z. B. der
Hinweis auf SPAM oder Mail-Attacken, dem
unbedingt entgegen zu treten ist, um die Ressourcen weiterhin optimal zu nutzen.

Relevanz

Erkennen von Ressourcenverschwendungen


Hinweis auf die Einfhrung neuer Technologien um einen Kostenanstieg dauerhaft zu vermeiden.

Messwert

Vergleich ber mehrere Tage, Wochen, Monate


der Anzahl der eingehenden zu den ausgehenden Mails.

179

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen

5.3.2.4 Availability Management


Der Prozess ist verantwortlich fr die Definition, Analyse, Planung, Messung und Verbesserung aller Aspekte der Verfgbarkeit fr IT Services.
Das Availability Management ist dafr verantwortlich, dass die gesamte
IT Infrastruktur, Prozesse, Tools, Rollen usw. den vereinbarten Service
Level Zielen bezglich der Verfgbarkeit entsprechen.
Name der Kennzahl

Verfgbarkeit des Service und Komponenten

Definition

Verfgbarkeit der Services und der Komponenten innerhalb des vereinbarten Zeitraums.

Relevanz

Die Verfgbarkeit ist als wichtigster Service


Level anzusehen. Deren Kenntnis ist ein wichtiger Input fr das Service Level Management.

Messwert

Die Definition der Messung ist abhngig von


der geforderten Qualitt und den damit verbundenen Kosten. Von der Auswertung von
Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel ber MessPCs.

Name der Kennzahl

Anzahl SLA-Verletzungen aufgrund fehlender


Verfgbarkeit

Definition

Anzahl der Verletzungen von SLAs aufgrund


der nicht sichergestellten Verfgbarkeit.

Relevanz

Wird die vereinbarte Verfgbarkeit nicht sichergestellt, so fhrt dies in der Regel zu Geschftsausfllen.

Messwert

Auswertung der gemessenen Verfgbarkeit


gegenber dem Soll-Wert.

Bemerkung

Die SLA-Verletzungen sind pro SLA auszuweisen.

Name der Kennzahl

Nicht-Verfgbarkeit innerhalb kritischer Geschftszeiten

Definition

Nicht-Verfgbarkeit innerhalb kritischer Geschftszeiten fr einen IT Service.

Relevanz

Wurden mit dem Kunden kritische Geschfts-

180

5.3 Prozess-Kennzahlen
zeiten vereinbart, so ist die Verfgbarkeit innerhalb dieser Zeit besonders herauszustellen.
Messwert

Die Definition der Messung ist abhngig von


der geforderten Qualitt und den damit verbundenen Kosten. Von der Auswertung von
Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel ber MessPCs.

Name der Kennzahl

Kosten der Nicht-Verfgbarkeit

Definition

Kosten fr das Business, wenn die vereinbarte


Verfgbarkeit nicht erreicht wird.

Relevanz

Wird die Verfgbarkeit nicht erreicht, so fhrt


dies in der Regel zu Geschftsausfllen oder
zumindest Zusatzkosten.

Messwert

Die Kosten sind zusammen mit dem Kunden zu


definieren. In der einfachsten Form wird die
Ausfallzeit pro Anwender ermittelt und mit der
Anzahl der Anwender und deren Stundensatz
multipliziert.

Name der Kennzahl

Mittlere Ausfallzeit pro Service

Definition

Mittlere Ausfallzeit pro IT Service, gemessen


vom Ausfall des Service bis zum Zeitpunkt, zu
dem der Service wieder vom Kunden (Anwender) genutzt werden kann.

Relevanz

Whrend die Verfgbarkeit ein statisches Ma


ist, bestimmt die mittlere Ausfallzeit die jeweilige Dauer. Maximale Dauer kann zusammen
mit der Verfgbarkeit als Service Level vereinbart werden.

Messwert

Die Definition der Messung ist abhngig von


der geforderten Qualitt und den damit verbundenen Kosten. Von der Auswertung von
Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel ber MessPCs.

Bemerkung

Zum Teil wird diese Zeit als MTTR - Mean Time


to Restore - bezeichnet. Hufiger wird die Ab-

181

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


krzung fr Mean Time to Restore verwendet.
Es ist daher stets zu prfen, ob die Zeitspanne
die Recovery-Zeit einschliet.
Eine Drill-Down Funktion sollte eine detaillierte
Analyse der einzelnen Zeitstrecke ermglichen.
Name der Kennzahl

Hufigkeit von Ausfllen pro Service

Definition

Anzahl der Unterbrechungen des vereinbarten


Service.

Relevanz

Die Kennzahl dient als Indiz fr die Zuverlssigkeit des IT Service.

Messwert

Die Definition der Messung ist abhngig von


der geforderten Qualitt und den damit verbundenen Kosten. Von der Auswertung von
Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel ber MessPCs.

Name der Kennzahl

Qualitt des Availability Plans

Definition

bereinstimmung der im Availability Plan dokumentierten Vernderungen gegenber den


tatschlichen Vernderungen.

Relevanz

Eine gute Planung ist wichtig fr das Financial


Management. Eine gute Planung verhindert
kurzfristige und in der Regel teurere Beschaffungsmanahmen.

Messwert

Gegenberstellung der Planungsdaten gegenber den Daten des Configuration Management


Systems.

Bemerkung

Es knnen auch Emergency Changes aus dem


Availability Managements ermittelt werden.
Diese sind ein Indiz fr einen kurzfristigen
Handlungsbedarf.

5.3.2.5 IT Service Continuity Management


Der Prozess IT Service Continuity Management (ITSCM) ist verantwortlich fr das Management der Risiken, die schwere Auswirkungen auf den
IT Service haben. Das ITSCM stellt durch eine Risikoreduzierung auf eine

182

5.3 Prozess-Kennzahlen
akzeptable Ebene und die Planung des Recovery von IT Services sicher,
dass der IT Service Provider immer die minimal vereinbarten Service Level Ziele bereitstellen kann. Das ITSCM sollte zur Untersttzung des Business Continuity Managements entworfen werden.
Name der Kennzahl

Anteil SLAs mit ITSC-Anforderungen

Definition

Anteil der SLAs, die Anforderungen an die IT


Service Continuity enthalten.

Relevanz

Die ITSCM Plne sind an die Geschftsanforderungen und den jeweiligen Service-Anforderungen auszurichten. Innerhalb von SLAs sind
diese zu dokumentieren.

Messwert

berprfung der vorhandenen SLAs.

Bemerkung

Hier wird davon ausgegangen, dass fr smtliche Services SLAs existieren. Alternativ ist zu
prfen, ob die ITSC-Plne mit den IT Services
korrespondieren.

Name der Kennzahl

Anzahl und Anteil erfolgreicher ITSCM Audits

Definition

Anzahl und Anteil der erfolgreich durchgefhrten ITSCM berprfungen.

Relevanz

Es muss sichergestellt werden, dass die ITSCM


Plne im Notfall auch funktionieren. Daher sind
sie regelmig zu berprfen.

Messwert

Auswertung der durchgefhrten Reviews und


Audits.

Bemerkung

Ergnzend sollte das Datum des letzten Audits /


Reviews ausgewiesen werden.

Name der Kennzahl

Anzahl und Anteil erfolgreicher ITSCM Tests

Definition

Anzahl und Anteil der erfolgreich durchgefhrten ITSCM Tests.

Relevanz

Es muss sichergestellt werden, dass die ITSCM


Plne im Notfall auch funktionieren. Daher sind
sie regelmig zu testen.

Messwert

Auswertung der durchgefhrten Testprotokolle.

183

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Bemerkung

Die Tests sollten zumindest einmal jhrlich zusammen mit den Geschftsbereichen (Business
Continuity Management) erfolgen.

Name der Kennzahl

Schulungsstunden und Manahmen ITSCM

Definition

Anzahl der durchgefhrten Schulungsstunden


und Schulungsmanahmen fr das ITSCM.

Relevanz

Schulung der Mitarbeiter stellt sicher, dass die


Mitarbeiter mit den Manahmen vertraut sind
und die Notwendigkeit einsehen.

Messwert

Auswertung der durchgefhrten Schulungsmanahmen.

Name der Kennzahl

Zeitdauer fr Aktualisierung der ITSC-Plne

Definition

Zeitdauer fr Aktualisierung der ITSC-Plne


aufgrund eines identifizierten nderungsbedarfs.

Relevanz

nderungen knnen sich aufgrund genderter


Kundenanforderungen oder durchgefhrter
Changes ergeben. Dann ist sicherzustellen, dass
die notwendigen nderungen zeitnah umgesetzt werden.

Messwert

ITSC-Plne sind CIs. Im Rahmen der Versionsverfolgung kann aus dem Configuration Management System die Zeitspanne ermittelt werden.

5.3.2.6 Information Security Management


Der Prozess Information Security Management stellt die Vertraulichkeit,
Integritt und Verfgbarkeit von den Vermgenswerten (Assets) einer
Organisation, deren Information, Daten und IT Services sicher. Das Information Security Management ist normalerweise ein Teil des organisatorischen Ansatzes zum Security Management, das einen breiteren Scope gegenber dem IT Service Provider hat und die Handhabung von Schriftstcken, Gebudezugngen, Telefonanrufe usw. fr die gesamte Organisation
beinhaltet.

184

5.3 Prozess-Kennzahlen
Name der Kennzahl

Anzahl und Auswirkungen Security Incidents

Definition

Anzahl und Auswirkungen der festgestellten


Security Incidents.

Relevanz

Aufgabe des Security Managements ist die Analyse mgliche Bedrohungen und deren prventive Reduktion. Diese Kennzahl zeigt die Qualitt der Prvention auf und ist Indikator fr
mgliche Verbesserungen.

Messwert

Auswertung der Incident Records mit der Kategorie Security und der Codierung Auswirkung (Impact).

Bemerkung

Voraussetzung ist, dass die Security Incidents


entsprechend erkannt und dokumentiert werden.

Name der Kennzahl

Anteil SLAs mit Sicherheits-Klauseln

Definition

Anteil des SLAs, die Klauseln zu den Sicherheits-Anforderungen enthalten.

Relevanz

Die notwendigen Sicherheitsmanahmen sind


auf die Geschftsanforderungen 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-Konformitt der


IT Service Management-Prozesse und Systeme
mit den definierten Sicherheitsanforderungen
(Security Policy und Prozess).

Relevanz

Die Kennzahl zeigt die zunehmende Akzeptanz


und Wahrnehmung von Sicherheitsbelangen.

Messwert

Auswertung durchgefhrter Audits und Revisionen.

Bemerkung

Festgestellte Verletzungen von ComplianceAnforderungen sind besonders herauszustellen.

185

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Name der Kennzahl

Anzahl vergeblicher Login-Versuche

Definition

Anzahl der festgestellten vergeblichen LoginVersuche.

Relevanz

Eine hohe Anzahl vergeblicher Login-Versuche


zeigt mgliche illegale Versuche der Informationsbeschaffung auf.

Messwert

Auswertung der Protokolldatei entsprechender


Identifizierungssysteme.

Bemerkung

Hierzu sind auffllige User-IDs zur Prvention herzustellen.

Name der Kennzahl

Anzahl Verbesserungsvorschlge zur Security

Definition

Anzahl der eingereichten Verbesserungsvorschlge und Verbesserungsmanahmen im Bereich des Security Managements.

Relevanz

Die Kennzahl zeigt die zunehmende Akzeptanz


und Wahrnehmung von Sicherheitsbelangen.

Messwert

Auswertung der Service und Prozess Improvement Plne (SIP und PIP).

Name der Kennzahl

Aufwand fr Security pro Jahr und pro Bereich.

Definition

Hhe der Investition pro Security-Bereich und


Jahr z. B. in Virenschutz, Firewalls etc. und damit z. B. in uere und innere Sicherheit.

Relevanz

Abstimmung, Umsetzung und Monitoring der


Investitionen in die Security eines Unternehmens

Messwert

Investitionen pro Jahr aufgeteilt in interne und


externe Security oder z. B. Virenschutz, Firewalls, Sniffer etc..

5.3.2.7 Supplier Management


Der Prozess Supplier Management ist dafr verantwortlich, sicherzustellen, dass alle Vertrge mit Lieferanten die Geschftsanforderungen untersttzen und dass alle Lieferanten ihren vertraglichen Verpflichtungen
nachkommen.

186

5.3 Prozess-Kennzahlen
Name der Kennzahl

Anteil eingehaltener UCs

Definition

Anteil der Lieferanten, die die im Underpinning


Contract (UC) vereinbarten Anforderungen
erfllen.

Relevanz

Die Enthaltung der SLAs ist abhngig von der


Einhaltung der UCs. Halten die Lieferanten die
Vereinbarungen nicht ein, so hat dies einen
unmittelbaren Einfluss auf die Untersttzung
der Geschftsprozesse.

Messwert

Wird dem Tool fr das Monitoring der Service


Level entnommen.

Name der Kennzahl

Anzahl Kundenbeschwerden zum Service

Definition

Anzahl der Kundenbeschwerden, die auf Nichteinhaltung von UCs zurckzufhren sein.

Relevanz

Die Nichteinhaltung von UCs fhrt in der Regel


zu Service Level-Verletzungen und zu Kundenunzufriedenheit. ber ein Monitoring sind
nicht smtliche Aspekte zu messen.

Messwert

Auswertung von Reviews.

Name der Kennzahl

Anzahl der Streitflle mit Lieferanten

Definition

Anzahl der formellen Streitflle mit den beauftragten Lieferanten.

Relevanz

Formelle Streitflle mit Lieferanten sind ein


Indiz fr nicht eindeutige Vereinbarungen innerhalb der UCs.

Messwert

Die Streitflle sind vom Supplier Manager in


einem System zu speichern.

Bemerkung

Bei Bedarf kann hier im Rahmen einer DrillDown Funktion noch nach dem Anlass unterschieden werden, wie zum Beispiel bemngelte
Rechnungen oder Verletzungen von Compliance-Anforderungen.

Name der Kennzahl

Anzahl der Reviews mit Lieferanten

Definition

Anzahl der mit Lieferanten zum Service und

187

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


UC durchgefhrten Reviews.
Relevanz

Reviews dienen der besseren Abstimmung mit


dem Lieferanten und fhren zu einer Steigerung
der Service-Qualitt.

Messwert

Die Anzahl der durchgefhrten Reviews sind


vom Supplier Manager in einem System zu
speichern.

Name der Kennzahl

Anzahl von Lieferanten, die faktisch der ITSteuerung unterliegen.

Definition

Anzahl der Lieferanten, die einem Supplierund Vertrags-Manager zugeordnet sind.

Relevanz

Die Supplier sind hinsichtlich der vereinbarten


Leistungen und vertraglichen Aspekte durch
verantwortliche Manager zu steuern.

Messwert

Die UCs sind zusammen mit den zugeordneten


Managern im SLM-Tool gespeichert. Die zugeordnete Anzahl kann diesem System entnommen werden.

Bemerkung

Ergnzend kann zur Anzahl auch der Anteil der


zugeordneten Lieferanten dargestellt werden.

Name der Kennzahl

Zufriedenheit mit dem Lieferanten

Definition

Zufriedenheit in der Zusammenarbeit und


Kommunikation mit dem Lieferanten.

Relevanz

Eine gute Kommunikation und Zusammenarbeit zeigt sich auch auerhalb der festgelegten
Service Level.

Messwert

Zufriedenheitsbefragung der innerhalb der IT


mit dem Lieferanten zusammenarbeitenden
Bereiche.

Bemerkung

Es kann auch der Lieferant zur Zufriedenheit


befragt werden.

188

5.3 Prozess-Kennzahlen

5.3.3

Service Transition

5.3.3.1 Transition Planning and Support


Der Prozess Transition Planning und Support ist verantwortlich fr die
Planung der gesamten Service Transition Prozesse und Koordination der
erforderlichen Ressourcen. Diese Prozesse sind Change Management,
Service Asset and Configuration Management , Release and Deployment Management, Service Validation and Testing, Evaluation und
Knowledge Management.
Name der Kennzahl

Anteil eingehaltener Release-Vereinbarungen

Definition

Anteil der Releases, die die zuvor vereinbarten


Kriterien hinsichtlich Kosten, Qualitt, Umfang
und Terminplanung einhalten.

Relevanz

Fr den Kunden ist nicht nur die Einhaltung der


Qualitt und die geplanten Termine fr Releases von Relevanz, sondern auch, dass der
implementierte Inhalt der Planung und Vereinbarung entspricht.
Die Auswirkung der Einhaltung der Kostenplanung ist abhngig von der Leistungsverrechnung.

Messwert

Hierzu sind in den Release-Records die Planungsinformationen hinsichtlich Kosten, Termine und geplante Inhalte (Changes) zu speichern und mit dem Auslieferungsumfang, Termin und ermittelten Kosten zu vergleichen. Die
Qualitt wird ber ggf. auftretende Incidents
gemessen.

Bemerkung

In dieser Kennzahl werden mehrere Aspekte


gemeinsam betrachtet. Dazu ist ggf. eine Gewichtung dieser Aspekte notwendig. Es ist auch
mglich, aus den einzelnen Aspekten (Kosten,
Termine, etc.) einzelne Kennzahlen zu definieren.

Name der Kennzahl

Kundenzufriedenheit Service Transition Plne

Definition

Ergebnis der Kundenzufriedenheit bezglich


der Service Transition Plne.

189

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Relevanz

Abweichungen des geplanten Release haben


Auswirkungen auf die Kunden- (und Anwender) -zufriedenheit.

Messwert

Abfrage in der Kundenzufriedenheitsumfrage

Bemerkung

Hier ist zustzlich auch eine Abfrage der Anwender mglich.

Name der Kennzahl

Zufriedenheit Service Team

Definition

Zufriedenheit in den Projekt- und ServiceTeams mit den in der Phase Service Transition
definierten Verfahren.

Relevanz

Die korrekte Nutzung der beschrieben Verfahren hngt von der Praktikabilitt und von Akzeptanz innerhalb der Service Teams und der
beteiligten Projekt-Teams ab.

Messwert

Hierzu sind interne Feedbacks einzuholen und


auszuwerten.

190

5.3 Prozess-Kennzahlen

5.3.3.2 Change Management


Der Prozess Change Management ist fr das Controlling des gesamten
Lifecycle aller Changes verantwortlich. Das primre Ziel des Change Managements besteht darin, die Durchfhrung vorteilhafter Changes zu ermglichen, mit minimalen Strungen der IT Services.
Name der Kennzahl

Anzahl Changes

Definition

Die Kennzahl stellt die Anzahl der bearbeiteten


Changes im Betrachtungszeitraum dar. Betrachtet werden alle RFCs, die vom Change Management bearbeitet wurden, das heit auch zurckgewiesene RFCs.

Relevanz

Die Kennzahl ist wichtig als Referenzwert. Darber hinaus zeigt die Anzahl der Changes die
Flexibilitt der IT-Organisation, auf Kundenanforderungen schnell zu reagieren.

Messwert

Aus der Change-DB werden smtliche RFCs im


Betrachtungszeitraum ermittelt.

Bemerkung

Die Darstellung der Gesamtzahl allein ist wenig


informativ. Daher ist eine Aufschlsselung in IT
Services, betroffene CIs (Infrastruktur, Applikation, etc.) notwendig.
Eine weitere Aufschlsselung besteht in der
Darstellung der Prioritten, wobei die Emergency Changes besonders herausgehoben werden sollten.
Weiterhin sollte eine Aufgliederung darstellen,
ob es sich um Kunden- oder IT-getriebene
Changes handelt.

Name der Kennzahl

Anteil fehlerfreier Changes

Definition

Darstellung des Verhltnisses fehlerfreier Changes das heit Implementierung des Changes
ohne anschlieende Incidents im Betrieb in
Bezug zur Anzahl der Changes

Relevanz

Diese Kennzahl ist die wichtigste Kennzahl fr


die Effektivitt des Change Managements. Ein
hoher Anteil nicht fehlerfreier Changes ist ein

191

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Indiz fr eine unzureichende Auswirkungsanalyse der RFCs. Fehlerhafte Changes fhren zu
Geschftsausfllen, dadurch sinkt die Kundenzufriedenheit. Weiterhin fhren fehlerhafte
Changes innerhalb der IT zu Zusatzaufwendungen, das heit die IT-Kosten steigen.
Messwert

Im Idealfall werden im Betrachtungszeitraum


die implementierten Changes aus der ChangeDB ermittelt und geprft, ob hierfr Incident
Records existieren (im Incident Record ist die
Nummer des Changes als Grund fr den Incident vermerkt).

Bemerkung

Fr die Aussagekraft dieser Kennzahl sind die


Datenqualitt und das Know-how im Incident
Management entscheidend. Wird ein fehlerhafter Change nicht als Grund der Strung erkannt
und eingetragen, so hat dies erheblichen Einfluss auf die Qualitt dieser Kennzahl. Hier
wre dann zu berlegen, ob alternativ die Probleme aufgrund von Changes auszuwerten sind,
da im Problem Management von einer besseren
Datenqualitt auszugehen ist.

Name der Kennzahl

Anteil termingerechter Changes

Definition

Darstellung des Verhltnisses termingerechter


Changes - das heit Implementierung bis zum
vereinbarten Termin - in Bezug zur Anzahl der
Changes

Relevanz

Diese Kennzahl ist eine Kennzahl fr die Effektivitt des Change Managements. Ein hoher
Anteil nicht termingerechter Changes ist ein
Indiz fr eine unzureichende Planung. Werden
die zugesagten Termine nicht eingehalten, sinkt
die Kundenzufriedenheit und unter Umstnden
entstehen Auswirkungen auf das Business.

Messwert

In der Change-DB werden die Datenfelder der


geplante Implementierung mit der tatschlichen Implementierung verglichen.

Bemerkung

Bei Bedarf knnen weitere Aspekte hinsichtlich


der Qualitt der Terminplanung verfolgt wer-

192

5.3 Prozess-Kennzahlen
den, wie zum Beispiel den Beginn der geplanten
Tests, etc.
Name der Kennzahl

Anteil kostengerechter Changes

Definition

Darstellung des Verhltnisses kostengerechter


Changes - das heit Changes, die die vereinbarten Kosten nicht berschreiten - in Bezug zur
Anzahl der Changes

Relevanz

Die Relevanz dieser Kennzahl ist abhngig von


der Leistungsverrechnung. Werden die Kosten
fr Changes vom Kunden getragen, so haben
Mehrkosten Auswirkungen auf die Kundenzufriedenheit. Muss die IT fr die Kosten aufkommen, so fhren Changes mit hheren
Durchfhrungskosten zu einer nicht eingeplanten Kostensteigerung innerhalb der IT. Die
Kennzahl zeigt die Qualitt der Planung und
Analyse von Changes hinsichtlich der Aufwendungen auf.

Messwert

Zum Change sind die damit verbundenen Aufwendungen (Personal, Material) zu erfassen.
Aus der Change-DB werden diese Aufwendungen ermittelt und den geplanten Kosten gegenbergestellt.

Name der Kennzahl

Anteil erfolgreicher Back-Out-Planungen

Definition

Die Kennzahl stellt die Anzahl der erfolgreichen


Back-Out-Manahmen im Verhltnis zu den
durchgefhrten Back-Out-Manahmen dar.

Relevanz

Nicht alle Changes knnen strungsfrei implementiert werden. Dann ist es wichtig, dass die
Mglichkeit besteht, in den gesicherten Ausgangszustand zurckzukehren. Hierzu ist im
Change Management eine Back-Out-Planung
notwendig. Diese Kennzahl misst die Qualitt
dieser Planung.

Messwert

Aus der Change-DB werden die Changes ermittelt, die zurckgenommen werden mussten und
die Changes, deren Back-Out-Plan erfolgreich

193

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


war.
Bemerkung

Existieren hierfr keine Datenfelder, so knnen


zur Generierung auch die Ergebnisse aus dem
Review herangezogen werden.

Name der Kennzahl

Anzahl offener RFCs

Definition

Die Kennzahl zeigt an, wie viele RFCs noch


nicht bearbeitet wurden.

Relevanz

Eine hohe Anzahl offener RFCs zeigt einen Bearbeitungsstau im Prozess an. Als Folge wird
die Akzeptanz fr das Change Management
sinken, unter Umstnden das Change Management umgangen und sinnvolle RFCs nicht mehr
eingereicht.

Messwert

Ermittelt werden aus der Change-DB die Anzahl der RFCs fr die Aktivitt Asses and evaluate the Change noch nicht durchgefhrt
wurde.

Name der Kennzahl

Anzahl nicht genehmigter Changes

Definition

Diese Kennzahl identifiziert die festgestellten


Changes, die unter Umgehung des Change Managements durchgefhrt wurden.

Relevanz

Die Anzahl deutet auf einen nicht wirksamen


Change Management-Prozess hin. Hufig ist er
zu administrativ, sodass der Prozess umgangen
wird. Insbesondere fr Unternehmen, die
Compliance-Anforderungen wie SOX erfllen
mssen, ist diese Kennzahl von besonderer
Bedeutung.

Messwert

Es werden die Ergebnisse des Verification and


Audit im Prozess Service Asset und Configuration Management ausgewertet.

Name der Kennzahl

Anteil zurckgewiesener RFCs

Definition

Die Kennzahl zeigt an, wie viele der eingereichten RFCs vom Change Management zurckgewiesen wurden.

194

5.3 Prozess-Kennzahlen
Relevanz

RFCs knnen zurckgewiesen werden, wenn


sie zum Beispiel unvollstndig sind. Ein hoher
Anteil zurckgewiesener RFCs fhrt zu einem
ineffizienten Prozess.

Messwert

Ermittelt werden aus der Change-DB, die Anzahl der RFCs, die den Status zurckgewiesen 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 fr die Verfolgung und das Reporting der Werte und Ownership smtlicher finanzieller
Assets whrend des gesamten Lebenszyklus verantwortlich. Das Configuration Management ist fr die Pflege der Information ber Configuration
Items (CIs) und deren Beziehungen verantwortlich, die fr die Bereitstellung der IT Services bentigt werden. Diese Informationen sind ber den
gesamten Lebenszyklus der CIs zu verwalten.
Name der Kennzahl

Anzahl der CIs

Definition

Anzahl der Service Assets und der Configuration Items (CIs).

Relevanz

Die Anzahl der CIs dient fr weitere Betrachtungen als Referenzwert.

Messwert

Ermittlung der CIs aus dem Configuration Management System (CMS)

Bemerkung

Hierfr sollte eine Drill-Down Funktion existieren, um die CIs aufgliedern zu knnen (zum
Beispiel CIs, die zu einem IT Service gehren,
Applikationen, etc.)

Name der Kennzahl

Anzahl abweichender CIs

Definition

Anzahl der festgestellten Abweichungen an CIs


zwischen dem CMS und dem tatschlichen
Bestand.

Relevanz

Die Informationen des CMS dienen unterschiedlichen Prozessen und Aktivitten als Planungsgrundlage. Fehlerhafte Informationen haben
eine negative Auswirkung auf die Qualitt des

195

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


IT Service.
In Verbindung mit Compliance-Anforderungen,
wie zum Beispiel SOX oder Versicherungsbestimmungen, knnen geschftliche Schden
bzw. Kosten entstehen.
Messwert

CI-Abweichungen zwischen Soll- und Ist-Bestand sind im CMS beim betroffenen CI zu dokumentieren. Ausgewertet werden die Ergebnisse dieser Audits.

Bemerkung

Eine Gruppierung der CIs nach IT Services oder


relevante
Compliance-Anforderungen
ist
zweckmig.

Name der Kennzahl

Anteil nicht genutzter Lizenzen

Definition

Anteil der erworbenen und nicht genutzten


Software-Lizenzen.

Relevanz

Nicht genutzte Software-Lizenzen fhren zu


unntigen Kosten fr die IT und die IT Services.

Messwert

Abgleich zwischen den erworbenen und in Nutzung befindlichen Software-Lizenzen. Hierzu


mssen die CIs mit einem entsprechenden Status in Nutzung und Codierung fr Software ausgewiesen werden.

Bemerkung

Diese Kennzahl kann auch genutzt werden, um


eine Unterlizenzierung darzustellen.

Name der Kennzahl

Zunahme an und Wert der CIs

Definition

Zunahme der CIs und finanzieller Wert der CIs.

Relevanz

Zeigt das Wachstum innerhalb der IT auf.

Messwert

Auswertung des Configuration Management


Systems.

Bemerkung

Hierfr sollte eine Drill-Down Funktion existieren, um die CIs aufgliedern zu knnen (ITZuordnung zum Service oder CI-Typen, wie
Applikationen etc.).

196

5.3 Prozess-Kennzahlen
Name der Kennzahl

Auswirkungen fehlerhafter CIs

Definition

Anzahl der fehlerhaften Changes, deren Ursachen auf fehlerhafte CIs und CI-Informationen
zurckzufhren sind.

Relevanz

Das CMS liefert eine wichtige Informationsbasis


fr die Analyse der Auswirkungen von Changes. Fehlerhafte Informationen knnen zu Ausfllen von IT Services und fr das Business fhren, wenn hierdurch Changes fehlerhaft sind.

Messwert

Zur Generierung dieser Kennzahl sind die Ergebnisse der Reviews im Change Management
auszuwerten.

Bemerkung

In der Literatur wird als Kennzahl auch Incidents oder Probleme aufgrund fehlerhafter
CIs beschrieben. Hier ist kritisch zu prfen, ob
eine eindeutige und verlssliche Unterscheidung im operativen Betrieb mglich 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 fr die Effizienz


des Configuration Managements.

Messwert

Hierzu sind die Audits zum jeweiligen CI auszuwerten. Mittels Codierung sind festgestellte
Abweichungen und deren Korrektur zu dokumentieren.

5.3.3.4 Release and Deployment Management


Der Prozess ist verantwortlich fr das Release und Deployment Management. Dabei ist das Release Management fr die Planung, Terminplanung
und Steuerung der berfhrung von Releases in die Test- und Live-Umgebung verantwortlich Das primre Ziel des Release Managements besteht
im Schutz der Live-Umgebung und der Herausgabe der richtigen Komponenten. Das Deployment Management ist verantwortlich fr die berfhrung von neuer oder genderter Hardware, Software, Dokumentation,
Prozesse usw. in die Live-Umgebung.

197

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Name der Kennzahl

Anzahl durchgefhrter Releases

Definition

Anzahl der durchgefhrten Releases pro IT


Service.

Relevanz

Die Anzahl der CIs dient fr weitere Betrachtungen als Referenzwert.

Messwert

Ermittlung der durchgefhrten Releases aus der


Release-DB.

Bemerkung

Hierfr sollte eine Drill-Down Funktion existieren, um die Releases aufgliedern zu knnen
(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 durchgefhrter Releases auftreten.

Relevanz

Treten nach einem Release Incidents auf, so


fhrt dies zu Geschftsbeeintrchtigungen und
einer Kundenunzufriedenheit.
Auerdem treten mit der notwendigen Behebung Zusatzkosten fr die IT-Organisation auf.

Messwert

Auswertung der Incidents im Betrachtungszeitraum, die auf einen Release referenzieren.

Bemerkung

Hier sollte eine Drill-Down Funktion auf betroffene IT Services bestehen.


Kann das Incident Management die notwendigen Informationen und Datenqualitt nicht
sicherstellen, so sind statt der Incidents die
Problems auszuwerten.

Name der Kennzahl

Kundenzufriedenheit durchgefhrter Releases

Definition

Kundenzufriedenheit mit der Durchfhrung


von Releases.

Relevanz

Die Kennzahl ist ein Ma fr die subjektive


Einschtzung des Kunden.

Messwert

Abfrage in der Kundenzufriedenheitsumfrage

198

5.3 Prozess-Kennzahlen
Name der Kennzahl

Fehlerhafte CMS

Definition

Anzahl der durch das Release Management


verursachten Abweichungen zwischen dem
CMS und dem Ist-Bestand.

Relevanz

Mittels Releases durchgefhrte Vernderungen


sind im CMS zu dokumentieren. Diese Kennzahl dient der Messung, ob die notwendigen
Daten dem Configuration Management zur
Verfgung gestellt werden.

Messwert

Auswertung der CIs hinsichtlich festgestellter


Abweichung und der Ursache Release Management

Bemerkung

Hierzu sind nicht nur festgestellte Abweichungen im Audit zum CI zu dokumentieren, sondern auch der Verursacher.

Name der Kennzahl

Vollstndigkeit DML

Definition

Anzahl der fehlenden Medien im Bestand der


Definitive Media Library (DML).

Relevanz

Sobald eine neue Software produktiv gesetzt


wird, sind die Medien in die DML aufzunehmen und das CMS zu aktualisieren.

Messwert

Ermittlung auf Basis durchgefhrter Verifikationen und Audits.

5.3.3.5 Evaluation
Der Prozess ist verantwortlich fr die Beurteilung neuer oder genderter
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 tatschlichen Ergebnisse
den angestrebten Ergebnissen entsprechen oder zum Vergleich einer Alternative mit einer anderen.
Name der Kennzahl

Anzahl Abweichungen in der Service Performance

Definition

Anzahl der festgestellten Abweichungen zwischen der bereitgestellten und der bentigten
Service Performance.

199

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Relevanz

Zur Untersttzung der Geschftsprozesse muss


der Service die bentigte Performance sicherstellen. Eine unzureichende Performance kann
zu Geschftsausfllen fhren.

Messwert

Auswertung der Testergebnisse.

Name der Kennzahl

Anzahl Incidents zum Service

Definition

Anzahl der zum Service gemeldeten Incidents

Relevanz

Eine hhere Anzahl fhrt zur Einschrnkung


des Geschftsbetriebs und Kundenunzufriedenheit.

Messwert

Auswertung der Incident Records, die zu einem


Service erfasst sind. Zustzlich sind die Termine
fr durchgefhrte Deployments darzustellen.

Bemerkung

Hierzu muss eine Zuordnung des Incident Records zum Service mglich sein.
Eine Drill-Down Funktion sollte die dazugehrigen Kategorien der Incidents aufzeigen.

Name der Kennzahl

Durchlaufzeit Auswertung

Definition

Durchlaufzeit, um die Auswertung der Tests


durchzufhren.

Relevanz

Eine geringe Durchlaufzeit bzw. deren Reduzierung ist ein Zeichen fr die verbesserte Effizienz.

Messwert

Auswertung der im Textbericht protokollierten


Zeiten.

5.3.3.6 Knowledge Management


Der Prozess ist dafr verantwortlich das Wissen und die Informationen
innerhalb einer Organisation zu sammeln, zu analysieren, zu speichern
und gemeinsam zu nutzen. Der Hauptzweck des Knowledge Managements ist es, durch das Reduzieren der Notwendigkeit das Wissen wieder
zu entdecken, die Effizienz zu verbessern.

200

5.3 Prozess-Kennzahlen
Name der Kennzahl

Anzahl Incident fehlendes Anwender-Wissen

Definition

Anzahl der Incidents mit der Kategorisierung


fehlendes Anwender-Wissen.

Relevanz

Das fehlende Anwender-Wissen fhrt nicht nur


zu Geschftsausfllen, sondern auch zu Zusatzressourcen und Kosten innerhalb der ITOrganisation.

Messwert

Auswertung der Incident Records mit der Kategorie fehlendes Anwender-Wissen.

Bemerkung

Hierzu knnen auch die damit verbunden Bearbeitungszeiten und resultierenden Kosten dargestellt werden.

Name der Kennzahl

Durchschnittliche Diagnosezeit

Definition

Durchschnittliche Diagnose- und Behebungszeit


fr die Lsung von Fehlern.

Relevanz

Eine schnelle Diagnose- und Behebungszeit ist


ein Indiz fr ein gutes Service Knowledge Management System (SKMS).

Messwert

Auswertung der Diagnosezeiten der Incident


Records.

Name der Kennzahl

Zugriffe SKMS

Definition

Anzahl der Zugriffe auf das SKMS.

Relevanz

Die Nutzung des SKMS fhrt in der Regel nicht


nur zu schnelleren Lsungen, 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 Fllen
(Anteil in Prozent) nach einer Lsung im SKMS
gesucht wurde.

Name der Kennzahl

Nutzungsgrad SKMS

Definition

Nutzungsgrad des SKMS zur Behebung von


Incidents.

201

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Relevanz

Die Nutzung des SKMS fhrt in der Regel nicht


nur zu schnelleren Lsungen, sondern sichert
auch ein konsistentes Vorgehen.

Messwert

Auswertung der Incident Records, die mit


Known Errors oder Workarounds verknpft
sind.

Bemerkung

In Verbindung mit den Zugriffen auf das SKMS


kann festgestellt werden, in wie vielen Fllen
eine Lsung in dem SKMS gefunden werden
konnte.

Name der Kennzahl

Anwenderzufriedenheit SKMS

Definition

Anwenderzufriedenheit mit den zur Verfgung


gestellten Informationen, wie zum Beispiel
Newsletter, Einweisungen, Web-Informationen,
etc.

Relevanz

Gute Informationen des Anwenders fhren zu


einer besseren Nutzung des Service und reduzieren Support-Kosten.

Messwert

Erhebung und Auswertung im Rahmen einer


Anwenderzufriedenheitsbefragung.

5.3.4

Service Operation

5.3.4.1 Event Management


Der Prozess ist verantwortlich fr das Management von Events whrend
des gesamten Lifecycle. Das Event Management ist eine der Hauptaktivitten von IT Operation.
Bisher wurden in ITIL und der ISO 20000 die Events im Incident Management aufgenommen und als Incidents gespeichert. Bis eine Erweiterung
der bestehenden Prozesse durch die Tool-Hersteller auf ITIL V 3 erfolgt,
sind die im Folgenden beschriebenen Events aus der Incident-DB anhand
einer Codierung zu ermitteln.
Name der Kennzahl

Anzahl der Events

Definition

Anzahl der Events im Betrachtungszeitraum.

Relevanz

Die Anzahl der Events dient fr weitere Betrachtungen als Referenzwert. Sie kann zusam-

202

5.3 Prozess-Kennzahlen
men mit einer Trend-Darstellung auch als Indiz
fr die Qualitt des Events Managements genutzt werden.
Messwert

Ermittlung der Records aus der Event-DB.

Bemerkung

Hierfr sollte eine Drill-Down Funktion existieren, um die betroffenen Cis (Applikationen,
Plattformen, etc.) darstellen zu knnen.

Name der Kennzahl

Anteil der Events

Definition

Prozentualer Anteil und Anzahl der Events pro


Art (Incident, Problem, Change) im Betrachtungszeitraum.

Relevanz

Die Anzahl der Events dient fr weitere Betrachtungen als Referenzwert. Sie kann zusammen mit einer Trend-Darstellung auch als Indiz
fr die Qualitt des Events Managements genutzt werden. Eine steigende Anzahl zeigt, dass
die Ereignisse besser erkannt werden, bevor sie
sich zum Beispiel als Strung beim Anwender
uern.

Messwert

Ermittlung der Records aus der Event-DB.

Bemerkung

Hierfr sollte ein Drill-Down mglich sein um


die betroffenen Cis (Applikationen, Plattformen,
etc.) darstellen zu knnen.

Name der Kennzahl

Events zu Incidents (Problems)

Definition

Prozentualer Anteil der per Events erkannten


Incidents (Problems) zu den von Anwendern
gemeldeten Incidents (Problems).

Relevanz

Ein hoher Anteil der Events zeigt, dass die Ereignisse vom System erkannt werden, bevor sie
sich zum Beispiel als Strung beim Anwender
uern. Dies fhrt zu einer hheren Verfgbarkeit und greren Kundenzufriedenheit.

Messwert

Ermittlung der Records aus der Event-DB und


Incident-DB bzw. Problem-DB.

203

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Name der Kennzahl

Events pro Signifikanz

Definition

Anzahl und Anteil der Events pro Signifikanz.

Relevanz

Zielsetzung fr das Event Management ist die


Erkennung von signifikanten Incidents oder
Problemen. Diese Kennzahl zeigt an, ob dieses
Ziel erreicht wird.

Messwert

Ermittlung der Records aus der Event-DB und


Incident-DB bzw. Problem-DB.

Name der Kennzahl

Events mit Verfgbarkeits-Belangen

Definition

Anzahl und Anteil der Events mit mglichen


Belangen fr die Verfgbarkeit.

Relevanz

Die Verfgbarkeit ist einer der wichtigsten Service Level. Eine Nicht-Verfgbarkeit wirkt sich
unmittelbar auf die Geschftsprozesse aus. Diese Kennzahl zeigt an, wie gut diese Incidents /
Probleme erkannt werden.

Messwert

Ermittlung der Records aus der Event-DB und


Incident-DB bzw. Problem-DB.

5.3.4.2 Incident Management


Der Prozess ist verantwortlich fr das Management der Incidents whrend
des Lifecycle. Das primre Ziel ist es, den IT Service fr den Anwender so
schnell wie mglich wieder herzustellen.
Mit der Herausgabe von ITIL Version 3 werden Service Requests in einem
gesonderten Prozess behandelt. Daher ist hier keine Filterung der erfassten
Vorgnge notwendig. Innerhalb von ITIL Version 2 und der ISO 20000
werden im Incident Management Strungen und Service Requests behandelt. Fr Auswertungszwecke ist hier eine Eingrenzung der erfassten Vorgnge auf Strungen notwendig.
Name der Kennzahl

Anzahl der Incidents

Definition

Anzahl der Incidents im Betrachtungszeitraum.

Relevanz

Die Anzahl der Incidents dient fr weitere Betrachtungen als Referenzwert. Sie kann zusammen mit einer Trend-Darstellung auch als Indiz
fr die Qualitt des Problem Managements
genutzt werden. Eine steigende Anzahl wirkt

204

5.3 Prozess-Kennzahlen
sich darber hinaus auf die Kundenzufriedenheit aus. Bei einer steigenden Anzahl fhrt deren Behebung zu steigenden Prozess- und ITKosten.
Messwert

Ermittlung der Incident Records aus der Incident-DB.

Bemerkung

Die Gesamtanzahl ist allein wenig aussagekrftig. Die Anzahl der Incidents ist aufzugliedern
in die betroffenen IT Services und pro Prioritt
darzustellen.
Hier ist eine Drill-Down Funktion zur weiteren
Analyse unbedingt notwendig.

Name der Kennzahl

Anzahl und Anteil der Major Incidents

Definition

Anzahl und Anteil der Major Incidents im Betrachtungszeitraum.

Relevanz

Major Incident fhren i. d. R. zu greren Ausfllen des IT Service und so der relevanten Geschftsprozesse.

Messwert

Ermittlung der Incident Records anhand der


Codierung aus der Incident-DB.

Name der Kennzahl

Erstlsungsquote

Definition

Die Erstlsungsquote definiert, wie viel Prozent


der eingehenden Incidents im Erstkontakt zwischen den Anwendern und dem Service Desk
gelst werden konnten.

Relevanz

Eine gute Erstlsungsquote steigert die Anwenderzufriedenheit und reduziert die Ausfallzeit
fr das Business.
Zustzlich trgt eine gute Erstlsungsquote
dazu bei, dass der 2nd Level Support entlastet
wird. In der Regel fhrt dies auch zu einer Reduzierung der Kosten fr die Behebung von
Incidents.

Messwert

Ausgewertet werden alle Incidents, die mittels


Telefon beim Service Desk eingegangen sind.
Als Erstlsungsquote wird der Prozentwert
dieser Incidents dargestellt, bei denen die Mitar-

205

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


beiter im Service Desk den Incident direkt lsen
konnten und der Incident nicht weitergeleitet
wurde.
Bemerkung

Die Erstlsungsquote kann auch als Service


Level in SLAs vereinbart werden. Dann ist die
Erstlsungsquote in Bezug auf den jeweiligen IT
Service darzustellen.
Diese Kennzahl kann auch fr 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 Ttigkeit in der zugewiesenen
Support-Einheit.

Relevanz

Hohe Reaktionszeiten knnen auf eine zu hohe


Arbeitslast fr die betroffene Support-Einheit
hinweisen.

Messwert

Aus den Incident Records wird die Zeitdauer


zwischen der Weiterleitung vom Service Desk
und der Beginn der Bearbeitung in der zugewiesenen Support-Einheit ermittelt.

Bemerkung

Hier ist zu definieren, was unter Reaktion bzw.


Reaktionszeit zu verstehen ist. Man knnte den
Begriff Reaktion z. B. als Kontaktaufnahme
mit dem Anwender definieren.

Name der Kennzahl

Einhaltung Reaktionszeit

Definition

Anteil der Incidents, die in Abhngigkeit der


Prioritt innerhalb der vereinbarten Reaktionszeit bearbeitet wurden.

Relevanz

Die Bedeutung ist abhngig von den vereinbarten Service Level. Ist die Reaktionszeit als Service Level vereinbart, so ist deren Einhaltung
wichtig fr die Kundenzufriedenheit.
Innerhalb der IT ist die Reaktionszeit ein wichtiges Ma fr die Bearbeitung von weitergeleiteten Strungen. Hohe Reaktionszeiten knnen
auf eine zu hohe Arbeitslast fr die betroffene

206

5.3 Prozess-Kennzahlen
Support-Einheit hinweisen.
Messwert

Mit der Festlegung der Prioritt zu einem Incident wird die vereinbarte Reaktionszeit ermittelt. Die Kennzahl wird durch Auswertung der
Incident Records und dem Vergleich zwischen
der geplanten Reaktionszeit und der tatschlichen 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

Lsungszeit

Definition

Die Lsungszeit ist die Dauer zwischen der


Aufnahme des Incidents und dessen Abschluss.

Relevanz

Die durchschnittlichen Lsungszeiten in Abhngigkeit von IT Service und Prioritt (SLA) mssen den vereinbarten Service Level entsprechen.

Messwert

Mit der Zuweisung der Prioritt liegt fr den


Incident Record die vereinbarte Lsungszeit
vor. Anhand der dokumentierten Lsungszeit
wird die tatschliche Lsungszeit ermittelt.

Bemerkung

Siehe auch Einhaltung Lsungszeit.

Name der Kennzahl

Einhaltung Lsungszeit

Definition

Anteil der Incidents, die in Abhngigkeit der


Prioritt innerhalb der vereinbarten Lsungszeit
behoben wurden.

Relevanz

Die Einhaltung der Lsungszeiten ist eine wichtige Kennzahl fr die Effektivitt des Prozesses.
Durch deren Einhaltung wird die Anwenderund Kundenzufriedenheit beeinflusst.

Messwert

Mit der Zuweisung der Prioritt liegt fr den


Incident Record die vereinbarte Lsungszeit
vor. Anhand der dokumentierten Lsungszeit
wird ermittelt, in welchem Ma (Prozent) diese
Zeit eingehalten wurde.

Bemerkung

Die Lsungszeit kann auch als Service Level in

207

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


SLAs, OLAs oder UCs vereinbart werden. Dann
ist die Lsungszeit in Bezug auf den jeweiligen
IT Service zu berechnen.
Entscheidend fr die Lsung ist, dass der Anwender wieder arbeiten kann. Es ist mit dem
Kunden festzulegen, wann ein Incident als abgeschlossen gewertet werden kann.
Name der Kennzahl

Anteil Remote-Lsungen

Definition

Anteil der bearbeiteten Strungen, die Remote - das heit ohne Vor-Ort-Service - gelst
werden konnten.

Relevanz

Der Vor-Ort-Service ist gegenber einer Remote


Lsung mit mehr Aufwand (Arbeitszeit und
Kosten) verbunden. Hinzu kommt, dass die
Lsungszeiten dadurch hher sind. Diese Kennzahl ist ein Indikator fr die Effizienz des Prozesses.

Messwert

Ausgewertet wird der Anteil der Incidents, bei


denen keine Vor-Ort Support-Einheit in die
Behebung eingebunden waren.

Name der Kennzahl

Kosten Incidents

Definition

Die Kennzahl weist die Kosten fr die Aufnahme und Behebung von Incidents aus.

Relevanz

Eine Reduzierung der Kosten ist ein Nachweis


fr eine Steigerung der Effizienz.

Messwert

Die durchgefhrten Aktivitten sind hinsichtlich ihrer Aufwendungen (Material, Arbeitszeit,


etc.) zu dokumentieren. Ausgewertet werden
die damit verbunden Kosten.

Bemerkung

Die Aufwendungen sind hufig abhngig von


den betroffenen IT Services, CIs und Kategorie.
Eine Drill-Down-Funktion ist hierfr notwendig.

Name der Kennzahl

Anteil fehlerhaft zugewiesener Incidents

Definition

Die Kennzahl weist die Kosten fr die Auf-

208

5.3 Prozess-Kennzahlen
nahme und Behebung von Incidents aus.
Relevanz

Werden Incidents einer fehlerhaften SupportGruppe zugewiesen, so entstehen zustzliche


Bearbeitungskosten (Effizienz) und die Bearbeitungszeit verlngert sich (Effektivitt).

Messwert

Hierzu muss im Incident Record bei einer Weiterleitung deren Grund eingepflegt werden.

Bemerkung

Diese Kennzahl kann auch als Kennzahl fr den


Service Desk herangezogen werden.

Name der Kennzahl

Anteil fehlerhafter Incident Kategorien

Definition

Die Kennzahl weist den Anteil der bei der Aufnahme eines Incidents fehlerhaft zugewiesener
Kategorien aus.

Relevanz

Die Kategorisierung untersttzt die Suche von


Known Errors, Workarounds sowie die Weiterleitung von Incidents. Fehlerhafte Kategorien
wirken sich negativ auf die Effizienz und Effektivitt aus.

Messwert

Hierzu wird im Incident Record geprft, ob


beim Abschluss gegenber der Erffnung eine
andere Kategorie zugewiesen wurde.

Bemerkung

Diese Kennzahl kann auch als Kennzahl fr den


Service Desk herangezogen werden.

Name der Kennzahl

Anteil wiedererffneter Incidents

Definition

Die Kennzahl weit den Anteil der Incidents


aus, bei denen die aufgetretene Strung wieder
auftritt.

Relevanz

Die Kennzahl zeigt an, ob Incidents fehlerhaft


als gelst abgeschlossen wurden.

Messwert

Hierzu muss im Incident Record eine Reopen Aktivitt dokumentiert werden. Die Anzahl der Incidents mit dieser Aktivitt wird
ausgewertet.

Bemerkung

Hufig werden Incidents nicht wiedererffnet,


sondern als neue Incidents aufgenommen.

209

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen

5.3.4.3 R
eq
u
est F
u
lfilment
Der Prozess ist fr das Management des Lifecycle smtlicher Service Requests verantwortlich.
Bisher wurden in ITIL und der ISO 20000 die Service Requests im Incident
Management aufgenommen. Daher werden die Service Requests bei vielen
IT-Organisationen in der Incident-DB gespeichert. Statt der im Folgenden
beschriebenen Request-DB sind in diesen Fllen die Service Requests aus
der Incident-DB anhand einer Codierung zu ermitteln.
Name der Kennzahl

Anzahl Service Requests

Definition

Anzahl der Service Requests im Betrachtungszeitraum.

Relevanz

Die Anzahl der Service Requests dient fr weitere Betrachtungen als Referenzwert.

Messwert

Ermittlung der Service Requests Records aus


der Request-DB.

Name der Kennzahl

Bearbeitungszeit Service Requests

Definition

Darstellung der mittleren Bearbeitungszeit "Service Requests" und Art der "Service Requests"
(z. B. Passwort-Reset, Umzug etc.).

Relevanz

Die Kennzahl zeigt die Zeitdauer fr den


Workflow und ist Basis fr die Berechnung
mglicher 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 Abhngigkeit


von der Art innerhalb der vereinbarten Bearbeitungszeit abgeschlossen wurden.

Relevanz

Die Einhaltung der vereinbarten Service Request-Zeiten ist eine wichtige Kennzahl fr die
Effektivitt des Prozesses. Durch deren Einhaltung wird die Anwender- und Kundenzufriedenheit beeinflusst.

210

5.3 Prozess-Kennzahlen
Messwert

Dem Service Request muss ein Workflow mit


einer geplanten Bearbeitungszeit hinterlegt sein.
Auf dieser Basis kann die Einhaltung berwacht
werden.

Bemerkung

Diese Kennzahl kann als Service Level in Service-Berichte einflieen. Bei einem Aufbruch in
die einzelnen Aktivitten und der Planwerte
knnen die Werte auch fr die Bewertung von
OLAs und UCs herangezogen werden.

Name der Kennzahl

Service Request-Kosten

Definition

Kosten fr die Durchfhrung fr die verschiedenen Arten von Service Requests (zum Beispiel
Passwort-Reset, Umzug, etc.).

Relevanz

Die Kosten werden fr die Kalkulation des Service bentigt. Darber hinaus zeigt die Kennzahl als Trenddarstellung die Effizienz auf.

Messwert

Zur Ermittlung mssen zu den einzelnen Aktivitten die bentigten Arbeitsstunden erfasst
werden.

Name der Kennzahl

Kundenzufriedenheit Service Request

Definition

Grad der Kundenzufriedenheit mit der Durchfhrung von Service Requests.

Relevanz

Die Kennzahl zeigt die Ausrichtung des Prozesses auf die Geschftsanforderungen auf.

Messwert

Abfrage in der Kundenzufriedenheitsumfrage

Bemerkung

Hier ist zustzlich auch eine Befragung der


Anwender mglich.

211

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen

5.3.4.4 Problem Management


Der Prozess ist fr das Management des Lifecycle smtlicher Probleme
verantwortlich. Das primre Ziel des Problem Managements besteht in der
Verhinderung von Incidents und der Reduzierung der Auswirkung von
Incidents, die nicht verhindert werden knnen.
Die Relevanz von Problemen hinsichtlich der SLAs ist kritisch zu prfen
und zu hinterfragen. Wenn der Kunden nicht die Terminologie von ITIL
nutzt, so ist hufig 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 fr weitere Betrachtungen als Referenzwert.

Messwert

Ermittlung der Problem-Records aus der Problem-DB.

Bemerkung

Die Gesamtanzahl ist wenig aussagekrftig.


Hier sollte eine Drill-Down Funktion auf betroffene IT Services, CIs, etc. mglich sein.

Name der Kennzahl

Anzahl offener Probleme

Definition

Anzahl der Probleme, die noch nicht gelst


wurden.

Relevanz

Die Kennzahl zeigt, wie viele Probleme zurzeit


vom Problem Management zu bearbeiten sind
bzw. die mittels eines Change zu implementieren sind.

Messwert

Auswertung der Probleme, die noch nicht abgeschlossen sind

Bemerkung

Die Gesamtzahl ist wenig aussagekrftig. Hier


sollte die Gesamtzahl aufgebrochen werden in
Problemursache unbekannt, Known Error,
RFC gestellt

212

5.3 Prozess-Kennzahlen
Name der Kennzahl

Durchschnittliche Problem-Lsungszeit

Definition

Durchschnittliche Zeitdauer fr die Lsung von


Problemen im Betrachtungszeitraum.

Relevanz

Eine lange Lsungsdauer kann dazu fhren,


dass innerhalb dieser Zeit weiterhin Incidents
auftreten und so zu Aufwendungen (Kosten) im
Support fhren. Auerdem wird die Kundenzufriedenheit beeintrchtigt, wenn Incidents weiterhin auftreten oder nur unzureichende Workarounds existieren.

Messwert

Ermittlung der durchschnittlichen Zeitdauer


zwischen der Erffnung eines Problems und
dessen Abschluss, das heit, bis ein Change
erfolgreich durchgefhrt wurde.

Bemerkung

Zeitdauer ber alle Services, CIs ist wenig aussagekrftig. Hier sollte ein Drill-Down auf betroffene IT Services, CIs, etc. mglich sein.

Name der Kennzahl

RFCs aufgrund von Problemen

Definition

Anzahl der vom Problem Management initiierten RFCs.

Relevanz

Eine hohe Anzahl vom Problem Management


eingereichter RFCs kann ein Indiz fr die Effektivitt des Problem Managements sein.

Messwert

Auswertung der RFCs im Betrachtungszeitraum


mit einer Verknpfung zu Problemen.

Name der Kennzahl

Nutzungsgrad Known Errors

Definition

Anteil der Incidents, die mithilfe der Known


Errors gelst wurden.

Relevanz

Das Problem Management erstellt und pflegt


die Known Errors. Mit deren Hilfe sollen Incidents besser und schneller behoben werden. Ein
hoher Nutzungsgrad zeigt, dass das Incident
Management diese Informationen verwenden
kann.

Messwert

Auswertung der Incidents hinsichtlich einer


Verknpfung mit Known Errors.

213

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen

5.3.4.5 Access Management


Der Prozess ist dafr verantwortlich, es den Anwendern zu ermglichen,
IT Services, Daten oder andere Assets zu benutzen. Das Access Management hilft, die Vertraulichkeit, Integritt und Verfgbarkeit von Assets
dadurch zu schtzen, dass nur autorisierte Anwender in der Lage sind,
auf die Assets zuzugreifen oder diese zu modifizieren. Das Access Management wird teilweise als Rechteverwaltung oder Identity Management
bezeichnet.
Bisher wurden in ITIL und der ISO 20000 die Service Requests im Incident
Management aufgenommen. Daher werden die Service Requests bei vielen
IT-Organisationen innerhalb der Incident-DB gespeichert. Statt der im
Folgenden beschriebenen Access-DB sind in diesen Fllen die Service
Requests mit dem Typ Zugriffsrechte aus der Incident-DB anhand einer
Codierung zu ermitteln.
Name der Kennzahl

Anzahl der Zugriffs-Anforderungen

Definition

Anzahl der Anforderungen auf Zugriffsberechtigungen im Betrachtungszeitraum.

Relevanz

Die Anzahl der Anforderungen dient fr weitere Betrachtungen als Referenzwert.

Messwert

Ermittlung der Access-Records aus der AccessDB.

Bemerkung

Die Gesamtanzahl ist wenig aussagekrftig.


Hier sollte eine Drill-Down Funktion auf betroffene IT Services, Abteilungen, etc. mglich sein.

Name der Kennzahl

Incidents aufgrund fehlerhafter Zugriffsrechte

Definition

Anzahl der Incidents aufgrund fehlerhaft vergebener Zugriffsrechte.

Relevanz

Die Anzahl der auftretenden Incidents ist ein


Ma fr die Effektivitt des Prozesses.

Messwert

Ermittlung der Incident-Records mit Kategorie


Zugriffsrechte

Name der Kennzahl

Anzahl Bearbeitungsinstanzen

Definition

Anzahl Bearbeitungsinstanzen fr die Generierung der Zugriffsrechte.

214

5.3 Prozess-Kennzahlen
Relevanz

Die Anzahl der Bearbeitungsinstanzen ist ein


Ma fr die Effizienz des Prozesses.

Messwert

Ermittlung der Access-Records aus der AccessDB und der beteiligten Bearbeiter von der Aufnahme bis zum Abschluss.

Name der Kennzahl

Kosten fr Zugriffsberechtigungen

Definition

Kosten fr die Generierungen der Zugriffsberechtigungen.

Relevanz

Die Kosten fr die Generierungen der Zugriffsberechtigungen sind ein Ma fr die Effizienz
des Prozesses und sind unter anderem bei der
Kalkulation der SLAs zu bercksichtigen.

Messwert

Ermittlung der Arbeitsstunden pro Access-Records aus der Access-DB.

Bemerkung

Die Gesamtkosten sind wenig aussagekrftig.


Hier ist eine Unterscheidung zwischen den IT
Services notwendig.

5.3.4.6 Service Desk


Der Service Desk dient als Single Point of Contact (SPOC) zwischen dem
IT Service Provider und den Anwendern. Ein typischer Service Desk verwaltet die Incident und Service Requests und wickelt auch die Kommunikation mit den Anwendern ab.
Der Service Desk beschreibt die funktionalen Anforderungen an eine Organisation und ist kein Service Management-Prozess. Der Service Desk ist
in verschiedene Prozesse eingebunden, mit dem Schwerpunkt in den Prozessen Incident Management und Request Fulfilment. In diesem Kapitel
werden die Kennzahlen ausgewiesen, die nicht zu den bereits ausgewiesenen Prozess-Kennzahlen, wie zum Beispiel der Erstlsungsquote, gehren.
Name der Kennzahl

Anzahl Lost-Calls

Definition

Anzahl der Lost-Calls (verlorene Anrufe) im


Betrachtungszeitraum.

Relevanz

Die Lost-Calls definieren die Anrufer, die aufgrund eines zu langen Wartezeitraums den
Anruf beenden, ohne mit einem Mitarbeiter des
Service Desk gesprochen zu haben. Diese Kenn-

215

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


zahl ist ein wichtiges Ma fr die Anwenderund Kundenzufriedenheit.
Messwert

Die Lost-Calls sind der Telefonanlage (ACD) zu


entnehmen.

Bemerkung

Diese Kennzahl kann Bestandteil eines SLAs


sein.

Name der Kennzahl

Dauer Telefonannahme

Definition

Durchschnittliche Dauer, bis ein Telefonanruf


entgegengenommen wird.

Relevanz

Die durchschnittliche Dauer, bis ein Telefonanruf entgegengenommen wird, ist ein wichtiges
Ma fr die Anwender- und Kundenzufriedenheit.

Messwert

Die durchschnittliche Dauer, bis ein Telefonanruf entgegengenommen wird, ist der Telefonanlage (ACD) zu entnehmen.

Bemerkung

Diese Kennzahl kann Bestandteil eines SLAs


sein.

Name der Kennzahl

Gesprchsdauer

Definition

Durchschnittliche Dauer pro Gesprch (Telefonkontakt) mit dem Anwender.

Relevanz

Das Ziel des Service Desk besteht in der Erreichbarkeit durch den Anwender. Zu lange Gesprche gefhrden die Erreichbarkeit fr andere
Anwender. Daher kann eine maximale Gesprchsdauer festgelegt werden. Diese Kennzahl zeigt, ob diese Vorgabe erreicht wird.

Messwert

Die durchschnittliche Dauer, bis ein Telefonanruf entgegengenommen wird, ist der Telefonanlage (ACD) zu entnehmen.

Bemerkung

Diese Kennzahl kann Bestandteil eines OLAs


sein.

216

5.3 Prozess-Kennzahlen

5.3.5

Continual Service Improvement

5.3.5.1 The 7 Step Improvement Process


Fr das Continual Service Improvement (CSI) ist das Konzept der Messung von grundlegender Bedeutung. Das CSI beschreibt hierzu den
7 Step Improvement Prozess. Ausgehend von Definition was sie wollen werden durchzufhrende Aktivitten bis zur Implementierung korrigierende Aktionen beschrieben.
Name der Kennzahl

Anzahl Eingaben in SIP

Definition

Anzahl der identifizierten Manahmen zur


Verbesserung der Services, als Eingabe in den
Service Improvement Plan (SIP).

Relevanz

Identifizierte Verbesserungsmanahmen fr die


Services sind im SIP zu dokumentieren.

Messwert

Auswertung des SIP.

Name der Kennzahl

Anzahl Eingaben in PIP

Definition

Anzahl der identifizierten Manahmen zur


Verbesserung der Prozesse, als Eingabe in den
Prozess Improvement Plan (PIP).

Relevanz

Identifizierte Verbesserungsmanahmen fr die


Prozesse sind im PIP zu dokumentieren.

Messwert

Auswertung des PIP.

Name der Kennzahl

Anzahl identifizierter Probleme

Definition

Anzahl der im proaktiven Problem Management identifizierten Probleme.

Relevanz

Ein proaktives Problem Management steigert


die Service-Qualitt und reduziert die Aufwendungen fr reaktive Manahmen.

Messwert

Auswertung der Problem-DB.

Bemerkung

In der ITIL Version 3 gehrt das proaktive Problem Management nicht mehr zu den Aktivitten
des Problem Managements im Service Operation.

217

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen

5.3.5.2 Service Reporting


Der Prozess ist fr die Erstellung und Lieferung von Berichten ber Leistung und Trends gegenber den Service Level verantwortlich. Das Service
Reporting sollte das Format, den Inhalt und die Hufigkeit von Berichten
mit den Kunden vereinbaren.
Name der Kennzahl

Kundenzufriedenheit Service Reporting

Definition

Ergebnis der Kundenzufriedenheit mit dem


Service Reporting.

Relevanz

Das Service Reporting und die enthaltenen sowie dargestellten Informationen mssen den
Geschfts- bzw. Kundenanforderungen entsprechen.

Messwert

Abfrage in der Kundenzufriedenheitsumfrage

Name der Kennzahl

Termintreue fr Service Reports

Definition

Einhaltung der vereinbarten Erstellungstermine


fr die Service Reports.

Relevanz

Service Reports stellen intern und extern eine


wichtige Informationsquelle dar. Im externen
Verhltnis sind die Berichtstermine zum Teil
Bestandteil des SLAs. Daher sind die Berichte
termingerecht zu verffentlichen.

Messwert

Auswertung der Erstellungsdaten im Vergleich


zu den definierten Terminen.

Name der Kennzahl

Anzahl fehlerhafter Service Reports

Definition

Anzahl der Service Reports, in denen fehlerhafte oder inkonsistente Informationen enthalten sind.

Relevanz

Fehlerhafte Service Reports fhren zur Kundenunzufriedenheit.

Messwert

Auswertung von Prozess Reviews.

218

5.3 Prozess-Kennzahlen

5.3.5.3 Service Measurement


Aufgabe des Service Measurement ist die Messung der IT Services. Hierzu
betont ITIL, dass es nicht mehr gengt, die Leistung einer einzelnen Komponente, wie einen Server oder eine Applikation zu messen und zu berichten. Die IT muss in der Lage sein, end-to-end Service zu messen und zu
berichten. Hierzu gibt es mit der Verfgbarkeit, Zuverlssigkeit und Performance drei Grundmessungen, von denen die meisten Organisationen
Gebrauch machen.
Name der Kennzahl

Anteil SLAs mit end to end Messung

Definition

Anteil der SLAs, deren Service Level und die


Erreichung der Service Level Ziele auf Basis
einer end to end Messung gemessen werden.

Relevanz

Eine end to end Messung stellt die Sicht des


Business auf den Service dar und ermglicht
eine Bewertung, in welchem Mae die Kunden
den vereinbarten Service nutzen konnten.

Messwert

Bewertung der implementierten Messverfahren.

Bemerkung

Hierbei sind die damit verbundenen Kosten zu


bewerten. Unter Umstnden kann aus Kostengrnden diese Messung lediglich fr geschftskritische Services angewandt werden.

5.3.5.4 Return on Investment (ROI) for CSI


Im Rahmen des Return on Investments (ROI) fr das Continual Service
Improvement (CSI) sind die Kosten fr die Durchfhrung dieser Phase des
Service Lifecycle zu ermitteln und zu bewerten, welche geschftlichen
Vorteile durch das Continual Service Improvement erzielt werden.
Name der Kennzahl

Kosten fr das Continual Service Improvement

Definition

Kosten fr die Durchfhrung des Continual


Service Improvement

Relevanz

Hier werden die Kosten fr das CSI dargestellt.


Im Vergleich mit den Kennzahlen erzielte Einsparungen (IT / Business) und Mehrwert Business kann so der ROI bewertet werden.

Messwert

Vorrangig Betrachtung der Prozesskosten und


Kosten fr Tools

219

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Name der Kennzahl

Erzielte Einsparungen (IT / Business)

Definition

Erzielte Einsparungen fr die IT und / oder das


Business

Relevanz

Primr geht es um die Einsparungen fr das


Business; aber auch Einsparungen innerhalb der
IT kommen dem Business zugute.

Messwert

Informationen aus dem Financial Management

Name der Kennzahl

Mehrwert Business

Definition

Mehrwert der durchfhrten Verbesserungsmanahme fr das Business

Relevanz

Wenn das Business einen Mehrwert hat, liegt


die Rechtfertigung von Investitionen vor

Messwert

Bewertung durch das Business

5.3.5.5 The Business Questions for CSI


Das Business muss in die Entscheidungsfindung im CSI eingebunden werden, um zu beurteilen, welche Verbesserungsmanahmen sinnvoll sind
und dem Business den grten Nutzen bringen.
Name der Kennzahl

Kundenzufriedenheit
men

Definition

Ergebnis der Kundenzufriedenheit mit den


identifizierten und umgesetzten Verbesserungsmanahmen.

Relevanz

Die Kennzahl identifiziert die Einbeziehung des


Business in das Continual Service Improvement.

Messwert

Abfrage in der Kundenzufriedenheitsumfrage.

Verbesserungsmanah-

5.3.5.6 Service Level Management


Die Kennzahlen zum Service Level Management sind zusammengefasst
im Kapitel 5.3.2.2 (Prozess Service Level Management innerhalb von
Service Design) beschrieben.
Speziell die Service Improvement Programme (SIP) und die damit verbundenen Kennzahlen betreffen die Manahmen innerhalb des Continual
Service Improvements.

220

6 Lessons learned: Empfehlungen und Ratschlge


6.1 Management Summary
Wir haben viele ITIL-Projekte durchgefhrt, geleitet oder wenigstens begleitet. Die Einfhrung von ITIL in Unternehmen ist oft kein einfaches
Projekt. Im Folgenden stellen wir unsere Erfahrungen dar und versuchen
herauszustellen, was man tun sollte und woran man scheitern kann. Insbesondere mchten wir die Notwendigkeit vorbereitender berlegungen
und Manahmen 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 fr die Implementierung und
Verbesserung des IT Service setzt voraus, dass Sie die unternehmensspezifischen IT Service Management-Prozesse definieren und
designen. Hierzu kann ITIL einen wichtigen Beitrag leisten, darf dabei aber nicht zum Selbstzweck werden. Ziel ist es nicht, ITIL zu
implementieren, sondern ITIL als Medium zu nutzen, um die IT
Service Management-Prozesse zu etablieren und stetig zu verbessern.
Faktisch etabliert die Einfhrung von durchgngigen IT Service Management-Prozessen eine Matrixorganisation. Zu der bestehenden
Linienorganisation existieren dann bereichsbergreifende IT Service
Management-Prozesse mit entsprechenden Verantwortlichkeiten
und Zielvorgaben unter Einbeziehung mglicher Supplier oder Lieferanten. Sie mssen sicherstellen, dass die organisatorische Verankerung dieser Prozesse erfolgt und die Akzeptanz der Prozesse und
Prozessverantwortlichkeiten in allen Hierarchieebenen erreicht wird.
Die damit verbundenen Implementierungsaufgaben drfen nicht
unterschtzt werden. Ohne ein geeignetes Vernderungsmanagement werden die an das Projekt bzw. an die spteren Prozesse gerichteten Erwartungen nicht erfllt. Ein fehlendes Vernderungsmanagement wird Zeitverschiebungen und Zusatzaufwendungen hervorrufen. Im schlimmsten Fall kann es zum Scheitern des gesamten
Vorhabens fhren.

221

6 Lessons learned: Empfehlungen und Ratschlge

6.2 ITIL-Einfhrung
6.2.1
Bercksichtigung
bestehender
Prozesse

Analyse der bestehenden Prozesse

Auf den ersten Blick mag es kurios erscheinen, aber jede auch Ihre ITOrganisation betreibt bereits IT Service Management-Prozesse. Zielsetzung und Aktivitten dieser Prozesse entsprechen aber in der Regel nur
zum Teil den ITIL Best Practices.
Sie sollten daher zunchst Ihre bestehenden Prozesse analysieren und mit
den ITIL Best Practices vergleichen. Damit stehen Sie aber in der Praxis
vor dem Dilemma, etwas bewerten zu mssen, was Sie und Ihre Mitarbeiter ggf. noch nicht ausreichend kennen.
Eine Lsungsmglichkeit fr Sie und die im Vorhaben involvierten Mitarbeiter besteht darin, sich kurzfristig ITIL-Know-how anzueignen. Hilfreich
ist hier der Erwerb eines Foundation Certificate in IT Service Management
und/oder das Studium der ITIL-Fachliteratur.
Alternativ knnen Sie auf einen erfahrenen, zertifizierten Berater zurckgreifen. Berater bieten i. d. R. zustzlich den Vorteil, nicht nur ber das
theoretische Grundwissen, sondern auch ber Erfahrungen in vergleichbaren Projekten zu verfgen. Besonders wichtig bei diesem Ansatz: Sie mssen sicherstellen, dass der Berater nicht selbststndig allein die Manahmen durchfhrt. Die wesentliche Aufgabe des Beraters besteht vielmehr darin, Sie zu begleiten. Sie bentigen einen Coach, der den Wissenstransfer sicherstellt.
Fungiert Ihr Berater nicht als Coach, so kann sowohl die Implementierungsanalyse, als auch die sptere Erweiterung und/oder Umsetzung schwierig werden.
Ohne Akzeptanz des Beraters als Coach in Ihrer Organisation verlieren Sie Zeit
und nutzen Ressourcen nicht optimal. Die Motivation zur Etablierung der Prozesse wird sinken.

Auf der Basis von ITIL sollten Sie analysieren und vergleichen, welche der
dort beschriebenen IT Service Management-Prozesse und Aktivitten bereits (zumindest vermeintlich) in Ihrer IT-Organisation etabliert sind. Dabei ist zunchst eine generische Betrachtung der Prozesse ausreichend.
Als Hilfestellung hierbei bietet sich eine tabellarische Darstellung an: Tragen Sie als Zeilen (-berschriften) die IT Service Management-Prozesse ein,
wie zum Beispiel Incident Management, Change Management, Service
Level Management. Auf der vertikalen Achse erfolgt eine Einstufung der
bestehenden Situation hinsichtlich Konzeption, Prozesse, Verfahren, Methoden und Nutzungsgrad. Diese ITIL-Prozesslandkarte ist eine erste,
einfache Darstellung des bestehenden Reifegrades.

222

6.2 ITIL-Einfhrung
Die ITIL-Prozesslandkarte soll aus der IT-Organisation heraus entwickelt werden, ggf. unter Beteiligung eines Coaches. Dadurch lernen Sie und Ihre Mitarbeiter die ITIL Best Practices erheblich besser kennen.

Fr die Einstufung der Prozesse ist ausreichendes internes oder externes


Know-how von groer Wichtigkeit. Speziell im Bereich des Incident und
Problem Managements bedarf es einer entsprechenden Erfahrung, um
eine Abgrenzung der Prozessaktivitten vornehmen zu knnen.
Sie mssen bei der Ist-Aufnahme unterstreichen, dass die Zielsetzung in
der neutralen Aufnahme der bestehenden Prozesse besteht. Nur so ist eine echte Standortbestimmung mglich. Bei der Ist-Aufnahme ggf. festgestellte
Fehler sowie Abweichungen von bestehenden Richtlinien, festgelegten
Ablufen oder Standards drfen keine negativen Auswirkungen auf die betroffenen Personen haben. Sie bentigen eine objektive Feststellung der IstSituation und keine geschnte Darstellung. Erffnen Sie Ihren Mitarbeitern
die Chance zur Offenheit und verzichten Sie auf Rgen fr Fehlverhalten. Geben Sie ihren Mitarbeitern die notwendige Sicherheit fr eine ungeschnte Darstellung der Ist-Situation.
Liegt die ITIL-Prozesslandkarte vor, so sollten Sie sptestens jetzt eine
Abstimmung mit einem externen Berater anstreben. Nur zusammen mit
einem externen Berater knnen Sie die bestehende Situation wirklich bewerten und mit anderen IT-Organisationen vergleichen.
Die Nutzung der ITIL Best Practices zur Optimierung der IT Service Management-Prozesse kann von verschiedenen Gruppen initiiert werden.
Der Kreis der Betroffenen kann grob wie folgt gruppiert werden:

Top-Management,
mittleres Management,
Mitarbeiter,
Kunde / Markt

Speziell wenn die Implementierung vom Top-Management ausgeht, werden hufig externe Berater frhzeitig mit den Durchfhrungsleistungen
beauftragt. Die Gefahr bei diesem Szenario liegt in den auftretenden Akzeptanzproblemen: Das mittlere Management und die Mitarbeiter knnen
das Gefhl entwickeln, die externen Berater und damit ITIL wrden
ihnen von oben bergestlpt. Folge hiervon sind die mangelnde Akzeptanz der geplanten Manahmen und die damit verbundene Verzgerung
bei der Umsetzung.
Konsequenz hieraus: Der eigenen Organisation muss die Chance gegeben
werden, sich weiterzuentwickeln und ITIL zu adaptieren.

223

Initiierung
der geplanten
Manahmen

6 Lessons learned: Empfehlungen und Ratschlge


Stellen Sie sicher, dass fr das Management und die Mitarbeiter im Vorfeld eine
Chance besteht, sich mit den ITIL Best Practices auseinander zu setzen. Damit
knnen Sie einer Abwehrhaltung innerhalb Ihrer IT-Organisation erfolgreich
begegnen.

Geht die Initiierung von der Mitarbeiterschaft aus, so muss zunchst das
mittlere Management von den Vorteilen der ITIL Best Practices berzeugt
werden: Die Nutzung von ITIL verlangt immer die Untersttzung des Managements.
Aufgabe des mittleren Managements ist es, das Top-Management fr die
Implementierung der IT Service Management-Prozesse auf Basis von ITIL
zu gewinnen. Dazu mssen Sie die Vorteile fr Ihre Organisation deutlich
herausstellen. Fehlt es hierzu an Kennzahlen, da noch keine messbaren
Prozesse existieren, sollten Sie auf mglichst prgnante Ereignisse in der
Vergangenheit verweisen, beispielsweise einen fehlgeschlagenen Change
mit groen Auswirkungen auf die IT-Organisation und auf die Geschftsprozesse Ihres Kunden. Nutzen Sie solche Beispiele und stellen Sie heraus,
welche Vorteile Ihnen ein IT Service Management nach ITIL hierbei geboten htte. Sie knnen auch den Weg ber Konferenzen nutzen wie zum
Beispiel das ITIL Forum und von den Erfahrungen anderer ITOrganisationen profitieren bzw. auf deren positive Erfahrungen verweisen.
Als Grund fr die Einfhrung von ITIL werden hufig die damit erreichbare hhere Servicequalitt und die bessere Ausrichtung auf die Geschftsprozesse angefhrt. Sie knnen das Top-Management von ITIL aber
nur dann berzeugen, wenn es Ihnen gelingt, die erkannten Defizite und
deren Auswirkungen mit finanziellen Betrgen zu hinterlegen. Von Vorteil
ist es, finanzielle Vorteile fr die IT-Organisation aufzeigen zu knnen.
Noch berzeugender ist die (glaubhafte) Aussicht auf finanzielle Vorteile
fr das Kerngeschft.
Stellen Sie gegenber dem Top-Management heraus, dass sich die mit der Einfhrung von ITIL verbundenen Investitionen amortisieren.

Ganz gleichgltig, ob die Nutzung der ITIL Best Practices vom Management oder aus dem Mitarbeiterkreis initiiert wurde: Es muss sichergestellt
werden, dass das gesamte Management hinter dem geplanten Vorhaben
steht und die damit verbundenen Vernderungen aktiv untersttzt.
Nutzen Sie die Kundenanforderungen, um die Notwendigkeit der geplanten
Manahmen 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 fr die optimale Zusammenarbeit
zwischen IT und Kunde ist.

224

6.2 ITIL-Einfhrung
Eine besondere Rolle bei der geplanten Implementierung fllt Ihren Kunden bzw. dem Markt zu. Hufig verlangen Ihre Kunden in Angebotsaufforderungen oder bei Ausschreibungen, dass die anbietende ITOrganisation (IT Service Provider) ITIL-konforme Prozesse bzw. eine ISO
20000 (vormals BS 15000) Zertifizierung nachweist.
Diese Situation stellt eine groe Chance fr Ihr geplantes Projekt dar: Mit
diesem Auendruck kann die Notwendigkeit einer ITIL Implementierung
in der IT-Organisation leichter vermittelt werden. Das Implementierungsprojekt wird unter diesen Voraussetzungen in der Regel mit einem hheren Nachdruck verfolgt werden.
Nutzen Sie die Kundenanforderungen, um die Notwendigkeit der geplanten
Manahmen in Ihrer Organisation herauszustellen. Nach dem Motto: Wir
implementieren IT Service Management, nicht weil es uns Spa macht, sondern
weil es vom Markt verlangt wird.

Hat sich Ihre Organisation entschieden, die IT Service Management-Prozesse zu etablieren, so mssen Sie Ihren Mitarbeitern die damit verbundenen Ziele vermitteln. Mit der Einfhrung von Prozessen soll eine Messbarkeit des IT Service Managements und eine Identifizierung von Schwachstellen sichergestellt werden. Die damit verbundene Transparenz ruft aber
unter Umstnden bei den Betroffenen ngste hervor.
Eine aus dem Kreis der Mitarbeiter hufig geuerte Sorge ist: Heute
muss ich meine Ttigkeiten und mein Wissen transparent dokumentieren
und morgen wird mit dem dokumentierten Wissen meine Leistung outgesourced.
Versuchen Sie diesen ngsten mit Gegenbeispielen aus anderen ITOrganisationen zu begegnen.
Erklren Sie Ihren Mitarbeitern, dass Outsourcing in der Regel keinen Sinn
macht, wenn die Prozesse in der IT-Organisation gut funktionieren, transparente Services und Leistungen erbracht und die gesetzten Ziele erreicht
werden. Stellen Sie den mit IT Service Management angestrebten Nachweis der eigenen Leistungsfhigkeit als mglichen Schutz vor Outsourcing
heraus.
Informieren Sie Ihre Mitarbeiter frhzeitig ber die geplanten Manahmen und
die damit verfolgten Ziele. Motivieren Sie die Mitarbeiter und begegnen Sie den
ngsten Ihrer Mitarbeiter.

Fr eine erfolgreiche Etablierung der geplanten IT Service ManagementProzesse ist die Akzeptanz seitens Ihrer Mitarbeiter eine unabdingbare
Voraussetzung.

225

Wertschtzung des
Bestehenden

6 Lessons learned: Empfehlungen und Ratschlge


Bei der Analyse der ITIL-Prozesslandkarte werden Sie wahrscheinlich
feststellen, dass die bestehenden Prozesse die Anforderungen der ITIL
Best Practices nicht vollstndig erfllen. Beispiel: Es existiert bereits ein
Change Management, aber dieses Change Management bietet gegenber
ITIL Verbesserungspotenzial. Trotzdem hat dieser Prozess bisher Erfolge
gezeigt, und Ihre Mitarbeiter haben sich in diesem bestehenden Prozess
engagiert.
Sie sollten die bisher bestehenden Ablufe und Leistungen nicht gering
schtzen, sondern als Basis fr eine Verbesserung wrdigen.
Zeigen Sie Ihre Wertschtzung fr die bestehenden Ablufe und fr die damit
erzielten Erfolge. Stellen Sie ITIL als Chance fr eine Verbesserung dar.

Nutzen Sie die bestehenden Prozesse und zeigen Sie die positiven Mglichkeiten der ITIL Best Practices auf, um diese Prozesse weiter zu verbessern. Ihre Mitarbeiter sollten ITIL als Angebot verstehen, auf das darin
dokumentierte Wissen zurckzugreifen. Dafr muss ITIL als Chance gesehen werden, nicht als Damoklesschwert, das Bestehendes entwertet.
Ihre Mitarbeiter und Manager sollen ITIL als Chance verstehen, von anderen zu
lernen und sich dadurch weiterzuentwickeln.

Ihr Ziel muss es sein, ein Verstndnis von ITIL als Chance fr eine ganzheitliche Betrachtung der IT in Ihrer Organisation zu verankern.

6.2.2
Selbst
erarbeiten
statt fertig
kaufen

Prozess-Einfhrungen

Sie mssen mit Widerstnden bei der Implementierung der geplanten


Prozesse rechnen. Sehr hilfreich ist es hier, wenn die IT Service Management-Prozesse aus Ihrer IT-Organisation heraus, von Ihren Mitarbeitern
entwickelt werden. Ihre Mitarbeiter knnen dabei Ihre praktischen Erfahrungen einbringen und so sicherstellen, dass die geplanten Prozesse auf
die Geschftsprozesse Ihres Kunden ausgerichtet sind sowie den Anforderungen der IT-Organisation entsprechen.
Ihre IT Service Management-Prozesse auf Basis von ITIL knnen Sie nicht extern
einkaufen, sondern sie mssen unbedingt von Ihren Mitarbeitern erarbeitet werden.

Externe Berater knnen und sollten Ihnen hierbei helfen. Der Berater
soll Ihre Mitarbeiter ansprechen knnen und als Coach ttig sein. Dazu
muss der Berater nicht nur ber die erforderlichen ITIL (und ISO 20000)
Zertifizierungen verfgen, sondern auch Erfahrungen aus vergleichbaren
Projekten und vergleichbaren Organisationen mitbringen. Nicht zuletzt ist

226

6.2 ITIL-Einfhrung
die Sozialkompetenz des Beraters dabei ein weiterer wichtiger Erfolgsfaktor: Die Chemie muss stimmen.
Das beauftragte Unternehmen muss sicherstellen knnen, dass es ber
eine ausreichende Anzahl von Beratern verfgt um ggf. mehrere gleichzeitig anstehende Projektaktivitten in Ihrer IT-Organisation qualitativ zu
untersttzen.
Der Berater muss in der Lage sein, mit ggf. anderen im Ihrem Hause ttigen Beratern zusammenarbeiten zu knnen. Hierbei kann es sich unter
Umstnden um Berater handeln, die im Rahmen des IT Governance ttig
sind oder den Vernderungsprozess einer Organisation untersttzen.
Beauftragen Sie keine Zertifizierungsorganisation mit der Beratung: Ist
eine sptere Zertifizierung der IT Service Management-Prozesse geplant,
muss Unabhngigkeit zwischen Berater und Zertifizierer gewhrleistet
sein. Zertifizierungsorganisationen konzentrieren sich auerdem hufig
auf die formalen Anforderungen des Standards, whrend ein Berater praxisorientiert vorgehen wird.
Der Betriebsrat sollte von Ihnen bzw. vom Top-Management frhzeitig
ber die geplanten Manahmen informiert werden.
Mit der Einfhrung von Prozessen auf Basis der ITIL Best Practices ist das
Ziel verbunden, die Wirksamkeit der Prozesse zu messen und ggf. den
Bedarf an notwendigen Optimierungsmanahmen zu identifizieren. In
vielen Fllen fhrt dies dazu, dass die Prozess-Aktivitten der Mitarbeiter
erfasst und aggregiert werden. Zum Beispiel wird die Kennzahl Einhaltung der Lsungszeiten in Abhngigkeiten der SLAs oder Dauer der
Liegezeiten aus den dokumentierten Manahmen in Tickets gewonnen.
Nach deutschem Recht ist der Betriebsrat zumindest ber diese Manahmen zu informieren; in Teilbereichen wird mglicherweise die Zustimmung des Betriebsrates erforderlich sein.
Informieren und beteiligen Sie den Betriebsrat frhzeitig. Unterstreichen Sie,
dass Prozesse ausgewertet werden sollen und nicht die Leistung einzelner Mitarbeiter. Machen Sie klar, dass die geplanten Manahmen der internen Optimierung und damit auch dem Schutz von Arbeitspltzen dienen.

Zur Information und Abstimmung mit dem Betriebsrat hat sich folgendes
Vorgehen bewhrt:
Das Top-Management hat den Betriebsrat frhzeitig ber die Ziele
der geplanten Prozesseinfhrung und das Erreichen von Meilensteinen informiert. Es wurde mit dem Betriebsrat vereinbart, dass die
Prozesse gemessen werden und keine Auswertung auf Mitarbeiterebene erfolgt.

227

Einbeziehung
des Betriebsrats

6 Lessons learned: Empfehlungen und Ratschlge


In Abhngigkeit der Gre Ihrer IT-Organisation ist zu entscheiden,
ob die Prozess Manager eine Full-time Ttigkeit bernehmen. In
vielen Unternehmen ist dies der Fall. Dann sollte der Betriebsrat bei
der Ausschreibung und Besetzung der Positionen der Prozess Manager beteiligt werden.
Eine detaillierte Absprache der geplanten und erhobenen Kennzahlen mit dem Betriebsrat liegt in der Verantwortung der eingesetzten
Prozess Manager.
Qualitt vor
Geschwindig
keit

Vielfach bedeutet die Einfhrung der IT Service Management-Prozesse auf


Basis der ITIL Best Practices eine vernderte Betrachtungsweise in der ITOrganisation: Weg von der Systemorientierung, hin zu einer Service- und
Prozessorientierung. Das bedeutet auch und gerade eine Vernderung in
der Denkweise und im Verhalten der Mitarbeiter in Ihrer IT-Organisation.
Wie bei allen Vernderungsmanahmen wird hierzu eine ausreichende
Zeit bentigt. Die Mitarbeiter mssen die Vernderungen adaptieren und
verinnerlichen. Eine Vernderung ber Nacht ist nicht zu erzwingen.
Ebenso ist es nicht ratsam, zu groe Vernderungen auf einmal durchzufhren.
Sie sollten unbedingt stufenweise vorgehen. Dies gilt sowohl fr die Gesamtheit aller IT Service Management-Prozesse, als auch innerhalb der
einzelnen Prozesse. Es ist wenig ratsam, smtliche IT Service Management-Prozesse gleichzeitig zu implementieren.
In der Regel beginnt man mit der Implementierung des Service Level Managements, gefolgt von Incident, Configuration, Change und Problem
Management. Die konkrete Reihenfolge der Einfhrung hngt aber von
Ihrer Ist-Situation und den Anforderungen an Ihre IT-Organisation ab,
also von Ihrer Pain.
Ebenso sollte der Reifegrad, die Qualitt der einzelnen Prozesse schrittweise gesteigert werden. Die Vernderungen mssen von den Mitarbeitern und der gesamten IT-Organisation verkraftet werden.
Planen Sie daher Projektpausen ein, in denen sich die Mitarbeiter und die
IT-Organisation zunchst mit den durchgefhrten Vernderungen vertraut machen knnen und Sicherheit zurckgewinnen.
Die Implementierung von IT Service Management-Prozessen bedingt eine Vernderung der IT-Organisation und der Mitarbeiter. Stellen Sie eine schrittweise
Vernderung mit entsprechenden Projektpausen sicher.

228

6.2 ITIL-Einfhrung

6.2.3

Die Organisation gewinnen

Innerhalb Ihrer IT-Organisation existieren verschiedene Interessengruppen. Sie mssen die Motivation der einzelnen Interessengruppen identifizieren und sie anschlieend auf Basis der identifizierten Motivationsgrnde fr ITIL gewinnen.
Eine wichtige Motivation zur Nutzung von ITIL besteht in der bereits beschriebenen Chance, die IT-Organisation und sich persnlich weiterzuentwickeln.
Das Qualittsmanagement knnen Sie leicht fr die ITIL Best Practices
gewinnen, wobei unter Qualittsmanagement hier nicht eine Abteilung,
sondern der Gedanke der Qualittsverbesserung zu verstehen ist. Ein
wichtiges Kriterium fr Qualitt ist Nachhaltigkeit. ITIL stellt eine hhere
Nachhaltigkeit in der IT sicher. So werden beispielsweise mit dem Incident
Management nicht nur akute Strungen behoben, sondern darber hinaus
wird mit dem Problem Management eine nachhaltige Untersuchung etabliert, die zu einer Qualittsverbesserung in der IT fhrt.
Mitarbeiter mit einem starken Kundenfokus gewinnen Sie fr ITIL, indem
Sie die Serviceorientierung und die Ausrichtung der IT Service Management-Prozesse auf die Geschftsprozesse des Kunden herausstellen.
Die Motivation des Top-Managements wird wahrscheinlich primr durch
die Qualittsverbesserung geprgt sein. Durch Hinweise auf Kostenbetrachtungen und einen hufig gegebenen Wachstums- oder Konsolidierungsdruck knnen Sie weitere Motivation fr die ITIL Best Practices
generieren.
Das mittlere Management gewinnen Sie fr ITIL mit den zu erwartenden
Verbesserungen in der abteilungsbergreifenden Zusammenarbeit oder
der Mess- und Nachweisbarkeit von Qualittsverbesserung gegenber
dem Top-Management.
Den Mitarbeitern bietet ITIL u. a. eine strkere Absicherung der durchgefhrten Aktivitten durch klare Rollen- und Prozessdefinitionen.
Die jeweilige Motivation fr IT Service Management wird auch von der
Gre der IT-Organisation beeinflusst. In kleineren IT-Organisationen
steht hufig allein die Kundenorientierung im Mittelpunkt. Kommunikationsprobleme innerhalb der IT-Organisation und die Vernetzung der einzelnen IT-Organisationen spielen hier kaum eine Rolle. Mit wachsender
Gre der IT-Organisation nehmen diese Probleme aber exponentiell zu
und ITIL wird als Chance erkannt, diese Probleme zu lsen.
Zur Identifizierung der verschiedenen Motivationsgrnde ist es hilfreich, ber
einen externen Berater mit entsprechenden Erfahrungen zu verfgen.

229

6 Lessons learned: Empfehlungen und Ratschlge


Verdeutlichen Sie den durch IT Service Management erzielbaren Gewinn
fr die IT-Organisation, indem Sie die Sicht des Kunden einnehmen:
Der Gewinn
fr die
Organisation

Die IT wird in der Regel vom Kunden nur dann (negativ) wahrgenommen,
wenn zugesagte Vereinbarungen nicht eingehalten werden oder grere
IT-Strungen auftreten. Durch ein regelmiges, kundenorientiertes Reporting knnen Sie dieses Erscheinungsbild zum Positiven verndern.
Reporten Sie Ihren Kunden aber nicht nur die einzelnen Bestandteile der
SLAs, sondern stellen Sie ihnen aussagekrftige Qualittsinformationen
aus den IT Service Management-Prozessen zur Verfgung. So wird im
Hause des IT Rechenzentrums dem Kunden unter anderem berichtet, welche Probleme identifiziert wurden und welche Manahmen ergriffen werden, um die identifizierten Probleme zu beheben.
Fr interne IT-Organisationen ist es ideal, ber erreichte Kosteneinsparungen berichten zu knnen. Im beschriebenen Unternehmen konnte zum
Beispiel mit Hilfe des Prozesses Capacity Management dargestellt werden,
welche Kosteneinsparungen durch die Konsolidierung der IT Infrastruktur
erzielt wurden.

6.2.4
Die Rollen
gem der
ITIL Best
Practices

Rollenbeschreibungen

Innerhalb der ITIL Best Practices bis Version 2 finden Sie Rollenbeschreibungen zu den einzelnen Prozess Managern der IT Service ManagementProzesse. Schauen Sie sich hierzu [OGC, 2005b], [OGC, 2006b] und [OGC,
2006a] an:
OGC Best Practice for Service Support,
OGC Best Practice for Service Delivery und
Best Practice fr Security Management.
Generelle Rollenbeschreibungen fr den Prozess Manager und den Prozess Owner sind der Originalliteratur zur ITIL Version 2 nicht zu entnehmen. Hier liefert aber entsprechende Sekundrliteratur Empfehlungen (vgl.
[OGC, 2005a]).
Die ITIL Version 3 greift diesen leichten Mangel aus Version 2 auf und gibt
Handlungsempfehlungen fr die Etablierung der organisatorischen Rollen
Prozess Owner und Prozess Manager. Diese generischen Rollenbeschreibungen sind im Rahmen der Umsetzung entsprechend der jeweiligen Organisation zu operationalisieren.
Diesen Empfehlungen gem ist der Prozessinhaber (Prozess Owner) fr
die Prozessergebnisse verantwortlich, whrend der Prozess Manager fr
die Durchfhrung und die Einrichtung des Prozesses verantwortlich ist.
Der Prozess Owner dient dem Prozess Manager primr als Coach.

230

6.2 ITIL-Einfhrung
Innerhalb des Unternehmens wurden fr die Rollen der Prozess Owner
und Prozess Managern abweichende Verantwortlichkeiten festgelegt.
Der Prozess Manager hat die Verantwortung fr das Funktionieren seines
Prozesses und steuert die notwendigen Optimierungen.
Der Prozess Manager muss demzufolge mit den notwendigen Weisungsrechten innerhalb seines Prozesses ausgestattet sein.

Die Rolle des


Prozess
Managers

Die Prozess-Ziele werden nicht nur primr vom Prozess Owner vorgegeben, sondern auch durch ihn aus der IT-Strategie und der Balanced Scorecard abgeleitet. Aus diesen Anforderungen heraus definiert der Prozess
Manager die notwendigen Prozess-Ziele und die damit verbundenen
Kennzahlen.
Es muss sichergestellt werden, dass die Prozess Manager ein Grundverstndnis aller IT Service Management-Prozesse haben. Dadurch wird
einerseits erreicht, dass der eigene Prozess hinsichtlich seiner Schnittstellen, Abhngigkeiten und Verzahnungen besser gemanagt werden kann.
Andererseits motivieren diese Kenntnisse und die damit verbundenen
Aufstiegsmglichkeiten 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 przisiert diese wichtige Rolle wie folgt:
Einzelne Prozess-Ziele knnen partiell miteinander konkurrieren, Umsetzungsmanahmen aus unterschiedlichen Prozessen sind zu priorisieren
und es knnen Abstimmungsprobleme zwischen Prozessorganisation und
hierarchischer Organisationsstruktur auftreten. In diesen Fllen ist der
Service Manager die Eskalationsinstanz fr die Prozess Manager.
Letztendlich liegt die Gesamtverantwortung fr das Service Management
in der Rolle des Service Managers (vgl. Continual Service Improvement,
[OGC, 2007e]
Seine Verantwortung umfasst die Entwicklung der Geschfts-Strategie, Marktund Kunden-Analyse, Lieferanten-Management, Inventarisierung, Kosten Management und insbesondere das Auslieferungs- und Lebenszyklus-Management
von Produkten und Services.

Fr die Einfhrung der IT Service Management-Prozesse und der identifizierten Optimierungsmanahmen ist der Service Manager richtungsweisend, er erstellt den Bebauungsplan.

231

Die Rolle des


Service
Managers

6 Lessons learned: Empfehlungen und Ratschlge


Die Rolle des Service Managers muss mit einem erfahrenen Manager besetzt
werden.
Die Rolle
des TopManagements

Aufgabe des Top-Managements ist es, den zu etablierenden IT Service


Management-Prozessen den Rcken zu strken und ihre Ziele nach auen
zu vertreten. Das Top-Management ist der Sponsor der IT Service Management-Prozesse.
Mit der Implementierung der neuen IT Service Management-Prozesse
kann vorbergehend eine Phase der Instabilitt entstehen. Mit den bisherigen Ablufen waren die Mitarbeiter vertraut, mit den neu implementierten Prozessen sind sie es noch nicht. Erworbene Kompetenzen, gehen unter Umstnden verloren, es beginnt eine unsichere Lernphase (Tal der
Trnen). Hier muss das Top-Management untersttzend einwirken und
die Sicherheit geben, dass Anfangsfehler toleriert werden.
Das Top-Management muss Anfangsfehler tolerieren und so dazu beitragen,
dass kein Rckfall in alte Zustnde eintritt.

Die Rolle
des mittleren
Managements

Das mittlere Management setzt einerseits die Vorgaben des Top-Managements im tglichen Betrieb aktiv um. Andererseits muss es die Prozess
Manager untersttzen und ihnen den erforderlichen Freiraum verschaffen.
Die Einfhrung von durchgngigen Prozessen mit dezidierter Prozessverantwortung fhrt hufig zu Widerstnden im mittleren Management.
Diese Widerstnde sind mit der Angst vor der geplanten Transparenz und
einem mglichen Machtverlust verbunden.
Manchmal kann diesen Widerstnden erfolgreich entgegen gewirkt werden, wenn die Rollen der Prozess Owner mit Personen aus dem mittleren
Management besetzt werden.
Dem mittleren Management kommt eine wichtige Rolle in der Untersttzung des
Wandels zu.

Die Rolle der


Mitarbeiter

Mit der Einfhrung von IT Service Management-Prozessen kann sich die


Rolle von Mitarbeitern im IT Service aus deren Sicht verkomplizieren.
Waren sie vorher ausschlielich einem Vorgesetzten verantwortlich (und
dort der Ergebniserbringung), wird Ihre Ttigkeit nun in verschiedenen
Prozessen berwacht und die Weisungen unterschiedlicher Prozess Manager steuern auf Qualittsebene die operative Arbeit der Mitarbeiter.
Stellen Sie sicher, dass Ihre Mitarbeiter sich in dieser Situation nicht verloren vorkommen. Die Hierarchie, insbesondere das mittlere Management,
muss die Prozesse aktiv untersttzen, um damit die Ziele der ITIL Einfhrung nachhaltig zu untersttzten.

232

6.3 Kontinuierlicher Verbesserungsprozess


Die Prozess Manager geben den Mitarbeitern Leitplanken (Prozessleitlinien) vor, innerhalb derer sie sich sicher bewegen knnen. Durch diese
Konzentration auf klare Prozesse geben sie ihren Mitarbeitern ein Gefhl
der Sicherheit.
Transparente Ziele und verffentlichte Kennzahlen als Erfolgsnachweis
der eigenen Arbeit steigern die Zufriedenheit der Mitarbeiter im Unternehmen.
Beziehen Sie Ihre Mitarbeiter und deren Know-how bei der Entwicklung
der neuen IT Service Management-Prozesse mit ein und gewinnen Sie
dadurch weitere Akzeptanz.
Damit die ITIL Best Practices erfolgreich zur Gestaltung und Implementierung Ihrer IT Service Management-Prozesse genutzt werden knnen, mssen Sie einen Vernderungsprozess in Ihrer IT-Organisation initiieren.
Ohne flankierende Manahmen fhrt das Einfhren von ITIL zu Akzeptanzproblemen und scheitert nicht selten.
Die ITIL Best Practices sind eine Methode, aber nicht das Ziel. Sie nutzen
lediglich die Best Practice-Erfahrungen, um von Ihnen bei der Definition
Ihrer IT Service Management-Prozesse zu profitieren.
Die angepassten IT Service Management-Prozesse mssen innerhalb Ihrer ITOrganisation gelebt werden. Dazu mssen Ihre Mitarbeiter die Prozesse verstehen, mitgestalten und insbesondere die Erfolge erfahren.

6.3 Kontinuierlicher Verbesserungsprozess


Eine wichtige Komponente der ITIL Best Practices ist das im konzeptionalen Ansatz enthaltene Qualittsmanagement. Hierzu verweisen die ITIL
Best Practices auf verschiedene Methoden wie zum Beispiel auf Six Sigma oder auf den Deming-Zyklus (vgl. [OGC, 2005b]), dargestellt in
Abbildung 66.
Von wesentlicher Bedeutung fr die Qualitt der IT Services und der Prozesse ist, dass Sie eine fortlaufende berprfung, ein Monitoring smtlicher implementierten IT Service Management-Prozesse durchfhren. Auf
die dazu notwendige Ermittlung von Kennzahlen wird im nchsten Kapitel eingegangen.
In der Publikation Best Practice fr Service Support vgl. [OGC, 2005b])
heit es hierzu: Dieser Ansatz bedingt, dass ein Unternehmen nach definierten Prozessen agiert, seine Aktivitten in Bezug auf die Zielerreichung
misst, sowie die aus den Prozessdurchlufen folgenden Outputs im Hinblick auf mgliche Prozessverbesserungen berprft.

233

6 Lessons learned: Empfehlungen und Ratschlge

Abbildung 66:

Deming (oder PDCA) Zyklus

Die Norm ISO 20000, der (einzige) internationale Standard fr das IT Service Management, konkretisiert diesen Ansatz der ITIL Best Practices weiter. So fordert die ISO 20000 einen bergeordneten Prozess Planung und
Implementierung. Dieser Prozess stellt unter anderem die Etablierung
eines bergreifenden kontinuierlichen Verbesserungsprozesses fr das IT
Service Management sicher. Darber hinaus sind gem der ISO 20000 in
den einzelnen IT Service Management-Prozessen notwendige Verbesserungsmanahmen 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]). Darber hinausgehende Informationen knnen Sie den im Quellenverzeichnis aufgefhrten Publikationen
zu ISO 20000 entnehmen.
Ein professionelles IT Service Management bedingt unabdingbar die stetige Messung der Prozesse und die Identifikation von mglichen Verbesserungsmanahmen (KVP: Kontinuierlicher Verbesserungs-Prozess).

6.3.1

KVP der bestehenden Prozesse

Ausgangspunkt ist die oben beschriebene Analyse der bereits innerhalb


der IT-Organisation bestehenden IT Service Management-Prozesse.
Prozess Manager von bereits bestehenden IT Service Management-Prozessen befinden sich dabei in einer vermeintlich komfortablen Ausgangsposition: Whrend andere Prozesse noch zu definieren und zu entwickeln sind,
bestehen deren Prozesse bereits.

234

6.3 Kontinuierlicher Verbesserungsprozess


In diesem Zusammenhang mag es zunchst paradox erscheinen, aber speziell die Prozess Manager von bestehenden Prozessen bentigen die intensivste Untersttzung durch eine externe Begleitung.
Sie mssen die IT Service Management-Prozesse, die am weitesten entwickelt
sind (mit der hchsten Prozessreife), besonders eng begleiten.

Ansonsten besteht die groe Gefahr, dass sich der betroffene Prozess Manager aufgrund der durchgefhrten Ist-Aufnahme (ITIL-Prozesslandkarte)
in seiner bestehenden Handlungsweise besttigt fhlt und keine notwendigen Handlungsmanahmen fr seinen Prozess identifiziert. Auch bei
guten (Einzel-) Ergebnissen der durchgefhrten Ist-Aufnahme (Prozessreife) muss aber zumindest davon ausgegangen werden, dass die Vernetzung
der IT Service Management-Prozesse noch nicht ausreichend gegeben ist.
Das heit, es besteht immer ein Handlungsbedarf, den Prozess mit den
anderen IT Service Management-Prozessen zu vernetzen. Die (externe)
Begleitung des Prozess Managers soll sicherstellen, dass die erforderliche
Vernetzung erkannt und aktiv betrieben wird. Die Rolle des externen Begleiters ist es, als Coach den Prozess Manager einzufangen.
Durch die Forcierung der Vernetzung vermeiden Sie eine isolierte Optimierung einzelner IT Service Management-Prozesse, die ansonsten den
anderen Prozessen davoneilen wrden. Die isolierte Optimierung einzelner Prozesse kann zu Mehraufwendungen fhren, wenn spter die notwendigen Schnittstellen und unter Umstnden damit verbundene Aktivitten angepasst werden mssen.
Es ist fr Ihre IT-Organisation von groem Vorteil, wenn eine gleichmige vertikale Entfaltung der geplanten IT Service Management-Prozesse betrieben wird.

Diese Forderung bedeutet nicht, dass Sie alle IT Service Management-Prozesse gleichzeitig einfhren sollen. Es ist vielmehr pro Projekt- bzw. Implementierungsphase eine synchrone Entwicklung der einzelnen Prozesse
sicherzustellen.
Dem Prozess Manager mit dem bereits am weitesten entwickelten Prozess
kommt hierbei eine besondere Rolle zu. Er muss auf die anderen Prozess
Manager zugehen, die Vernetzung der einzelnen Prozesse aktiv vorantreiben und sicherstellen.
Planen Sie zum Beispiel die Etablierung des Incident, Problem und Change Managements und ist der Prozess des Incident Managements am weitesten fortgeschritten, so muss der Prozess Manager des Incident Managements die fhrende Rolle bei der erforderlichen Vernetzung der drei Prozesse einnehmen.

235

6 Lessons learned: Empfehlungen und Ratschlge


Bei den bestehenden Prozessen zeichnet sich der KVP dadurch aus, dass
die Prozesse gleichmig (vertikal) entwickelt werden und keine Prozesse
die Entwicklung isoliert vorantreiben.
Nicht zu frh
beginnen

6.3.2

KVP der neuen Prozesse

Mit dem Start des kontinuierlichen Verbesserungsprozesses darf bei neuen


Prozessen nicht zu frh begonnen werden. Stellen Sie zunchst sicher,
dass der Prozess bereits komplett eingefhrt ist.
Am Bild einer Treppe verdeutlicht: Sie sollten die Stufen stetig, mit ruhigen Schritten emporsteigen. Nehmen Sie nicht mehrere Stufen auf einmal,
berspringen Sie keine Stufen. Um das Ziel sicher zu erreichen, sollten Sie
auf jeder Stufe erst einmal verharren und Kraft tanken, um dann erholt die
nchste Stufe zu erklimmen.
Ihre Organisation muss die Prozesse angenommen haben und damit verbundene (Ver-) nderungen mssen verkraftet sein. Die Einfhrung von
IT Service Management-Prozessen auf Basis der ITIL Best Practices ist eine
Manahme der Organisationsentwicklung und bedarf eines Vernderungs-Managements.
Der Soziologe Kurt Lewin gilt als Wegbereiter der Organisationsentwicklung. Aufbauend auf seiner Grundannahme, dass sich eine Organisation
ndert, wenn sich ihre Akteure ndern, entwickelte er sein Phasenmodell
(vgl. Abbildung 67) zum Vernderungs-Management (vgl. [Lewin, 1958]).

Neue Welt

Alte Welt

Einfrieren

Auftauen

Bewegen
Abbildung 67:

236

3-Phasen-Modell nach Lewin

6.3 Kontinuierlicher Verbesserungsprozess


Im Ausgangszustand befindet sich eine Organisation im Gleichgewicht.
Die bestehenden Ablufe und Prozesse werden in Frage gestellt. Hierzu
kann auf die ITIL Best Practices und die damit in anderen IT-Organisationen erzielten Erfolge verwiesen werden. Die bestehende IT-Organisation
wird aufgetaut. Ist das Auftauen der IT-Organisation (und der Mitarbeiter) erreicht, werden in der Phase der Bewegung neue Prozesse implementiert und die Mitarbeiter in deren Handhabung ausgebildet und eingewiesen.
Es ist dann von groer Bedeutung, dass dieser Zustand zunchst eingefroren wird.
Mit den alten Ablufen waren Ihre Mitarbeiter vertraut. Die Implementierung der neuen IT Service Management-Prozesse fhrt zu einer Instabilitt.
Die Mitarbeiter sind mit in den neuen Prozessablufen und den damit
verbundenen Ablufen noch nicht vertraut. Sie fhlen sich unsicher.
Ihre Aufgabe besteht jetzt darin, den Mitarbeitern die notwendige Sicherheit zu vermitteln. Das heit, Sie mssen den Mitarbeitern die Chance
geben, sich mit den neuen Prozessen auseinander zu setzen und deren
Handhabung im tglichen Betrieb einzuben.
Die Mitarbeiter Ihrer IT-Organisation mssen die Vernderungen bewltigen.
Geben Sie ihrer Organisation die Chance, sich mit neuen Ablufen vertraut zu
machen und planen Sie Phasen des Einfrierens ein.

Erst wenn die Mitarbeiter mit den neuen Prozessaktivitten vertraut sind,
sollten Sie eine weitere Verbesserung und Erweiterung des Prozesses angehen.
Zustzlich ist die Phase des Einfrierens fr die Motivation Ihrer ITOrganisation von groer Bedeutung.
Die Einfhrung von IT Service Management-Prozessen auf Basis der ITIL
Best Practices fhrt zu vernderten Ablufen und ggf. zu anderen Aktivitten, die die Mitarbeiter durchzufhren haben. Von nachhaltigem Erfolg
sind diese Manahmen nur dann, wenn Sie akzeptiert werden. Akzeptiert
werden die Manahmen in der Regel, wenn Sie den Erfolg wenn mglich fr den Einzelnen nachweisen.
Haben Sie zum Beispiel ein Configuration Management eingefhrt, so
sollten Sie die Erfolge des Prozesses fr Ihre IT-Organisation und Ihre
Mitarbeiter erfahrbar machen. Die Mitarbeiter sollen erleben, welche Vorteile dieser Prozess in der tglichen Arbeit bietet.
Damit stellen Sie die Motivation der Mitarbeiter fr weitere Vernderungsmanahmen sicher.

237

6 Lessons learned: Empfehlungen und Ratschlge


Beginnen Sie zu frh mit den nchsten Verbesserungsmanahmen, so
nehmen Sie ihrer IT-Organisation und Ihren Mitarbeiter die Chance, die
bisher erzielten Vorteile zu erleben.
Das Service
Improvement
Programm

Innerhalb der ITIL Best Practices wird lediglich im Rahmen des Service
Level Management-Prozesses auf ein Service Improvement Programm
(SIP) eingegangen. Die ISO 20000 IT Service Management ist hier konsequenter. Dort wird zu den jeweiligen Prozess-Reviews gefordert, dass ein
erkanntes Verbesserungspotenzial zu Prozessen oder Services der Input
fr das SIP ist.
Durch die Dokumentation im SIP stellen Sie die Nachhaltigkeit der Umsetzung von identifizierten Verbesserungsmanahmen sicher.
Hufig wird innerhalb der IT-Organisation die Feststellung getroffen
Darum msste man sich einmal kmmern . Dann jedoch diktiert wieder das Tagesgeschft das Geschehen. Bis zum nchsten akuten Auftreten
eines Problems gert die identifizierte Schwachstelle samt Optimierungsbedarf wieder in Vergessenheit.
Ein Service Improvement Programm und die Mglichkeit, dass jeder Mitarbeiter hierzu einen Input liefern kann, hilft Ihnen nachhaltig, die Qualitt 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 persnlich zum Erfolg der IT-Organisation
beitragen.

Damit entsteht letztendlich eine Kombination aus formellen Reviews zur


Service- und Prozessoptimierung und einem betrieblichen Vorschlagswesen. In Ihrer Organisation existiert damit ein Verbesserungsprozess, der
Input fr neue und eingefhrte IT Service Management-Prozesse aus der
IT-Organisation (Reviews) und von den Mitarbeitern bezieht.
ITIL
Einfhrung
erfordert ein
Release

Aufgabe des Prozess Managers ist die Bewertung des Inputs fr den Service Improvement Plan und die Erstellung einer Umsetzungsplanung.
Die Einfhrung 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 Manahmen verbundenen
Vorteile identifizieren und die Umsetzung planen.
Diese Ttigkeit ist mit dem IT Service Management-Prozess des Release
Management vergleichbar. Es ist nicht zweckmig eine Reihe von nderungen jeweils einzeln und nacheinander zu implementieren. Sie sollten
vielmehr die Einzelmanahmen bndeln und als Aufgabenpaket (Release)
durchfhren.

238

6.3 Kontinuierlicher Verbesserungsprozess


Bndeln Sie die einzelnen Verbesserungs- und Erweiterungsmanahmen zu einem Aufgabenpaket (Release).

Dem Prozess Owner kommt hierbei als Coach eine qualittssichernde


Aufgabe zu. Zum Beispiel hat der Prozess Owner beim Prozess Manager
kritisch zu hinterfragen, ob die nchste Umsetzungsmanahme sowohl
inhaltlich als auch vom Zeitpunkt her die IT-Organisation nicht berfrachtet.
Sobald diese Abstimmung erfolgt ist, muss der Prozess Manager die geplanten Verbesserungen und Erweiterungen in der IT-Organisation gegenber dem Management und den Mitarbeitern kommunizieren.
Kommunizieren Sie als Prozess Manager Ihre geplanten Manahmen (SIP fr
Ihre IT Service Management-Prozesse) in der IT-Organisation.

Die Initiierung zur Entfaltung weiterer IT Service Management-Prozesse


muss vom IT-Management erfolgen. Haben Sie zum Beispiel bereits Incident, Problem, Configuration und Change Management implementiert, so
muss eine Erweiterung um das Release Management vom IT-Management
initiiert werden.
Die Verantwortung fr die Prozessentfaltung die Erweiterung der bestehenden IT Service Management-Prozesse liegt beim Service Manager
und dem prozessverantwortlichen Prozess Manager. Diese stimmen die
mit der Prozesseinfhrung verbundenen Manahmen mit dem Prozess
Owner ab.
Die Verantwortung fr die Prozessentfaltung die Erweiterung der bestehenden IT Service Management-Prozesse liegt beim Service Manager.
Dieser stimmt zunchst die damit verbundenen Manahmen mit dem
Prozess Owner ab. Sobald der Prozess Manager fr den neuen IT Service
Management-Prozess etabliert ist, stimmen sich dann der Prozess Owner
und der Prozess Manager ab.
Es ist hilfreich, wenn die Prozess Owner fr alle IT Service ManagementProzesse zu Beginn benannt werden, auch wenn die Prozesse noch nicht
implementiert wurden. Die Prozess Manager knnen mit der Entscheidung des Managements ber die Einfhrung eines Prozesses benannt
werden.
Wichtig ist, nicht nur die implementierten Prozesse hinsichtlich ihrer Zielerreichung zu messen, sondern auch die Einfhrung von Prozessen zu
messen und zu berwachen.

239

Der
Entfaltungsprozess

6 Lessons learned: Empfehlungen und Ratschlge


Der Service Manager hat hierzu ein prozessorientiertes Fhrungssystem
aufgebaut, in dem pro Prozess die folgenden Stufen vom Service Manager
gemessen und berichtet werden:

1. Stufe Prozess verstanden


2. Stufe Prozessnutzung initiert
3. Stufe Prozess implementiert
4. Stufe Prozess wird kontinuierlich verbessert (KVP)

Damit die Implementierung der Prozesse vom Management besser verfolgt werden kann, knnten die obigen Stufen der IT Service ManagementProzesse
mit
einem
Ampelsystem
dargestellt
werden.
Fr die Gestaltung des Ampelsystems empfiehlt es sich, auf der vertikalen
Achse die unternehmenswichtigen Prozesse (z. B. Incident, Problem,
Change aufzufhren (etc.) und auf der horizontalen Achse die involvierten
Gruppen, Abteilungen, Hauptabteilungen etc. darzustellen. Die Matrix
kann dann anschlieend in der Stufigkeit 1 4 befllt werden. Wir haben
sehr gute Erfahrung mit einer einfachen Einstufung der Skala 1 4 gemacht:
Stufe 1:
die Mitarbeiter sind geschult, die Mitarbeiter haben die richtigen Informationen ber die Umsetzung der Prozesse;
Stufe 2:
die Mitarbeiter leben die Prozesse in den ersten Anfngen, nutzen die
neuen Tools, Portale etc.;
Stufe 3:
die Prozesse werden vollumfnglich genutzt (es kommen Vorschlge zur
Verbesserung), die Prozesstools werden ausgereizt;
Stufe 4:
die Organisation denkt darber nach, Erweiterungen und Verbesserungen
umfnglich einzufhren.
Mit diesem Ampelsystem verfgt der Service Manager und damit das
gesamte Management ber ein gutes Fhrungssystem zur berwachung
der geplanten Manahmen und der erzielten Prozessreife.
Sie bentigen nicht nur ein System zur Messung der Effizienz und Effektivitt
der Prozesse, sondern auch ein Messsystem fr die Prozessimplementierung. Mit
einem Ampelsystem knnen Sie die Einhaltung der Prozesse und deren Wirksamkeit in der Linie berprfen.

240

6.3 Kontinuierlicher Verbesserungsprozess

6.3.3

Wettbewerb der Prozesseinfhrung

Fr die Einfhrung der IT Service Management-Prozesse werden so genannte Quick-Wins bentigt. In unserer schnelllebigen Zeit akzeptiert
kein Management mehr Projekte, deren erste Erfolge nach 9 Monaten eintreten.
Daher mssen die Prozess Manager bei der Prozesseinfhrung die QuickWins identifizieren und darstellen. Damit kann nicht nur gegenber dem
Management ein erster ROI demonstriert werden, sondern Sie knnen
auch die Anerkennung des Prozesses in der IT-Organisation erleichtern.
Selbst mit der besten Einfhrungsplanung und einem optimalen VernderungsManagement werden Sie nicht alle Mitarbeiter von den geplanten Manahmen
berzeugen knnen. Mit den Quick-Wins knnen Sie erste Erfolge nachweisen,
die die Richtigkeit des Vorhabens demonstrieren. Die Einfhrung wird anschlieend durch eine grere Akzeptanz beschleunigt.

Die ITIL Einfhrung bentigt eine durchgngige Kommunikationsplattform. Hier berichten die Prozess Manager dem Service Manager und dem
Prozess Owner ber die bereits erzielten Erfolge.
Diese Erfolge knnen aus einer Verbesserung der Prozessreife und der
damit verbundenen nderung der Ampelfarbe bestehen, wie zum Beispiel der erreichten Dokumentation eines Prozesses. Ein Erfolg kann aber
beispielsweise auch darin bestehen, dass Probleme erfolgreich behoben
wurden und dadurch die Anzahl der Strungen gesenkt werden konnte.
Mit der Zeit lernen die Prozess Manager, wie sie der Organisation die
Wirksamkeit ihrer Prozesse darstellen knnen. Zum Beispiel kann der
Prozess Manager Configuration Management dem Produktionsleiter demonstrieren, wie mithilfe des Configuration Managements sehr viel
schneller wichtige Informationen abgerufen werden knnen.
Dadurch, dass die Prozess Manager erste Erfolge aufzeigen, entsteht innerhalb der IT-Organisation ein Wettbewerb der Prozesseinfhrung. Andere
Prozess Manager haben ein Interesse daran, ebenfalls Erfolge aufzuzeigen.
Es entsteht eine Sogwirkung.
Durch die gemeinsame Kommunikationsplattform ist die notwendige
Transparenz gegeben. Zusammen mit dem kontinuierlichen Verbesserungsprozess und der damit verbundenen Planung entsteht so auch ein
internes Benchmarking.

241

6 Lessons learned: Empfehlungen und Ratschlge

6.3.4

Reifegradanalyse der Prozesse im laufenden Betrieb

Die oben angegebenen Manahmen zur Bestimmung des Reifegrads drfen nicht zu einer Behinderung des Betriebs innerhalb Ihrer IT-Organisation fhren.
Eine berprfung der IT Service Management-Prozesse, die zu frh
durchgefhrt wird oder zu lange dauert, fhrt zu einer Verunsicherung
der Mitarbeiter. Wird eine berprfung zu frh durchgefhrt, so fhlen
sich Ihre Mitarbeiter in eine Position der Rechtfertigung gedrngt. Es entsteht eine Vorwurfshaltung, bis hin zu Neid und Missgunst. Es geht dann
nicht mehr um die Identifizierung von Verbesserungspotenzial, sondern
es werden Schuldige gesucht. Eine zu frhe bzw. zu lange Analyse hinterlsst 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 berprfung durch eine externe Organisation vor der Einfhrungsphase kann zu diesen Problemen fhren. In der Regel werden groe
Defizite zu den ITIL Best Practices identifiziert und die Mitarbeiter verbinden dies mit einer Disqualifikation ihrer Leistungen und ihres Know-how.
Der Berater muss daher unbedingt als Coach auftreten. Erfahrene Berater
sind in der Lage sich durch eine kurze Bestandsaufnahme einen Eindruck
zu verschaffen, der fr eine Planung der notwendigen Manahmen vllig
ausreichend ist, ohne die Mitarbeiter zu verunsichern.
Dies soll keinesfalls heien, dass Sie Ihre Prozesse nicht extern berprfen
und zertifizieren lassen sollten. Achten Sie lediglich darauf, dass die berprfung erst dann erfolgt, wenn eine reelle Chance besteht, dass die
Anforderungen erfllt werden knnen.
Mit einer externen Zertifizierung knnen Sie Ihre Mitarbeiter weiter motivieren und in Ihrer IT-Organisation den Erfolg der vollzogenen Vernderungsmanahmen nachweisen. Die Zertifizierung nach der ISO 20000 belegt, dass auch eine externe, neutrale Organisation den Erfolg Ihrer IT
Service Management-Prozesse anerkennt.
Achten Sie darauf, dass der externe Berater nicht nur Unterschiede und "Nicht
100% ITIL konform" feststellt, sondern in der Lage ist, Ihren Mitarbeitern Wertschtzung zu geben und das bisher Erreichte positiv unterstreichen zu knnen.

Die Abstimmung des IT Service Management auf die Business-Strategie


sollte frhestmglich erfolgen. Klren Sie zunchst innerhalb der ITOrganisation, welche IT Services, welche Service Level und welche Messungen realistisch zugesichert werden knnen. Sie vermeiden dadurch

242

6.4 Kennzahlen
eine falsche Erwartungshaltung bei Ihrem Kunden. Holen Sie dann unbedingt Ihren Kunden ab, erlutern Sie ihm die jetzige Situation, gehen Sie
ggf. auf die Kostensituation ein und binden Sie ihn in die weitere Entwicklung ein.
Think big, start small getreu diesem Motto sollte die Entwicklung von
Kennzahlen erfolgen. Starten Sie zunchst 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 fr das IT Service Management und die dazu gehrigen


Prozesse muss aus der IT-Organisation heraus entwickelt werden. Sie ergibt sich aus der Umsetzung der IT-Strategie und der Strategie Ihres Kunden. Beachten Sie stets, dass die ITIL Best Practices nur eine Methode sind.
Definieren Sie keine isolierten ITIL Ziele.
Ihre Mitarbeiter mssen die IT Service Management-Prozesse verstehen,
dafr bentigen sie theoretische und praktische Schulungen. Wichtig ist
die Hinfhrung der Mitarbeiter von der ITIL-Theorie zu den fr sie relevanten Prozessen in Ihrer IT-Organisation.
Das Management sollte regelmig z. B. Kongresse als Informationsquelle
nutzen, um Ihre IT-Organisation mit anderen Unternehmen vergleichen
zu knnen und um weiteres Optimierungspotenzial zu identifizieren.

6.4 Kennzahlen
Die IT Service Management-Prozesse auf der Basis der ITIL Best Practices
sind fortlaufend kritisch hinsichtlich ihrer Zielerreichung und ihrer Ausrichtung auf die Geschftsprozesse Ihres Unternehmens zu berprfen.
In diesem Kapitel stellen wir Ihnen vor, wie Sie Ihre IT Service Management-Prozesse bezglich der Zielerreichung und der Ausrichtung auf die
Geschftsprozesse berprfen knnen. Anschlieend gehen wir darauf ein,
wie Sie die IT Service Management-Prozesse auf Ihre IT-Strategie und Ihre
Geschftsanforderungen ausrichten knnen. Zum Schluss dieses Kapitels
erlutern wir, warum auch nach der Einfhrung der Prozesse ein Transition Management weiterhin notwendig bleibt.

243

6 Lessons learned: Empfehlungen und Ratschlge

6.4.1

IT-Prozesse am Tagesgeschft 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 gewhrleistet werden, dass die IT Service Management-Prozesse die jeweils
definierten Ziele erfllen.
Die Publikation Best Practice fr Service Support hierzu (vgl. [OGC,
2005b]): Um ermitteln zu knnen, ob Ihre Aktivitten einen optimalen
Beitrag der vom Prozess verfolgten geschftlichen Zielsetzung leisten,
sollten Sie regelmig ihre Effektivitt messen. Die Durchfhrung von
Messungen ermglicht Ihnen, das tatschlich Erreichte mit dem Geplanten
zu vergleichen sowie eine eventuell erforderliche Verbesserung zu erwgen bzw. einzuleiten.
Angesichts der Komplexitt und der groen Zahl von durchgefhrten
Aktivitten innerhalb einer IT-Organisation kann in der Praxis nur ber
Kennzahlen verfolgt werden, ob die IT Service Management-Prozesse die
definierten Ziele erreichen bzw. welche Entwicklungen sich in den IT Service Management-Prozessen abzeichnen.
Die Prozesssteuerung von IT Service Management-Prozessen ist ohne Kennzahlen unmglich. Sie bentigen Kennzahlen fr jeden einzelnen IT Service Management-Prozess.

Die Kennzahlen werden dabei zum Teil aus den operativen Systemen gewonnen, wie zum Beispiel aus den in einem Tool fr das Incident Management dokumentierten Aktivitten. Die gespeicherten Informationen werden dabei zu aussagekrftigen Kennzahlen verdichtet, mit denen die Effektivitt 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, knnen die Ergebnisse fr das Management sehr
ernchternd sein. Einzelwerte knnen sogar erschreckend sein. Sehen Sie diesen
ersten Eindruck als Chance fr das Management. Sie knnen die Prozesse messen und haben dadurch die Basis fr ein erfolgreiches Management der Prozesse
geschaffen.

Ein Nutznieer der Kennzahlen ist Ihr IT-Management, z. B. Gruppenoder Abteilungsleiter. Anhand weniger signifikanter Kennzahlen kann
sich das IT-Management einen berblick ber die aktuelle Situation verschaffen.

244

6.4 Kennzahlen
Folgende Kennzahlen knnen 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 auerdem als Indikator fr die Arbeitsbelastung der Mitarbeiter. Ein sprunghaftes Ansteigen von Incidents kann auf eine Flchenstrung hinweisen. Das Management sollte jeweils die Grnde hinterfragen und ggf. die notwendigen organisatorischen Manahmen veranlassen.
Stellen Sie in Ihrer IT-Organisation heraus, dass die Ermittlung und Auswertung
von Kennzahlen fr das Management der IT Service Management-Prozesse unbedingt notwendig sind. Betonen Sie, dass die Kennzahlen nicht zur Messung
und Beurteilung Ihrer Mitarbeiter dienen und auch nicht dazu genutzt werden.

Wenn Sie noch ber keine Messwerte zu einem Prozess verfgen, sollten
Sie sich zunchst 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 Verhltnis.
80 % der Arbeit lsst sich mit 20 % Aufwand erledigen. Die restlichen 20% erfordern dagegen 80 % Aufwand.

Bei der 80/20-Regel geht es nicht nur um den Aufwand zur Definition der
Kennzahl, sondern insbesondere um den Aufwand der Datengenerierung.
Ihre IT-Organisation muss zunchst Erfahrungen mit dem Management
von und mit Kennzahlen gewinnen. Daher sollten Sie anfangs mit einfachen Kennzahlen beginnen. Komplexere Kennzahlen z. B. wie viele
Incidents werden auf Probleme referenziert? sollten erst in einer zweiten oder dritten Stufe des kontinuierlichen Verbesserungsprozesses (KVP)
angewandt werden.
Fr das Incident Management ist es zunchst ausreichend, wenn Sie feststellen, wie viele Incidents berhaupt gemeldet und bearbeitet werden.
Die Verfolgung des Trends der Incidents und die Identifizierung signifikanter Abweichungen sind fr erste Analysen ausreichend. Mit den ersten
Kennzahlen erhalten Sie eine Art Fieberthermometer fr Ihre IT Service
Management-Prozesse.
Auch bei der Definition von Kennzahlen bewahrheitet sich die Erkenntnis Weniger ist oft mehr. Wenn noch keine Messwerte vorliegen, sollten Sie sich zunchst auf wenige signifikante Kennzahlen konzentrieren.

245

Wenige, der
IT-Organisation nutzbringende, Kennzahlen

6 Lessons learned: Empfehlungen und Ratschlge


Die Anforderungen hinsichtlich der Messbarkeit von Prozessen werden
von Prozess Managern oft berinterpretiert. Der Konzeptphase folgt dann
hufig ein Erschrecken ber den Umfang der definierten Kennzahlen und
als (vermeintliche) Lsung der Ruf nach einer Tool-Untersttzung. Werden die definierten Kennzahlen schlielich mit Daten hinterlegt, wird oft
klar, dass lediglich 10% der Kennzahlen nutzbringend sind.
Dieses Vorgehen rhrt z. T. auch aus einer unkritischen Nutzung von Publikationen. In den ITIL Best Practices finden Sie zwar beispielhaft einige
Kennzahlen. Aber Sie sollten die dargestellten Kennzahlen nicht komplett
und ungeprft bernehmen.
Um Ihre Kennzahlen zu definieren, mssen Sie sich fragen, welche Kennzahlen sich aus Ihrer IT-Strategie ableiten und welche Kennzahlen von
Ihrer Linienorganisation bentigt werden. Das heit, welche Kennzahlen
untersttzen Ihr Tagesgeschft?
Eine groe Hilfestellung bei der Definition von Kennzahlen fr die Linienorganisation kann der Prozess Owner geben. Aufgrund der Anforderungen und seinen Erfahrungen aus dem Tagesgeschft ist der Prozess Owner
der ideale Partner, um die notwendigen Kennzahlen zu diskutieren und
zu definieren.
Interessante Kennzahlen fr den Beginn eines Kennzahlenmonitorings
knnen sein:
Anzahl der ausgefertigten und abgeschlossenen SLAs mit Ihren
Kunden in Bezug auf den Servicelevelprozess
Anzahl der Notfall / BCM bungen pro Jahr in Bezug auf das IT
Service Continuity Management
Anzahl der vorhandenen Assets pro Gruppe (Windows, Unix, Host
etc.) in Bezug auf das Configuration Management.
Anzahl der Ausflle > 120 min pro Applikation und Monat in Bezug
auf das Availability Management
Verwendete Kennzahlen mssen fr das Management prgnant und beeinflussbar sein.
Kann ein Linien-Manager die Kennzahlen nicht sinnvoll nutzen, so findet
ITIL beim Management keine Anerkennung!
Schrittweise
Erweiterung
der Kennzahlen

Im Rahmen der schrittweisen Weiterentwicklung Ihrer IT Service Management-Prozesse knnen Sie ggf. auf einzelne Kennzahlen verzichten oder
Kennzahlen ergnzen. Haben Sie zum Beispiel im Incident Management
mit der Kennzahl Anzahl Incidents insgesamt begonnen, so knnen Sie
dann die Incidents auf einzelne Kunden, IT Services oder IT-Systeme
gruppieren.

246

6.4 Kennzahlen
Im Rahmen dieser schrittweisen Erweiterung knnen Sie dann auch auf
Best Practices wie ITIL oder COBIT zurckgreifen. Prfen Sie die dort
dokumentierten Kennzahlen auf sinnvolle Nutzung in Ihrer IT-Organisation, und bernehmen Sie sie nur bei einer positiven Bewertung.
Wollen Sie eine Revision Ihrer IT Service Management-Prozesse auf der
Basis von COBIT sicherzustellen, so sollten Sie die Umsetzung dieser Anforderung als Stufe Ihres KVP planen und nicht zu Beginn des Prozesses
integrieren.
Im weiteren Reifegrad der ITIL Einfhrung knnen 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 darber, wie viele Manahmen im Problem Management
aktuell betrachtet werden.
Anzahl der Service Level Agreements in verschiedenen monetren
Volumen (z. B. < 100.000 Euro; < 500.000 Euro) und damit eine
Gruppierung nach A,B,C Kunden.

6.4.2

ITIL abgestimmt auf die Business- und IT-Strategie

Charakteristisch fr IT Service Management-Prozesse auf der Basis der


ITIL Best Practices ist ihre Ausrichtung auf die Geschftsprozesse Ihres
(internen oder externen) Kunden.
Hierzu heit es in Best Practice fr Service Support (vgl. [OGC, 2005b]):
ITIL richtet den Fokus auf die Bereitstellung qualitativ hochwertiger Services und unterstreicht insbesondere die Bedeutung von Kundenbeziehungen. Dies bedeutet, dass die IT-Organisation bereitstellen sollte, was immer mit dem Kunden vereinbart wurde, was wiederum eine enge Beziehung zwischen der IT-Organisation und deren Kunden und Partnern voraussetzt.
Planen Sie die Einfhrung von kundennahen IT Service ManagementProzessen (z. B. Service Level Management oder Financial Management
for IT Services), sollten Sie vorab die Erwartungshaltung des Kunden in
Erfahrung bringen.
Sie mssen die Erwartungshaltung Ihres Kunden verstehen, um auf dieser
Basis die Machbarkeit innerhalb der IT-Organisation zu prfen und mit
den mglichen Anforderungen abzugleichen.
Im Idealfall sollten Sie in der Lage sein, smtliche Kundenanforderungen
an einen IT Service dort zu messen, wo der Kunde bzw. Anwender den IT

247

Den Kunden
rechtzeitig
einbinden.

6 Lessons learned: Empfehlungen und Ratschlge


Service wahrnimmt. Dies ist in der Regel der Arbeitsplatz, und dieser Ansatz fhrt damit zu einer end-to-end Messung des IT Service.
Diese end-to-end Messungen knnen jedoch zurzeit in vielen Unternehmen noch nicht durchgefhrt werden, da die notwendigen Werkzeuge
fehlen. Die Implementierung dieser Werkzeuge ist in der Regel in Abhngigkeit von den betrachteten IT Services und der genutzten IT-Infrastruktur mit nicht unerheblichen Investitionen verbunden.
Eine kunden- bzw. serviceorientierte Messung und ein entsprechendes Reporting, die Realisierung einer end-to-end Messung, sollte zumindest mittel- bis
langfristig Ihr Ziel sein. Da dieses Ziel hufig nicht kurzfristig erreichbar ist, sollten Sie gemeinsam mit dem Kunden machbare Lsungen definieren.

Prfen Sie zunchst, was zurzeit an Messungen und damit an verbindlichen Vereinbarungen berhaupt technisch darstellbar ist, statt im Vorfeld
die Anforderungen des Kunden unstrukturiert einzufordern. Erst dann
sollten Sie konkrete Vereinbarungen mit dem Kunden treffen. Der Prozess
Manager sollte dies gemeinsam mit dem fr den Kunden verantwortlichen
Personenkreis durchfhren. Je nach IT-Organisation kann dies mit dem
Relationship Management, dem Key-Account-Manager oder dem KundenService Manager erfolgen. Oft wird diese Vorprfung mglicher Service
Level gemeinsam mit dem Kundenservicemanager und dem RelationshipManager, der den Kunden strategisch verantwortet, vorgenommen.
Die innerhalb Ihrer IT-Organisation bestehenden Mglichkeiten zur Definition von Service Level und deren Messung sollten Sie dann gemeinsam
Ihrem Kunden erlutern. Es besteht ansonsten die Gefahr, dass der Kunde
einige von Ihnen nicht umsetzbare Anforderungen definiert, was in der
Folge zu (vermeidbarer) Unzufriedenheit und Enttuschung bei Ihrem
Kunden fhren wrde.
Gehen Sie daher mit einem ersten Vorschlag was zurzeit technisch machbar ist auf den Kunden zu. Ist dieser Vorschlag dem Kunden nicht ausreichend, so seien Sie offen fr die Anforderungen Ihres Kunden. Zeigen
Sie dem Kunden aber auch die damit fr ihn ggf. verbundenen finanziellen Auswirkungen auf.
In unserem Beispiel konnte durch die so erfolgte Abstimmung zwischen
notwendigen Anforderungen aus Kundensicht und der technischen
Machbarkeit innerhalb der IT-Organisation ein sinnvoller Kompromiss
gefunden werden.
Bei diesem Abstimmungsprozess muss der Prozess Manager selbstverstndlich ber die notwendige Verantwortung und Kompetenz fr seinen
Prozess verfgen. Er bentigt aber auch die Untersttzung des gesamten
Managements, wie zum Beispiel des Key-Account-Managements.

248

6.4 Kennzahlen
Sie sollten die IT Service Management-Prozesse schrittweise einfhren.
Dies betrifft sowohl die Anzahl der einzufhrenden Prozesse, als auch den
stufenweisen Ausbau (KVP).
Dieses schrittweise Vorgehen bedingt eine Priorisierung der Einfhrung
durch das Management. Ein Aspekt ist dabei der so genannte Pain-Faktor. Gibt es innerhalb Ihrer IT-Organisation in bestimmten Bereichen
besonderen Handlungsdruck, so empfiehlt sich eine Priorisierung derjenigen IT Service Management-Prozesse, die hier Abhilfe schaffen knnen.
Stellen Sie zum Beispiel fest, dass durchgefhrte nderungen hufig zu
Betriebsstrungen gefhrt haben, so sollte der Change Management-Prozess priorisiert eingefhrt werden.
Ein weiterer wichtiger Aspekt fr die Priorisierung von IT Service Management-Prozessen ist das Wissen um die Geschftsstrategie Ihres Kunden.
Sie mssen diese Strategie verstehen, um zu entscheiden, wie Sie ihre Prozessentfaltung vorantreiben, wie Sie die stufenweise Einfhrung und den
Ausbau der IT Service Management-Prozesse planen.
Befindet sich Ihr Unternehmen bzw. Ihr Kunde in einer Wachstumsphase,
so wrde sich die Priorisierung der Planungsprozesse (Service Delivery)
und des Release Managements empfehlen. Denn damit stellen Sie sicher,
dass die notwendigen Kapazitten rechtzeitig bereitgestellt werden knnen und die Geschftsprozesse nicht durch fehlende IT-Kapazitten in
Mitleidenschaft gezogen werden.
Betreibt Ihr Unternehmen dagegen eine Kostendmpfungsstrategie, so
bietet sich eine Konzentration auf das Problem und Change Management
an. Durch das Problem Management identifizieren Sie die Ursachen von
Strungen und knnen die Qualitt der IT Services steigern. Die Anzahl
von Strungen und Geschftsausfllen wird abnehmen und Sie leisten
einen Beitrag zur Kosteneinsparung. Betrachten Sie die Grnde fr ITStrungen, so werden Sie unter Umstnden feststellen, dass die Ursachen
hufig in fehlerhaften nderungen (Changes) liegen. Durch einen Change
Management-Prozess steigern Sie nicht nur die Qualitt, sondern reduzieren Aufwnde fr Folge-Manahmen und tragen so mit dem Change Management zu einer weiteren Kosteneinsparung bei.
So wie die Geschftsstrategie Ihres Kunden in die IT-Strategie einfliet, so beeinflusst die Geschftsstrategie auch die Einfhrungsplanung Ihrer IT Service Management-Prozesse.

Auch wenn Sie ber erste Kennziffern verfgen, sollten Sie ihrem Kunden
keine technischen Kennziffern berichten.

249

Die Strategie
des Kunden
verstehen

6 Lessons learned: Empfehlungen und Ratschlge


Das Reporting der
Kennzahlen
muss kundenorientiert
erfolgen

Grundstzlich besteht Ihre Verantwortung darin, Ihrem Kunden die vereinbarten Service Level zu berichten.
Manchmal bewhrt sich die Maxime, dieses Reporting in einer Sprache
und Darstellung vorzunehmen, die der Kunde versteht, also in der Sprache des Kunden, nicht in der Sprache des Technikers. Statt zum Beispiel
dem Kunden ber die Anzahl von Incidents zu berichten, wird dargestellt,
was fr Folgen die wichtigsten Strungen hatten, welche Konsequenzen
zum Beispiel ein Ausfall einzelner Standorte hatte und welche Verbesserungsmanahmen innerhalb der IT ergriffen wurden, um diese Ausflle in
Zukunft zu vermeiden.
Speziell die Darstellung eingeleiteter Verbesserungsmanahmen ist fr
den Kunden von groer Bedeutung. Der Kunde ist zwar auch an der Historie interessiert, aber viel wichtiger ist ihm, dass die IT Verbesserungsmanahmen ergreift und die Ausflle in Zukunft vermieden werden knnen.
Als signifikanter Report reicht aus, dem Kunden einmal im Monat eine
kleinere Powerpoint-Prsentation zur Verfgung zu stellen, die vor allem
auf die Availability- und Performancekennzahlen eingeht also das, was
der Kunde direkt ber die IT wahrnimmt.
Zum Beispiel knnte der Report folgende Informationen enthalten:
Im Monat Mrz hatten wir am 12.3.2006 eine Strung in der Anwendung
(xyz). Diese Strung wurde hervorgerufen durch einen Netzwerk-Change,
der im Wechsel einer technischen Komponente zu einem Ausfall von 6.00
Uhr 7.30 Uhr fhrte. Um dies zuknftig zu vermeiden, haben wir unseren Servicepartner angewiesen, eine weitere redundante Komponente im
Falle eines Hardwarewechsels vor Ort verfgbar zu haben, um damit
schneller eine Reparatur zu ermglichen.
Berichte zu den geleisteten IT Services und den Kennzahlen aus den IT Service
Management-Prozessen mssen aus der Sicht und in der Sprache des Kunden
erfolgen.

6.4.3

ITIL Refresh oder wie geht es weiter?

Nachdem Sie auf Basis der ITIL Best Practices Ihre IT Service Management-Prozesse gestaltet und eingefhrt haben, bedarf es eines regelmigen Refresh. Dieser Refresh betrifft alle Beteiligten Ihrer IT-Organisation
mit unterschiedlichen Ausprgungen und Inhalten. In diesem Abschnitt
stellen wir die wichtigsten Aspekte gruppiert nach den beteiligten Bereichen vor.

250

6.4 Kennzahlen
Falls Sie eine Zertifizierung Ihrer IT Service Management-Prozesse durchfhren, wird von der Zertifizierungsorganisation auch geprft, ob eine
Aus- und Weiterbildungsplanung existiert und mgliche Defizite werden
aufgezeigt.
Das Top-Management, der Service Manager, die Prozess Owner und die
Prozess Manager sollen beobachten, wie sich die Umsetzung der ITIL Best
Practices im Unternehmen weiterentwickelt. Hierbei ist auch relevant, wie
sich vergleichbare andere IT-Organisationen weiter entwickeln und wie
sich diese Weiterentwicklung in Bezug auf Ihre Organisation darstellt.

Das Management hat die


Weiterentwicklung zur
Aufgabe

Die dokumentierten ITIL Best Practices unterliegen zwar einer stetigen


Weiterentwicklung, aber diese geht erst mit einem Zeitverzug in die offiziellen Publikationen ein. Auf Kongressen, wie dem ITIL Forum oder dem
Jahreskongress der itSMF Deutschland e.V., wird aktuell ber Erfahrungen mit der Umsetzung der ITIL Best Practices und ber in Unternehmen
vollzogene Ausgestaltungen und Erweiterungen berichtet.
Auf diesen Kongressen knnen Sie nicht nur aufnehmen, wo Ihre ITOrganisation in Bezug auf andere IT-Organisationen steht. Sie knnen
Ideen aufnehmen und prfen, ob diese Ideen auch fr Ihre IT-Organisation eine Innovation darstellen und einen Mehrwert generieren knnen.
Insbesondere fr den Service Manager, den Prozess Owner und den Prozess Manager stellt dieser Informationsprozess eine wichtige Aufgabe dar.
Es ist sehr wichtig, dass Sie sich mit den erreichten Manahmen nicht zufrieden
geben. Sie mssen die Weiterentwicklung von ITIL und von anderen ITOrganisationen beobachten, andere Anstze prfen und mehrwertschaffendeKonzepte adaptieren.

In der Ebene der Mitarbeiter ist es von groer Bedeutung, dass neue Mitarbeiter ber ITIL Know-how verfgen bzw. entsprechend geschult werden.
Diese Schulung sollte in drei Teilen erfolgen:
Die Mitarbeiter bentigen zunchst einen Gesamtberblick ber die
Ziele des IT Service Managements sowie aller Prozesse. Ansonsten
werden die Mitarbeiter den Nutzen von ITIL nicht verstehen. Es
empfiehlt sich diese Schulungen extern wahrnehmen zu lassen. Gegebenenfalls knnte dies auch von einem Service Manager mit entsprechender Schulungserfahrung bernommen werden.
Sind die theoretischen Aspekte bekannt, so sollten die Prozess Manager die Mitarbeiter in denjenigen Prozessen schulen, in denen
diese eingebunden sind. Hierbei wird insbesondere geschult, wie
die jeweiligen Prozesse innerhalb der jeweiligen Organisation des
Unternehmens ihre Anwendung finden (von der Theorie zur Praxis).

251

Mitarbeiter
mssen geschult werden

6 Lessons learned: Empfehlungen und Ratschlge


Sind die IT Service Management-Prozesse auf Basis der ITIL Best
Practices eingefhrt, so ist unbedingt darauf zu achten, dass es regelmige Nachschulungen fr die geschulten Mitarbeiter gibt
(Wissen erhalten und erweitern) und neue Mitarbeiter ebenfalls die
Stufen des aufgesetzten ITIL Schulungsprozesses durchlaufen.
Ein erfolgreiches IT Service Management bedingt, dass Ihre Mitarbeiter die Prozesse kennen und verstehen. Sie mssen sicherstellen, dass dieses Verstndnis
auch bei neuen Mitarbeitern ausreichend gegeben ist.

Sie werden wahrscheinlich feststellen mssen, dass die Prozesse nach der
Implementierung und lngerem Betrieb auf Mitarbeiter-Ebene einschlafen. Der bei der Einfhrung vorhandene Elan geht im Laufe der Zeit verloren. Die Aktivitten erstarren in Routine. Dem Prozess Manager kommt
hier eine weitere wichtige Aufgabe zu.
Der Prozess
Manager sorgt
dafr, dass
Prozesse
gelebt werden

Der Prozess Manager muss Manahmen entwickeln, die ein Einschleifen


der Prozesse verhindern. Hierzu knnen bestimmte Prozesse, wie das
Change Management, angepasst werden.
Der Prozess Manager muss einen Prozess aktiv halten und das Einschlafen verhindern. Besondere Aufmerksamkeit bentigen bereits lnger eingefhrte Prozesse.

Zerschlagen Sie nicht unntig erfolgreiche Prozesse. Drcken Sie vielmehr


ihre Wertschtzung aus und motivieren Sie ihre Mitarbeiter, diese Prozesse in Richtung der ITIL Best Practices weiter zu entwickeln. Nutzen Sie
so die vorhandene Erfahrung.
Stellen Sie sicher, dass die Prozesse innerhalb der Phasen gleichmig
entwickelt werden (vertikale gleichmige Entfaltung) und dass sie vernetzt werden. Vermeiden Sie ein unkontrolliertes Davoneilen einzelner
Prozesse. Diese Entwicklungen zu kontrollieren und zu steuern ist Aufgabe des Service Managers.
Zeigen Sie die Erfolge der eingefhrten Prozesse unbedingt auf. Lassen Sie
Ihre Mitarbeiter die erzielten Verbesserungen im tglichen Betrieb spren.
Damit erhalten und steigern Sie die Motivation. Um dies mglich zu machen, sollten Sie Ruhe- und Stabilittsphasen in der Entwicklung der Prozesse einplanen. Ansonsten knnen in einem permanenten Vernderungsprozess die Erfolge nicht mehr sprbar gemacht werden.
Darber hinaus frdert das Aufzeigen von Erfolgen in einem Prozess den
Wettbewerb unter den Prozess Managern.
Der Service Manager bentigt ein System zur Messung und Verfolgung
der Prozess-Fortschritte. Im Beispiel hat sich hierzu ein Ampelsystem be-

252

6.4 Kennzahlen
whrt. Damit werden auch fr die Prozess Manager die erzielten Erfolge
sichtbar.
Die IT Service Management-Prozesse haben eine eindeutige Ausrichtung
auf die Geschftsprozesse Ihres Kunden und mssen daher Bestandteil
Ihrer IT-Strategie sein.
Diese Anforderung bedeutet nicht nur, dass die IT Service ManagementProzesse aufgrund Ihrer IT-Strategie eingefhrt werden, sondern auch,
dass sich deren Ziele stets aus der IT-Strategie ableiten.
Logische Konsequenz hieraus ist, dass sich auch die Kennzahlen und deren Soll-Werte aus der IT-Strategie ergeben.
Um alle Bereiche auf die IT-Strategie auszurichten, sollten sie anfnglich
eine einfache Balanced Scorecard (BSC) nutzen. Dazu werden aus den
bergeordneten strategischen Betrachtungen konkrete Manahmen 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 Verknpfung der Balanced
Scorecard mit den Kennzahlen der jeweiligen IT Service ManagementProzesse etablieren Sie ein durchgngiges Controlling-System.
Vermeiden Sie den Aufbau eines zweiten, isolierten Kennzahlensystems fr Ihre
IT Service Management-Prozesse.

Service Manager, Prozess Manager und Prozess Owner


In den vorhergehenden Kapiteln wurde bereits auf die Rolle des Service
Managers, des Prozess Managers und des Prozess Owners eingegangen.
An dieser Stelle sei angemerkt, dass die Aufgabenzuordnungen zu den
Rollen des Prozess Owners und des Prozess Managers von den Rollenbeschreibungen in der Literatur abweichen knnen.
Oft knnen Prozess Owner und Prozess Manager organisatorisch ber
Kreuz besetzt werden dass heit, der Prozess Owner kommt aus einem
anderen Bereich als der Prozess Manager und so kann die Vernetzung
innerhalb der IT-Organisation gestrkt werden. Bestehende Abteilungsgrenzen knnen erfolgreich berbrckt werden. Voraussetzung hierfr ist
die Strkung der Rolle des Prozess Managers, ansonsten dominiert der
Prozess Owner allein aufgrund der hierarchischen Stellung den Prozess
Manager.

253

Die Balanced
Scorecard ermglicht die
Ausrichtung
auf die ITStrategie

6 Lessons learned: Empfehlungen und Ratschlge

Service Manager
In den ITIL Best Practices finden sich zwar an einigen Stellen Hinweise
zum Service Manager, aber eine durchgngige Beschreibung dieser Rolle
ist in ITIL nicht zu finden. Dabei ist diese Rolle fr ein IT Service Management von existenzieller Bedeutung und damit auch die organisatorische
Verankerung dieser Rolle.
Die IT Service Management-Prozesse sollen sicherstellen, dass die IT Services auf die Geschftsprozesse des Kunden ausgerichtet sind und deren
Anforderungen optimal untersttzen. Daher bieten sich zwei Bereiche an,
denen die Rolle des Service Manager organisatorisch zugeordnet werden
kann.
Zunchst wre die Kundenschnittstelle der IT-Organisation zu nennen.
Damit wird sichergestellt, dass die geforderte Ausrichtung der IT Service
Management-Prozesse auf die Kundenanforderungen gewhrleistet ist.
Alternativ bietet sich eine Stabstelle zur IT-Geschftsfhrung an. Hierfr
sprechen die dann kurzen Wege zur Geschftsfhrung und die enge Verknpfung mit der IT-Strategie.
Sie mssen fr Ihre IT-Organisation entscheiden, welche Zuordnung fr
Ihren Bereich zweckmig ist.
Der Service Manager muss unbedingt ber eine langjhrige Erfahrung im
Bereich des IT Service Managements und mit dem Management von ITOrganisationen verfgen.
Hufig ist der Service Manager im Bereich der Kundenschnittstelle angesiedelt und stimmt seine Planungen und Manahmen mit dem Board der
Prozess Owner ab.

Prozess Manager
Der Prozess Manager sollte aus der Linienfunktion besetzt werden, in der
wesentliche Prozessaktivitten durchgefhrt werden.
Der Prozess Manager sollte weiterhin in der Linienorganisation angesiedelt bleiben und nicht herausgelst 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 erfhrt, 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 verfgt.

254

6.4 Kennzahlen

Prozess Owner
Innerhalb des RZs hat es sich als vorteilhaft erwiesen, die Rolle des Prozess Owners rotieren zu lassen. Durch die wechselnden Prozess Owner
wird der Blickwinkel des Prozess Managers im Laufe der Zeit erweitert.
Wenn mglich, wird die Rolle des Prozess Owners aus dem Bereich besetzt, der die grten Auswirkungen des Prozesses erfhrt. So kommt zum
Beispiel der Prozess Owner fr das Change Management nicht aus der
Produktion, sondern aus dem Kunden-Management, da dort die Auswirkungen der Changes unmittelbar zu spren sind.
Die Prozess Owner werden aus einer Hierarchieebene besetzt, die gegenber der IT-Organisation weisungsbefugt ist. Innerhalb des Rechenzentrums unseres Beispiels sind die Prozess Owner Bereichs- und Abteilungsleiter, die direkt der Geschftsfhrung berichten.

IT im Wandel und wie untersttzt ITIL


Ein stndiger Abgleich Ihrer IT Service Management-Prozesse mit der
Business- und der IT-Strategie ist unumgnglich.
Sie mssen diese Strategien nicht nur whrend der Einfhrung bercksichtigen, sondern auch whrend der gesamten Prozessphase.
Wurden die IT Service Management-Prozesse beispielsweise whrend
einer Wachstumsphase eingefhrt, drfte die spezifische Ausrichtung des
Capacity Managements darin bestehen, zuknftige Erweiterungen der ITInfrastruktur rechtzeitig einzuplanen, um das Wachstum der Organisation
zu untersttzen. In einer Schrumpfungsphase wird das Hauptaugenmerk
des Prozess Managers Capacity Management dagegen auf einer mglichst
groen Auslastung bestehender Systeme bzw. auf der Reduzierung bestehender Systeme liegen, um so die notwendige Kostenreduzierung sicherzustellen.
Die grundstzlichen 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 Aktivitten sind Empfehlungen, die Sie in Ihre IT-Organisation sinnvoll bertragen mssen. Damit
sind diese Aktivitten aber nicht fr alle Zukunft festgeschrieben. Mit
einer vernderten Business- und IT-Strategie knnen sich die Schwerpunkte und damit die Aktivitten innerhalb der IT Service ManagementProzesse ndern. Ihre IT Service Management-Prozesse unterliegen damit
einem stetigen Wandel.
Beispiel: Hat ein Change Manager eine Vorlaufzeit von fnf Tagen fr den
RFC festgelegt, so muss dieser Ansatz unter Umstnden modifiziert wer-

255

6 Lessons learned: Empfehlungen und Ratschlge


den, wenn sich die Organisation in einer sehr starken Wachstumsphase
befindet.
Logische Konsequenz ist, dass die Business- und IT-Strategie einen Input
fr den kontinuierlichen Verbesserungsprozess der IT Service Management-Prozesse sind.
Der Prozess Owner ist die Person, die diesen Input sicherstellt. Der Prozess Owner erfhrt aufgrund seiner hierarchischen Stellung frhzeitig von
Vernderungen in der Business- oder IT-Strategie. Er muss als Coach unter
Einbeziehung des Service Managers den Prozess Manager auf die vernderten Rahmenbedingungen aufmerksam machen. Aufgabe des Prozess
Managers ist es dann, notwendige Manahmen abzuleiten, sie mit dem
Prozess Owner und dem Service Manager abzustimmen und schlielich
im Prozess umzusetzen.
Fr die organisatorische Einbindung der IT Service Management-Prozesse
ist die Besetzung des Prozess Managers von groer Bedeutung. Der Prozess Manager sollte aus der Linien-Organisation stammen und auch dort
verbleiben. Als Bereich ist die Organisationseinheit zu whlen, in der die
wesentlichen Aktivitten des Prozesses stattfinden.
Das berkreuzen von Prozess Manager und Prozess Owner hat sich sehr
bewhrt. Dadurch konnte unter anderem eine bessere Vernetzung in der
IT-Organisation erzielt werden. Ein wichtiger Nebeneffekt ist, dass der
Prozess nicht durch Bereichsdenken geprgt wird. Diese Gefahr besteht,
wenn Prozess Owner und Prozess Manager aus dem gleichen Bereich
kommen. Die Rotation der Prozess Owner erweitert den Horizont der
Prozess Manager. Sehr oft kommt dem Prozess Owner die Rolle eines Coaches zu.

256

7 Praxisbeispiel: ALTANA Pharma AG


IT Service Management im regulierten Umfeld
am Beispiel der ALTANA Pharma AG

Dr. Jan Hadenfeld


IT Change und Configuration Manager
ALTANA Pharma AG, ein Unternehmen der Nycomed Gruppe
www.nycomed.com

Firmenportrait
Nycomed ist ein internationales pharmazeutisches Unternehmen, das
Arzneimittel fr Krankenhuser, Fachrzte und Allgemeinmediziner anbietet. Darber hinaus versorgt das Unternehmen Patienten in ausgewhlten Mrkten mit OTC-Medikamenten.
Nycomed arbeitet in einer Reihe von Therapiegebieten wie Kardiologie,
Gastroenterologie, Osteoporose, Atemwegserkrankungen, Schmerztherapie und Gewebemanagement. Neue Produkte entstehen sowohl in der
eigenen Forschung als auch in der Zusammenarbeit mit externen Partnern.
Nycomed ist in etwa 50 Mrkten weltweit prsent und engagiert sich in
ganz Europa sowie in wachstumsstarken Mrkten wie Lateinamerika,
Russland/GUS und der asiatisch-pazifischen Region.
Der im Privatbesitz befindliche Konzern verzeichnete 2006 einen Jahresumsatz von ca. 3,4 Milliarden sowie ein bereinigtes EBITDA von 933,4
Millionen .
Weitere Informationen finden Sie unter www.nycomed.com

Ausgangslage
Die IT der ALTANA Pharma hatte sich 2004 das Ziel gesetzt, sich vom IT
Service Provider zum innovativen Business Enabler zu wandeln. Um dieses Ziel zu untersttzen und die angebotenen Services und Lsungen an
den sich ndernden Geschftsanforderungen und der globalen IT-Strategie
des Unternehmens auszurichten, wurde das Betriebsmodell der IT an IS
Lite von Gartner ausgerichtet.

257

7 Praxisbeispiel: ALTANA Pharma AG


Gartner hat 1999 folgende vier Trends ausgemacht, die zu signifikanten
nderungen in der IT fhren 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 Verfgung, um die unterschiedlichen Geschftsanforderungen beherrschen zu knnen.
Bei ALTANA Pharma waren hierzu strukturelle nderungen in der ITOrganisation notwendig. Es wurde unter anderem das Global CIO Office
aufgebaut und Abteilungen wie Project Management, Business Process
Management, Architektur, Account Management und IT Service & Vendor
Management dort etabliert.

IT Service Management im regulierten Umfeld


Sauber definierte IT Service-Prozesse stellen einen professionellen ITBetrieb sicher. Ein professionelles Vendor Management ist Voraussetzung
fr eine erfolgreiche Beschaffung von IT Services, intern wie extern.
Die Zielsetzungen des IT Service Management bei ALTANA Pharma,
Einfhrung einheitlicher, standardisierter IT Serviceprozesse, um
die Qualitt und Quantitt der IT Services fr den Kunden zu
steuern, zu berwachen und sicherzustellen, sowie die
Ausrichtung der IT Services auf die Bedrfnisse der Kunden in den
Fachbereichen und Standorten,
haben ausdrcklich den Kunden und seine Zufriedenheit mit den erbrachten Dienstleistungen im Focus. Die Anforderungen der Kunden an einen
IT Service sind oft zustzlich durch Compliance-Vorgaben beschrieben.
In dem sehr stark regulierten Bereich der Pharmaindustrie gibt es nationale und internationale Vorgaben, an die sich auch die ALTANA Pharma
halten muss. Dazu zhlen die Good x Practices (GxP) (x steht fr Laboratory,
Clinical oder Manufacturing), die 1978 von der amerikanischen Gesundheitsbehrde FDA (Food and Drug Administration) aufgestellt wurden,
um die Sicherheit und Produktqualitt von Medikamenten sicher zu stellen. Auch der Sarbanes-Oxley Act (SOX) mit seiner Sektion 404 stellt seit
2002 an die IT der ALTANA Pharma hohe Anforderungen, die von an USBrsen notierten Firmen erfllt werden mssen.

258

7 Praxisbeispiel: ALTANA Pharma AG


Hier haben sich sogenannte Best Practices wie
Good Automated Manufacturing Practice (GAMP)
Control objectives for information and related technology (CobiT)
IT Infrastructure Library (ITIL)
bewhrt, um die IT bei der Erfllung der genannten regulatorischen Vorgaben zu untersttzen. Auch wenn diese drei einen unterschiedlichen
Focus haben, so sind doch viele Basisaktivitten gleich.
Um das IT Service & Vendor Management der ALTANA Pharma zu optimieren wurde das Projekt SMILE (Service Management ImpLEmentation)
2004 initiiert. Im Vordergrund stand dabei die Ausrichtung der IT-Prozesse nach ITIL. Damit verbunden war die Optimierung und Stabilisierung
bestehender Prozesse, auch um grere Transparenz zu schaffen und eine
Grundlage fr die Messung von Kennzahlen zu ermglichen.
Das Projekt hatte Initial den Fokus auf die IT Service Support Prozesse
und verfolgte die folgende Zielsetzung:
Erstellung eines ALTANA Pharma spezifischen Konzepts zum IT
Service Management nach ITIL (bzgl. der betrachteten Disziplinen)
Aufbau eines Account Managements fr interne Kunden der IT
Aufbau eines Service Level Management-Prozesses, insbesondere
Einfhrung eines Leistungs- und Service Katalogs
berarbeitung der Incident- und Problem Management-Prozesse sowie deren inhaltliche Trennung
Finetuning des Change Management-Prozesses sowie die Erstellung
der Grobstruktur fr eine Konfigurationsdatenbank
Definition eines Release Management-Prozesses
Die Einfhrung der Prozesse nach ITIL wurde untersttzt, indem nahezu
alle IT-Mitarbeiter und weitere wichtige Ansprechpartner aus den Fachbereichen von der Firma KESS DV-Beratung GmbH in ITIL geschult worden
sind und erfolgreich mit dem Foundation Certificate in IT Service Management abschlossen. Neben dem Verstndnis fr die ITIL-Prozesse wurde so
auch ein einheitlicher Sprachgebrauch gefrdert.
Um eine sptere Akzeptanz der Prozesse zu erzielen, wurden fr jeden
Prozess mit abteilungsbergreifenden Teams Workshops veranstaltet. Die
Ergebnisse wurden, wie in einem Pharma-Unternehmen blich, in
Standard Operating Procedures (SOPs) festgehalten. Diese SOPs dienen auch
als Schulungsunterlagen.
Logische Konsequenz dieser Vorbereitungen war die Untersttzung der IT
Service Management-Prozesse mit einem integrierten System, auch um
Messungen der Prozessperformance zu ermglichen. Bis auf das Incident

259

7 Praxisbeispiel: ALTANA Pharma AG


Management war dies durch die teilweise papierbasierende Vorgehensweise nicht oder nur schlecht mglich.
Das Folgeprojekt eSmile wurde initiiert.

eSmile: Einfhrung einer integrierten Systemuntersttzung


Die Zielsetzung des Projektes eSmile lsst sich in den folgenden Punkten
zusammenfassen:
Integration aller betrachteten IT Service Management-Prozesse
Durchgngiger Informationsfluss und Transparenz
Etablierung der Configuration Management Database (CMDB) als
zentrale Datenbank fr 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 fr 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-Vertrgen wurde diese System-Vorgabe deswegen mit in die
Angebotsaufforderungen aufgenommen. Dadurch wird auch sichergestellt,
dass die Verantwortung fr das Prozess-Management im Hause liegt und
durch eine gemeinsame Datenbasis die Prozess-Verantwortlichen ohne
Medienbrche Informationen und Kennzahlen ber den gesamten Prozess
erhalten.
Das System wurde nach dem V-Modell validiert eingefhrt. Das V-Modell
ist eine im Pharma-Umfeld gngige Vorgehensweise. Es beschreibt Aktivitten und Ergebnisse, die bei der Einfhrung von IT Systemen durchzufhren bzw. zu erzielen sind, und Bereiche wie Anforderungen, Umsetzung und Tests zur Qualittssicherung beinhaltet. Validierung eines computergesttzten Systems ist der dokumentierte Nachweis, dass das System
den GxP-Anforderungen gengt und so arbeitet und in Zukunft arbeiten
wird, wie es dies laut Spezifikationen soll.
Nach der Validierungsfreigabe im April 2006 wurde die Produktivschaltung des Systems zweiphasig umgesetzt. In der ersten Phase kamen die
Prozesse Problem, Change und Configuration Management zum Einsatz.
Hier hat man sich erhofft, durch die Ablsung 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 besttigt, da trotz der Verdoppelung der eingegangenen RfCs die Bearbeitung im Change Management
handhabbar geblieben ist.

260

7 Praxisbeispiel: ALTANA Pharma AG


In der zweiten Phase wurde kurz darauf das Incident Management mit
dem Service Level Management aktiviert. Nach einer Eingewhnungsphase kamen dann schnell die notwendigen Daten zustande, um ein aussagekrftiges Management Reporting zu beginnen und mit Kennzahlen die
untersttzten Prozesse zu bewerten.

Ansatz fr Kennzahlen und KPIs


In der IT der ALTANA Pharma haben sich mit der Einfhrung der IT
Service Management-Prozesse auch unterschiedliche Gremien etabliert. In
diesen Gremien werden Kennzahlen zur Steuerung bentigt. Hierzu zhlt
das Incident-, Problem- und Change-Meeting (IPC-Meeting), das die Prozesse mit den internen Support-Einheiten bespricht. Es dient einer Verbesserung der Organisation der IPC-Bearbeitung (Organisatorisches Meeting,
keine Diskussionsplattform), der Vermittlung des Status Quo an die Teamleiter, Ableitung von erforderlichen Manahmen sowie Nachverfolgung
der beschlossenen Manahmen.
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 berprfen, aber
auch, um Probleme zu identifizieren und gemeinsam Verbesserungen zu
erarbeiten.
Die Kennzahlen werden je nach Anforderung wchentlich, 14-tgig und
monatlich erhoben und zur Verfgung gestellt.

Incident Management
Im Incident Management beziehen sich die erstellten Berichte berwiegend auf die mit dem externen Service Provider vereinbarten Service Level.
Hauptaugenmerk wird auf den dorthin vergebenen Service Desk gelegt.
Neben allgemeinen mengenorientierten Kennzahlen werden die folgenden
berichtet:

Erreichbarkeit
Longest Wait Call
Wartezeit
Direktlsungsrate
Lsungsrate
Erfllungsgrad Weiterleitung
Reset / Aktivierung von Passwrtern
Account Administration

Dabei werden die Erreichbarkeit, Wartezeit und Longest Wait Call durch
Auswertungen der Telefonanlage berechnet, alle anderen auf Basis des IT
Service Management Systems eSmile. Durch eine direkte Datenbankanbin-

261

7 Praxisbeispiel: ALTANA Pharma AG


dung werden die monatlichen Reporte teilweise auch automatisiert
erzeugt.

Change Management
Aus den genannten Gremien heraus wurden immer wieder Informationen
ber den Change Management-Prozess bentigt. Die Kennzahlen wurden
meistens nach der Bottom-up Methode erstellt, dort wo der Schuh am
meisten drckte. Dies sind mengenorientierte Kennzahlen wie
Anzahl RfCs pro Kalenderwoche / Monat (siehe Abbildung 68) /
Jahr / Workgroup / Priorisierung / Service
32
28
24

# of RfCs

20
16
12
8
4

07

20
ai
M

pr
il

20

20
0

07

7
M

r2

Fe

br

ua

ar
nu
Ja

be
em
D

ez

00

07
20

00
r2

r2
em

ov
N

6
00

06
be

er
kt
ob
O

be
S

ep

te

ug
A

20

00

r2

00

6
us

li
2

t2

00

6
ni
Ju

Ju

20
0

06
20
ai
M

Abbildung 68:

Anzahl der RfCs pro Monat (Demo-Daten)

um eine Auslastung der Supporteinheiten darzustellen, aber auch


Kennzahlen, welche die Prozessqualitt beschreiben knnen wie
Status aller RfCs (siehe Abbildung 69) pro Workgroup / Priorisierung / Service
Durchlaufzeiten der einzelnen Phasen (Initiierung, Prfung, Genehmigung, Test, Implementierung, Abschluss)
Anzahl RfCs ohne Planungsdatum / ohne CIs / mit mehrmaligem
Routing
Anzahl nicht implementierter RfCs, bei dem das vorgegeben Datum
des nderungsanforderers berschritten ist
Anzahl RfCs mit verknpften Incidents oder Problems

262

7 Praxisbeispiel: ALTANA Pharma AG


Rejected

New
Assessed
Authorized
Developm ent Com pleted
Release to Production
Technically Completed
User Acceptance

New
4
2,2%
Ass ess ed
1
0,6%
Authorized
6
3,3%
Developm ent C om pleted
1
0,6%
Releas e to Production
6
3,3%
Tec hnic ally Com pleted
3
1,7%
Us er Ac ceptanc e
3
1,7%
Finished
132 72,9%
Rejected
25 13,8%
Summ e:
181 100,0%

Finished

Abbildung 69:

Status aller RfCs (Demo-Daten)

Eine Darstellung fr die Qualitt der erbrachten Leistungen durch einen


Change wird durch die
Auswertung des Post Implementation Review (PIR)
ermglicht, in dem neben der technischen Umsetzung auch die Zufriedenheit des Kunden abgefragt wird.
Ein auch in der ITIL-Literatur beschriebenes Thema ist der Audit. hnlich
werden Systeme und Verfahren auch im GxP- und SOX-Umfeld auditiert.
Hier ist als Kennzahl die
Anzahl und Reduzierung der Findings pro Kategorie (Critical,
Major, Minor)
wichtig.

Ausblick
Whrend der Erarbeitung der fr ALTANA Pharma angepassten IT
Service Management-Prozesse nach ITIL wurden fr jeden Prozess auch
die Prozessziele angegeben. Durch den Change Management-Prozess wird
beispielsweise sichergestellt, dass alle nderungen an den IT-Systemen
notwendig, begrndet und getestet sind,
dokumentiert sind,
hinsichtlich Abhngigkeiten der betroffenen Schnittstellen berprft
sind,
auf Basis einer nachvollziehbaren Ressourcenplanung durchgefhrt
werden,
eine transparente Darstellung von Kosten zu Nutzen haben und
gegenber den Anwendern, der Hotline und anderen betroffenen
Funktionen kommuniziert werden.

263

7 Praxisbeispiel: ALTANA Pharma AG


Durch die Etablierung des Change Management-Verfahrens wird den
Validierungsanforderungen bezglich der nderungskontrolle nachgekommen.
Ein nchster 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) strker betrachtet werden, da dies ein wichtiges Instrument
ist, um eine Planungssicherheit zu haben und frhzeitig ber nderungen
informieren zu knnen.

264

8 Praxisbeispiel: Autobahn Tank & Rast GmbH

IT Kennzahlensystem der
Autobahn Tank & Rast GmbH

Gerhard Gttert
Leiter Technologie- und Innovationsmanagement
Autobahn Tank & Rast GmbH
www.tank.rast.de

Dienstleister Nr. 1 auf deutschen Autobahnen


Die Autobahn Tank & Rast ist der fhrende Anbieter von Services und
Dienstleistungen entlang der Autobahn in Deutschland: Rund 500 Millionen Gste besuchen jedes Jahr die Servicebetriebe der Tank & Rast. Mit
seinen Pchtern betreibt das Unternehmen rund 340 Tankstellen und rund
370 Raststtten (einschlielich ca. 50 Hotels). Durchschnittlich alle 60 Autobahnkilometer finden Kunden eine Tank- und Raststtte des Unternehmens.

Autobahn Tank & Rast: Auftanken und Abschalten


1998 hervorgegangen aus einer bundeseigenen Gesellschaft, hat sich das
Unternehmen mit seinen rund 720 Servicebetrieben zu einem Dienstleister
entwickelt, der in Kundenbefragungen ein Hchstma an Anerkennung
geniet. Tankstellen, Raststtten und zahlreiche Shops stehen den Autobahn-Reisenden sieben Tage die Woche rund um die Uhr zur Verfgung.
Bestnoten vor allem in der Wertung Gastronomie und Service in europaweit durchgefhrten Tests des ADAC besttigen immer wieder die Leistungen der Tank & Rast.

Grnde fr die Entwicklung eines IT Kennzahlensystems


Die Entwicklung der T&R wird von einer Vielzahl technologischer Projekte begleitet. Wesentlichen Einfluss auf den Projekterfolg haben dabei
die bentigten IT-Services. Die Herausforderungen fr das IT-Management sind, die verfgbaren Ressourcen und Mittel effektiv und effizient
einzusetzen. Dabei stehen Flexibilitt, Innovationsstrke und Wirtschaft-

265

8 Praxisbeispiel: Autobahn Tank & Rast GmbH


lichkeit im Focus der mittel- und langfristigen Ziele. Um dies zu gewhrleisten wurde ein IT-Kennzahlensystem entwickelt, dass die Steuerung des IT-Bereichs nach den genannten Kriterien ermglicht und gleichzeitig eine hohe Transparenz der Prozesse und der Leistungsfhigkeit
sicherstellt.

Entwicklung eines eigenen IT Kennzahlensystems


Die Entwicklung eines IT-Kennzahlensystems ist ein nicht unerhebliches
Unterfangen. Dies war dem IT-Management bereits zum Start des Projekts
bewusst.
Neben der Nutzung des Kennzahlensystems als strategisches Instrument
zur Steuerung und Entwicklung des IT-Bereichs, verfolgt das IT-Management auch den Ansatz, das Kennzahlensystem, zumindest teilweise, zur
operativen Steuerung des IT-Bereichs zu nutzen.
Um grtmglichen Nutzen zu gewhrleisten muss jedes IT-Kennzahlensystem auf die individuellen Anforderungen eines Unternehmens abgestimmt sein. Es ist deshalb nicht sinnvoll, Kennzahlensysteme wie z. B. das
Diebold- oder das Brogli-Kennzahlensystem einfach eins zu eins in das
Reporting eines Unternehmens zu bernehmen.
In Zusammenarbeit mit der Victor GmbH, Bonn, hat Tank & Rast deshalb
ein Kennzahlenkonzept entwickelt, dass explizit auf die Anforderungen
des Unternehmens abgestimmt ist. Dieses Konzept wurde im weiteren
Verlauf des Projekts gemeinsam mit der Victor GmbH erfolgreich umgesetzt und implementiert.
Die Umsetzung des Projekts erfolgte in folgenden Schritten:
Im ersten Step wurden Interviews mit IT-Mitarbeitern aus ausgewhlten IT-Serviceeinheiten gefhrt. In diesem Kreis erfolgte eine
Bestandsaufnahme der vorhandenen IT-Kennzahlen und die Relevanz der einzelnen Kennzahlen fr die jeweiligen IT-Serviceeinheiten wurde diskutiert. Dabei stellte die Victor GmbH Kennzahlen aus
verschiedenen Kennzahlensystemen, teilweise aus den klassischen
aber auch aus neueren Systemen (COBIT) zur Diskussion.
Im weiteren Verlauf erfolgten zwei Interviews mit der IT-Leitung.
Ziel war die finale Festlegung des zuvor erarbeiteten IT Kennzahlen-Pools. Es wurde fr jede Kennzahl geprft, welchen Mehrwert
sie isoliert oder im Verbund weiterer Dimensionen aufweist, fr
wen sie bestimmt ist, wer fr sie verantwortlich ist und wie und wie
oft sie gemessen wird. Zur Sicherstellung des strategischen Ziels des
neuen Kennzahlensystems, wurde bereits zu diesem Zeitpunkt der
Controlling-Bereich der Tank & Rast in das Projekt eingebunden.

266

8 Praxisbeispiel: Autobahn Tank & Rast GmbH


Das Ergebnis war eine Tabelle mit ca. 35 Kennzahlen, die fr die IT
der Tank & Rast strategisch und operativ relevant sind.

Strukturierung der Kennzahlen anhand der Balanced Scorecard


Tank & Rast verfolgte bereits zu Begin des Projekts das Ziel, eine IT Balanced Scorecard zur Steuerung der IT einzusetzen. Eine Herausforderung
bestand darin, festzulegen, welche Perspektiven diese BSC haben sollte.
Die operative und strategische Nutzung des IT-Kennzahlensystems setzt
eine vernnftige Clusterung in valide und zuverlssige Dimensionen des
Systems voraus. Diese mssen mit einer sinnvollen Anzahl von Kennzahlen ausgebildet sein.
Fr das Kennzahlensystem der Tank & Rast wurden folgende Dimensionen auf der obersten Ebene erarbeitet:

Finanzdimension
Kundendimension
Technologie-/Innovationsdimension und die
Mitarbeiterdimension.

Jede der Dimensionen beinhaltet 4 bis 6 Kennzahlen.

Erfahrungen und Ratschlge


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 frhe
Einbindung des Unternehmenscontrollings hat sich als sehr sinnvoll und
zielfhrend herausgestellt. Durch die Mitarbeit fand eine Sensibilisierung
der Mitarbeiter des Controllings fr die IT-Besonderheiten statt. Zudem
konnten die Projektbeteiligten beim Aufbau des strategischen Berichtswesens umfassend vom Know-how der Controlling-Mitarbeiter partizipieren.
Die fachliche Untersttzung durch die Victor GmbH hat dazu gefhrt, das
Projekt in kurzer Zeit umzusetzen. Die Auswahl der fr Tank & Rast sinnvollen Kennzahlen aus den vielen mglichen Werten der bekannten Kennzahlensysteme war eine der wesentlichen Aufgaben der Victor GmbH.
Dabei bildeten international anerkannte Kennzahlensysteme die Basis des
Auswahlprozesses. Zustzlich wurde Tank & Rast durch Victor GmbH bei
der Einbindung der neuen IT-BSC in die bereits vorhandenen ITILProzesse, insbesondere den Prozess des Service-Level-Managements, untersttzt.
Das IT Kennzahlensystem liefert heute verlssliche und zeitnahe Daten.
Neben der effizienten Steuerung der IT mit der IT-BSC wurde die Basis
geschaffen, die strategische Entwicklung des IT-Bereichs transparent darzustellen.

267

9 Praxisbeispiel: Flughafen Mnchen


Service Management des
Flughafens Mnchen

Michael Zaddach
Leiter Servicebereich IT
Flughafen Mnchen GmbH
www.munich-airport.de

Zum Autor
Michael Zaddach ist Leiter des Servicebereichs IT bei der Flughafen Mnchen GmbH.
In seinen Verantwortungsbereich fallen die Servicefelder Projekte und
Entwicklung, sowie Betrieb & Service und Field-Services fr alle IT- und
Kommunikationssysteme am Flughafen. Nach dem Abschluss des Studiums der Nachrichtentechnik war M. Zaddach bei Siemens, AEG und debis
Systemhaus in verschiedenen Funktionen wie zum Beispiel Systementwicklung, Product-Line-Management, Projektmanagement und Consulting ttig. Bei debis Systemhaus leitete er von 1997 2000 eine Business
Unit fr 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 Mnchen.

Firmenportrait
Am 22. Dezember 2006 hat der Flughafen Mnchen den 30-millionsten
Passagier des Jahres 2006 begrt und damit den Grundstein fr eine dauerhafte Prsenz Mnchens unter den groen Luftverkehrsdrehscheiben
Europas gelegt. Die Planung fr das Jahr 2007 ist ebenso ambitioniert und
geht von 32,5 Mio. Passagieren aus.
Die Erfolgsstory des Mnchner Flughafens, die den letzten Hhepunkt im
Jahr 2003 mit der Erffnung des neuen Terminal 2 hatte, geht damit in die
nchste Runde. Die Planer arbeiten bereits wieder an neuen Infrastrukturprojekten und reagieren damit auf die weiterhin berproportionalen Steigerungsraten bei Passagieren, Flugbewegungen und beim Frachtaufkom-

269

9 Praxisbeispiel: Flughafen Mnchen


men. Im Jahr 2007 beginnen die Arbeiten an einem neuen Speditionsgebude und einem weiteren Hotel.
Die Planungen zum Bau einer dritten Start- und Landebahn laufen seit
2005. Die Flughafen Mnchen GmbH rechnet mit der Inbetriebnahme im
Jahr 2012. Im Erffnungsjahr werden fr den Flughafen Mnchen ca. 40
Millionen Passagiere prognostiziert. Der Mnchner Flughafen verfgt
dann ber drei Bahnen mit jeweils 4000 Meter Lnge und kann damit die
aus dem weiteren Ausbau des Drehkreuzes erwarteten Verkehrssteigerungen bewltigen.
Der Erfolg des Mnchner Flughafens als Drehkreuz des Sdens liegt nicht
zuletzt in der starken Verzahnung der Flughafen-Kernprozesse mit untersttzenden IT-Lsungen. So kann dank effizientem IT-Einsatz im Terminal 2 eine krzeste Umsteigezeit von nur 30 Minuten garantiert werden.
Um diesen Wert einhalten zu knnen, werden Passagier- und Gepckstrme sowie die Umsteigebeziehungen der Passagiere und Crews laufend
berwacht und gesteuert. Dazu wurde gemeinsam mit dem Home-Carrier
Lufthansa eine interdisziplinre und unternehmensbergreifende Kontrollzentrale, das HCC (Hub-Control-Center) eingerichtet. Dort laufen alle
abfertigungsrelevanten Informationen zusammen und werden ber individuelle prozessuntersttzende Systeme angezeigt und verarbeitet. So
kann frhzeitig auf Abweichungen in den Hub-Prozessen reagiert werden.
Versptungen im Flugzeugumlauf durch Probleme in der HubKoordination werden so auf ein Minimum reduziert.
Neben dem Flugbetrieb spielt aber auch das so genannte Non-AviationBusiness eine immer grere Rolle. Mit der Vermietung, Verpachtung,
Retail-Business, Gastronomie und dem Parken generiert der Airport heute
bereits fast die Hlfte seines Gesamtumsatzes.

Der Servicebereich IT
Der Servicebereich IT des Flughafens versteht sich nicht nur als ICT-Provider fr die Flughafengesellschaft, sondern auch fr die weiteren am Flughafen ansssigen Unternehmen. So zhlen heute ber 500 Firmen, wie zum
Beispiel Airlines, Speditionen, Behrden und viele weitere Dienstleistungsunternehmen zu den Kunden des Servicebereichs. Die Forderungen
nach Qualitt und der professionellen Abwicklung der Leistungen bekommen dadurch nochmals einen hheren Stellenwert.
Mit 180 Mitarbeitern erwirtschaftet der Servicebereich IT einen Gesamtumsatz von ca. 42 Millionen Euro. Ein Drittel dieser Leistung wird dabei
mit Kunden auerhalb der Flughafengesellschaft generiert.

270

9 Praxisbeispiel: Flughafen Mnchen


Der Servicebereich IT des Flughafens Mnchen stellt die IT Services auch fr externe Kunden mit wachsendem Anteil bereit.

Die Organisation des Servicebereichs IT gliedert sich in drei Servicefelder


und drei Untersttzungsbereiche, wie im folgenden Bild dargestellt.
Servicebereich
IT

Projekte und
Entwicklung
ITE

Operation
& Service
ITO

ITEA - AS Aviation
ITEG - AS GroundHandling

ITOS - Systems
Management

Schichtleiter 1

ITOP - Plattforms

Schichtleiter 3

ITET - AS Technik

ITOC - Communications

ITEP - AS Personal

ITOR - Rollout
Management

ITES - SAP-CCC und


AS Rechnungsw.

Field
Service
ITF

Interne
Services
ITS

Controlling
& Sales
ITK

Schichtleiter 2

ITOI - Internal Services

ITEV - AS Vertrieb
ITED - CC-Anwendungsentwicklung
ITEC - CC Basistools

Abbildung 70:

Organisationsstruktur Flughafen Mnchen, Servicebereich IT

Zu den Leistungen gehrt neben dem Betrieb und dem Service fr die
eingesetzten Systeme auch die Entwicklung und Implementierung von
flughafenspezifischen Applikationen.
Die Mengenangaben zu den betriebenen Systemen sind der folgenden
Aufstellung zu entnehmen.

Betriebene PCs
Aktive LAN-Anschlsse
Telefone
FIDS Displays
CCTV-Kameras
Zentrale Server
Speicherkapazitt (brutto)
Applikationen

ca. 2.500
ca. 12.000
12.500
2.400
ca. 1.700
240
> 100 TB
ca. 420

271

CIM
ITC

9 Praxisbeispiel: Flughafen Mnchen


Smtliche Leistungen werden den internen, wie auch den externen Kunden als
Full-Services verkauft.

Der Servicebereich steht dabei stndig unter dem Druck, die angebotenen
Leistungen zu marktblichen Preisen anzubieten und muss die Marktfhigkeit ber entsprechende Benchmarks nachweisen.
Andererseits haben die vereinbarten IT Services hufig hohe Auswirkungen auf die Geschftsprozesse und die Services der internen und externen
Kunden. Daher muss die Servicequalitt auf einem sehr hohen Niveau
sichergestellt und nachgewiesen werden. Speziell die reibungslose Abwicklung der "just in time" Abfertigungsprozesse am Flughafen verlangt
diese hohe Qualitt und Stabilitt der Leistungen.
"Eine hohe Servicequalitt zu mglichst geringen Kosten zu erbringen ist die
Zielsetzung des Servicebereichs IT.

Implementierung des Service Managements


Zielsetzung des Service Managements
Damit der Flughafen Mnchen auch den zuknftigen Anforderungen
gerecht werden kann und die erzielten Ergebnisse verbessert werden knnen, wurden ausgehend von den Unternehmenszielen und der Unternehmensstrategie des Flughafens Mnchen die IT-Ziele definiert und dementsprechende Umsetzungsmanahmen erarbeitet.

272

9 Praxisbeispiel: Flughafen Mnchen

Ergebnis

Frage

Zielsetzung
FMG

Wie kann die FMG


in Zukunft im
Wettbewerb
wirtschaftlich
bestehen ?

Ideenfindung

Mit welchen Mitteln


knnen wir das
gesteckte Ziel
erreichen ?

Strategische
FMG-weit 1000
Neuausrichtung
Ideen aus
ErgebnisverWorkshops
besserung
Neue Organisation

Abbildung 71:

Zielsetzung
IT

Manahmen
IT

Umsetzung

Welche Zielsetzung
ergibt sich fr den
Bereich IT ?

Welche konkreten
Manahmen sind
zur Zielerreichung
erforderlich ?

Wie erfolgt die


Umsetzung ?

Effizienzsteigerung
und Generierung
zustzlicher Erlse
zur nachhaltigen
Senkung der ITKosten um 10% im
Konzern

13 Umsetzungsmanahmen zur
Senkung der

Effizienzsteigerung in den
ServiceProzessen
Verbesserung
der Projektabwicklung
Systemkonsolidierung
Strkung des
Vertriebs

Kapitalkosten
Fremdleistungen
Personalkosten
und Erhhung der
Marktdurchdringung

Von den Unternehmenszielen zu der Umsetzung in der IT

Zur Effizienzsteigerung wurde ein umfangreiches Optimierungsprogramm durchgefhrt, das unter anderem eine Reorganisation des IT-Bereichs und die Implementierung des Service Managements beinhaltete.
Die Implementierung des IT Service Management war kein Selbstzweck, sondern
ergab sich als Umsetzungsmanahme aus der Unternehmensstrategie des Flughafens Mnchen.

Um eine durchgngig hohe Servicequalitt zu niedrigen Kosten anbieten


zu knnen, hatte der Servicebereich IT in den letzten Jahren bereits umfangreiche Manahmen zur Optimierung der IT Serviceprozesse durchgefhrt. 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 fr die Organisation und die Mitarbeiter des Servicebereichs eine
gravierende Vernderung. So wurde die Organisation von der rein systemorientierten auf eine prozessorientierte Struktur umgestellt, ein 90Grad-Schwenk in der Organisation und in den Kpfen aller Beteiligten.

273

9 Praxisbeispiel: Flughafen Mnchen

Abbildung 72:

Prozessorientierte Sicht des Servicebereichs IT

Der Abschied von den Technik-Silos


Die Organisationsnderung war dabei kein Selbstzweck, sondern die logische Folge der Konvergenz in der eingesetzten Systemtechnik.
Frher gab es zum Beispiel fr Anzeigesysteme, Videoberwachung und
die Datenkommunikation vollstndig unterschiedliche und voneinander
getrennte Systemlandschaften. Heute wachsen diese Welten technisch
zusammen. Die Kommunikation der Systeme wird zuknftig einheitlich
ber das flughafenweite MPLS-Netz abgewickelt. Die Individualitt der
Systeme zeigt sich nur noch in den eingesetzten Endgerten und in den
verwendeten Applikationen auf Client- und Serversystemen. Eine sehr
weit reichende Standardisierung der verwendeten Systemkomponenten ist
mglich und wird konsequent durchgefhrt. Dies fhrt zu erheblichen
Kostensenkungen beim Einkauf der IT-Infrastruktur, die dann meist nur
noch aus Standardkomponenten besteht. Spezialwissen fr das Engineering, die Betreuung und den Betrieb von "Silo-Technik" ist in Zukunft immer weniger erforderlich. Die Verfolgung dieser Strategie der konsequenten Standardisierung und Konvergenz bedingt natrlich die bernahme
des Integrationsrisikos und erfordert die entsprechende Integrationskompetenz. Die beteiligten Mitarbeiter mssen 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 fr individuelle Systeme.

274

9 Praxisbeispiel: Flughafen Mnchen


Die Abkehr von den Silo-Systemen bietet enorme Chancen in der effizienteren Gestaltung der Serviceprozesse. Whrend frher zum Beispiel die
Bereiche Telekommunikation (TK), Anzeigesysteme (FIDS), Videoberwachung, Office-Systeme und Netzwerk eine eigene Auftragsannahme und eigenes Strmanagement unterhielten, werden in der neuen
Struktur alle Auftrge und Strungen vom zentralen Service Desk angenommen und durchgngig bearbeitet.
Auch beim Betrieb und bei den Field-Services knnen erhebliche Synergien erschlossen werden. Die Konvergenz der Systeme und die Konzentration auf standardisierte Plattformen werden damit in der Organisationsstruktur nachvollzogen.
Voraussetzung fr einen reibungslosen und effizienten Ablauf in der neuen
Organisation sind dokumentierte und kommunizierte Prozesse.

Und weiterhin erfordert dieser Transformationsprozess fr eine zeitgerechte Umsetzung eine klare Definition des angestrebten Zielzustands und
einen Endtermin, auf den alle Beteiligten gemeinsam hinarbeiten.

Das Prozessmodell und die Verantwortlichkeiten


Die strategische Ausrichtung der Prozesse
Die Prozessziele werden in regelmigen Planungsrunden aus der Strategie abgeleitet und definiert. Durch die Einhaltung der Prozesse ist sichergestellt, dass von der Fhrungs- bis zur Mitarbeiterebene die IT-Strategie
einheitlich verstanden und deren Umsetzung untersttzt wird.
Die Service Management-Prozesse verbinden die langfristige Ausrichtung des
Servicebereichs IT mit der kurzfristigen Zieldefinition und -verfolgung.

275

9 Praxisbeispiel: Flughafen Mnchen


Strategische Grundausrichtung
Strategieklausur

langfristig (3 5 Jahre)
Kunde

Prozess

Finanz

Mitarbeite r.

jhrlich

Strategieelemente
langfristig (3 5 Jahre)
Kunde

Prozess

Kunde

P rozess

Finanz

Mitarbeite r.

Finanz

Mitarbeiter .

Strategische Initiativen

Ziele (Fhrungskrfte)

mittelfristig (1 - 3 Jahre)

Manahmenplne

kurzfristig (1 Jahr)
bezogen auf Meilensteine
der Initiativen

Ziele (Mitarbeiter)

kurzfristig (1 Jahr)

Abbildung 73:

Quartalsreview

Projektmonitoring,
Mitarbeitergesprche

kurzfristig (1 Jahr)

Ausrichtung der Prozesse an der IT-Strategie

Skill-Management und Soft Factors


In einem Unternehmen mit einer etablierten IT und akzeptierter Qualitt
sind die Implementierung von ITIL-Prozessen und die Zertifizierung nach
ISO 20000 nicht ohne weiteres einzusehen. Dies gilt sowohl fr die Mitarbeiter des IT-Bereichs, als auch fr die Kunden. Es werden immer wieder
Fragen gestellt, wie zum Beispiel: "... was haben wir denn falsch gemacht,
dass nun alles gendert wird?", oder "... wer soll denn die Zusatzkosten fr
diesen ganzen Overhead zahlen?".
Die besondere Herausforderung liegt an dieser Stelle sicherlich darin, von
Beginn der Planungen an die Mitarbeiter intensiv an dem Prozess zu beteiligen und immer wieder Erfordernisse, angestrebte Ziele und die Verbesserungspotenziale zu verdeutlichen.
Aus diesem Grund wurde bereits zu Beginn des Projekts ein Team aus 15
Mitarbeitern den spteren Prozess Ownern eingesetzt. Gemeinsam
wurden die Vorgaben und Rahmenbedingungen festgelegt und vom Groben ins Feine entwickelt. Schnittstellen wurden diskutiert und beleuchtet
und in ihrem brokratischen Aufwand reduziert.
Die Mitarbeiter wurden dabei extern begleitet und untersttzt. Aber fr
die Entwicklung waren die Mitarbeiter des Servicebereichs IT verantwortlich, der externe Dienstleiter nahm die Rolle eines Coachs ein und war fr
den notwendigen Wissenstransfer verantwortlich.
Der folgenden Abbildung knnen die im Servicebereich IT implementierten Service Management-Prozesse entnommen werden.

276

9 Praxisbeispiel: Flughafen Mnchen

Abbildung 74:

Die Prozesslandkarte des Servicebereichs IT

Fr 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 flieen in einen kontinuierlichen Verbesserungsprozess ein

Die Vorgehensweise zur Inbetriebnahme der Prozesse erfolgte wie folgt:


Erarbeitung der Prozesse gem Vorgaben
Freigabe der Prozessdokumentation durch den IT-Qualittsbeauftragten
Verffentlichung der Prozesse im ITSM-Portal im Intranet
Ausbildung der Mitarbeiter
Leben der Prozesse
Internes Audit als Vorbereitung auf die Zertifizierung
Externes Audit mit der Zertifizierung gem ISO 20000

277

9 Praxisbeispiel: Flughafen Mnchen


Die Prozesse wurden vom Projektteam so dokumentiert, dass sie die tgliche Arbeit der Mitarbeiter untersttzten, aber wann immer sinnvoll trotzdem eigenverantwortliche Handlungsspielrume zulassen und vor allem
die Kompetenz der Mitarbeiter bercksichtigen.
Die Grundstze 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 ntig zu
erstellen, andererseits aber so viel Eigenstndigkeit und Serviceorientierung wie mglich 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 unntig einengen sollen.
Der Servicebereich IT wird auch weiterhin von der Leistungsbereitschaft
und Serviceorientierung der Mitarbeiter getragen.

Die Prozessdurchfhrung und der kontinuierliche Verbesserungsprozess


Alle Mitarbeiter des Servicebereichs IT haben einen Zugriff auf das ITSMPortal und knnen ber dieses Portal auf die Prozessdokumentation, Arbeitsanweisungen, Templates und weitere untersttzende Dokumentation
zugreifen (siehe Abbildung 75).
Den Mitarbeitern des Servicebereichs IT wurde im Rahmen der Trainings
und Einweisungen verdeutlicht, dass sie - wenn ntig - auch vom vorgegebenen Prozess abweichen drfen. Dann besteht allerdings die Verpflichtung zu erlutern, warum die abweichende Durchfhrung notwendig war
und zu definieren, wie der Prozess zuknftig entsprechend anzupassen ist.
Dieses Feedback aus der praktischen Prozessdurchfhrung ist ein wichtiger Input in den kontinuierlichen Verbesserungsprozess (Prozess Improvement Plan).

278

9 Praxisbeispiel: Flughafen Mnchen

Abbildung 75:

Das ITSM-Portal des Servicebereichs IT

Trainings
Um die Mitarbeiter in die Lage zu versetzen, die ITIL Prozessanforderungen auf den Servicebereich IT zu adaptieren, galt es in einer ersten Trainingsphase den Prozess Ownern und deren Mitarbeiter die notwendigen
ITIL Best Practices zu vermitteln.
Prozesse knnen nur dann erfolgreich implementiert werden, wenn die
beteiligten Mitarbeiter die Notwendigkeit dieser Prozesse, deren Aktivit-

279

9 Praxisbeispiel: Flughafen Mnchen


ten, Abhngigkeiten und Schnittstellen verstehen. In einer zweiten Phase
wurden hierzu alle Mitarbeiter des Servicebereichs ausgebildet.
Fr die Durchfhrung dieser Trainings war es wichtig, dass die Dozenten
nicht nur ber das theoretische Know-how verfgten, sondern auch praktische Umsetzungsbeispiele vermitteln konnten.
Das Trainingsprogramm fr die Mitarbeiter des Servicebereichs IT hatte
den folgenden Umfang:
-

ITIL-Foundation Trainings fr alle Mitarbeiter des Servicebereichs


mit abschlieender Prfung, durchgefhrt vom beratenden Unternehmen
Prozesstrainings fr alle Prozess Manager und die weiteren betroffenen Mitarbeiter mit dem Ziel, ein einheitliches Verstndnis fr
die implementierten Prozesse zu erreichen, durchgefhrt von den
Prozess Ownern
ITSM-Praxistrainings mit Fallbeispielen und Toolnutzung fr die
Prozesse Incident-, Problem- und Change-Management , durchgefhrt von den Prozess Ownern und Prozess Managern

Die ISO 200000 IT Service Management


Obwohl die Zertifizierung nach der ISO 20000 des Servicebereichs IT zunchst nicht im Fokus der Zielsetzung stand, hat der klare Zieltermin und
der klar definierte Umfang der Zertifizierung allen Beteiligten enorm geholfen. Bei einer solch umfassenden Neugestaltung der Prozesslandschaft
besteht die Gefahr, dass man sich sonst in den Tiefen der Prozessgestaltung verliert. Die Zertifizierung hilft in diesem Zusammenhang zur Einhaltung einer pragmatischen Flughhe und zwingt zur rechtzeitigen
Landung.
Als Motivationsfaktoren fr eine ISO 20000 Zertifizierung findet man in
der Literatur hufig die folgenden Grnde:
Verbesserung der Qualitt der Services und dadurch verbessertes
Vertrauen der Kunden in die IT-Abteilung
Verbessertes Ansehen sowie Verbesserung der Stabilitt und Zusammenarbeit
Transparente Darstellung der Leistungsfhigkeit Ihrer IT besttigt
durch einen unabhngigen Dritten (Zertifizierer)
Manager und Mitarbeiter erhalten ein besseres Verstndnis fr das
Geschft, die Rollen und die Verantwortlichkeiten
Die genannten Grnde trafen fr den Servicebereich IT des Flughafens
Mnchen nur eingeschrnkt zu. Der Hauptgrund lag in der gewnschten

280

9 Praxisbeispiel: Flughafen Mnchen


Effizienzsteigerung des Servicebereichs IT und einer angestrebten Prozessorientierung der gesamten Organisation.
Da der Servicebereich IT nicht nur intern Leistungen erbringt, wurde die
Definition des Scopes der ISO 20000 Zertifizierung bereits zu Beginn der
Planungen auf das gesamte Leistungs- und Kundenspektrum bezogen. Die
Scope-Definition lautet daher:
"The IT Service Management System that supports the provision of IT services to
internal and external customers of Flughafen Muenchen GmbH"

Und wenn zum Zertifizierungsdatum noch nicht alles perfekt ist?


Die Zertifizierung nach der ISO 20000 umfasst grundstzlich immer die
gesamte in der Norm definierte Prozesslandschaft mit den in der Norm
definierten Mindestanforderungen an den jeweiligen Prozess. Dieser sehr
groe Umfang stellt fr viele Organisationen eine groe Hemmschwelle
dar und die Frage liegt nahe: "Wie ist denn eine Vorbereitung auf diesen
Umfang in passabler Zeit machbar und wie bringt man dann auch die
Prozesse in diesem Umfang zum "Leben"?".

Prozess-Kennzahlen und Prozesssteuerung


Eine wesentliche Komponente der Prozessdefinitionen und der Prozesssteuerung stellt die Festlegung von Kennzahlen (KPIs) und deren Controlling dar. Die Kennzahl soll Schlsselindikator fr die Leistungsfhigkeit
des Prozesses sein und Messgren liefern, die anzeigen, wie schnell und
zu welchem Grad strungsfrei ein Prozess abluft.
Besonders hier ist jedoch zu beachten, dass jede definierte Kennzahl erhoben werden muss und auch interpretiert werden will, um als Steuerungsinformation einen Nutzen zu liefern, entsprechende Messindikatoren sind
zu implementieren.
In der Euphorie der Prozessdefinition werden gerne Kennzahlen definiert,
die beiden Kriterien nicht gerecht werden. In der Praxis hat sich im Servicebereich IT gezeigt, dass die Anzahl der ursprnglich definierten Kennzahlen nach einem Jahr um etwa 50 % reduziert wurde.
Weiterhin ist nicht jede Kennzahl auf jeder Organisationsebene gefragt. So
ist zum Beispiel die Anzahl der geffneten und geschlossenen ProblemRecords je Priorittsklasse" fr den Prozess Owner Problem-Management und seinen Linienverantwortlichen von groem Interesse, jedoch
weniger fr die Geschftsfhrung des Unternehmens.
Die folgende Tabelle zeigt einen Auszug der ersten Ebene der ProzessKennzahlen:

281

9 Praxisbeispiel: Flughafen Mnchen

Abbildung 76:

Auszug der ersten Ebene der Kennzahlen des SB IT

Im Rahmen der jhrlichen IT-Strategie werden konkreten Prozessziele und


die Sollwerte fr die einzelnen Kennzahlen mit dem Prozess Owner festgeschrieben.

Der Prozess Improvement Plan


Im Laufe der Vorbereitung auf die Zertifizierung wird sehr schnell klar,
dass es viele Prozessdetails gibt, die eine gewisse Reifezeit brauchen, bis
sie in der Organisation wirklich umgesetzt sind und Wirkung zeigen. Zum
Zeitpunkt der Zertifizierung wird in den meisten Unternehmen noch nicht
alles absolut perfekt laufen.
Diese Erfahrung hat auch der Servicebereich IT des Flughafens Mnchen
gemacht. Um dennoch zertifizierungsfhig zu sein, ist zum Zeitpunkt der
Zertifizierung eine klare Aussage zur Weiterentwicklung der Prozesse und

282

9 Praxisbeispiel: Flughafen Mnchen


die Definition von angestrebten Zielzustnden erforderlich; der so genannte Prozess Improvement Plan (Schema siehe Bild).
Prozess: Problem-Management

Datum: 27.04.2005

Freigabe (FK1 / FK2):

Definierte Einschrnkungen:
Werden die Zielzeiten bei Incidents berschritten
erfolgt noch nicht zwingend die Analyse mittels
Problem-Management

Manahmen- und Zeitplan fr die Erhhung des Abdeckungsgrades und zur Verbesserung der inhaltlichen Ausgestaltung:
Manahme

Ziel

Zieldatum

Verantwortlicher

Ausweitung der Problem-Management


Verfahren auf den gesamten Bereich IT

Einbindung aller Mitarbeiter in den


Prozess Problem-Management

01.08.2006

Prozess-Owner, Prozess-Manager

Schulungen aller IT-Mitarbeiter ber die


Inhalte und Arbeitsanweisungen zum
Problem-Management

Einbindung aller Mitarbeiter in den


Prozess Problem-Management

01.10.2006

Prozess-Owner, Prozess-Manager

Arbeitsanweisung zum ProblemManagement erweitern um Vor-gehen bei


Zielzeitberschreitungen von Incidents zu
bercksichtigen

Sicherstellen da Known Errors und


Workarounds fr die IncidentBearbeitung zur Verfgung gestellt
werden

01.08.2006

Prozess-Owner, Prozess-Manager

Verbesserungen am ARS-Tool und ARSMasken

Vereinfachtes Bearbeiten und


Erhhung der Akzeptanz

01.12.2006

Prozess-Owner, Prozess-Manager

Abbildung 77:

Auszug aus dem Service Improvement Plan des SB IT

In diesem Plan sind fr jeden Prozess, die zum Zertifizierungstermin getroffenen und bekannten Einschrnkungen hinsichtlich der Prozess Implementierung zu beschreiben und der Plan fr die Weiterentwicklung der
Prozesse mit klaren Zielen, Terminen und Verantwortlichkeiten zu hinterlegen.
Aber Vorsicht! Im Zuge der Vorbereitung auf die Zertifizierung arbeiten
alle beteiligten Mitarbeiter mit einer sehr hohen Intensitt und Euphorie
an dem Thema. Dieser Aufwand ist in der spteren betrieblichen Praxis im
Rahmen des kontinuierlichen Verbesserungsprozesses nicht zu halten. Bei
der Definition des Prozess Improvement Plans besteht daher die potentielle Gefahr, dass die Messlatte fr die angestrebten Ziele zu hoch gelegt
wird und nach kurzer Zeit die Enttuschung einsetzt, weil eine Zielerreichung aufgrund von Aufwandslimitierungen nicht mglich ist.

283

9 Praxisbeispiel: Flughafen Mnchen

Der ITSM-Manahmenkatalog
Auch nach der Zertifizierung werden viele neue Erkenntnisse in Hinblick
auf eine Verbesserung oder Abrundung der definierten Prozesse aufkommen. Um diese Informationen von Mitarbeitern und weiteren Prozessbeteiligten konsequent verfolgen zu knnen, 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 Qualittsmanagement hat in diesem Kontext die Aufgabe des Moderators bernommen und hinterfragt die geforderten Aspekte, definiert
gemeinsam mit den Linienverantwortlichen die Verantwortlichkeiten fr
die Manahmenbearbeitung, berprft die Zielerfllung und eskaliert ggf.
bei Terminberschreitungen. Ein Reporting ber den Bearbeitungsstatus
der Manahmen an das Bereichsmanagement erfolgt einmal im Quartal,
an die direkten Linienverantwortlichen monatlich.

Erfolge
Die Erfolge der konsequent verfolgten Strategie sprechen bereits jetzt fr 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 fr die eingesetzten Systeme, als auch die Kosten fr
Fremdleistungen konnten bei gleich bleibender Personalkapazitt erheblich reduziert werden.
Die IT-Organisation der Flughafen Mnchen GmbH hat als fnftes deutsches Unternehmen und als erster Flughafen weltweit ein ISO 20000 Zertifikat erhalten und weist damit seine exzellente Servicequalitt aus. Speziell
fr neue Kunden, die die Qualitt und Leistungsfhigkeit des Servicebereichs IT noch nicht beurteilen knnen und den Zusicherungen vertrauen
mssen, ist die Zertifizierung und damit Nachweis des Service Managements ein wichtiger Indikator fr die Servicequalitt.
Der Anteil des externen Geschfts konnte auch in 2006/2007 weiter gesteigert werden. Aus diesem Grund hat sich der Flughafen entschlossen, innerhalb des SB IT eine neue Business-Unit fr externes Geschft zu grnden, 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 fr weiteres wirtschaftliches Wachstum des
Mnchner Flughafens und fr die Umsetzung neuer innovativer Ideen fr
den Airport der Zukunft.

284

10 Praxisbeispiel: VOSS Gruppe


IT Management Report
der VOSS Gruppe

Gottfried Weibler
Leiter Informationstechnologie
VOSS Automotive GmbH
www.voss.de

Firmenportrait
VOSS ist eine mittelstndische Unternehmensgruppe mit Stammsitz in
Wipperfrth. Unter dem Dach der VOSS Holding betreuen die organisatorisch eigenstndigen Unternehmen VOSS Automotive und VOSS Fluid,
untersttzt von zehn Auslandsgesellschaften, die internationalen Mrkte
von Fahrzeug- und Maschinenbau. Die VOSS Gruppe beschftigt ca. 1.400
Mitarbeiter.
VOSS ist einer der fhrenden Systempartner fr Leitungs- und Verbindungstechnik im internationalen Fahrzeug- und Maschinenbau und versteht sich als kompetenter Entwicklungspartner seiner Kunden. Ergebnis
der Entwicklungspartnerschaft sind mageschneiderte Lsungen der Leitungsauslegung, der Leitungsfhrung und der Verbindungstechnik. Dies
gilt fr Pneumatik, Hydraulik, Kraftstoff- und Klimasysteme, insbesondere auch fr 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 geprgt, z. B. in der Verbindungstechnik fr die Druckluftbremse
in Nutzfahrzeugen und fr die Luftfederung in PKW.
Als einer der fhrenden Anbieter hydraulischer Verbindungstechnik ist
VOSS Fluid ein international gefragter Partner. Im engen Kundenkontakt
optimiert VOSS Fluid die Verbindungsauslegung der Hydraulik und bernimmt damit wesentliche Aufgaben innerhalb der gesamten Hydrauliksysteme. Durch ein Komplettprogramm in der Rohrverschraubung wird
unser Anspruch, den Kunden ein umfassendes Lieferprogramm zu bieten,
erweitert. Darber hinaus liefert die VOSS Fluid weitere Komponenten

285

10 Praxisbeispiel: VOSS Gruppe


wie Messtechnik, Rohrschellen, Kugelhhne, einbaufertige Schlauchleitungen, Flanschverbindungen und komplette Kits.
Die IT Abteilung ist organisatorisch in der VOSS Automotive GmbH angesiedelt und ist zentraler IT-Dienstleister fr alle VOSS-Gesellschaften.

Herausforderungen an die VOSS IT


Die VOSS Gruppe expandiert weltweit und das immer schneller. Dies ist
eine enorme Herausforderung auch fr die VOSS IT, die mit einer relativ
kleinen Personaldecke sehr flexibel und skalierbar sein muss.
Schon sehr frh haben wir uns nach ITIL ausgerichtet und das Potenzial
des IT Service Managements erkannt. Wir konnten die durch ITIL erreichten Verbesserungen in vielen Kontexten einsetzen, z. B. werden die turnusmigen Audits nach ISO/TS 16949 unserer IT, sowie kundenspezifische Audits unserer IT und IT berprfung durch unsere Wirtschaftsprfer durch den praktischen Einsatz von ITIL sehr viel einfacher.

ITIL und Kennzahlen


Einen wesentlichen Erfolg haben wir im letzten Jahr durch die enge Verzahnung von IT-Kennzahlen und ITIL erreicht.
Das Service Desk liefert wesentliche IT-Kennzahlen.
Ein Cockpitsystem auf der Basis von NAGIOS, das sich in der letzten Phase des Aufbaus befindet, ermittelt die fr den IT-Betrieb relevanten Kennzahlen automatisch und zeigt insbesondere Abweichungen auf. Dadurch ist eine schnelle Reaktion seitens der IT im
Service Desk und im Problem Management mglich.
Das Reporting der VOSS IT an unsere Geschftsfhrung ist enorm
professionalisiert worden. Neben den Beitrgen in Management
Meetings stellen wir unserem Top Management einen jhrlichen Bericht, den IT Management Report, zur Verfgung, der in der Sprache der Geschftsfhrung die Lage der IT in der VOSS Gruppe darstellt.

IT Management Report
Ich mchte in dieser Kurzdarstellung nur auf den IT Management Report
eingehen. Die Entwicklung dieses Reports, der die Situation der VOSS IT
jhrlich beleuchtet, war kein einfaches Projekt. Sehr viel Vorarbeit war
dazu ntig, u. a. im Bereich IT-Controlling und die Recherche nach den fr
die VOSS Gruppe geeigneten Kategorien mit den wichtigsten Key Performance Indikatoren, die sich letztlich aus technischen und finanzwirtschaftlichen IT-Kennzahlen ableiten.

286

10 Praxisbeispiel: VOSS Gruppe


Die Struktur unseres IT Management Reports haben wir in Form einer
Balanced Scorecard entwickelt, allerdings haben wir diese auf unsere firmenspezifischen Bedrfnisse erweitert. Diese erfolgt bei uns in fnf Kategorien, die nicht nur die Finanzperspektive, sondern auch die Perspektivsichten auf Kunden, Leistung, Mitarbeiter und insbesondere die fr die
Weiterentwicklung der VOSS Gruppe wichtigen IT - Projekte und Innovationen abgeleitet aus der Geschftsstrategie bercksichtigt.
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. Bemht man sich,
diese Interpretation klar und verstndlich in den Business-Zusammenhang einzuordnen, so fllt es leicht, aus dieser Darstellung die Ziele fr
das nchste Jahr abzuleiten.
Der jhrlich erscheinende IT Management Report soll einen umfassenden
und prgnanten Eindruck ber die IT in der VOSS Gruppe vermitteln.
Daher wird besonderer Wert auf Knappheit und Transparenz der Darstellung gelegt.
Die Kennzahlen, die wir verwenden, sind natrlich vertraulich. Wir haben
kein fertiges Kennzahlensystem eingesetzt, sondern unser eigenes entwickelt, das insbesondere unsere Geschftsziele und firmenspezifischen
Bedrfnisse bercksichtigt. Wegen des enormen weltweiten Wachstums
der VOSS Gruppe waren uns Kennzahlen wichtig, die eventuell fr 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 fr
das Jahr 2006 entwickelt. Unser Top Management hat diesem Report groe
Beachtung geschenkt. Insbesondere vermittelt der Report ein geschlossenes Bild der IT. Es wird deutlich, wieso wir bestimmte Dinge, z. B. Virtualisierung und Serverkonsolidierungen zu einem bestimmten Zeitpunkt,
durchgefhrt haben, und wie sie sich auswirken.
Wir sehen den IT Management Report als ideales Kommunikationsinstrument zur Darstellung der Leistungen unserer IT.
Die Darstellung der aktuellen Situation der IT und die Zielformulierung
werden anhand der Balanced Scorecard integriert und stehen nicht mehr
isoliert nebeneinander wie in den Vorjahren.
Wir werden den IT Management Report jhrlich an die Geschftsziele und
davon abgeleitete IT-Strategie anpassen denn diese ist natrlich im Fluss.

287

11 Anhang
11.1 Quellenverzeichnis
[Baschin, 2001]
Baschin, Anja
Die Balanced Scorecard fr Ihren IT-Bereich
Ein Leitfaden fr Aufbau und Einfhrung
Campus Verlag, Frankfurt, New York, 2001,
ISBN 3 593 36715 7
[Bung, 2006]
Bung, Jakob
Entwicklung eines Kennzahlensystems fr das IT-Service
Management auf der Basis von ITIL, ISO 20000 und
COBIT
Masterarbeit im Studiengang Entrepreneurial Management der Fachhochschule fr Wirtschaft Berlin, 2006
[BS 15000-1, 2002]
BS 150000-1:2002
IT service management - Part 1: Specification
BSI, London, 2002, ISBN 0 580 40470 6
[BS 15000-2, 2002]
BS 150000-2:2002
IT service management - Part 2: Code of practice
BSI, London, 2002, ISBN 0 580 41125 7
[COBIT, 2000]
IT Governance Institute
COBIT 3rd Edition - Management Guidelines
www.isaca.org, Rolling Meadows, IL 60008 USA,
2000, ISBN 1-893209-12-1

289

11 Anhang
[COBIT, 2004a]
IT Governance Institute
COBIT Mapping - Overview of International IT Guidance
www.isaca.org, Rolling Meadows, IL 60008 USA,
2004, ISBN 1-893209-57-1
[COBIT, 2004b]
IT Governance Institute
COBIT Mapping - Mapping of ISO/IEC 17799:2000
With COBIT
www.isaca.org, Rolling Meadows, IL 60008 USA,
2004, ISBN 1-893209-62-8
[COBIT, 2005]
IT Governance Institute
COBIT 4.0 - Control Objectives, Management Guidelines,
Maturity Models
www.isaca.org, Rolling Meadows, IL 60008 USA, 2005,
ISBN 1-933284-37-4
[COBIT, 2006]
IT Governance Institute
IT Control Objectives for Sarbanes-Oxley, 2nd Edition The Role of IT in the Design and Implementation of
Internal Control Over Financial Reporting
www.isaca.org, Rolling Meadows, IL 60008 USA,
2006, ISBN 1-933284-76-5
[COBIT, 2007]
IT Governance Institute
Mapping of ITIL With COBIT 4.0
www.isaca.org, Rolling Meadows, IL 60008 USA,
2007, ISBN 1-933284-77-3

290

11.1 Quellenverzeichnis
[Gartner, 2006]
Gartner Research
ISO/IEC 20000 Has an Important Role in Sourcing
Management
Gartner Research, 2006, ID Number: G00136652
[Harvard, 2004]
Harvard Business Manager
Balanced Scorecard Unternehmen erfolgreich steuern
Manager Magazin Verlagsgesellschaft, Hamburg,
Auflage 1, Mrz 2004, ISBN 3-935577-07-9
[ISO 20000-1, 2005]
ISO/IEC 20000-1:2005-12
Information technology - Service management Part 1:
Specification
Beuth Verlag, Berlin, 2005, ISBN 0 580 47529 8
[ISO 20000-2, 2005]
ISO/IEC 20000-2:2005-12
Information technology - Service management - Part 2:
Code of practice
Beuth Verlag, Berlin, 2005, ISBN 0 580 47530 1
[ISO 17799, 2005]
ISO/IEC 17799:2005
Information technology - Security techniques - Code of
practice for information security management
Beuth Verlag, Berlin, 2005, ISBN 0580467813

291

11 Anhang
[itSMF, 2001]
itSMF The IT Service Management Forum
IT Service Management Ein Begleitband zur IT
INFRASTRUCTURE LIBRARY, Version 2.1.b
itSMF Ltd., Winnersh, 2001, ISBN 0-9524706-2-4
[Kaplan et al., 1996]
Kaplan, Robert S.; Norton, David P.
The Balanced Scorecard. Translating Strategy Into Action
Mcgraw-Hill Professional, 1996, ISBN 0875846513
[Kaplan et al., 1997]
Kaplan, Robert S.; Norton, David P.
Balanced Scorecard Strategien erfolgreich umsetzen
Schffer-Poeschel Verlag, Stuttgart, 1997,
ISBN 3-7910-1203-7
[KESS, 2006a]
KESS DV-Beratung GmbH
Erfolgreiche ISO 20000-Zertifizierung der ITOrganisation des Flughafens Mnchen
Pressemitteilung
http://www.kess-dv.de/Pressemitteilung
ISO_20000_Flughafen__Munchen.pdf, 10.01.2007
[KESS, 2006b]
KESS DV-Beratung GmbH
Download-Bereich
http://www.kess-dv.de/Wir-Ueber-Uns/Beschreibungenund-Downloads/beschreibungen-und-downloads.html,
10.03.2007

292

11.1 Quellenverzeichnis
[KESS, 2007a]
KESS DV-Beratung GmbH
Beschreibung zum ITIL Service Manager Seminar
http://www.kess-dv.de/Seminare/ServiceManager/service-manager.html,
17.03.2007
[KESS, 2007b]
KESS DV-Beratung GmbH
IT Service Management Simulationen
http://www.kess-dv.de/Seminare/seminare.html,
16.06.2007
[KESS, 2007c]
KESS DV-Beratung GmbH
Workshop Unterlage ITIL V3 - was ist neu
http://www.kess-dv.de/Seminare/seminare.html,
16.06.2007
[Ktz, 2007]
Ktz, Martin
Kennzahlen in der IT
dpunkt Verlag, Heidelberg, 2. Auflage, 2007
[Kurth, 2006]
Kurth, Sascha
IT Service Management Prozesse mit Kennzahlen steuern
Tagungsband zur dritten Fachtagung IT-Controlling
Fachhochschule Bonn-Rhein-Sieg, Band 16,
Sankt Augustin 2006

293

11 Anhang
[Lewin, 1958]
Lewin, Kurt
Group decision and social change
In: Maccoby, Newcomb, Hartley (Hrsg.): Readings in
social Psychology, 3. Auflage, New York, 1958, S. 197-211.
[OGC, 2005a]
OGC
Best Practice Einfhrung in ITIL
The Stationery Office Books, London, 2005,
ISBN 0 11 331035 8
[OGC, 2005b]
OGC
Best Practice fr Service Support
The Stationery Office Books, London, 2005,
ISBN 0 11 330970 8
[OGC, 2006a]
OGC
Best Practice fr Security-Management
The Stationery Office Books, London, 2006,
ISBN 0 11 330968 6
[OGC, 2006b]
OGC
Best Practice fr Service Delivery
The Stationery Office Books, London, 2006,
ISBN 0 11 330056 2
[OGC, 2007a]
OGC
Service Strategy
The Stationery Office Books, London, 2007,
ISBN 97801133104560

294

11.1 Quellenverzeichnis
[OGC, 2007b]
OGC
Service Design
The Stationery Office Books, London, 2007,
ISBN 9780113310470
[OGC, 2007c]
OGC
Service Transition
The Stationery Office Books, London, 2007,
ISBN 9780113310487
[OGC, 2007d]
OGC
Service Operation
The Stationery Office Books, London, 2007,
ISBN 9780113310463
[OGC, 2007e]
OGC
Continual Service Improvement
The Stationery Office Books, London, 2007,
ISBN 9780113310494
[OGC, 2007f]
OGC
The Official Introduction to Service Lifecycle
The Stationery Office Books, London, 2007,
ISBN 9780113310617
[Preiner, 2006]
Preiner, Andreas
Balanced Scorecard anwenden
Kennzahlengesttzte Unternehmenssteuerung
Hanser Wirtschaft, 2. Auflage, 2006, ISBN: 3446407383

295

11 Anhang
[van Bon, 2006]
van Bon, Jan
ISO/IEC 20000 - Das Taschenbuch
Van Haren Publishing, Zerwole (Niederlande), 2006,
ISBN 90 77212 87 6
[Victor et al., 2005]
Victor, Frank; Gnther Holger
Optimiertes IT Management mit ITIL
Vieweg Verlag, Wiesbaden, 2005, ISBN 978-3528158941
[Victor GmbH, 2007]
Victor GmbH
ITIL Implementation Guide
http://www.VictorGmbH.de
27.05.2007
[Wikipedia, 2007]
Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Key_performance_indicators,
08.05.2007
[Zeithaml et al., 1988]
Zeithaml, V. A.; Berry, L. L.; Parasuraman, A.
Communication and control processes in the
delivery of service quality
Journal of Marketing, 52(1), 1988, S. 44

296

11.2 Abkrzungsverzeichnis

11.2 Abkrzungsverzeichnis
ACD

Automatic Call Distribution

BCM

Business Continuity Management

BIA

Business Impact Analyse

BS

British Standard

BSC

Balanced Scorecard

CAB

Change Advisory Board

CAPI

Computer Assisted Personal Interview

CCTA

Central Computer and Telecommunications Agency

CI

Configuration Item

CMDB

Configuration Management Database

CMS

Configuration Management System

COBIT

Control Objectives for Information and related Technology

CSF

Critical Success Factor

CSI

Continual Service Improvement

CSI

Customer Satisfaction Index

DHS

Definitive Hardware Store

DML

Definitive Media Library

DSL

Definitive Software Library

EC

Emergency Committee

ISACA

Information Systems Audit and Control Association

ISACF

Information Systems Audit and Control Foundation

ISO

International Standardization Organization

ITGI

IT Governance Institute

ITIL

IT Infrastructure Library (Version 2),


in Version 3 Synonym fr Service Management

ITSC

IT Service Continuity

ITSCM

IT Service Continuity Management

ITSM

IT Service Management

itSMF

IT Service Management Forum

297

11 Anhang
ISO

International Organization for Standardization

KGI

Key Goal Indicator

KPI

Key Performance Indicator

KSF

Key Success Factor

KVP

Kontinuierlicher Verbesserungsprozess

OGC

Office of Government Commerce

OLA

Operational Level Agreement

PDCA

Plan, Do, Check, Act

PIP

Prozess Improvement Plan

PMP

Prozess-Management Plan

RFC

Request for Change

ROI

Return of Investment

SCM

Service Catalogue Management

SIP

Service Improvement Program

SIP

Service Improvement Plan

SKMS

Service Knowledge Management System

SLA

Service Level Agreement

SLM

Service Level Management

SLR

Service Level Requirements

SMP

Service Management Plan

SPOC

Single Point of Contact

UC

Underpinning Contract

298

11.3 Abbildungsverzeichnis

11.3 Abbildungsverzeichnis
Abbildung 1:

ITIL Rahmenstruktur ...............................................................8

Abbildung 2:

Die 10 ITIL-Prozesse und der Service Desk ..........................9

Abbildung 3:

Generisches ITIL-Prozessmodell ..........................................10

Abbildung 4:

Die Ausrichtung der Services auf das Business..................13

Abbildung 5:

Die 5 Phasen des Service Lifecycles nach ITIL V3..............15

Abbildung 6:

Verbindung zwischen IT Service und Business Service ....17

Abbildung 7:

Service Strategy Prozesse.......................................................18

Abbildung 8:

Service Design Prozesse.........................................................19

Abbildung 9:

Service Transition Prozesse ...................................................20

Abbildung 10: Service Operation Prozesse ...................................................22


Abbildung 11: Continual Service Improvement...........................................23
Abbildung 12: ITIL Version 3 Prozessmodell ...............................................25
Abbildung 13: Die 5 Phasen des Service Lifecycles und ihre Prozesse .....33
Abbildung 14: Service Strategy .......................................................................34
Abbildung 15: Service Design .........................................................................35
Abbildung 16: Service Transition ...................................................................39
Abbildung 17: Service Operation....................................................................42
Abbildung 18: Continual Service Improvement...........................................46
Abbildung 19: 7 Step Improvement Prozess .................................................47
Abbildung 20: IT Service Management-Prozesse der ISO 20000................54
Abbildung 21: PDCA-Methodik .....................................................................55
Abbildung 22: COBIT Prozess-bersicht ......................................................58
Abbildung 23: Zusammenhang zwischen Control Objectives in COBIT.60
Abbildung 24: Ziele, Prozesse und Metriken in COBIT ..............................62
Abbildung 25: Prozess, Ziele und Kontrollebenen in COBIT .....................63
Abbildung 26: Mapping der Prozesse in ITIL Version 2 und COBIT........65
Abbildung 27: Wertschpfungskette nach Porter ........................................75
Abbildung 28: Zusammenhang zwischen SLAs, OLAs und UCs..............79
Abbildung 29: Beispiel fr mehrschichtige SLAs .........................................80
Abbildung 30: Allgemeine Balanced Scorecard............................................91

299

11 Anhang
Abbildung 31: Ursache-Wirkungskette .........................................................93
Abbildung 32: Stellung der BSC im Unternehmensplanungsprozess .......93
Abbildung 33: PDCA-Zyklus ........................................................................102
Abbildung 34: Exemplarische Darstellung der Bearbeitung eines
Incidents .................................................................................106
Abbildung 35: IT-Prozesse und bestehende Aufbauorganisation............107
Abbildung 36: Ausschnitt der RACI-Matrix zum Change Management
(vgl. [OGC, 2007c])................................................................111
Abbildung 37: Definition der IT Services ....................................................116
Abbildung 38: Definition der IT Services Service Improvement Plan ..117
Abbildung 39: Definition der Prozessziele Neue Services .....................118
Abbildung 40: Definition der Prozessziele Kundenanforderungen .....118
Abbildung 41: Definition der Prozessziele IT-Strategie..........................119
Abbildung 42: Definition der Prozessziele Prozess Improvement
Plan .........................................................................................120
Abbildung 43: Definition der Prozessziele Planung und
Implementierung ..................................................................121
Abbildung 44: Definition der Prozessziele Service Management Plan 122
Abbildung 45: Konformitt des Managementsystems ..............................124
Abbildung 46: Prozess-Management Prozessdesign ..............................125
Abbildung 47: Prozess-Management berprfung ................................126
Abbildung 48: Prozess-Management Nutzung von COBIT und ITIL ..127
Abbildung 49: Prozess-Management Konformitt..................................128
Abbildung 50: Prozess-Management Prozess Improvement Plan ........129
Abbildung 51: Entwicklung von Kennzahlen .............................................130
Abbildung 52: Zusammengesetzte Prozess-Kennzahlen ..........................133
Abbildung 53: Darstellung der SLAs mit dem Q-Board von Q to be ......133
Abbildung 54: Das IT Service Management Kennzahlensystem..............134
Abbildung 55: Exemplarischer Prozess-Bericht Deckblatt zum
Report .....................................................................................135
Abbildung 56: Exemplarischer Prozess-Bericht Darstellung der
Kennzahlen ............................................................................136
Abbildung 57: Darstellung des Management Cockpits von iET
Solutions.................................................................................137

300

11.3 Abbildungsverzeichnis
Abbildung 58: Beispiel fr eine Trenddarstellung .....................................138
Abbildung 59: Beispiel 1 fr eine Analyse mglicher Ursachen ..............139
Abbildung 60: Beispiel 2 fr eine Analyse mglicher Ursachen ..............140
Abbildung 61: Schema zur Klassifikation von IT-Kennzahlen.................156
Abbildung 62: Key Success Faktoren im IT Management Report............159
Abbildung 63: Key Success Faktoren zur Gruppierung von KPIs und
CSIs .........................................................................................160
Abbildung 64: Beispiele fr Lcken zwischen Kunden- und
Providersicht .........................................................................161
Abbildung 65: Gaps nach OGC (aus [OGC, 2007e])...................................163
Abbildung 66: Deming (oder PDCA) Zyklus..............................................234
Abbildung 67: 3-Phasen-Modell nach Lewin..............................................236
Abbildung 68: Anzahl der RfCs pro Monat (Demo-Daten) ......................262
Abbildung 69: Status aller RfCs (Demo-Daten) ..........................................263
Abbildung 70: Organisationsstruktur Flughafen Mnchen,
Servicebereich IT...................................................................271
Abbildung 71: Von den Unternehmenszielen zu der Umsetzung in
der IT ......................................................................................273
Abbildung 72: Prozessorientierte Sicht des Servicebereichs IT ................274
Abbildung 73: Ausrichtung der Prozesse an der IT-Strategie ..................276
Abbildung 74: Die Prozesslandkarte des Servicebereichs IT ....................277
Abbildung 75: Das ITSM-Portal des Servicebereichs IT ............................279
Abbildung 76: Auszug der ersten Ebene der Kennzahlen des SB IT.......282
Abbildung 77: Auszug aus dem Service Improvement Plan des SB IT...283

301

11 Anhang

11.4 Sachwortverzeichnis
A

Access Management 44, 214


Asset 34

Financial Management 30, 34,


169

Asset Management 40

Availability Management 8, 31,


37, 180

Governance 11, 56, 57

Improvement Prozess 46

Balanced Scorecard 3, 5, 88

Incident 28

Benchmark 160
Best Practice 1, 3

Incident Management 6, 27, 43,


105, 204

Business Continuity
Management 31, 37

Information Security
Management 38, 101, 185

ISO 20000 3, 4, 5, 50, 51, 53, 54,


81

Capacity Management 30, 36,


177
Change Management 26, 28, 29,
39, 191
COBIT 2, 5, 56
Configuration Management 29,
40
Continual Service Improvement
14, 22, 46, 217

IT Prozess-Management 101
IT Service 5, 13, 73
IT Service Continuity
Management 31, 37, 183
IT Service Management 5, 27
IT Service Provider 13, 22, 77, 78,
86, 87
IT-Controls 164

Controls on Demand 164

ITIL 1, 2, 3, 5, 7, 11, 14, 23

Critical Success Factor 63, 113

ITIL Best Practice 83

ITIL Refresh 250

Definitive Media Library 199

Demand Management 24, 35,


172

Kennzahlen 1, 7, 11, 27, 32, 54,


88, 101, 115, 124, 130, 140, 141,
143, 155, 166, 243

Evaluation 41, 199


Event Management 42, 202

302

Kennzahlensystem 2, 5, 94, 143,


147, 155, 158, 161

11.4 Sachwortverzeichnis
Key Performance Indikator 33,
61, 158, 161, 163

Request Fulfilment 43, 53, 167,


210

Knowledge Management 42, 189,


200

Return on Investment 49, 89, 219

Kontinuierlicher
Verbesserungsprozess 233

Lifecycle 6, 14
M

Metriken 66
Monitoring 72
O

Risiko Management 14
Security Management 31, 65, 72
Service 12
Service Asset 40
Service Asset and Configuration
Management 40, 167, 189, 195
Service Catalogue Management
35, 173

Operational Level Agreement 32,


77, 174

Service Design 14, 18, 35, 173

Outsourcing 225, 258


P

Service Improvement Plan 55,


116, 122, 134, 238

PDCA-Zyklus 101

Service Katalog 35, 81

Plan-Do-Check-Act 55

Service Level 14, 21, 36

Problem Management 28, 44, 64,


67, 73, 212

Service Level Agreement 13, 35,


43, 52, 77, 78, 82, 174

Prozess Manager 26, 97, 103, 108,


112

Service Level Management 8, 30,


36, 49, 77, 81, 174, 220

Prozess Owner 10, 26, 97, 103,


108, 110, 111

Service Level Requirement 77

Prozess-Kennzahlen 124, 130,


166

Service Management 1, 7

Prozess-Management 104
R

Service Desk 9, 28, 37, 44, 66, 215

Service Level Target 145, 174


Service Manager 109
Service Measurement 48, 219

Reifegrad 242

Service Operation 14, 21, 23, 42,


202

Release and Deployment


Management 40, 189, 197

Service Portfolio 16, 34, 35, 171

Release Management 29, 197

Service Portfolio Management


24, 34, 35, 171

Reporting 72

Service Reporting 48, 218

Request for Change 28, 73

Service Request 32, 43, 44, 45, 49,


204, 210

303

11 Anhang
Service Strategy 11, 15, 34, 53,
115, 169

Transition Planning and Support


39, 189

Service Transition 14, 19, 23, 39,


189

Service Validation and Testing


41, 189

Underpinning Contract 32, 77,


174
V

Single Point of Contact 215

Verification and Audit 194

Supplier Management 38, 187

System Management 143

Workaround 82

The 7 Step Improvement Process


217

304