Sie sind auf Seite 1von 379

Ralf Buchsein | Frank Victor |

Holger Gnther | Volker Machmeier


IT-Management mit ITIL V3

Ralf Buchsein | Frank Victor |


Holger Gnther | Volker Machmeier

IT-Management

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

Bibliografische Information der Deutschen Nationalbibliothek


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

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

Vorwort zur 1. Auflage


ITIL als Basis fr eine neue Sicht auf die IT hat sich in den letzten Jahren in
deutschen Unternehmen rasant verbreitet, und das mit anhaltendem Erfolg. Der Grund liegt darin, dass ITIL in der Version 2 gut 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

Vorwort zur 2. Auflage


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

ITIL V3 steht im Mittelpunkt. Darum ranken sich eine Reihe von


praxisrelevanten Themen, wie IT-Management-Strategien, Kennzahlensysteme, Zertifizierungen, Balanced Scorecards und Reporting.

ITIL V3 wird in einem Detaillierungslevel dargestellt, so dass die


Kernideen und die Einordnung in die Gesamtzusammenhnge
deutlich werden.

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

VII

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

2.4.2

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

2.4.3

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

2.4.4

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

2.4.5

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

2.4.6

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

2.4.7

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

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


2.5.1

Ausgewhlte Kennzahlen der ITIL Version 2.........................52

2.5.2

Prozesse und ausgewhlte Kennzahlen der ITIL Version 3 .57

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


2.6.1

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

2.6.2

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

2.6.3

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

2.6.4

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

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

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

2.7.2

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

2.7.3

Prozess-Management gem COBIT .....................................106

2.7.4

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

IX

Inhaltsverzeichnis
2.7.5

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

2.7.6

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

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


2.8.1

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

2.8.2

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

2.8.3

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

2.8.4

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

2.8.5

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

2.8.6

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

2.8.7

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

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


2.9.1

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

2.9.2

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

2.9.3

Ausprgungen der Balanced Scorecard ................................142

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

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

3.3.2

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

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


3.4.1

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

3.4.2

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

3.4.3

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

3.4.4

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

3.5 Von der Kennzahl zur Verbesserungsmanahme .............................185


3.6 Kennzahlen mssen reifen ....................................................................188
3.7 Der Umgang mit Kennzahlen ...............................................................189
4 IT Kennzahlensysteme ................................................................................191
4.1 Management Summary .........................................................................191
4.2 Ziele ..........................................................................................................192

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

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

5.2.2

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

5.2.3

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

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


5.3.1

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

5.3.2

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

5.3.3

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

5.3.4

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

5.3.5

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

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


6.1 Management Summary .........................................................................269
6.2 ITIL-Einfhrung .....................................................................................270
6.2.1

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

6.2.2

Prozess-Einfhrungen..............................................................274

6.2.3

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

6.2.4

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

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


6.3.1

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

6.3.2

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

6.3.3

Wettbewerb der Prozesseinfhrung ......................................289

6.3.4

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

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

XI

Inhaltsverzeichnis
6.4.1

IT-Prozesse am Tagesgeschft ausrichten .............................292

6.4.2

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

6.4.3

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

7 Praxisbeispiel: ALTANA Pharma AG ......................................................305


8 Praxisbeispiel: Autobahn Tank & Rast GmbH.......................................313
9 Praxisbeispiel: Flughafen Mnchen .........................................................317
10 Praxisbeispiel: VOSS Gruppe ..................................................................333
11 Anhang .........................................................................................................337
11.1 Quellenverzeichnis ...............................................................................337
11.2 Abkrzungsverzeichnis.......................................................................345
11.3 Abbildungsverzeichnis ........................................................................347
11.4 Glossar....................................................................................................351
11.5 Sachwortverzeichnis ............................................................................369

XII

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 downVerfahren 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 downAnsatz 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 upVerfahren 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 IT-Kennzahlen setzen wir ein?
Kapitel 5: Praxisleitfaden zur Entwicklung von IT-Kennzahlensystemen mit Klassifikationsschemata und Prozess-Kennzahlen aus ITIL
V3 und unseren Projekterfahrungen.
Kapitel 6: Wie geht man am besten in IT Service ManagementProjekten vor? Empfehlungen aus unseren Projekten 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 und Service Delivery hierzu insgesamt
zehn erforderliche IT-Prozesse dokumentiert. Zustzlich ist der Prozess
Security Management in einem eigenen Dokument beschrieben.
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-Verfgbar-

2.3 Die Struktur gem ITIL Version 2


keit. Jeder IT Service Management-Prozess hat eine charakteristische Zielrichtung 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 folgendermaen definiert:
Prozessteuerung:
Der Prozess der Planung und Regelung; mit dem Ziel, einen Prozess in einer
effektiven und effizienten Weise durchzufhren.

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

ProzessOwner
Qualittsparameter
und KPIs
Prozessmanagement

Aktivitten und
Subprozesse

Input

Output

Prozessausfhrung

Ressourcen

Rollen

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

Generisches ITIL-Prozessmodell

Auf Basis der vom Process Owner vorgegebenen Prozessziele gilt es, die
notwendigen 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.

10

2.4 Die Struktur gem ITIL Version 3


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


Die in diesem Buch wiedergegebenen Definitionen stammen aus dem
ITIL V3 Glossar des Arbeitskreises Publikation, ITIL Version 3 Translation Projekt des itSMF Deutschland e. V. Dieses Glossar bildet die
Basis fr die bersetzung der Originalliteratur.

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

11

ITIL
Kennzahlen
sind lediglich
Empfehlungen.

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

Mithilfe der ITIL Best Practice soll nicht nur eine bessere Ausrichtung der
IT-Organisation an den Geschftsprozessen und Anforderungen des Kunden ermglicht werden, sondern es wird mit der ITIL V3 eine IT- / Business Integration angestrebt.
In den meisten Organisationen ist inzwischen die Abwicklung eines Geschftsprozesses ohne entsprechende IT-Untersttzung nicht mehr denkbar. In einigen Fllen findet die Durchfhrung eines Geschftsprozesses
inzwischen nur durch elektronische Systeme und ohne manuelle Bearbeitungsschritte statt. Als Beispiele hierfr knnen Web-Shops oder das
Online Banking herangezogen werden. Die Qualitt, Funktionalitt und
Leistungsfhigkeit dieser IT-Untersttzung prgt mageblich das Erscheinungsbild der gesamten Organisation nach auen zum Kunden. Gleichzeitig gehrt die auf den Geschftsprozess ausgerichtete IT-Untersttzung zu
den strategischen Fhigkeiten und Ressourcen einer Organisation. Damit
wird die notwendige und auf die jeweilige Organisation ausgerichtete ITUntersttzung zum elementaren Bestandteil des Geschftserfolges.
Diese Untersttzung eines Geschftsprozesses wird in den ITIL Best Practices als Service bezeichnet. Den Service definiert ITIL (Version 3) als:
Service:
Eine Mglichkeit, einen Mehrwert fr Kunden zu erbringen, indem das
Erreichen der von den Kunden angestrebten Ergebnisse erleichtert oder
gefrdert wird. Dabei mssen die Kunden selbst keine Verantwortung fr
bestimmte Kosten und Risiken tragen.

In dieser neuen Definition des Service werden die Erbringung eines


Mehrwertes fr den Kunden und die angestrebten Ergebnisse herausgestellt. Damit unterstreicht die ITIL Version 3 die beabsichtigte Business
Integration. Es wird nicht nur ein Service bereitgestellt, sondern er muss
auch die angestrebten Ergebnisse erzielen und einen Mehrwert fr das
Business erbringen. ITIL Version 3 spricht hier von einer ergebnisbasierten
Definition des IT Service: Was ist das Ergebnis bzw. der Mehrwert des IT
Service fr den Geschftsprozess?.

12

2.4 Die Struktur gem ITIL Version 3


Damit verbunden ist auch die Erweiterung der Definition fr den IT Service (aus Service Strategy, [OGC, 2007a]). Hier wird der allgemeine Begriff des Service auf den Bereich der IT konkretisiert:
IT Service:
Ein Service, der fr einen oder mehrere Kunden von einem IT Service Provider
bereitgestellt wird. Ein IT Service basiert auf dem Einsatz der Informationstechnologie und untersttzt die Business-Prozesse des Kunden. Ein IT Service
besteht aus einer Kombination von Personen, Prozessen und Technologie und
sollte in einem Service Level Agreement definiert werden.

Sinngem lsst sich der IT Service also wie folgt definieren:


IT Services werden von einem IT Service Provider fr einen oder
mehrere 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.
IT Services erbringen einen Mehrwert fr Kunden.
Ein IT Service ist demzufolge mehr als die Bereitstellung einer Technologie.
Der IT Service Provider muss zur Bereitstellung des IT Service nicht nur
die geeignete Technik, sondern auch ber entsprechend qualifiziertes Personal und auf den IT Service ausgerichtete Prozesse verfgen.
Innerhalb der Publikation Service Strategy werden diese Grundlagen
und der Bezug eines IT Service zu den Geschftsprozessen des Business
deutlich herausgestellt. Letztendlich stellen die IT Services die Geschftsprozesse des Business sicher bzw. stellen den IT Service aus Sicht des
Kunden dar (Abbildung 4, auf Basis Service Strategy, [OGC, 2007a]).
Die Abbildung zeigt die Ausrichtung der IT Services auf das Business und
die Business Prozesse. Der IT Service Provider verfgt ber spezielle Ressourcen und Fhigkeiten. ITIL V3 bezeichnet diese Ressourcen und Fhigkeiten als Service Assets, die im nachfolgenden Kapitel Service Strategy nher betrachtet werden. Mithilfe dieser Ressourcen und Fhigkeiten wird dem Business der notwendige IT Service bereitgestellt, der in die
Business Prozesse integriert ist. Teilweise ist, wie zum Beispiel fr WebShops, der IT Service mit dem Business Prozess gleichzusetzen (rechter
mittlerer Teil der Abbildung). Letztendlich dienen die Business Prozesse
dazu, dem Kunden der Organisation einen Service oder ein Produkt zu
liefern. Hier wird die Leistungsfhigkeit der Organisation fr den Kunden
als Ganzes erlebbar.

13

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

Business
Service

Business Prozesse

IT Services
IT
Service

IT
Service

IT
Service

IT
Service

Ressourcen und Fhigkeiten


Internet

Abbildung 4:

Die Ausrichtung der IT Services auf das Business

IT Services bestehen in der Regel aus verschiedenen technischen Systemen,


Applikationen und Teilleistungen mit unterschiedlichen Verantwortungen
und 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]):
Service Owner (Serviceverantwortlicher):
Eine Rolle, die fr die Bereitstellung eines bestimmten IT Service verantwortlich
ist.

Demzufolge ist der Service Owner verantwortlich fr einen spezifischen IT


Service, unabhngig davon, wo innerhalb der Organisation die zugrunde
liegenden Ressourcen und Fhigkeiten, wie zum Beispiel technologischen
Komponenten oder Applikationen angesiedelt sind. In vielen IT-Organisationen hat sich diese Rolle bereits etabliert, wenn auch zum Teil unter ei-

14

2.4 Die Struktur gem ITIL Version 3


nem anderen Namen. Hufig wird diese Rolle als Service Manager bezeichnet. Da innerhalb der ITIL Best Practice mit der Version 3 auch die
Rolle des Service Managers beschrieben wird, gilt es, innerhalb der jeweiligen IT-Organisation eindeutige Bezeichnungen und Rollendefinitionen
zu finden.
In der Vergangenheit fhrte die Bezeichnung IT Infrastructure Library zu Missverstndnissen. So wurde der Begriff Infrastructure flschlicherweise dahingehend interpretiert, dass die ITIL Best Practice lediglich
auf den Bereich der Infrastruktur der IT-Organisationen anzuwenden sei
und zum Beispiel die Applikationen nicht im Betrachtungsbereich von
ITIL liegen. Mit der neuen Version ist ITIL nicht mehr die Abkrzung fr
IT Infrastructure Library, sondern ITIL ist nun ein Synonym fr Service
Management.
Hierzu definiert die ITIL Version 3 den Begriff ITIL wie folgt:
ITIL:
Ein Satz an Best Practice-Leitlinien fr das IT Service Management. Inhaber von
ITIL ist das OGC. ITIL umfasst eine Reihe von Publikationen, die Leitlinien zur
Bereitstellung von qualittsbasierten IT Services sowie zu den Prozessen und
Einrichtungen bieten, die zur Untersttzung dieser Services erforderlich sind.

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:
Das Service Management ist die Gesamtheit der spezialisierten organisatorischen Fhigkeiten, die zur Generierung eines Mehrwerts fr Kunden in Form
von Services verfgbar 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),
die 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).

15

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

Innerhalb der Informationstechnologie haben sich traditionell die Phasen


Plan (Planung), Build (Entwicklung, Erstellung) und Run (Betrieb,
Produktion) etabliert:
Die Phase Plan beinhaltet dabei in der Regel den ganzheitlichen
Blick auf die Informationstechnologie und die Ausrichtung an den
Anforderungen des Unternehmens.
Innerhalb von Build werden darauf aufbauend die notwendigen
IT-Systeme konzipiert, entwickelt und beschafft.
Innerhalb von Run werden die Systeme betrieben und die Leistungen fr die Kunden zur Verfgung gestellt.
Diese bewhrte Struktur hat die ITIL V3 konzeptionell aufgegriffen und
mit einem umfassenden kontinuierlichen Verbesserungsprozess als Service Lifecycle beschrieben. Ausgehend von der strategischen Ausrichtung
und Definition des IT Service (Service Strategy) werden die IT Services
entwickelt (Service Design) und in die Produktion bzw. in den Betrieb
berfhrt (Service Transition). Anschlieend werden die IT Services betrieben und den Geschftsprozessen zur Verfgung gestellt (Service Operation). Diese Phasen werden umschlossen von einem kontinuierlichen
Verbesserungsprozess (Continual Service Improvement), der ber alle
Phasen des Service Lifecycle mgliche Verbesserungen identifiziert.
Die Beschreibung dieses Service Lifecycle mit den Best Practices fr jede
einzelne Phase wird als ITIL Core bezeichnet. Der ITIL Core besteht aus den
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])

Diese fnf Core-Publikationen bilden die Phasen eines iterativen und


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

16

2.4 Die Struktur gem ITIL Version 3


Dies soll dem Schutz von Investitionen dienen. Was hier angestrebt wird,
ist ein Kreislauf aus Messen, Lernen und Verbesserung.
Abbildung 5 verdeutlicht das Zusammenspiel dieser 5 Phasen.

Continual
Service
Improvement
Service
Transition

Service
Strategy
Service
Design

Abbildung 5:

Service
Operation

Die 5 Phasen des Service Lifecycle nach ITIL V3.

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

17

18

Change
Management

Service
Tranistion

Abbildung 6:

CSI

Definition
Metriken

Lsen
& Wiederherstellen

Risiken
optimieren

Verhandeln/
Vereinbaren

Definition des
Marktes

Service
Reporting

Incident
Management

Service Asset
Configuration
Management

Service
Level
Management

Demand
Management

Integrierter Ablauf der Lifecycle Elemente

Service
Measurement

Request
Fulfilment

Supplier
Management

Service
Design
Package

Service
Performance
Reports

Strategie
Generierung

Service
Strategie

Analyse

Monitoring
& Aktionen

Verifizieren

Entwicklung
Angebote

Entwicklung
Angebote

Improvement

Event
Management

Release &
Deployment
Management

Service
Portfolio
Management

Service
Portfolio
Management

Service
Operation

Early
Life
Support

Service
Design

Service
Level
Package

2 IT Service Management

2.4 Die Struktur gem ITIL Version 3


Eine der wichtigsten Aufgaben der Service Strategy ist die Definition des
Serviceportfolios. Mittels des so genannten Service Level Package werden IT Services beschrieben, die den Kunden zur Verfgung gestellt werden und innerhalb von Service Design zu entwickeln sind. Die in Service
Design entwickelten IT Services werden mittels so genannter Service Design Packages dokumentiert und Service Transition bergeben. Mittels
Service Transition wird der IT Service in den IT-Betrieb berfhrt. Service
Transition endet nicht mit der berfhrung des IT Service in den Betrieb,
sondern beinhaltet den Support fr eine bestimmte Zeitspanne nach seiner
Freigabe (Early Life Support). Innerhalb von Service Operations wird der
IT Service dem Kunden zur Verfgung gestellt. Aus der Phase des Service
Operation werden dann Service Performance Reports generiert, die im
Continual Service Improvement analysiert werden und Aufschluss ber
mgliche Verbesserungsmanahmen geben.
Zu jeder dieser Phasen des Service Lifecycle beschreibt jeweils eine ITILPublikation die Best Practice und gibt so einen Leitfaden zur Ausgestaltung dieser Phase. Dabei sind nicht nur die relevanten IT Service Management-Prozesse beschrieben, sondern unter anderem auch die phasenbezogenen Prinzipien, Methoden und Aspekte der Implementierung. So wird
zum Beispiel innerhalb von Service Design auf Aspekte wie der Business
Impact Analysis, der Risiko Analyse von Services und Prozessen sowie
von Sourcing Prinzipien eingegangen.
Die IT Service Management-Prozesse werden jeweils innerhalb der relevanten Service Lifecycle-Phase beschrieben. Dadurch wird sichergestellt,
dass die Prozesse grundstzlich nur in einer Publikation beschrieben sind.
Einzige Ausnahme bildet hier das Service Level Management. Beim Service Level Management werden die wesentlichen Aspekte innerhalb von
Service Design beschrieben. Ergnzungen hierzu finden sich noch im Continual Service Improvement.
Im Fall des Incidents Managements (Strungs-Management) ist die Zuordnung zu Service Operation offensichtlich. Die Zielsetzung des Incident
Managements besteht in der schnellstmglichen Wiederherstellung des IT
Service fr die Anwender. Da Service Operation das tgliche Management
eines IT Service, eines Systems oder eines anderen Configuration Item
beschreibt, ist der Incident Management-Prozess ein wichtiger Bestandteil
dieser Phase des Service Lifecycle.
Es gibt aber auch Prozesse, die phasenbergreifend Aktivitten beschreiben und anzuwenden sind. Als Beispiel fr die phasenbergreifende Anwendung von Prozessen dient der Prozess des Change Managements.
Dieser Prozess ist fr die Steuerung des Lebenszyklus aller Changes verantwortlich. Wichtigstes Ziel des Change Managements ist es, die Durchfhrung von lohnenden Changes bei einer minimalen Unterbrechung der

19

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

Abbildung 7 veranschaulicht die Prozesse der einzelnen Phasen und ihren


Wirkungsbereich (vereinfachte Darstellung aus The Official Introduction
to Service Lifecycle ([OGC, 2007e]).
Dieser ITIL Core soll von der OGC sukzessive um weitere Komponenten
ergnzt werden und in ihrer Summe die gesamte ITIL Library ausmachen:
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.
Ergnzt werden diese offiziellen Publikationen der OGC um eine allgemeine Einfhrung The Official Introduction to Service Lifecycle ([OGC,
2007e]).

2.4.2

Service Strategy

Im Zentrum des dargestellten Service Lifecycle steht die Phase Service Strategy (vgl. [OGC, 2007a]). Hier werden die strategischen Entscheidungen
getroffen. Es geht um das Design, die Entwicklung und Implementierung
des Service Managements nicht nur im organisatorischen, sondern vielmehr im strategischen Sinne.
Service Management Richtlinien (Policies), Anleitungen und Prozesse ber
den gesamten ITIL Service-Lebenszyklus hinweg werden hier entwickelt
und untersttzt. Service Strategy bildet im Kern des Kreislaufs das zentrale
strategische Fundament fr die Phasen Service Design, Service Transition,
Service Operation und den alles umfassenden permanenten Verbesserungskreislaufs des Continual Service Improvement.

20

2.4 Die Struktur gem ITIL Version 3

Service Lifecycle
Governance Prozesse
Service
Strategy

Operational Service Lifecycle Prozessezb

Continual Service
Improvement

Service
Design

Service
Transition

Service
Operation

IT Financial Management
Service Portfolio
Management

Service
Measurement

Strategie
Generierung

Service
Reporting

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

Service
Improvement

IT Service Continuity Management


IT Security Management
Supplier Management
Transition Planning
Change Management

Service Asset and Configuration Management


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

Service Lifecycle und Prozesse

Ausgangspunkt der Phase Service Strategy sind die Identifizierung, Auswahl und Priorisierung von Geschftschancen und Marktpltzen. Betrachtungen und Analysen der Marktentwicklung und die Definition von Zielen und Erwartungen fhren zur Formulierung von Serviceleistungen
gegenber Kunden und Marktpltzen. Marktpltze sind nicht nur fr IT
Service Provider zu definieren, die ihre Leistungen auf dem Markt anbieten, sondern auch fr interne IT-Bereiche. Hierzu gilt es, auch die Frage zu

21

2 IT Service Management
beantworten: Wie knnen wir uns von der Konkurrenz bzw. externen
Dienstleistern abheben?.
Innerhalb der Service Strategy gilt es, auf Basis dieser Fragestellung geeignete Servicestrukturen zu entwickeln, die eigenen Strken zu erkennen
und kritisch zu prfen, welche externen Leistungen einbezogen werden
sollten. Heute kann keine IT-Organisation mehr alle Ressourcen und Fhigkeiten mit eigenen Ressourcen produzieren. Es gilt demzufolge, durch
die Konzentration auf die Alleinstellungsmerkmale und die Einbeziehung
geeigneter Lieferanten (Supplier) zweckmige Servicestrukturen zu konzipieren.
Mit Untersttzung des IT Financial Managements werden ein Serviceportfolio definiert und die Entwicklung eines Servicekatalogs vorbereitet.
Hierzu werden vom IT Financial Management Kostenmodelle entwickelt
sowie Return on Investment und Return on Value-Berechnungen angestellt.
Unter Bercksichtigung der Aktivitten im IT Financial Management kann
die zuvor auf Seite 18 dargestellte Abbildung 6: Integrierter Ablauf der
Lifecycle Elemente aus dem Kapitel 2.4.1 ITIL und der Service Lifecycle nun wie folgt detailliert werden (Auszug aus der Darstellung in The
Official Introduction to Service Lifecycle ([OGC, 2007e]):

Gelegenheiten und Grenzen

Kostenmodelle

Return on Investment

Return on Value

IT Financial Management
Service
Level
Package

Service
Strategie
Strategie
Generierung

Definition des
Marktes

Demand
Management

Entwicklung
Angebote

Service
Portfolio
Management

Service Design

Abbildung 8:

Elemente Service Strategy

Mit der ITIL V3 nimmt das Serviceportfolio eine wichtige Funktion im


Service Management ein. Innerhalb der Service Strategy wird definiert,
welche IT Services zur Untersttzung der Geschftsprozesse zu liefern
bzw. zu entwickeln sind. Diese IT Services werden im Serviceportfolio
dokumentiert. Dagegen enthlt der bereits aus ITIL V2 bekannte Servicekatalog lediglich die IT Services, die sich in der Nutzung bzw. im bergang in die Betriebsumgebung befinden.

22

2.4 Die Struktur gem ITIL Version 3


Innerhalb von Service Strategy gilt es, nicht nur zu entscheiden, welche IT
Services zu liefern und zu entwickeln sind, sondern auch, welche IT Services auer Kraft gesetzt werden sollen. Auch diese IT Services sind dem
Serviceportfolio zu entnehmen. Insbesondere die Entscheidung ber und
die Kennzeichnung der auer Kraft gesetzten IT Services sind fr einen
wirtschaftlichen IT-Betrieb wichtige Informationen, da die damit freigesetzten Ressourcen fr andere IT Services zur Verfgung stehen und so
ggf. zustzliche Beschaffungen vermieden werden.
Fr das Serviceportfolio und die beschriebenen Phasen werden mit der
ITIL V3 folgende Begriffe geprgt ([OGC, 2007a]):
Serviceportfolio:
Die Gesamtheit aller Services, die von einem Service Provider verwaltet werden.
Das Serviceportfolio wird fr das Management des gesamten Lebenszyklus aller
Services genutzt. Es umfasst drei Kategorien: Servicepipeline (beantragt oder in
der Entwicklung), Servicekatalog (Live oder bereit zum Deployment) und auer
Kraft gesetzte Services.
Servicepipeline:
Eine Datenbank oder ein strukturiertes Dokument, in dem alle IT Services
aufgelistet sind, die zur Diskussion stehen oder sich in der Entwicklung befinden
und noch nicht fr den Kunden verfgbar sind. Die Servicepipeline bietet einen
berblick ber mgliche zuknftige IT Services und ist Teil des Serviceportfolios, das in der Regel nicht an die Kunden weitergegeben wird.
Servicekatalog:
Eine Datenbank oder ein strukturiertes Dokument mit Informationen zu allen
Live IT Services, einschlielich der Services, die fr das Deployment verfgbar
sind. Der Servicekatalog ist der einzige Bestandteil des Serviceportfolios, der an
die Kunden ausgehndigt wird. Er untersttzt den Vertrieb und die Bereitstellung von IT Services. Der Servicekatalog enthlt Angaben zu Lieferergebnissen,
Preisen, Bestellungen und Anfragen sowie Kontaktinformationen.
Auerkraftsetzen:
Die dauerhafte Entfernung eines IT Service oder eines anderen Configuration
Items aus der Live-Umgebung. Das Auerkraftsetzen ist bei vielen Configuration
Items Bestandteil des Lebenszyklus.

Letztendlich ist jeder IT Service mit einem Status verknpft, ber den eine
eindeutige Zuordnung mglich wird. Die folgende Abbildung 9 aus [KESS,
2007d] veranschaulicht diesen Zusammenhang:

23

Service Status:
Requirements
Defined
Analyzed
Approved

Chartered
Designed
Developed
Built
Test
Released
Operational
Retired

Servicepipeline

Servicekatalog

Serviceportfolio

Service Lifecycle

2 IT Service Management

Auerkraftgesetzte Services

Abbildung 9:

Serviceportfolio und die einzelnen Stati

Die Definition des Serviceportfolios und dessen Integration in die aktuellen und
zuknftigen Geschftsprozesse ist eine der wichtigsten Aufgaben von Service
Strategy.

Auch Themen wie Organisationsentwicklung sowie Kosten- und Risikobetrachtungen im Hinblick auf das Serviceportfolio werden angegangen.
Neben dem Faktor operationelle Effizienz geht es entscheidend um ganzheitliche, nachhaltige und effektvolle Entscheidungen und Leistungen und
deren Entwicklung. Strategische Reviews helfen, Fhigkeiten zu verbessern, und tragen zum weiteren Ausbau von Geschftsstrategien und
-chancen bei.
Das Fazit in einem kurzen Satz wre wohl, die Service Strategy folgendermaen zu formulieren: Erst das WAS, dann das WIE!
Im gesamten Service Lifecycle wird eines sehr deutlich: die Ausrichtung
der IT Services an den Anforderungen und am wirklichen Bedarf des Kunden und seines Geschftes. Dieses Ziel wird stringent verfolgt. IT Services
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 10).

24

2.4 Die Struktur gem ITIL Version 3


Geschftsprozess
Nutzt den IT Service
Nimmt Leistungen in Anspruch

Integration in Geschftsprozess
ermglicht Wertbeitrag

IT Service
IT Service Provider

Fhigkeiten und Ressourcen


IT-Infrastruktur

Personen

Configuration Items

Organisation

Andere Elemente

Geld

IT Service

Prozesse

Abbildung 10:

Anwendungen

Verbindung zwischen IT Service und Business-Service

Business Service Management:


Ein Ansatz zur Verwaltung von IT Services, bei dem die untersttzten BusinessProzesse und der Geschftswert bercksichtigt werden. Dieser Begriff bezeichnet
darber hinaus die Verwaltung von Business-Services, die fr Business-Kunden
bereitgestellt werden.

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

25

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

Zweckmig?

Die Service Utility hilft dem Kunden in der Steigerung der Produktivitt
seiner Geschftsprozesse, whrend die Service Warranty die notwendigen
Voraussetzungen wie zum Beispiel Verfgbarkeit und Kapazitt fr den
Betrieb spezifiziert. Der hier beschriebene Zusammenhang lsst sich wie
folgt darstellen (Abbildung 11, aus [OGC, 2007a]):

Untersttzt
Leistung?

Utility
Zwecke erfllt?
ODER

Verschiebt
Grenzen?

W/F

Warranty
Anforderungen
erfllt ?

Wertschaffend?

UND

W/F

W/F

Verfgbar?
Kontinuitt?
Kapazitt?

UND

W/F = wahr / falsch


betriebsfhig?

Sicherheit?

Abbildung 11:

Die Wertebetrachtung eines IT Service

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

26

2.4 Die Struktur gem ITIL Version 3

Strategie Implementierung

Messung
und
Bewertung

Service
Design
Service
Design
Anforderungen
Service
Strategy
Service Portfolio
Service Katalog

Service
Transition
Anforderungen

Service
Transition

Service
Operation
Service
Operation
Anforderungen

Abbildung 12:

2.4.3

Continual
Service
Improvement

Messung
und
Bewertung

Service Strategy als Basis fr den Service Lifecycle

Service Design

Dieses Buch (vgl. [OGC, 2007b]) trgt den Untertitel Building structural
service integrity, was sehr prgnant die Zielsetzung dieser Phase des
Service Lifecycle wiedergibt. Die Integritt des Service wird aber nicht nur
von der eingesetzten Technologie gewhrleistet, sondern auch von den
damit in Verbindung stehenden Prozessen.
Beim Service Design sind die folgenden fnf Aspekte zu betrachten:
Das Design der IT Services einschlielich aller funktionellen Erfordernisse, Ressourcen und Fhigkeiten
Das Design von Service Management Systemen und Tools, insbesondere des Serviceportfolios fr das Management und die Steuerung der IT Services whrend des gesamten Lebenszyklus
Das Design der technologischen Architekturen und der Managementsysteme, die erforderlich sind, um den IT Service bereitzustellen
Das Design der Prozesse, die bentigt werden zum Design, Transition, Operation und Improvement der IT Services

27

2 IT Service Management
Das Design der Messsysteme und Metriken der IT Services, der Architekturen, ihrer verbundenen Komponenten und der Prozesse
selbst.
ITIL spricht hier von einem ereignisgesteuerten Ansatz, in dem fr jeden
der genannten Aspekte die gewnschten und geplanten Ergebnisse definiert werden, so dass der gelieferte IT Service den Erwartungen der Kunden und Benutzer entspricht.
Ausgehend von den strategischen Zielen, die in der Phase Service Strategy
definiert wurden, findet hier die Transformation zu einem Portfolio von IT
Services statt. Wichtigstes Ergebnis dieser Stufe ist das Design einer effektiven und effizienten Service-Lsung. Die sich stndig verndernden Anforderungen des Business und der IT erfordern eine stndige Interaktion
mit allen anderen Bereichen und Prozessen.
Abbildung 13 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.
Service
Level
Package

Service Strategy

Supplier
Management
Service
Design
Package

Verhandeln/
Vereinbaren

Design ausgewogener Zuverlssigkeit


Availability

Service
Level
Management

Anforderungen

Design Lsung

Messsysteme

Capacity

Servicekatalog
Management

Architektur
Security

Service
Design

Compliance
Continuity

Service Transition

Abbildung 13:

Service Design Aufgaben und Einbindung

Dies beinhaltet auch nderungen und Verbesserungen, die notwendig


werden, um sowohl den Wert der IT Services fr den Kunden ber den
Lebenszyklus der IT Services hinweg zu erhalten, als auch die Kontinuitt
der IT Services, das Erreichen der Service-Qualitt (Service Level-Ziele)
und die Konformitt zu Standards und Regeln.

28

2.4 Die Struktur gem ITIL Version 3


Die Aufgaben des Service Design und die Einbindung in den Service Lifecycle stellen sich wie in Abbildung 13 dar (Auszug aus der Darstellung in
The Official Introduction to Service Lifecycle ([OGC, 2007e]).
Bevor ein neuer IT Service oder eine nderung an einem bestehenden IT
Service entwickelt wird, sind die damit verbundenen Kundenanforderungen aufzunehmen und zu analysieren. Eine damit verbundene Aufgabe ist
die Analyse der bestehenden Fhigkeiten innerhalb der eigenen Organisation. Der Begriff der Fhigkeiten ist hier im Kontext zur Begriffsdefinition
gem ITIL V3 zu verstehen:
Fhigkeit (Capability):
Die Fhigkeit einer Organisation, einer Person, eines Prozesses, einer
Anwendung, eines Configuration Item oder eines IT Service zur Durchfhrung
einer Aktivitt. Fhigkeiten gehren zu den nicht greifbaren Assets einer
Organisation.

Gibt es zwischen bestehenden Fhigkeiten und den notwendigen Fhigkeiten fr den neuen bzw. zu ndernden IT Service Diskrepanzen, so sind
geeignete Manahmen zu konzipieren. Dabei ist es nicht unbedingt erforderlich, die notwendigen Fhigkeiten innerhalb der eigenen IT-Organisation aufzubauen. Die zustzlichen Fhigkeiten knnen auch extern bezogen
werden. Innerhalb von Service Design werden hierzu Delivery Model
Options zur Integration von externen Lieferanten und Partnern beschrieben.

Serviceportfolio
Beschreibung
Wertbeitrag
Geschftsplne
(Business Cases)
Prioritten
Risiken
Angebote und
Einheiten
Kosten und
Preisgestaltung

Abbildung 14:

Servicekatalog(e)
Services
Untersttzte Produkte
Richtlinien (Policies)
Bestellung und
erforderliche Prozesse
Untersttzte Liefer- und
Zahlungsbedingungen
Eingangspunkt und
Eskalationen
Preisgestaltung und
Verrechnung

Vom Serviceportfolio zum Servicekatalog

29

2 IT Service Management
Das Serviceportfolio ist eine zentrale Informationsquelle innerhalb des Service Lifecycle. Dem Serviceportfolio knnen smtliche IT Services und
deren jeweiliger Status entnommen werden. Zustzlich knnen weitere
Details zum IT Service, dessen Schnittstellen und die Abhngigkeiten zu
anderen IT Services hinterlegt werden. Eine Teilmenge des Serviceportfolios ist der Servicekatalog mit den Informationen zu smtlichen in der Nutzung und der berfhrung in die Betriebsumgebung befindlichen IT Services. Abbildung 14 beschreibt die Inhalte des Serviceportfolios und des
Servicekatalogs (aus [KESS, 2007d]).
Verbunden mit der Integration des IT Service in den Geschftsprozess des
Kunden entsteht die Notwendigkeit, diesen IT Service innerhalb der ITOrganisation zu strukturieren. Besteht der IT Service zum Beispiel in der
Form eines Personalverwaltungssystems, so knnte dieser IT Service in
den Betrieb eines Servers, eines LAN, einer Datenbank usw. verfeinert
strukturiert werden. Zur besseren Abgrenzung bezeichnet ITIL V3 diesen
IT Service als Business-Service:
Business-Service:
Ein IT Service, der einen Business-Prozess direkt untersttzt, im Gegensatz zu
einem Infrastrukturservice, der intern vom IT Service Provider eingesetzt wird
und der in der Regel nicht vom Business wahrgenommen wird. Der Begriff
Business-Service bezeichnet darber hinaus einen Service, der von einem
Geschftsbereich fr Business-Kunden erbracht wird. Dazu gehren beispielsweise die Bereitstellung von Finanzdienstleistungen fr Kunden einer Bank oder
die Lieferung von Waren an Kunden eines Einzelhandelsgeschfts. Die erfolgreiche Bereitstellung von Business-Services hngt hufig von einem oder mehreren
IT Services ab.

Es ist eine wesentliche Aufgabe innerhalb des Service Design, diese Business-Services so zu gestalten, dass sie die sich ndernden Anforderungen
der Kunden und deren Geschftsprozesse erfllen. Hierzu sind die notwendigen untersttzenden IT Services zu bestimmen und auszugestalten.
Der Prozess des Servicekatalog Managements hat zum Ziel, dass ein Servicekatalog erstellt und gepflegt wird, der diese Informationen ber alle operationellen IT Services enthlt, die fr den operativen Betrieb vorbereitet
werden. Hierzu werden zwei unterschiedliche Sichten zur Verfgung
gestellt. Fr den Kunden werden die Business-Services prsentiert, whrend innerhalb der IT die damit verbundenen (internen) IT Services in
Verbindung gebracht werden (aus [OGC, 2007b]):

30

2.4 Die Struktur gem ITIL Version 3

Business
Prozess 1

Business
Prozess 2

Business
Prozess 3

Business Servicekatalog

Service A

Service B

Service C

Service D

Service E

Applikationen

Daten

Technischer Servicekatalog

Support
Services

Abbildung 15:

Hardware

Software

Die Inhalte und Sichten des Servicekatalogs

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

31

2 IT Service Management
Ist der IT Service vollstndig entwickelt, ist die Phase Service Transition
verantwortlich fr die berfhrung des IT Service in den operativen Betrieb.

2.4.4

Service Transition

Die Phase Service Transition (vgl. [OGC, 2007c]) umfasst das Management
und die Koordination von Prozessen, Systemen und Funktionen, um ein
Release zu paketieren, zu bauen, zu testen, auszuliefern und in die Produktion zu bernehmen und die durch Kunden und Stakeholder spezifizierten Anforderungen umzusetzen.
Hierzu werden die Anforderungen aus den Phasen Service Strategy und
Service Design fr ein effektives Service Operation realisiert.
Hier findet das Management komplexer Changes 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.
Die Aufgaben der Phase Service Transition sind Abbildung 16 zu entnehmen (Darstellung aus The Official Introduction to Service Lifecycle
([OGC, 2007f]):
Service Design

Service
Design
Package
Qualittssicherung

Service Abnahme

Planung & Support

Konformitt

Utility und Warranty

Validierung & Testen

Entscheidung Fhigkeiten

Evaluierung

Knowledge

Service
Transition
Change
Optimierung Riskien
Management

Service Asset &


Configuration
Management

Verifizieren

Release &
Deployment
Management

Early
Life
Support

Service Operation

Abbildung 16:

Service Transition-Prozesse

Innerhalb von Service Transition haben die Prozesse Change Management, Service Asset und Configuration Management und Release und
Deployment Management eine besondere Bedeutung. Smtliche Prozesse

32

2.4 Die Struktur gem ITIL Version 3


von Service Transition knnen dem Abschnitt 2.5.2.3 Service
on entnommen werden.

Transiti-

Jegliche Vernderung eines stabilen laufenden Systems ist mit Risiken


verbunden. Das Change Management hat zum Ziel, die notwendigen
Changes mit minimaler Unterbrechung der IT Services zu implementieren.
Hierzu sind die einzelnen Changes zu bewerten, zu planen und so die
damit verbundenen Risiken zu reduzieren. Die Verantwortung fr die
Autorisierung und Umsetzung von Changes liegt in der Rolle des Change
Managers. Diese Bewertung kann bei umfassenden Changes nicht von
einer Person allein mit einer ausreichenden Sicherheit durchgefhrt werden. Daher hat sich die Untersttzung des Change Managers durch das so
genannte Change Advisory Board (CAB) bewhrt:
Change Advisory Board (CAB)
Eine Gruppe von Personen, die den Change Manager bei der Bewertung,
Festlegung von Prioritten und zeitlichen Planung in Bezug auf Changes
beraten. Dieses Gremium setzt sich in der Regel aus Vertretern aller Bereiche des
IT Service Providers, dem Business und den Drittparteien wie z. B Suppliern
zusammen.

Damit mgliche Auswirkungen von Changes beurteilt werden knnen,


bentigt das Change Management Informationen zu den betroffenen IT
Services und den damit in Verbindung stehenden Komponenten.
Die Pflege dieser Informationen zu den Komponenten liegt in der Verantwortung des Configuration und Service Asset Managements. In ITIL
werden diese Komponenten als Configuration Items (CIs) bezeichnet:
Configuration Item (CI):
Alle Komponenten, die verwaltet werden mssen, um einen IT Service
bereitstellen zu knnen. Informationen zu den einzelnen CIs werden in einem
Configuration Record innerhalb des Configuration Management Systems erfasst
und ber den gesamten Lebenszyklus hinweg vom Configuration Management
verwaltet. CIs unterstehen der Steuerung und Kontrolle des Change
Management. CIs umfassen vor allem IT Services, Hardware, Software,
Gebude, Personen und formale Dokumentationen, beispielsweise zum Prozess
und SLAs.

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

33

Configuration
Items sind
mehr als
Hard- und
Software

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

Die folgende Abbildung 17 (Auszug aus [OGC, 2007c]) verdeutlicht die


mglichen Daten- und Informationsquellen sowie Tools fr ein Configuration Management System:

Projekt
Dokumentation

Definitive
Media
Library

Daten- und
Strukturiert
InformationsQuellen
und Tools

Definitive
Document
Library 1

Projekt
Software

Definitive
Multimedia
Library 1

Abbildung 17:

34

Physikalische
CMDBs

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

CMDB1

CMDB2

wie
Datenbank
Netzwerk,
Mainframe,
Verteilte
Desktop

Human
Ressourcen
Supply Chain
Management
Customer
Relationship
Management

Daten und Informationsquellen fr ein CMS

und
Audit
Tools

2.4 Die Struktur gem ITIL Version 3


Innerhalb des Release und Deployment Managements werden die Releases in den IT-Betrieb bergeleitet. Hierbei ist sicherzustellen, dass das
Release effektiv in einen Einsatzbereich bzw. eine Zielumgebung ausgebracht (deployed) werden kann und die damit verbundenen Geschftsanforderungen erfllt werden.
Die in Service Transition beschriebenen Prozesse lassen sich in die zwei
Gruppen aufteilen:
Prozesse, die den gesamten Service Lifecycle untersttzen
Prozesse innerhalb des Service Transition
Die Gruppe Prozesse, die den Service Lifecycle untersttzen enthlt
einerseits wichtige Prozesse innerhalb von Service Transition, aber diese
Prozesse untersttzen darber hinaus alle Service Lifecycle-Phasen (siehe
Abbildung 7). Diese Prozesse sind:
Service Asset und Configuration Management
Knowledge Management
Change Management
Dagegen sind die folgenden Prozesse auf die Phase Service Transition
fokussiert:

Transition Planning and Support


Release and Deployment Management
Service Testing and Validation
Evaluation

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

35

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

Service Knowledge
Management System
(SKMS)

Entscheidung

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

Abbildung 18:

Service Knowledge Management System

Die Bedeutung des Change Managements und seine Anwendung ber


den gesamten Service Lifecycle wird mit der ITIL V3 deutlich herausgestellt. In einigen IT-Organisationen wird der Umfang des Change Managements auf die Durchfhrung von Changes in der technischen Infrastruktur,
zum Beispiel der Hardware in einem Rechenzentrum, eingegrenzt. Aber
ITIL bringt deutlich zum Ausdruck, dass auch die Einfhrung eines neuen
IT Service oder grere Vernderungen an einem existierenden IT Service
einen Change darstellen und demzufolge in die Verantwortung des Change Managements fallen. In ITIL V3 werden daher die Ebenen des strategischen Change, des taktischen Change und des operationellen Change beschrieben. So werden zum Beispiel strategische Changes ber die
Service Strategy oder das Business Relationship Management eingebracht.
Mit diesem Geltungsbereich des Change Management ber den gesamten
Service Lifecycle und ber alle Bereiche vom Configuration Item bis zum
Serviceportfolio kommt der Definition notwendiger Entscheidungsinstanzen eine groe Bedeutung zu. Die folgende Abbildung 19 (aus OGC,
2007c) stellt ein mgliches Modell fr die verschiedenen Ebenen dar:

36

2.4 Die Struktur gem ITIL Version 3


Kommunikation,
Kommunikation,
Entscheidungen Eskalationen fr RFCs,
und Aktionen
Risiken, Erteilung

Change
Autorisierung

Business
Executive Board

Hohe Kosten/Risiken
Change
erfordert Entscheidung
von Executive

IT
Management Board

Change wirkt sich auf


mehrere Services
oder organisatorische
Abteilungen aus

CAB
oder ECAB

Change wirkt sich


nur lokal oder
auf Service-Gruppe aus

Lokale Autorisierung

Abbildung 19:

Beispiele fr betroffene
Configuration-Ebene

Standard Change

Autorisierungsebenen fr Changes

Sobald die Changes bzw. das Release in den operativen Betrieb bergeleitet sind, wird der neue oder genderte IT Service innerhalb einer bestimmten Zeitspanne untersttzt und dann an Service Operation bergeben
(Early Life Support).

2.4.5

Service Operation

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


Operation). Sie enthlt Anleitungen fr effektive und effiziente Lieferung
und Support der IT Services, um den gewnschten Wert fr die Kunden
und den Service Provider sicherzustellen. Die strategischen Ziele werden
in dieser letzten Stufe letztendlich durch Service Operation realisiert, was
seine kritische Bedeutung erkennen lsst.
Die Anforderungen an neue oder zu verndernde IT Services werden innerhalb von Service Strategy auf Basis der Kunden- und Marktanforderungen getroffen. Innerhalb von Service Design und Service Transition werden die IT Services entwickelt und in den Betrieb bergeleitet. Aber innerhalb von Service Operation wird der IT Service dem Kunden zur Verfgung gestellt und in dessen Geschftsprozesse integriert. Hier wird der IT
Service nutzbar und liefert den erwarteten Mehrwert. So kann Service
Operation mit einer Produktionssttte verglichen werden, in der der IT
Service ausgeliefert wird. Siehe hierzu die Darstellung der Phasen des

37

Hier wird der


IT Service fr
den Kunden
erleb- und
nutzbar

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

Business (Geschftsanforderungen) / Kunden

Service
Strategy

Service
Portfolio

Anforderungen

IT Services

Service
Design

Service
Transition
Service
Katalog

Service
Operation

Operationelle
Services

Continual
Service
Improvement

Abbildung 20:

Improvement
Plne u. Aktionen

Service Operation im Service Lifecycle

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

die Grundkonflikte in Service Operation


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

Service Operation beschreibt mit den vier Grundkonflikten:


interne IT-Sicht versus der externen Sicht,

38

2.4 Die Struktur gem ITIL Version 3


Stabilitt versus Fhigkeit, auf nderungswnsche einzugehen,
Servicequalitt versus Servicekosten und
reaktive versus proaktive Organisation
die Herausforderungen fr den IT-Betrieb. Zwischen den konkurrierenden
Anforderungen wie Stabilitt und der Fhigkeit, auf nderungswnsche
des Kunden einzugehen, gilt es, fr die eigene IT-Organisation eine angemessene Balance zu finden. Steht zum Beispiel die Stabilitt zu sehr im
Vordergrund, so werden die nderungswnsche des Kunden nicht rechtzeitig umgesetzt, und die IT-Untersttzung fr die Geschftsprozesse
wird als unzureichend angesehen. Werden aber alle nderungswnsche
sehr schnell umgesetzt, so besteht die Gefahr eines instabilen IT-Betriebs.
Innerhalb von Service Operation kann hinsichtlich der geeigneten Ausprgung kein Patentrezept geliefert werden, sondern es werden fr die jeweilige Betrachtung mgliche Risiken beschrieben und Best Practices beschrieben, wie sich die Balance erzielen lsst.
Auch fr die Phase Service Operation werden Best Practices notwendiger
Prozesse beschrieben. Die Anzahl der Prozesse wird gegenber der
ITIL V2 erweitert. Das Zusammenwirken der Service Operation Prozesse ist
in der Abbildung 21 aus [OGC, 2007f] dargestellt.
Early
Life
Support

Service Transition

Request
Fulfilment
Service
Performance
Reports

Lsen/Wiederherstellen

Incident
Management

Monitoring/Aktionen

Event
Management

Service
Operation
Stabilitt

Qualitt

Operationeller Change

Monitor Control Kreislauf


Problem

Performance

Qualitt zu Kosten Feedback


Technologie

Access

Continual Service Improvement

Abbildung 21:

Service Operation-Prozesse

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

39

2 IT Service Management
die freie Kapazitt eines Speicherbereichs einen Grenzwert erreicht. Dadurch kann in Service Operation schneller reagiert werden, und die Servicequalitt wird verbessert. Knnen zu einzelnen Events automatisierte
Aktionen hinterlegt werden, so trgt das Event Management zu einer Verringerung der Aufwendungen in Service Operation bei.
ITIL stellt bei der Beschreibung heraus, dass ein Event einen Incident, ein
Problem oder einen Change generieren kann. In den meisten Fllen wird
ein Event zu einem Incident Record fhren.
Das Ziel des Incident Management mit der Wiederherstellung des normalen Service-Betriebs ist gegenber der Version 2 unverndert geblieben. Der normale Service-Betrieb ist hier als Einhaltung der Vorgaben
aus den SLAs zu verstehen. Da es im Rahmen der Umsetzung der ITIL
Best Practice noch Abgrenzungsschwierigkeiten zwischen Incident und
Problem gibt, wird in der Version 3 deutlich herausgestellt, dass ein
Incident immer ein Incident bleibt. Ein Incident kann ein zustzliches
Problem hervorrufen, wandelt aber niemals seinen Status oder seine Eigenschaft in ein Problem.
An Service Operation werden von den Anwendern aber nicht nur Incidents herangetragen, sondern auch so genannte Service Requests.
Service Request
Eine Anfrage eines Anwenders nach Informationen, Beratung, einem StandardChange oder nach Zugriff auf einen IT Service. Dabei knnte es sich beispielsweise um das Zurcksetzen eines Passworts oder die Bereitstellung standardmiger IT Services fr einen neuen Anwender handeln. Service Requests werden in der Regel von einem Service Desk bearbeitet und erfordern blicherweise
nicht die Einreichung eines RfC.

Mit dem Request Fulfilment wird ein Prozess beschrieben, in dem diese
Service Requests bearbeitet werden. Dieser Prozess wurde in den frheren
Versionen von ITIL zwar nicht beschrieben, aber in vielen IT-Organisationen existiert dieser Prozess bereits und wird zum Teil als AnforderungsManagement bezeichnet.
Whrend das Incident Management den IT Service schnellstmglich wiederherstellen soll, hat das Problem Management die zugrunde liegende
Ursache zu identifizieren und Bekannte Fehler (Known Error) zu dokumentieren, so dass das Incident Management auf dieses Wissen zurckgreifen und auftretende Strungen schneller beheben kann. Gegenber der
ITIL Version 2 wurde das proaktive Problem Management in die Phase
des Continual Service Improvement verlagert.

40

2.4 Die Struktur gem ITIL Version 3


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

Event Management

Incident

Workaround

Known
Error
Record

Abbildung 22:

Incident
Management

Event

Service
Request

Request
Fulfilment

Change
Record

Problem
Management
Known
Error
Datenbank

Prozesse aus Service Operation

Mit dem Access Management wird ein zustzlicher Prozess beschrieben, der
fr die Zulassung der Nutzung von IT Services verantwortlich ist; insbesondere im Rahmen der stetig steigenden Compliance Anforderungen eine
sehr wichtige Aufgabenstellung innerhalb von Service Operation.
Neben diesen innerhalb von Service Operation etablierten Prozessen werden die Prozessaktivitten beschrieben, die in den anderen Phasen des
Service Lifecycle beheimatet sind, beispielhaft wird auf Aktivitten von
Service Operation im Rahmen des Change Management eingegangen.
Fr die Organisation des Service Operation beschreibt ITIL als Organisationseinheiten so genannte Funktionen, innerhalb derer bestimmte
Aktivitten durchzufhren sind. Die folgende Abbildung 23 stellt diese
Funktionen dar (aus [OGC, 2007d]):

41

2 IT Service Management

Service Desk

Technical
Management

IT Operations
Management

Application
Management

Operations
Control
Facility
Management

Abbildung 23:

Service Operation-Funktionen

Der Service Desk ist der Single Point of Contact (SPOC) fr die Kommunikation zwischen Service Provider und Anwendern. Ein Service Desk bearbeitet in der Regel Incidents und Service Requests und ist fr die Kommunikation mit den Anwendern zustndig. Das Technical Management ist
verantwortlich fr die Bereitstellung von technischem Fachwissen zur
Untersttzung von IT Services und fr das Management der ITInfrastruktur. Das IT Operations Management fhrt die tglichen Aktivitten durch, die zur Verwaltung von IT Services und Untersttzung der
IT-Infrastruktur erforderlich sind, wie zum Beispiel Backup und Restore.
Das Application Management ist fr die Verwaltung von Anwendungen
whrend ihres gesamten Lebenszyklus verantwortlich.

2.4.6

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

42

2.4 Die Struktur gem ITIL Version 3


tion) und Betrieb (Operation) der IT Services. Aber auch die Service Strategy erfhrt aus dem Continual Service Improvement ein Feedback.
Siehe hierzu die bergreifende Aufgabenstellung des Continual Service
Improvement auf Basis der Darstellung in Continual Service Improvement, [OGC, 2007e] (siehe Abbildung 24).

Continual
Service
Improvement

Messung
Bewertung/Feedback
Service
Transition

Messung
Bewertung/Feedback
Service
Strategy
Service
Design

Service
Operation

Messung
Bewertung/Feedback

Abbildung 24:

Continual Service Improvement

Sharon Taylor, Chief Architect des Refresh Programms zur ITIL V3, verglich den Service Lifecycle mit einem Rad, wobei das Rad vom Continual
Service Improvement umgeben wird, den gesamten Service Lifecycle
durchdringt und fr die Fortbewegung steht und einen Beharrungszustand innerhalb der IT-Organisation verhindert.
Fr eine optimale Untersttzung der Geschftsprozesse mssen die IT
Services und die IT Service Management-Prozesse nach klar definierten
Zielen und mit relevanten Messsystemen implementiert, verwaltet und
untersttzt werden. Hierfr ist es auerordentlich kritisch und wichtig zu
verstehen, was gemessen und warum es gemessen werden muss und Erfolgsfaktoren sorgfltig zu definieren.
ITIL fhrt zu Messung und Management aus:

43

2 IT Service Management
Sie knnen nichts managen, was Sie nicht kontrollieren knnen.
Sie knnen nichts kontrollieren, was Sie nicht messen knnen.
Sie knnen nichts messen, was Sie nicht steuern knnen.

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

Baseline & Metriken

Korrektive Aktionen

7 Step Improvement

Continual
Service
Improvement

Service
Messung

Definition Metriken

Abbildung 25:

Service
Reporting

Analyse

Verbessern

Service
Improvement
Plan

Service Transition-Prozesse

Das wesentliche Element von Continual Service Improvement ist die Messung von IT Services, Prozessen und Service Assets. Der Hauptgrund fr
Messungen besteht darin, die gesetzten Ziele erreichen zu knnen. Durch
Messungen werden mgliche Abweichungen frhzeitig erkannt, und das
Management ist in der Lage, frhzeitig gegensteuern zu knnen. Andererseits kann eine bererfllung vermieden und so die Effizienz sichergestellt werden. Darber hinaus knnen Messungen auch den Erfolg durchgefhrter Manahmen besttigen und so fr das Reporting gegenber
dem Kunden oder innerhalb des Service Providers genutzt werden.
Ein wichtiger Ausgangspunkt, um einen Verbesserungsbedarf herauszustellen und den Erfolg einer durchgefhrten Verbesserung zu besttigen,
besteht in der Etablierung einer definierten Ausgangsbasis (Baseline).

44

2.4 Die Struktur gem ITIL Version 3


Baseline:
Ein Benchmark, der als Referenzpunkt verwendet wird. Beispiel:
Mit einer ITSM-Baseline als Ausgangspunkt knnen die Folgen eines Serviceverbesserungsplans gemessen werden.
Mit einer Performance Baseline knnen nderungen in der Performance whrend der Lebensdauer eines IT Service gemessen werden.

Der 7-Step Improvement-Prozess ist der primre Prozess innerhalb des


Continual Service Improvement (Einzelheiten zum Prozess siehe Abschnitt 2.5.2.5 Continual Service Improvement). Dieser Prozess hat zum
Ziel, ber Daten zu gesicherten Informationen zu gelangen. Durch Analyse dieser Informationen sind anschlieend geeignete Verbesserungsmanahmen zu implementieren. Im Rahmen dieses 7-Step Improvement-Prozesses werden sowohl strategische, als auch taktische und auch operative
Ziele verfolgt und beleuchtet, die innerhalb von Service Strategy und Service Design definiert wurden.
Die identifizierten Verbesserungsmanahmen werden in dem Service Improvement-Plan (SIP) dokumentiert; einem Dokument, das ebenfalls in
Qualittsmanagementsystemen wie der ISO 9001 und der ISO 20000 gefordert wird.
Wichtig fr das Selbstverstndnis dieser Phase des Service Lifecycle ist
auch hier Business-Orientierung. Diese Orientierung zum Kunden und
dessen Geschftsprozessen besteht im Wesentlichen aus zwei Betrachtungsbereichen.
Eine Messung der IT-Systeme hinsichtlich der Verfgbarkeit und Performance ist fr jeden Service Provider selbstverstndlich. ITIL spricht hier
von technologischen Messungen. Auch die Messung der IT Service Management-Prozesse findet zunehmend Anwendung, die so genannten Prozess-Messungen. Aber hierbei handelt es sich in der Regel um eine ITinterne Sicht und Messung. Fr den Kunden ist es viel wichtiger, ob die
gelieferten IT Services den Vereinbarungen entsprechen und die Service
Level-Ziele erreicht werden. Hierzu ist eine Messung der IT Services (aus
Sicht des Kunden bzw. Geschftsprozesses) notwendig. ITIL betont hier:
Service-Messungen:
Diese Messungen sind das Ergebnis eines end-to-end-Service.

Ohne funktionierende IT Services knnen viele Geschftsprozesse nicht


mehr durchgefhrt werden. Daher ist die Messung einzelner Komponenten wie Server oder Datenbanken nicht mehr ausreichend. Der IT Service
ist als Ganzes zu betrachten und zu messen. Die folgenden drei Messungen finden hierbei in der Regel ihre Anwendung:

45

2 IT Service Management
Verfgbarkeit
Zuverlssigkeit
Performance
Der zweite Betrachtungsbereich in Richtung des Kunden und dessen Geschftsprozessen sind die umzusetzenden Verbesserungsmanahmen.
Zielsetzung des Continual Service Improvement ist nicht eine optimierte
IT, sondern eine optimierte Integration der IT Services in die Business Prozesse und deren Anforderungen. Demzufolge ist der Kunde bzw. sind die
Geschftsbereiche in den Entscheidungsprozess der umzusetzenden Verbesserungsmanahmen unbedingt einzubeziehen. Letztendlich kann nur
mit dem Kunden gemeinsam entschieden werden, welche Verbesserungsmanahmen den grten geschftlichen Nutzen bringen.
Eine Schlsselrolle nimmt dabei das Service Level Management ein. Mit
dem Abschluss von Service Level Agreements (SLAs) werden mit dem
Kunden eindeutige Service Level-Ziele vereinbart. Vor dem Abschluss
dieser SLAs ist zu prfen, ob die definierten Ziele berhaupt messbar sind.
Im Rahmen der Lieferung des IT Service sind die erbrachten Service Level
zu messen, zu berichten und zu berprfen.
Mit dem Service Reporting enthlt das Continual Service Improvement
einen Prozess, der fr die Erstellung und Bereitstellung von Berichten zu
den IT Services und den erzielten Service Level verantwortlich ist. Die
Kunden- und Geschftsprozessorientierung findet Bercksichtigung in der
Forderung nach Abstimmung mit dem Kunden bezglich Format, Inhalt
und Hufigkeit der Berichte.
Die Ausrichtung des Service Reportings an der Sicht des Kunden bzw. an
dessen Geschft ist der folgenden Abbildung 26 zu entnehmen (aus [OGC,
2007e]). Von wesentlicher Bedeutung ist es, die gesammelten (technischen)
Daten so aufzubereiten und so zu prsentieren, dass sie der Sicht des Geschfts entsprechen und von Nicht IT-Mitarbeitern verstanden werden
knnen.

46

2.4 Die Struktur gem ITIL Version 3

Das Business
Definition Reporting
Policies und Rollen
Sammlung

Businesssichten

Service
Reporting

bersetzung und
Anwendung

Publikation

Abbildung 26:

Service Reporting orientiert am Kundenbedarf

Das Continual Service Improvement hat vielfltige Schnittstellen zu den


anderen Phasen des Service Lifecycle. Ein Schlsselprozess ist der bereits
beschriebene Prozess des Service Level Managements. Eine weitere wichtige Schnittstelle besteht zum Service Design, denn dort sind die notwendigen Messverfahren beim Design des IT Service zu bercksichtigen und
zu entwickeln.

2.4.7

Der prozessorientierte Ansatz von ITIL Version 3

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

47

2 IT Service Management
Diese umfangreiche Erweiterung mag den Leser vielleicht 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 Organisationen bereits so implementiert sind, wie zum Beispiel das Event Management zur Entdeckung und
Interpretation von Ereignissen, die ber entsprechende Tools generiert
und behandelt werden.
Mit der ITIL Version 3 werden das notwendige Prozess-Management und
die damit verbundenen Aspekte strker hervorgehoben. Als Prozess wird
definiert (vgl. Service Design, [OGC, 2007b]):
Prozess:
Ein strukturierter Satz an Aktivitten, mit deren Hilfe ein bestimmtes Ziel
erreicht werden soll. Ein Prozess wandelt einen oder mehrere definierte Inputs in
definierte Outputs um. Ein Prozess kann beliebige Rollen, Verantwortlichkeiten,
Hilfsmittel und Steuerungen fr das Management enthalten, die fr eine
zuverlssige Bereitstellung der Outputs erforderlich sind. Ein Prozess kann den
Anforderungen entsprechend Richtlinien, Standards, Leitlinien, Aktivitten und
Arbeitsanweisungen definieren.

Prozesse weisen gem ITIL Version 3 die folgenden Merkmale auf:


Messbar:
Die Prozesse sind in einer relevanten Art zu messen. Prozesse sind
leistungsgetrieben. Manager wollen Kosten, 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 27).

48

2.4 Die Struktur gem ITIL Version 3


ProzessOwner

ProzessDokumentation
Trigger

ProzessZiele
ProzessPolicy

ProzessFeedback

Prozesssteuerung

ProzessAktivitten

ProzessInput

ProzessProzeduren

ProzessRollen

ProzessMetriken
Prozess-Arbeits
-anweisungen

ProzessImprovement

Prozessdurchfhrung

ProzessOutput
inklusive
Prozess-Reports
und -Reviews

Prozessbedingungen
ProzessRessourcen

Abbildung 27:

ProzessBefhigungen

ITIL Version 3 Prozessmodell

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

49

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

Bezglich der Verantwortung fr die Prozesse stellt die ITIL Version 3


folgende Anforderungen (vgl. Service Design, [OGC, 2007b):
Jedem Prozess ist ein Process Owner2 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.

50

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

2.4 Die Struktur gem ITIL Version 3


Whrend in der ITIL Version 2 keine exakte Definition und Beschreibung
fr den Process Owner und Prozess-Manager existieren, werden in der
ITIL Version 3 diese Rollen definiert und unterschieden:
Process Owner:
Eine Rolle, verantwortlich fr die Sicherstellung der Zweckmigkeit eines
Prozesses. Zu den Verantwortlichkeiten des Process Owners gehren das
Sponsoring, das Design, das Change Management sowie die kontinuierliche
Verbesserung des Prozesses und seiner Messgren. Diese Rolle wird hufig
derselben Person zugewiesen, der bereits die Rolle des Prozess-Managers
zugewiesen ist. In greren Organisationen knnen diese Rollen jedoch separat
zugewiesen sein.
Prozess-Manager:
Eine Rolle, die fr das operative Management eines Prozesses verantwortlich
ist. Zu den Verantwortlichkeiten des Prozess-Managers gehren die Planung
und die Koordination aller Aktivitten, die zur Ausfhrung, dem Monitoring
und der Berichtserstellung in Bezug auf einen Prozess erforderlich sind. Es
knnen mehrere Prozess-Manager fr einen Prozess vorhanden sein, z. B.
regionale Change Manager oder IT Service Continuity Manager fr jedes
Rechenzentrum. Die Rolle des Prozess-Managers wird hufig der Person
zugewiesen, der bereits die Rolle des Process Owners zugewiesen ist. In
greren Organisationen knnen diese Rollen jedoch separat zugewiesen sein.

Um das Zusammenspiel zwischen den Prozessen und der Aufbauorganisation zu beschreiben, nutzt ITIL hierfr den Begriff der Funktion.
Funktion:
Ein Team oder eine Gruppe von Personen und die Hilfsmittel, die eingesetzt
werden, um einen oder mehrere Prozesse oder Aktivitten durchzufhren. Ein
Beispiel dafr ist das Service Desk.

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

51

Process
Owner und
ProzessManager

2 IT Service Management

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

In ITIL und COBIT sind viele Kennzahlen dokumentiert. Wir beschrnken


uns hier aber auf die, die im Rahmen unserer Projekterfahrung eine wichtige Rolle spielen bzw. gespielt haben. Spter werden diese PraxisKennzahlen nher spezifiziert und ihre Bedeutung 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:
Anzahl der aufgetretenen Strungen
Durchschnittliche Zeitdauer bis zur Behebung oder Umgehung der
Strung in Relation zur Prioritt

52

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


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 (d.h. ohne Vor-OrtSupport) 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); d.h. 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

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

53

2 IT Service Management
Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:
Anteil der Konfigurationen, die nicht dem autorisierten Zustand
entsprechen
Anteil fehlerhafter Changes aufgrund falscher Daten in der CMDB
(Configuration Management Database)
Bearbeitungsdauer bis zur Aktualisierung der CMDB
Anteil und Anzahl nicht genutzter Lizenzen
Anteil nicht autorisierter IT-Komponenten
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 Produktionsumgebung zum Ziel und soll durch die Anwendung formeller Verfahren und
Prfungen die Produktionsumgebung schtzen.
Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:

54

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse

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.
Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind:
Anteil von Strungen durch nicht ausreichende Kapazitten
Anteil von SLA-Verletzungen aufgrund mangelnder Performance

55

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

56

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Die Leistungsindikatoren des Security-Managements entsprechen demzufolge den brigen Service Level-Zielen 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

Prozesse und 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 28 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 bearbeitet oder Aufgaben des Service
Level Managements aus der ITIL Version 2 finden sich in anderen, neuen
Prozessen wieder.
Bei den aus der ITIL V2 bekannten Prozessen gilt es aber zu beachten, dass
diese Prozesse zum Teil verndert wurden. So finden sich Inhalte aus dem
Service Level Management gem der ITIL V2 nun in den Prozessen Service Katalog Management, Service Level Management, Supplier Management und Service Reporting wieder.
Diese durchgefhrten Anpassungen gegenber der ITIL Version 2 haben
auch Auswirkungen auf die damit verbundenen Kennzahlen und Metriken, deren Definition und deren Vergleichbarkeit.
Im Folgenden werden die 5 Phasen des Service Lifecycle mit ihren Prozessen vorgestellt und die seitens der ITIL Best Practices dokumentierten Key
Performance-Indikatoren beispielhaft beschrieben.

57

2 IT Service Management

Service
Transition

Continual
Service
Improvement

Service Asset
and Configuration M.

Release and
Deployment M.

Service Validation
and Testing

Change Management

Evaluation

Transition Planning
and Support
Service
Level
Management

Supplier M.
Information
Security M.

Knowledge
Mgmt.

Service
Portfolio
M.

Demand
M.

Service Level M.

Abbildung 28:

58

Request
Fulfilment

Financial
Management

Capacity M.

Service
Catalogue M.

Service
Reporting

Incident
Management

Strategy

Availability M.

The
Business
Questions
for CSI

Event
Management

Service

Service
Continuity M.

Service
Design

The 7 Step
Improvement
Process

Service
Operation

Problem M.
Access Management
Service Desk

Service
Measurement

Return on
Investment
(ROI) for CSI

Die 5 Phasen des Service Lifecycle und ihre Prozesse

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse

2.5.2.1 Service Strategy

Service
Portfolio
M.

Demand
M.

Service

Strategy
Financial
Management

Abbildung 29:

Service Strategy

Die Publikation Service Strategy ([OGC, 2007a]) weicht von den brigen
vier Publikationen dahingehend ab, dass sie kein Kapitel Prozesse 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.
Innerhalb der Service Strategy werden in ITIL V3 zu den Prozessen keine
Kennzahlen ausgewiesen.

Financial Management
Financial Management quantifiziert IT Services, ihre zugrunde liegenden
Assets und sogar operationelle Vorhersagen mit Metriken aus der FinanzTerminologie. Die Frage, die hier im Raum steht, ist die nach dem Wert fr
das Business und die zugrunde liegende IT. Auf strategischer Ebene ist
ber die Entwicklung von IT Services und den damit verbundenen Mehrwert zu entscheiden. Hierzu ist fr den jeweiligen IT Service der Business
Case zu betrachten. Der Business Case beinhaltet Informationen zu Kosten, Nutzen, Optionen, offenen Punkten, Risiken und mglichen Problemen.

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

59

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

Service Portfolio Management


Ein Serviceportfolio beschreibt die IT Services eines IT Service Providers im
Hinblick auf deren Wert fr die Geschftsprozesse (Business Value). Service Portfolio Management formuliert die geschftlichen Anforderungen und
ist die Antwort des IT Service Providers auf diese Bedrfnisse.
Die Definition des Serviceportfolios ist eine der wichtigsten Aufgaben
innerhalb von Service Strategy. Das Serviceportfolio enthlt nicht nur alle
in Nutzung befindlichen IT Services (= Servicekatalog), sondern auch alle
beantragten und in Entwicklung befindlichen IT Services (= Servicepipeline) sowie smtliche IT Services, die auer Kraft gesetzt sind.
Mit dem Service Portfolio Management stellt der IT Service Provider die
mittel- und langfristige wirksame Integration seiner IT Services in die Geschftsprozesse des Kunden und die Generierung eines Mehrwertes fr
die Business-Prozesse sicher. Der IT Service Provider wird so in die Lage
versetzt, frhzeitig seine IT Services an den Marktanforderungen auszurichten. Aber auch nicht mehr bzw. zuknftig nicht mehr gefragte IT Services werden identifiziert und deren Auerkraftsetzung festgelegt. Damit
verbunden werden Ressourcen freigesetzt, die fr andere IT Services genutzt werden knnen, und ansonsten notwendige Investitionen werden
vermieden.
Der Prozess besteht aus den Aktivitten Definition, Analyse, Freigabe und Ausgestaltung. Innerhalb der Definition gilt es, die bestehenden IT Services und Anforderungen zu analysieren. Hierzu wird fr

60

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


jeden IT Service der Business Case definiert. Bei der Analyse wird der
Inhalt der Servicestrategie festgelegt. Hierzu werden die langfristigen Ziele festgelegt und ermittelt, welche IT Services hierzu notwendig sind. In
Verbindung mit diesen IT Services sind die damit verbundenen Ressourcen und Fhigkeiten zu spezifizieren. Mit einer Betrachtung zwischen dem
Wert fr das Business und den damit in Verbindung stehenden Kosten
knnen IT Services priorisiert werden. Die Freigabe stellt die Autorisierung des Serviceportfolios sicher. Nach der Freigabe stellt die Aktivitt
Ausgestaltung sicher, dass die IT Services kommuniziert und die damit
verbundenen Ressourcen eingeplant werden.
Das Serviceportfolio wird fr das Management ber den gesamten Lifecycle aller IT Services genutzt.
Service Portfolio Management:
Der Prozess, der fr das Management des Serviceportfolios verantwortlich ist.
Beim Service Portfolio Management steht der Wert der Services im Vordergrund,
den diese fr das Business darstellen.

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

Ausgangspunkt des Demand Managements sind die Business Prozesse


und deren Aktivitten. Auf Basis einer differenzierten Analyse der Servicenachfrage einzelner Businessaktivitten knnen zum Beispiel die IT
Services innerhalb von Service Design besser entwickelt werden, und
das Service Portfolio Management kann Investitionen in zustzliche Kapazitten, neue IT Services oder zu ndernde IT Services rechtfertigen.
Mit der Identifizierung der zuknftigen Aktivitten innerhalb der Business-Prozesse liefert das Demand Management einen wichtigen Beitrag
zur angemessenen Ausgestaltung der IT Services. berkapazitten werden vermieden und dadurch die Kosten fr den jeweiligen IT Service reduziert. Andererseits werden Unterkapazitten vermieden, so dass die
Business Prozesse nicht in Mitleidenschaft gezogen und planmig durchgefhrt werden knnen.

61

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

2.5.2.2 Service Design

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

Service
Design

Capacity M.
Service Level M.
Service
Catalogue M.

Abbildung 30:

62

Service Design

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse

Service Catalogue Management


Ziel des Prozesses Service Catalogue Management (SCM) ist die Erstellung
und Pflege eines Servicekatalogs mit genauen Informationen ber alle
aktuellen und geplanten operationalen Services. Hierzu werden die vom
Service Portfolio Management definierten Services entsprechend spezifiziert
und sind als Teilmenge bzw. konkrete Ausprgung des Serviceportfolios
anzusehen.
Der Servicekatalog enthlt Angaben zu Lieferergebnissen, Preisen, Bestellungen und Anfragen sowie Kontaktinformationen zu allen Live IT Services, einschlielich der Services, die fr das Deployment verfgbar sind. Es
ist der Bereich des Serviceportfolios, der von den Kunden eingesehen
werden kann.
Aber nicht nur fr den Kunden und den Vertrieb von IT Services ist der
Servicekatalog von Bedeutung. Der Servicekatalog sollte strukturiert aufgebaut werden. Der so genannte Business-Servicekatalog beinhaltet die
Details aller IT Services, die den Kunden geliefert werden, und stellt die
Beziehungen zwischen den IT Services und den davon abhngigen Geschftsbereichen und Business Prozessen dar. Nur dieser Bereich ist fr
den Kunden sichtbar. Ein Technischer Servicekatalog untermauert den
Business-Servicekatalog mit den notwendigen technischen IT Services, die
die Business-Services ermglichen. Der Technische Servicekatalog enthlt Details zu allen IT Services sowie die Beziehungen zu den untersttzenden Services, CIs, etc., die notwendig sind, den IT Service fr das Business bereitzustellen.
Das Service Katalog Management stellt sicher, dass sowohl die Inhalte, als
auch die hinterlegte Struktur erstellt und gepflegt werden.
Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:
die Anzahl der aufgenommenen und verwalteten Services innerhalb
des Servicekatalogs als Prozentsatz der Services, die ausgeliefert
und bergeben wurden und sich in der Live-Umgebung befinden
die Anzahl von Abweichungen zwischen den Informationen im Servicekatalog und der realen Welt.

Service Level Management


Der Service Level Management-Prozess definiert und vereinbart fr alle aktuellen und zuknftigen IT Services die damit verbundenen Service Level
und die erreichbaren Zielwerte (Service Level-Ziel). Auerdem stellt er
sicher, dass Services auf diesem Level ausgeliefert werden. Proaktive Messungen und Reports helfen bei den notwendigen Verbesserungen zur Zufriedenheit der Kunden.

63

2 IT Service Management
Das Service Level Management reprsentiert den IT Service Provider gegenber dem Business und das Business gegenber dem IT Service Provider. Mit der Verantwortlichkeit fr das Verhandeln von Service Level
Agreements (SLAs) sowie deren Einhaltung liefert dieser Prozess einen
wichtigen Beitrag fr die Kundenzufriedenheit und das Vertrauen des
Kunden in die Servicequalitt. Damit die mit dem Kunden vereinbarten
SLAs eingehalten werden knnen und die am IT Service beteiligten Parteien ihre Leistungen besser planen knnen, werden intern Operational Level
Agreements (OLAs) und extern Underpinning Contracts (UCs) abgeschlossen. In Verbindung mit den Underpinning Contracts arbeitet das Service
Level Management mit dem Supplier Management zusammen.
Dieser Prozess arbeitet eng mit dem Continual Service Improvement (CSI)
zusammen. Die vereinbarten Service Level-Ziele sind vom IT Service Provider zu messen und dem Kunden regelmig zu berichten. Daher muss
vor dem Abschluss sichergestellt sein, dass die vereinbarten Service Level
gemessen werden knnen. Eine weitere Schnittstelle besteht zum Service
Reporting, das fr das Reporting zu Ergebnissen und Trends hinsichtlich
bestimmter Service Level verantwortlich ist. Beim Service Reporting sollten das Format, der Inhalt und die Hufigkeit der Berichte zuvor mit den
jeweiligen Kunden abgesprochen werden und so in die SLAs eingehen.
Service Level Management (SLM):
Der Prozess, der fr das Verhandeln von Service Level Agreements sowie deren
Einhaltung verantwortlich ist. Das SLM soll sicherstellen, dass alle IT Service
Management-Prozesse, Operational Level Agreements und Underpinning
Contracts fr die vereinbarten Service Level-Ziele angemessen sind. SLM ist fr
das Monitoring und die Berichterstattung in Bezug auf Service Level sowie fr
die regelmige Durchfhrung von Kunden-Reviews zustndig.

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

64

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse

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.
Hierzu muss das Capacity Management hinsichtlich der Kosten und Kapazitten sowie Angebot und Bedarf einen Balanceakt durchfhren.
Einerseits muss das Capacity Management sicherstellen, dass die Verarbeitungskapazitten zu vertretbaren Kosten dem Bedarf des Business nachkommen und mglichst effizient genutzt werden. Andererseits ist es die
Aufgabe, dass das verfgbare Angebot der Verarbeitungsleistungen dem
aktuellen und zuknftigen Bedarf des Business gerecht wird.
Hierzu finden im Capacity Management drei Sub-Prozesse ihre Anwendung:
Business Capacity Management (BCM):
Im Kontext von ITSM die verantwortliche Aktivitt, um die zuknftigen Business-Anforderungen fr die Verwendung im Capacity-Plan nachzuvollziehen.
Service Capacity Management (SCM):
Dient der Gewinnung von Erkenntnissen zur Performance und Kapazitt von IT
Services. Die Ressourcen, die von jedem IT Service verwendet werden, werden
fr die Nutzung im Capacity-Plan erfasst, aufgezeichnet und analysiert.
Component Capacity Management (CCM):
Verantwortlich fr die Aspekte der Kapazitt, Auslastung und Performance von
Configuration Items. Hier werden Daten im Capacity-Plan gesammelt, erfasst
und analysiert.

Die Messung und die Trendverfolgung bestehender Kapazitten und der


erzielten Performance ist die Grundvoraussetzung fr diesen Prozess. Das
Review derzeitiger Kapazitten und Performance liefert den Input fr
deren Verbesserung. Die Beurteilung neuer Anforderungen ermglicht
eine rechtzeitige Planung neuer Kapazitten, verhindert Panikkufe und
liefert so einen wichtigen Beitrag fr kostenwirksame IT Services. Andererseits werden Performance-Engpsse vermieden.
Capacity Management:
Der Prozess, bei dem sichergestellt wird, dass die Kapazitt der IT Services und
die IT-Infrastruktur ausreicht, um die vereinbarten Service Level-Ziele wirtschaftlich und zeitnah erreichen zu knnen. Beim Capacity Management werden

65

2 IT Service Management
alle Ressourcen, die fr die Erbringung von IT Services erforderlich sind, sowie
Plne fr kurz- mittel- und langfristige Business-Anforderungen bercksichtigt.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:
akkurate Business Vorhersagen (Vorhersagen ber Arbeitsauslastungen in der Produktion; prozentuale Genauigkeit der Vorhersagen von Business Trends, etc.)
Wissen ber aktuelle und zuknftige Technologien (Fhigkeit, Performance und Durchsatz aller Services und Komponenten zu monitoren; rechtzeitige Ausrichtung und Implementierung neuer Technologien, abgestimmt auf die Business-Anforderungen, etc.)
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.
Ausgehend von den Geschftsanforderungen ist die Verfgbarkeit eines
IT Service der Kern der Kundenzufriedenheit und des Geschftserfolgs. Ist
ein IT Service nicht verfgbar, so kann in vielen Fllen der Geschftsprozess nicht mehr durchgefhrt werden, und es entsteht ein unmittelbarer
Schaden fr das Unternehmen. Eine schlechte Performance wird von den
Anwendern und Kunden ebenfalls als Nicht-Verfgbarkeit angesehen und
sollte dementsprechend bei der Definition der Verfgbarkeit bercksichtigt werden.
Bei der Definition der Verfgbarkeit wird der Bezug auf die Geschftsprozesse des Kunden deutlich:
Verfgbarkeit (Availability):
Fhigkeit eines Configuration Items oder IT Service, bei Bedarf die dafr
vereinbarte Funktion auszufhren.
Die Verfgbarkeit wird durch Aspekte in Bezug auf Zuverlssigkeit, Wartbarkeit, Servicefhigkeit, Performance und Sicherheit bestimmt.

66

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Die Verfgbarkeit wird in der Regel als Prozentwert ausgedrckt, der hufig
basierend auf der vereinbarten Servicezeit und der Ausfallzeit berechnet wird.
Gem der Best Practice wird die Verfgbarkeit mithilfe von Messgren aus
dem Business-Ergebnis des IT Service berechnet.

Zur Sicherstellung der notwendigen Verfgbarkeit werden innerhalb des


Availability Managements so genannte reaktive und proaktive Aktivitten
durchgefhrt.
Innerhalb der reaktiven Aktivitten ist die Verfgbarkeit der IT Services
und IT-Komponenten zu messen, zu berwachen, zu analysieren und zu
berichten. Werden dabei Nicht-Verfgbarkeit fr IT Services und ITKomponenten ermittelt, so sind geeignete Abhilfemanahmen zu entwickeln.
Innerhalb der proaktiven Aktivitten besteht eine wichtige Aufgabe in der
Durchfhrung eines Risiko Assessments und dem Management der Risiken. Betreibt zum Beispiel ein Unternehmen eine Web-Plattform zur Bestellung von Artikeln und verfgt lediglich ber eine Leitung zum Internet-Serviceprovider, so ist das damit in Verbindung stehende Risiko zu
analysieren, und es sind mgliche nderungen im Design zu initiieren.
Eine wichtige Aufgabe kommt hier der Business-Auswirkungsanalyse (Business Impact Analysis, BIA) zu. Innerhalb der Business-Auswirkungsanalyse werden Funktionen eines Geschftsprozesses identifiziert, die fr den
Erfolg des Business entscheidend sind. Das Ergebnis dieser Analyse liefert
wichtige Anforderungen fr das Design der Verfgbarkeit, aber auch fr
die Anforderungen an die Wiederherstellung, die seitens des IT Service
Continuity Managements umzusetzen sind.
Availability Management:
Der Prozess, der fr die Definition, Analyse, Planung, Messung und Verbesserung smtlicher Aspekte in Bezug auf die Verfgbarkeit von IT Services verantwortlich ist. Im Availability Management muss sichergestellt werden, dass die
gesamte IT-Infrastruktur, sowie smtliche Prozesse, Hilfsmittel, Rollen etc. fr
die vereinbarten Service Level-Ziele eine entsprechende Verfgbarkeit ermglichen.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:
prozentuale Verringerung in der Nichtverfgbarkeit von Services
und Komponenten
prozentualer Anstieg in der Verlsslichkeit von Services und Komponenten

67

2 IT Service Management
effektives Review und Verfolgung aller Verletzungen bei SLAs,
OLAs und UCs
prozentuale Verbesserung in der allumfassenden end-to-endVerfgbarkeit von Services.

IT Service Continuity Management


Das IT Service Continuity Management (ITSCM) untersttzt den allumfassenden Business Continuity Management (BCM)-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.
Zielsetzung des IT Service Continuity Managements besteht nicht in der
berlebensfhigkeit der IT im Katastrophenfall, sondern darin, den ordnungsgemen Geschftsbetrieb schnellstmglich zu ermglichen. Daher
wird die Integration des IT Service Continuity Managements in das bergeordnete Business Continuity Management nicht nur ausdrcklich betont, sondern es wird auch die Verantwortung des Business Continuity
Managements fr einzelne Phasen im ITSCM-Prozess dokumentiert.
Die Prozessphasen bestehen aus der Initiierung, Anforderung und
Strategie, Implementierung und Laufender Betrieb. Die Aufgaben
der Initiierung und Definitionen der Anforderungen sind vornehmlich Aktivitten des Business Continuity Managements. Das ITSCM sollte
in dieser Phase beteiligt werden, um einerseits die Aktivitten des BCM zu
untersttzten, aber primr, um die Beziehungen zwischen den BusinessProzessen und deren Bedeutung zu verstehen. Die erste wirkliche verantwortliche Aktivitt des ITSCM ist es, eine Strategie zu entwickeln, die die
Strategie des BCM untermauert.
Voraussetzung fr ein wirkungsvolles ITSCM ist die Kenntnis der bereits
im Availability Management beschriebenen Analyse der Business-Auswirkungen, wenn der vereinbarte IT Service nicht zur Verfgung gestellt werden kann. Verbunden mit einer Analyse der Risiken kann eine angemessene Strategie festgelegt werden. Innerhalb der Implementierung wird
diese Strategie umgesetzt und in den laufenden Betrieb integriert.
Die beste Planung wird nicht funktionieren, wenn sie nicht einmalig und
laufend getestet wird. Die Durchfhrung laufender Tests ist eine wichtige
Aufgabe des laufenden Betriebs. Der Nachweis dieser berprfungen findet verstrkt Bercksichtigung bei Wirtschaftsprfungen und anderen Auditierungen oder Revisionen.

68

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Weiterhin muss sichergestellt werden, dass das ITSCM in den Change
Management-Prozess eingebunden wird und im Rahmen von geplanten
Changes beurteilen kann, ob mgliche Auswirkungen auf den IT Service
Continuity Plan bestehen. Im IT Service Continuity Plan sind die erforderlichen Schritte fr eine Wiederherstellung eines oder mehrerer IT Services
dokumentiert und identifizieren darber hinaus die Bedingungen fr das
Auslsen des Plans sowie die zu bercksichtigenden Mitarbeiter.
IT Service Continuity Management:
Der Prozess, der fr die Verwaltung von Risiken verantwortlich ist, die zu
schwerwiegenden Auswirkungen auf IT Services fhren knnen. Das ITSCM
stellt sicher, dass der IT Service Provider stets ein Mindestma an vereinbarten
Service Level bereitstellen kann, indem die Risiken auf ein akzeptables Ma
reduziert werden und eine Wiederherstellungsplanung fr IT Services erfolgt.
Das ITSCM sollte so konzipiert sein, dass es das Business Continuity
Management untersttzt.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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
regelmige, mindestens jhrliche Reviews der Business- und IT
Continuity-Plne mit den Geschftsbereichen.

Information Security Management


Informations-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.
Schon aufgrund gesetzlicher Verpflichtungen kann es sich keine Organisation leisten, die damit verbundenen Aspekte nicht zu beachten. Daher ist
die Information Security eine Managementaktivitt und Bestandteil des
"Corporate Governance Framework. Die Information Security ist fr die
Assets, Informationen, Daten und IT Services einer Organisation angemessen sicherzustellen und umfasst die Aspekte der Vertraulichkeit, Integritt
und Verfgbarkeit:

69

2 IT Service Management
Vertraulichkeit:
Ein Sicherheitsprinzip, das fordert, dass ausschlielich autorisierte Personen auf
Daten zugreifen knnen.
Integritt:
Ein Sicherheitsprinzip, das sicherstellt, dass Daten und Configuration Items nur
durch autorisierte Mitarbeiter und Aktivitten modifiziert werden. Die Integritt
bercksichtigt alle mglichen Ursachen einer Modifikation, wie Ausflle von
Software oder Hardware, Umgebungs-Events und Eingriffe durch Personen.
Verfgbarkeit:
Fhigkeit eines Configuration Items oder IT Service, bei Bedarf die dafr
vereinbarte Funktion auszufhren. Die Verfgbarkeit wird durch Aspekte in
Bezug auf Zuverlssigkeit, Wartbarkeit, Servicefhigkeit, Performance und
Sicherheit bestimmt. Die Verfgbarkeit wird in der Regel als Prozentwert
ausgedrckt, der hufig basierend auf der vereinbarten Servicezeit und der
Ausfallzeit berechnet wird. Gem der Best Practice wird die Verfgbarkeit
mithilfe von Messgren aus dem Business-Ergebnis des IT Service berechnet.

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

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

70

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


prozentuale Verringerung der im Service Desk berichteten Sicherheits-Verletzungen
prozentuale Verringerung bei den Auswirkungen von SicherheitsVerletzungen und Incidents
prozentualer Anstieg der SLA-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 die Ausgaben fr die Lieferanten den gelieferten Leistungen entsprechen.

Bereits innerhalb der Service Strategy werden grundstzliche Betrachtungen zu den Service-Strukturen angestellt und letztendlich die ServiceStruktur definiert. Verbunden mit der Zielsetzung, einen IT Service bereitzustellen, der die Business-Prozesse untersttzt, hat der IT Service Provider eine End-To-End-Verantwortung fr den IT Service. Angesichts der
Komplexitt der einzubeziehenden technischen IT Services werden verstrkt externe Partner in den IT Service eingebunden: Eine Entwicklung,
die in anderen Branchen bereits vollzogen ist.
Diese Auslagerung von technischen IT Services an externe Lieferanten
oder Partner ist aber mit Risiken verbunden. Einerseits muss sichergestellt
werden, dass die notwendigen IT Services tatschlich wie vereinbart geliefert werden, andererseits mssen die Kosten dem gelieferten IT Service
entsprechen. Diese Aufgabe hat das Supplier Management sicherzustellen.
Hierzu ist eine fr die Organisation angemessene Supplier Policy zu definieren, Lieferanten sind auszuwhlen und zu kategorisieren sowie die
Leistungen und Abrechnungen der Lieferanten zu bewerten. Die Bewertung der Lieferanten entscheidet ber die Fortfhrung bestehender Vertrge oder deren Kndigung. Hierzu empfiehlt ITIL die Etablierung einer
Supplier- und Vertragsdatenbank (Supplier and Contract Database, SCD)
zum Management der Vertrge whrend ihres gesamten Lebenszyklus.
Supplier Management:
Der Prozess ist verantwortlich dafr, sicherzustellen, dass alle Vertrge mit
Suppliern die Anforderungen des Business untersttzen und alle Supplier ihre
vertraglichen Verpflichtungen erfllen.

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

71

2 IT Service Management
Anstieg der Anzahl von Lieferanten, die vertraglich vereinbarte Ziele einhalten
Anstieg der Anzahl der mit Lieferanten durchgefhrten Serviceund Vertrags-Reviews
Reduzierung der Anzahl von durch Lieferanten verursachten Service-Verletzungen
Anstieg der Anzahl von Lieferanten mit ernanntem Lieferanten-Manager.

2.5.2.3 Service Transition


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

Abbildung 31:

Service Transition

Transition Planning and Support


Transition Planning and Support plant und koordiniert Ressourcen 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.

Ein wirksamer Prozess Transition Planning and Support soll die Voraussetzung dafr schaffen, dass der Service Provider ein hohes Volumen von
Changes und Releases bearbeiten kann. Hierzu ist die Planung von Kapazitten und Ressourcen fr die Inbetriebnahme von neuen oder genderten Services erforderlich, so dass die Anforderungen aus Service Strategy
und Service Design umgesetzt werden knnen. Der Prozess Transition
Planning and Support deckt dazu die notwendigen Planungen im Vorfeld
der Einfhrung von Changes und Releases ab. Um diese Anforderungen
bzw. Ziele erfllen zu knnen, empfiehlt ITIL eine Service Transition
Policy formal zu vereinbaren. Darin soll unter anderem geregelt werden,
dass alle Vernderungen (= Changes) am Service Portfolio und insbeson-

72

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


dere am Service Katalog ber das Change Management umgesetzt werden.
Dadurch soll eine frhzeitige Einbindung in den Service Lifecycle und die
Ausrichtung der Transition Plne an den Business-Anforderungen sichergestellt werden.
Eine wichtige Aktivitt besteht in der Definition einer Service TransitionStrategie. Diese Strategie definiert den umfassenden Ansatz zur Organisation der Service Transition und Ressourcenzuordnung und bercksichtigt
unter anderem die folgenden Aspekte:

Zweck und Ziele


Kontext (Kunden, Vertrge etc.)
Relevante Standards, Vereinbarungen, Gesetze und Vertrge
Identifizierung der Anforderungen und Inhalte von neuen oder genderten Services
Personal (Verantwortlichkeit, Ausbildung etc.)
Ergebnisse der Aktivitten mit obligatorischen und optionalen Dokumentationen
Meilensteinplanung
Finanzielle Mittel (Budget)

Zu den weiteren Aktivitten im Prozess gehren die Vorbereitungen, die


integrierte Planung und die Untersttzung der einzelnen TransitionProzesse.
Transition Planning and Support:
Der Prozess, der fr die Planung aller Service Transition-Prozesse und die
Koordinierung der hierfr bentigten Ressourcen verantwortlich ist. Zu diesen
Service Transition-Prozessen zhlen Change Management, Service Asset and
Configuration Management, Release and Deployment Management, Service
Validation and Testing, Evaluation und Knowledge Management.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:
die Anzahl implementierter Releases, die im Hinblick auf Kosten,
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.

73

2 IT Service Management

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

74

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


lohnenden Changes bei einer minimalen Unterbrechung der IT Services zu
ermglichen.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:
Anzahl der nderungen (Changes) an den Services, die die mit den
Kunden vereinbarten Anforderungen z.B. hinsichtlich 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 an 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 and Configuration Management liefert ein logisches Modell der
IT-Infrastruktur und stellt falls erforderlich den Zusammenhang zwischen den IT Services mit notwendigen IT-Komponenten her.

Durch diese Bereitstellung von Informationen fr den gesamten Service


Lifecycle untersttzt das Service Asset and Configuration Management
(SACM) unter anderem bei der Beurteilung der Auswirkung und Ursache
von Incidents und Problemen, bei der Beurteilung der Auswirkung von
Changes, bei der Planung und Design neuer oder genderter Services und
der Planung der Aktualisierung von Technologie und Software.
Darber hinaus liefert das Service Asset and Configuration Management
analog zum Change und IT Service Continuity Management einen wichtigen Beitrag zum Nachweis der Einhaltung von Compliance Anforderungen.
Die Configuration Items knnen nach den folgenden Aspekten kategorisiert werden. Die Auflistung dieser Aspekte vermittelt einen Eindruck
ber den Geltungsbereich des Configuration Managements:
Service Lifecyle CIs, wie der Business Case oder der Service Management-Plan
Service CIs, wie die Service-Fhigkeiten (Organisation, Prozesse,
Personen, etc.) und die Service Ressourcen (Systeme, Applikationen,
etc.)

75

2 IT Service Management
Organisatorische CIs, wie zum Beispiel Dokumentationen wie Policies
Interne CIs, wie Software, um den Service bereitstellen zu knnen
Externe CIs, wie Service Level Anforderungen
Schnittstellen CIs, die notwendig fr einen end-to-end-Service
sind.
Diese Kategorien und die Definition des Configuration Items (CI) zeigen
deutlich, dass das Configuration und Service Asset Management erheblich
mehr ist, als die Verwaltung von Hard- und Software.
Die Prozessaktivitten bestehen aus Management und Planung, Configuration Identifizierung, Configuration Steuerung (Control), Status
Accounting und Reporting sowie Verfikation und Audit.
Service Asset and Configuration Management:
Der Prozess, der sowohl fr das Configuration Management als auch das Asset
Management verantwortlich ist.
Asset Management:
Das Asset Management ist der Prozess, der fr die Verfolgung der Werte und
Besitzverhltnisse in Bezug auf finanzielle Assets sowie deren Erfassung in Berichten whrend ihres gesamten Lebenszyklus verantwortlich ist.
Configuration Management
Der Prozess, der fr die Pflege von Informationen zu Configuration Items einschlielich der zugehrigen Beziehungen verantwortlich ist, die fr die Erbringung eines IT Service erforderlich sind. Diese Informationen werden ber den
gesamten Lebenszyklus des CI hinweg verwaltet.

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

76

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse

Release and Deployment Management


Das Ziel von Release and Deployment Management ist die Auslieferung und
berfhrung von Releases in die Produktion. Hier werden die Services
den Kunden zur Verfgung gestellt und sichergestellt, dass die Services
sinnvoll und produktiv genutzt werden knnen. Das Ziel des Release and
Deployment Managements ist es unter anderem, genaue und umfassende
Release und Deployment-Plne zu erstellen, die den Kunden- und Business Change-Projekten ermglichen, ihre Aktivitten mit diesen Plnen
auszurichten.
Fr das Verstndnis und die Zielsetzung ist es wichtig, die Definition eines Release zu betrachten. Bei diesem handelt es sich um eine Zusammenstellung von Hardware, Software, Dokumentation, Prozessen oder anderen Komponenten, die fr die Implementierung eines oder mehrerer genehmigter Changes an IT Services erforderlich sind. Aus dieser Definition wird deutlich, dass das Change Management verantwortlich fr die
Genehmigung von Changes ist. Das Release and Deployment Management ist dagegen fr die Steuerung des bergangs in die Live-Umgebung
verantwortlich.
Eine wichtige Aufgabe besteht dabei in der Definition der Release Units.
Dabei handelt es sich um Komponenten eines IT Service, die blicherweise
im selben Release verffentlicht werden. Eine Release Unit umfasst in der
Regel gengend Komponenten, um eine ntzliche Funktion auszufhren.
Eine Release Unit knnte zum Beispiel die gesamte Anwendung fr die
Lohnbuchhaltung sein, einschlielich IT-Betriebsverfahren und Anwendertrainings.
Basis der Prozessaktivitten ist die Release Policy. Die Release Policy beinhaltet fr einen oder mehrere Services unter anderem die folgenden Definitionen:
eindeutige Identifikation, Nummerierung und Namenskonventionen
Die Rollen und Verantwortungen in jeder Prozessphase
die Frequenz von Releases
Mechanismus zur Automatisierung von Build, Installation und
Release-Verteilung
Kriterien fr die Autorisierungen im Prozess
Kriterien und Berechtigungen, um den Early-Life Support zu beenden und an Service Operation zu bergeben.
Diese Release Policy ist mit dem Kunden bzw. auf die Business-Prozesse
abzustimmen.

77

2 IT Service Management
Jedes Release durchluft die Prozessaktivitten Planung, Vorbereiten
von Build, Test und Deployment, Build und Test, Service Tests und
Piloten, Planung und Vorbereitung Deployment, Durchfhrung
Transfer, Deployment und Auerkraftsetzung, Early-Life Support und
Review und Abschluss Deployment.
Hier ist zu beachten, dass ein Release nicht mit dem Deployment abgeschlossen ist, sondern der Early Life Support und das Review die Prozessaktivitten abschlieen.
Release and Deployment Management:
Der Prozess, der sowohl fr das Release Management als auch fr das
Deployment verantwortlich ist.
Release Management:
Der Prozess, der fr die Planung, den zeitlichen Ablauf und die Steuerung des
bergangs von Releases in Test- und Live-Umgebungen verantwortlich ist. Das
wichtigste Ziel des Release Managements ist es, sicherzustellen, dass die
Integritt der Live-Umgebung aufrechterhalten wird und dass die richtigen
Komponenten im Release enthalten sind.
Deployment:
Die Aktivitt, die fr den bergang neuer oder genderter Hardware, Software,
Dokumentation, Prozesse etc. in die Live-Umgebung verantwortlich ist.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:
Abweichung von der vom Kunden geforderten Service Performance
(Service Leistung)
Anzahl von Incidents bzgl. des Service
Reduzierter Einsatz von Ressourcen und Kosten 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.

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

78

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Die Zielsetzung des Prozesses besteht in:
Sicherstellung, dass ein Service den Wertbeitrag fr Kunden und
Business liefert
Planung und Implementierung eines strukturierten Validierungsund Test-Prozesses fr den objektiven Nachweis gem der vereinbarten Anforderungen und Service Level-Ziele
Qualittssicherung von Release, Komponenten, Service und Servicefhigkeit
Identifizierung, Bewertung und Zuordnung von Vorfllen, Fehlern
und Risiken whrend der Transition Phase
Vertrauen schaffen, dass die erwarteten Ergebnisse und der Wert
fr das Business tatschlich entstehen
Besttigung, dass der Service fit for purpose ist.
Service Package
Angebote, Vertrge
validieren

Kunden/Business
Anforderungen
definieren
Service
Anforderungen
definieren

Serviceabnahme
testen

Design Service
Lsung

Betriebsbereitschaft testen
Service Release
Package Test

Design Service
Release

Komponenten &
Komponentengruppen Test

Design Lsung
entwickeln

Level fr Configuration und Testen


Abbildung 32:

Build
& Test

Das Service V-Modell

Mithilfe des Service V-Modells (Abbildung 32) kann sichergestellt werden,


dass Service Validation and Testing frh in den Service Lifecycle eingebunden und eine Validierung und Test ber alle Ebenen erfolgt (aus OGC,
2007c).

79

2 IT Service Management
Von Bedeutung fr das Verstndnis dieses Prozesses ist es, dass der Prozess Service Validation and Testing nicht nur Fehlerfreiheit berprft, sondern auch die Einhaltung des zugesicherten Wertes fr das Business. Dieser Wert setzt sich zusammen aus der Utility und Warranty.
Service Validation and Testing:
Der Prozess, der fr die Validation und das Testen eines neuen oder genderten
IT Service verantwortlich ist. Service Validation and Testing stellt sicher, dass der
IT Service den jeweiligen Designspezifikationen entspricht und den Bedrfnissen
des Business gerecht wird.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:
Vertrauen, dass ein Release die erwarteten Ergebnisse und den Wert
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 neue oder genderte IT Services, um mgliche Risiken
zu managen und so sicherzustellen, dass mit dem Service Change fortgefahren werden kann. Mit dieser Zielsetzung liefert der Prozess Evaluation
eine Entscheidungsvorlage fr das Change Management, ob ein Change
genehmigt oder abgelehnt wird.

Die Lieferung von relevanten und genauen Informationen fr das Change


Management stellt sicher, dass Service Changes mit negativen Auswirkungen und Risiken nicht ungeprft umgesetzt werden.
Der Prozess Evaluation stellt hierzu ein konsistentes und standardisiertes
Mittel zur Bewertung eines Service Changes bereit. Diese Beurteilung erfolgt gemeinsam mit dem Kunden und identifiziert smtliche gewnschten und unerwnschten Auswirkungen. Hierzu ist die Objektivitt, Fairness, Konsistenz und Offenheit in der Bewertung unumgnglich.

80

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Evaluation:
Der Prozess, der fr die Bewertung eines neuen oder genderten IT Service verantwortlich ist, um sicherzustellen, dass Risiken verwaltet wurden, und festlegen
zu knnen, ob mit dem Change fortgefahren werden soll. Eine Evaluierung
bezeichnet darber hinaus den Vergleich eines Ist-Ergebnisses mit dem
beabsichtigten Ergebnis oder den Vergleich unterschiedlicher Alternativen.

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

Abweichung der Service Performance


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

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

Dem Knowledge Management liegt das DIKW-Modell (Data-to-Information-to-Knowledge-to-Wisdom) zugrunde. Innerhalb der Organisation des
Service Providers fllt eine Unmenge von Daten an, die aber noch keine
Entscheidung ermglichen. Durch die Analyse der Daten werden Informationen gewonnen. Hier werden Informationen zu den Schlsselfragen
Wer?, Was?, Wann?, und Wo? generiert. Das Knowledge entsteht durch die
Anwendung der Informationen fr bestimmte Manahmen. Das Wisdom
stellt schliet die Anwendung und Umsetzung des Wissens dar. Dieses
Modell ermglicht die Schlsselfrage des Warum? zu beantworten.
In Verbindung mit dem Knowledge Management definiert ITIL das Service
Knowledge Management System (SKMS). Das SKMS besteht aus einer Sammlung von Hilfsmitteln und Datenbanken, die zur Verwaltung von Wissen
und Informationen verwendet werden. Ein wesentliches System fr das
SKMS ist das Configuration Management System.
Das Knowledge Management soll die Entscheidungsqualitt verbessern
und die Effizienz des Service Providers erhhen. Daher ist ein wirksames
Knowledge Management als ein mchtiges Asset fr alle Beteiligten (und
damit auch fr Kunden/Anwender) anzusehen.
Knowledge Management:
Der Prozess, der fr die Sammlung, die Analyse, das Speichern und die
gemeinsame Nutzung von Wissen und Informationen innerhalb einer Organisa-

81

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

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:
Incidents und verlorene Zeiten, kategorisiert als Mangel an Anwender-Wissen
durchschnittliche Diagnose- und Reparatur-Zeit 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 33:

Service Operation

Event Management
Event Management befhigt zur Entdeckung und Interpretation von Ereignissen (Events) und ermglicht deren Steuerung. Deshalb ist Event Management die Basis vieler Routine-Aktivitten des Operation Managements
und liefert die Eingangsstelle fr viele Prozesse und Aktivitten des Service Operation.

82

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Innerhalb von Service Operation wird der IT Service fr den Kunden bereitgestellt. Daher ist es in dieser Phase des Service Lifecycle sehr wichtig,
mgliche Incidents (Strungen) mglichst frh zu erkennen und zu beheben, so dass die Auswirkungen fr die Business-Prozesse minimiert werden. Durch die berwachung von Events, die innerhalb der ITInfrastruktur auftreten, ist es mglich, Ausnahmebedingungen frh zu
erkennen und darauf gezielt zu reagieren.
Hierzu werden so genannte Alarme (Alerts) definiert, die eine Warnung
melden, wenn ein Grenzwert erreicht, eine nderung vorgenommen wird
oder ein Ausfall aufgetreten ist. Die gezielte Reaktion auf die hinterlegten
Alarme erfolgt dann im Event Management.
ber das Event Management werden verschiedene Arten von Events gesteuert, wie zum Beispiel:
Events, die regulre Operationen kennzeichnen, wie: ein Anwender
hat sich angemeldet, um eine Applikation zu nutzen
Events, die eine Ausnahme kennzeichnen, wie: ein Anwender versucht, sich bei einer Applikation mit dem falschen Kennwort anzumelden, oder ein PC-Scan zeigt die Installation unautorisierter Software
Events, die eine ungewhnliche aber nicht auergewhnliche Operation kennzeichnen und so einen Hinweis fr ein genaueres Monitoring liefern.
Das Event Management sollte durch definierte Regeln und Tools in der
Lage sein, auf bestimmte Events automatisch zu reagieren, wie zum Beispiel durch einen automatischen Neustart eines Systems.
Events fhren hufig zu einem Incident, der im Incident Management
verfolgt wird. Ein Event kann aber auch zu einem Problem oder Change
fhren.
Event Management:
Der Prozess, der fr die Verwaltung von Events whrend ihres Lebenszyklus
verantwortlich ist. Das Event Management ist eine der wichtigsten Aktivitten
des IT-Betriebs.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:
Anzahl von Ereignissen je Kategorie
Anzahl von Ereignissen nach Signifikanz
Anzahl und Prozentsatz an Ereignissen, die menschliche Intervention erforderten und ob dies durchgefhrt wurde

83

2 IT Service Management
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 Business-Prozesse minimiert werden.
Die auftretenden Incidents sind zu kategorisieren und zu priorisieren. ITIL
empfiehlt, die Priorisierung auf Basis der Auswirkung und Dringlichkeit
durchzufhren und hilft, den erforderlichen Zeitbedarf fr die auszufhrenden Aktionen zu ermitteln. Die Business-Orientierung wird bei der
Definition der Auswirkung und Dringlichkeit sehr deutlich. Die Auswirkung eines Incidents wird durch die Folgen auf die Business-Prozesse
bestimmt und basiert hufig darauf, inwieweit Service Level betroffen
sind. Die Dringlichkeit ist ein Wert, der wiedergibt, wie lange es dauert,
bis ein Incident magebliche Auswirkungen auf das Business hat.
Fr die Effizienz des Incident Managements ist es von Vorteil, im Vorfeld
Incident-Modelle zu definieren. Diese Modelle ermglichen es, den Umgang mit einer bestimmten Art des Incidents im Vorfeld festzulegen und
sichern in der Umsetzung eine konsistente Durchfhrung. Beispiele fr
Incident Modelle sind sicherheitsrelevante Incidents, deren Informationen
an das Security Management automatisch weitergeleitet werden oder performancerelevante Incidents, die automatisiert an das Capacity Management weitergeleitet werden.
Eine Herausforderung in diesem Prozess besteht in der berzeugung aller
Mitarbeiter, dass alle Incidents protokolliert werden mssen. Darber
hinaus ist die Trennung zwischen Incident und Problem Management von
groer Bedeutung. Die Aufgabe des Incident Managements besteht in
einer schnellen Lsung des Incidents und nicht darin, die zugrunde liegende Ursache zu ermitteln. Die Ermittlung dieser Ursache und mgliche
Umgehungslsungen zu entwickeln ist die Aufgabe des Problem Managements.
Incident Management:
Der Prozess, der fr die Verwaltung des Lebenszyklus aller Incidents verantwortlich ist. Wichtigstes Ziel des Incident Management ist eine schnellstmgliche
Wiederherstellung des IT Service fr die Anwender.

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

84

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


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 zum Beispiel Lizenzen und SoftwareMedien, werden beschafft und ausgeliefert.

Ein Service Request knnte zum Beispiel die Anfrage eines Anwenders
nach Informationen, Beratung, einem Standard-Change oder nach Zugriff
auf einen IT Service sein. Das Zurcksetzen eines Passworts oder die Bereitstellung standardmiger IT Services fr einen neuen Anwender sind
Service Requests, die an jeden Service Provider gerichtet werden.
Viele an den Service Provider gerichtete Service Requests wiederholen
sich, so dass ein vordefinierter Prozessablauf (ein Modell) entworfen werden kann, wie diese Anforderungen einheitlich mit einer gleich bleibenden
Service-Qualitt bearbeitet werden knnen. Diese Modelle beinhalten:
beteiligte Personen oder Support-Gruppen
geplante Zeitdauer
Eskalationswege.
Die Service Requests werden normalerweise durch Implementierung eines
Standard Change abgedeckt. Der Standard Change ist ein vorab genehmigter Change, der von geringem Risiko ist, relativ hufig eingesetzt wird
und einem bestimmten Verfahren oder einer Arbeitsanweisung folgt. Mit
dem Standard Change wird auch die Dokumentation der durchgefhrten
Manahme sichergestellt.
Die Verantwortung der Aufnahme, berwachung, Eskalation und Zuweisung der Service Requests liegt im Service Desk.
Request Fulfilment:
Der Prozess, der fr das Management des Lebenszyklus aller Service Requests
verantwortlich ist.

85

2 IT Service Management
Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:
Gesamtzahl an Service Requests
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.

Problem Management
Der Prozess Problem Management ist verantwortlich fr den Lebenszyklus
aller Probleme 3 . Das Problem Management hat hierzu die Ursachen zu
identifizieren und sicherzustellen, dass die erarbeiteten Lsungen ber die
Control Prozesse hauptschlich Change Management implementiert
werden.
Whrend das Incident Management die schnelle Wiederherstellung des IT
Service zum Ziel hat, muss vom Problem Management sichergestellt werden, dass sich diese Incidents nicht wiederholen. Ein gutes Problem Management stellt die Reduzierung von Incidents bzw. die Reduzierung deren Auswirkungen sicher und liefert einerseits dem Business einen stabileren IT Service, andererseits werden die Aufwendungen und Kosten fr
das Incident Management reduziert.
Das Incident und Problem Management sind zwei eng verbundene, aber
getrennte Prozesse. Ein Incident nimmt im Rahmen seiner Bearbeitung
nicht den Status eines Problems an, sondern bleibt whrend der gesamten Bearbeitung ein Incident. Sehr wohl bedingen sich Incident und Problem Management.
Eine wichtige Aufgabe des Problem Managements besteht in der Dokumentation von Known Errors. Ein Known Error liegt vor, wenn die
zugrunde liegende Ursache fr ein Problem identifiziert und ein Workaround (Umgehungslsung) dokumentiert wurde. Diese Umgehungslsung
ermglicht die Reduzierung oder Beseitigung der Auswirkungen von Incidents oder Problemen, fr die noch keine vollstndige Lsung verfgbar
ist, wie zum Beispiel durch den Neustart eines ausgefallenen Configuration Items. Gespeichert werden die Known Errors in der Known Error Da-

86

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


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


tenbank (KEDB), die Bestandteil des Configuration Management Systems
(CMS) und des Service Knowledge Management (Systems) ist.

So wird der Zugriff des Incident Managements auf diese Umgehungslsungen sichergestellt. Mitarbeiter im Incident Management knnen diese
Informationen abfragen, die beschriebenen Manahmen durchfhren und
konsistente und mit einer hohen Qualitt verbundene Wiederherstellungsmanahmen durchfhren. Eine gute KEDB ermglicht eine hohe
Erstlsungsquote im Service Desk.
Die im Problem Management entwickelten Lsungskonzepte werden nicht
vom Problem Management eigenstndig umgesetzt und implementiert,
sondern fhren zu einem Request for Change (RfC) und unterliegen so
dem Change Management.
Innerhalb des Problem Managements wird zwischen dem reaktiven und
proaktiven Problem Management unterschieden. Das reaktive Problem Management wird allgemein in Service Operation durchgefhrt. Das proaktive Problem Management wird in Service Operation initiiert, aber generell
innerhalb von Continual Service Improvement vorangetrieben.
Problem Management:
Der Prozess, der fr die Verwaltung des Lebenszyklus aller Probleme verantwortlich ist. Wichtigstes Ziel des Problem Managements ist es, Incidents zu verhindern bzw. die Auswirkungen von Incidents zu minimieren, die nicht verhindert werden knnen.

Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:
Gesamtzahl der Probleme (als Kontroll-Wert)
Prozentsatz von Problemen, die innerhalb der SLA-Ziele 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.

Aus den gestiegenen Compliance Anforderungen (zum Beispiel Sarbanes


Oxley Act, SOX) resultiert die Notwendigkeit einer Regelung fr den

87

2 IT Service Management
Zugriff auf IT Services und Daten. Diese Anforderungen sind leicht nachzuvollziehen, wenn die Folgen eines unautorisierten Zugriffs betrachtet
werden. Die mglichen Folgen von Manipulationen, aber auch die unberechtigte Weitergabe von Informationen, knnen fr ein Unternehmen
immens sein.
Das Access Management wird als Prozess des IT Service Managements
erstmalig in der ITIL V3 beschrieben, wird aber in vielen Organisationen
betrieben. Dieser Prozess wird hufig auch als Berechtigungs-Management
oder Identitts-Management (Identity Management) bezeichnet.
Im Prozess werden folgende Begriffe unterschieden:
Access (Zugriff), bezieht sich auf den Level und Umfang der ServiceFunktionalitt oder Daten, fr deren Nutzung ein Anwender berechtigt ist
Identity (Identitt), bezieht sich auf die Information, die sie als individuell charakterisiert und die ihren Status innerhalb der Organisation verifiziert (wie der Anwender)
Rights (Rechte, auch genannt Privilegien), beziehen sich auf die aktuellen Einstellungen, wodurch einem Anwender der Zugriff zu einem Service oder einer Gruppe von Services bereitgestellt wird, typische Rechte beinhalten lesen, schreiben, etc.
Service oder Service Gruppen, es ist effizienter, einen Zugriff einer
vollstndigen Gruppe von Services zu gewhren
Directory Services, bezieht sich auf bestimmte Typen von Tools, die
benutzt werden, um Zugriffe und Rechte zu verwalten
In der Regel nimmt der Service Desk die Access-Anforderung entgegen
und nutzt hierzu einen Service Request. Nach der Durchfhrung von
berprfungen erfolgt die Weiterleitung an das entsprechende Team.
Der Prozess ist nicht auf den Service Provider begrenzt, sondern schliet
den Kunden im hinterlegten Workflow ein. Die Prozessaktivitten bestehen aus Zugriffsberechtigung beantragen, Verifikation, Zugriffsrechte bereitstellen, Monitoring des Identitts-Status und Entfernen
oder Begrenzung der Rechte.
Access Management:
Der Prozess, der fr die Zulassung der Nutzung von IT Services, Daten und
anderen Assets durch Anwender verantwortlich ist. Das Access Management
bietet Untersttzung beim Schutz der Vertraulichkeit, Integritt und Verfgbarkeit von Assets, indem sichergestellt wird, dass nur berechtigte Anwender auf
die jeweiligen Assets zugreifen oder nderungen an diesen vornehmen knnen.
Das Access Management kann auch als Berechtigungs-Management oder Identitts-Management (Identity Management) bezeichnet werden.

88

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren 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.
Der Service Desk als Anforderung an die Organisation ist im Kapitel Organizing Service Operation beschrieben.
Der Service Desk bernimmt in der Organisation des Service Providers die
Funktion als Primary Point of Contact fr den Anwender. Als Ansprechpartner fr die Anwender nimmt der Service Desk Incidents, Service Requests und einige Kategorien von Requests for Change auf. Die Zielsetzung besteht darin, den Anwendern eine einfache Kommunikation zu
ermglichen. Mit der Funktion als Primary Point of Contact stellt der Service Provider den Anwendern eine einfache Schnittstelle zur Verfgung.
Es soll vermieden werden, dass der Anwender entscheiden muss, welche
Stelle innerhalb der Provider-Organisation fr die jeweilige Bearbeitung
verantwortlich ist.
Der Service Desk ist aber nicht nur fr die Aufnahme von Incidents und
Service Requests verantwortlich, sondern bernimmt auch Aktivitten in
den jeweiligen Prozessen, wie zum Beispiel:
Kategorisierung und Priorisierung aller Incidents / Service Requests
sowie Erfassung der relevanten Details
Erste Ebene der Untersuchung, Diagnose und Problemlsung
Eskalation von Incidents / Service Requests
Informieren von Anwendern ber den Fortschritt
Schlieen aller gelsten Incidents, Service Requests und andere Anfragen
Durchfhrung von Anwenderbefragungen.
Darber hinaus bernimmt der Service Desk die Koordination einiger ITGruppen und Prozesse.
Fr den Service Desk beschreibt ITIL mit dem lokalen Service Desk, dem
zentralen Service Desk, dem virtuellen Service Desk und Follow the

89

2 IT Service Management
Sun verschiedene Strukturen. Im Rahmen der Implementierung des Service Managements gilt es dann, die fr die jeweilige Organisation geeignete Struktur zu spezifizieren.
Die seitens der ITIL Best Practices dokumentierten Key PerformanceIndikatoren sind zum Beispiel:
Prozentsatz von Calls (Anrufen), deren Requests bzw. Strungen sofort whrend des ersten Kontaktes am Service Desk gelst wurden
Prozentsatz gelster Calls ohne Untersttzung anderer Gruppen
Prozentsatz gelster Calls mit Untersttzung anderer Gruppen.

2.5.2.5 Continual Service Improvement

Continual
Service
Improvement

The 7 Step
Improvement
Process

Service
Reporting

Service
Level
Management

The
Business
Questions
for CSI

Abbildung 34:

Service
Measurement

Return on
Investment
(ROI) for CSI

Continual Service Improvement

The 7 Step Improvement Process


Hier werden Fragen gestellt nach den Business-Treibern hinter der ITILImplementierung, der finanziellen Bewertung von IT-Investitionen, dem
Reifegrad, der Effektivitt und Effizienz aktueller Prozesse, den Lcken
(Gaps) und Problemen bei der Bereitstellung von Services, der Bewertung

90

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


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

Definieren, was gemessen werden soll

2.

Definieren, was gemessen werden kann

3.

Daten sammeln

4.

Daten bearbeiten

5.

Daten analysieren

6.

Informationen prsentieren und nutzen

7.

Korrekturen durchfhren.

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


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

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

7. Implementiere
Korrekturmanahmen

Ziele
6. Prsentiere
und nutze die
Informationen

3. Sammle
Daten

5. Analysiere
Daten
Abbildung 35:

4. Bearbeite
Daten

7 Step Improvement-Prozess

1. Definiere, was Du messen solltest (should)


Als erster Schritt sollte ein Satz mglicher Messungen definiert werden,
der die Ziele des IT Service Providers und deren Messung vollstndig
abdeckt. Der Fokus sollte hier bei der Definition liegen, welche Daten gebraucht werden und um die Zielerreichung vollstndig zu messen. Eine

91

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

2. Definiere, was Du messen kannst (can)


Whrend im ersten Schritt mgliche Daten fr Messungen definiert werden, gilt es im zweiten Schritt festzustellen, was tatschlich gemessen werden kann. Dabei knnen Service Provider unter Umstnden feststellen,
dass nicht alle Anforderungen umgesetzt werden knnen. Fr den Service
Provider ist es wichtig, die Lcken und damit verbundene mgliche Risiken zu erkennen. Die identifizierten Lcken und die damit verbundenen
Auswirkungen sind dem Business, den Kunden und dem IT-Management
zu berichten.
Eine mgliche Abhilfe kann in der Beschaffung neuer Tools liegen, dabei
sind die damit verbundenen Kosten und erzielten Vorteile zu prfen.

3. Sammle Daten (gather)


Die Zielsetzung des Continual Service Improvement besteht in der berwachung der Service-Qualitt. Hierzu sind durch eine geeignete Kombination von Monitoring-Tools und manuellen Prozessen die notwendigen
Messungen zur Mittlung der erforderlichen Daten einzufhren.
Der Betrachtungsbereich erstreckt sich von der Effektivitt der Services,
ber Prozesse, Tools und Organisation bis zu den CIs. Dabei werden nicht
nur Ausnahmesituationen betrachtet, sondern auch Entwicklungen wie
zum Beispiel eine schleichende Verschlechterung der Verfgbarkeit.
Eine Automatisierung der Datensammlung ist anzustreben und wie bereits ausgefhrt Messpunkte sowohl so zu whlen, dass eine durchgngige
Betrachtung (end-to-end), als auch eine zeitliche Betrachtung mglich
wird.
Die in diesem Schritt gesammelten Daten sind aber noch Rohdaten und
erlauben keine Rckschlsse. Hierzu sind die gesammelten Daten entsprechend zu erarbeiten.

4. Bearbeite Daten (process)


Die gesammelten Rohdaten werden in diesem Schritt so bearbeitet und in
das erforderliche Format transformiert, dass ber eine end-to-endBetrachtung die Bewertung der Leistungsfhigkeit der Prozesse und / oder
IT Services mglich wird.

92

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


Hierzu werden unter anderem Daten aus verschiedenen Quellen konsolidiert, auf Zeitskalen abgebildet und fhren zu den definierten KPIs und
Kennzahlen. Die Kennzahlen knnen in drei Betrachtungsebenen dargestellt werden:

Technische Kennzahlen sind hufig mit den eingesetzten Komponenten


und Applikationen verbunden und betrachten technische Aspekte wie
Performance, Verfgbarkeit etc.
Prozess-Kennzahlen 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 Kennzahlen sind das Ergebnis einer end-to-end-Betrachtung
der Services.

5. Analysiere Daten (analyse)


Durch eine Analyse der generierten Informationen knnen die Ergebnisse
analysiert werden, um Fragen zu beantworten wie:

Erreichen wir die Ziele?


Gibt es klare Trends?
Sind Korrekturmanahmen erforderlich?
Welche eingeleiteten Korrekturmanahmen waren erfolgreich?
Welche Kosten entstehen?

Insbesondere der umfassende Ansatz des Continual Service Improvement


stellt sicher, dass sich die Identifizierung von mglichen Korrekturmanahmen nicht auf einen Bereich oder eine Phase des Lifecycle konzentriert.
So kann zum Beispiel sichergestellt werden, dass auftretende Probleme in
Service Operation zu Korrekturmanahmen innerhalb von Service Design
fhren.

6. Prsentiere und Nutze die Informationen (present)


Dieser Schritt dient der Prsentation des gewonnenen Wissens. Hierzu
sind die Ergebnisse so aufzubereiten und zu prsentieren, das sie leicht zu
verstehen sind und es so ermglicht wird, strategische, taktische und operative Entscheidungen zu treffen.
Grundvoraussetzung hierzu ist eine Zielgruppen-ausgerichtete Prsentation der Ergebnisse. Insbesondere ist ein Bezug zum Business und zu den
Business-Zielen herzustellen. Dabei stellt es sich als groer Vorteil dar,
dem Business mgliche Verbesserungen in Verbindung mit ihrem Wertbeitrag zu prsentieren.

93

2 IT Service Management
Dieser Schritt sollte aber nicht nur dazu dienen, mgliche Schwachpunkte
zu prsentieren, sondern auch als Marketingmanahme die exzellenten IT
Services herauszuheben. Hier erffnet sich die Chance, dass die IT nicht
nur als Kostenfaktor empfunden wird, sondern auch als Leistungsgeber
fr den Erfolg der Business-Prozesse.

7. Implementiere Korrekturmanahmen (implement)


Das gewonnene Wissen wird verwendet, um die IT Services, die Prozesse
und alle anderen untersttzenden Aktivitten und Techniken zu optimieren, zu verbessern und zu korrigieren. Die Verbesserungsmanahmen, die
den IT Service verbessern, sind zu identifizieren und innerhalb der Organisation zu kommunizieren.
Innerhalb des Continual Service Improvement werden unter Umstnden
mehr Verbesserungsmglichkeiten identifiziert, als mit den vorhandenen
Ressourcen und Budget umgesetzt werden knnen. Daher muss der Service Provider auf Basis der Zielsetzung und der Business-Vorteile die Umsetzung der Verbesserungsmanahmen priorisieren.
Die Umsetzung einer Verbesserungsmanahme fhrt zu einem Durchlauf
des beschriebenen Zyklus.
Innerhalb von The 7 Step Improvement sind allgemeine Fragestellungen
hinsichtlich der Definition von KPIs dokumentiert:
Was sagt uns der KPI ber die Zielerreichung aus?
Wie leicht ist es, den KPI zu interpretieren?
Wann brauchen wir die Information? Wie oft? Wie rasch sollte die
Information verfgbar sein?
In welchem Mae 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?
Key Performance-Indikatoren sind zu diesem Prozess nicht ausgefhrt,
sondern allgemeine Anforderungen an die Metriken.

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

94

2.5 ITIL Kennzahlen fr IT Service Management-Prozesse


ten sind hierzu die Daten so aufzubereiten, dass das Business die notwendigen Informationen erhlt.
Fr das Business ist eine historische Betrachtung des geleisteten IT Service
mit den erreichten Service Level und der Performance wichtig. Aber viel
wichtiger sind die daraus gezogenen Kenntnisse und welche Manahmen
eingeleitet werden, um erkannte Defizite zu beheben. Das Business verlangt eine nachvollziehbare Darstellung von den Ereignissen und wie der
Service Provider sicherstellt, dass das nochmalige Geschehen nicht wieder
eintritt und wie der Service Provider generell den Service verbessern wird.
Service Reporting:
Der Prozess, mit dem Berichte zu Ergebnissen und Trends hinsichtlich
bestimmter Service Level erstellt und bereitgestellt werden. Beim Service
Reporting sollte das Format, der Inhalt und die Hufigkeit der Berichte zuvor
mit den jeweiligen Kunden abgesprochen werden.

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

95

2 IT Service Management
Verbesserte Verfgbarkeit (durch Service / Systeme / Applikationen)
Verringerung der Service Level Verletzungen (durch Service / Systeme / Applikationen)
Verringerung mean time to repair (gemessen anhand von Prioritten)
Verringerung von Major Incidents.

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 des Service Providers 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?.
Die Definition Was wollen wir? kann nur in Partnerschaft zwischen dem
Business und dem Service Provider erarbeitet werden. Zunchst mgen
sich einige Wnsche des Business wie 100%ige garantierte Verfgbarkeit
als Wunschliste anfhren. Hier gilt es, die zugrunde liegenden Begrndungen zu erkennen und sich diesen Anforderungen zu stellen. Die
Grnde aus Sicht des Business knnen zum Beispiel bestehen in:

Einhaltung zu neuen/bevorstehenden Gesetzen


(Compliance Anforderungen)

Wettbewerb
Finanzielle Beschrnkungen.
Es ist fr den Service Provider wichtig, lang-, mittel- und kurzfristige Ziele
und Zielsetzungen fr das Business zu identifizieren, so dass die zugrunde liegenden IT Services und Service Assets sich dementsprechend ausrichten knnen.

96

2.6 ISO 20000


Die Aktivitten des Continual Service Improvement setzen einen betriebsbereiten IT Service voraus. Die Aktivitten des CSI knnen innerhalb der
Lifecycle-Phasen: Service Strategy, Service Design, Service Transition und
Service Operation ausgefhrt werden.
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-Zielen 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.

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

Key Performance-Indikatoren sind zu diesem Prozess nicht ausgefhrt.

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

97

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

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

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.

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

98

2.6 ISO 20000

2.6.1

Die Geschichte der ISO 20000

Die im September 2005 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 bereinstimmung 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, so dass die ISO 20000
weitestgehend dem BS 15000 entspricht.

2.6.2

Der Aufbau der ISO 20000

Die ISO 20000 besteht aus den beiden Dokumenten ISO 20000-1 und
ISO 20000-2.
Der erste Teil der Norm ISO 20000-1: Specification (vgl. [ISO 20000-1,
2005]) 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
ISO 20000-1 enthlt die Muss-Kriterien des Standards und umfasst inklusive Deckblatt und Inhaltsverzeichnis insgesamt 36 Seiten.

ISO 20000-1
enthlt die
Muss-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.

ISO 20000-2
enthlt die
Soll-Anforderungen

Anhand des Umfangs der Dokumentation kann die Zielsetzung der


ISO 20000 leicht nachvollzogen werden. Die Norm definiert Anforderungen an die Prozesse (ISO 20000-1) und Umsetzungsempfehlungen
(ISO 20000-2), liefert aber keine generischen Prozessbeschreibungen, wie
sie durch die ITIL Best Practices zur 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

99

2 IT Service Management
20000-1, 2005], Kapitel 6.1 Service Level Management): Each service
provided shall be defined, agreed and documented in one or more service level
agreements (SLAs). Die ISO 20000-2 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 20000Zertifizierung geschaffen. Die ISO 20000 definiert Mindestanforderungen
und hilft dadurch, sich zunchst auf die Mindestanforderungen zu konzentrieren. Hierzu die Presseerklrung des Flughafens Mnchen zur erfolgreichen 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

100

2.6 ISO 20000


der ISO 20000 erweitert worden, wie zum Beispiel durch die Aufteilung
des alten Incident Managements in Incident Management und Request Fulfilment. Ungeachtet dieser 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.
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

ReleaseProzesse

Service Level Management


Service Reporting

Control-Prozesse
Configuration Management
Change Management

Resolution-Prozesse
Release
Management

Abbildung 36:

Information Security
Management

Incident Management
Problem Management

Budgeting and
accounting for IT
services

RelationshipProzesse
Business Relationship
Management
Supplier Management

IT Service Management-Prozesse der ISO 20000

Explizit fordert die ISO 20000 einen strategischen Planungsprozess fr das


IT Service Management. Er soll unter anderem kurz-, mittel und langfristige Planungen miteinander vereinen. Damit wird die Integration des IT

101

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

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

102

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

GeschftsErgebnisse

berwachung, Messen
und Review

Weitere Prozesse, z.B.


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

PDCA-Methodik

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

103

Im Rahmen
einer ISO
20000-Zertifizierung werden
Prozesskennzahlen berprft.

2 IT Service Management
erungszielen 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 sicherstellen.
ITIL Version 3 definiert den Begriff IT Governance und bezieht sich
dabei auf eine Definition des IT Governance Instituts (vgl. [OGC, 2007e]):
IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership, organizational structures and processes that ensure that the 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, so dass diese verschiedenen Best Practices besser aufeinander abgestimmt sind.

104

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

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.

105

COBIT sind
Best Practices.

2 IT Service Management
Prozesse
- berwache und bewerte
IT-Performance
- berwache und bewerte
interne Controls
- Stelle die angeordnete
Compliance sicher
- Sorge 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 38:

2.7.3
Control
Objectives
dienen der
Steuerung,
nicht der
Kontrolle

PO:
Plan and
Organise

AI:
Acquire
and
Implement

Prozesse
- Definiere stragischen IT-Plan
- Def. Informationsarchitektur
- Def. technolog. Ausrichtung
- Definiere die IT-Prozesse,
Organisation, Beziehungen
- Manage IT-Investitionen
- Kommuniziere Ziele und
Ausrichtung des Mgmts.
- Manage IT-PersonalRessourcen
- Manage die 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

COBIT Prozess-bersicht

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.

106

2.7 COBIT
Die Control Objectives dokumentieren das Ziel oder den Zweck eines Prozesses und definieren so die Mindestanforderung, die zu erreichen ist. Pro
Prozess existiert immer ein bergeordnetes Control Objective.
Die Prozesse sind so bezeichnet, dass sich das bergeordnete Control Objective direkt aus dem Prozessnamen ergibt. Zu jedem Prozess stellt
COBIT eingangs das bergeordnete Control Objective gemeinsam mit den
wichtigsten Prozesszielen und Metriken dar.
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
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.
Abbildung 39 (textuell angelehnt an [COBIT, 2005]) stellt die detaillierten
Control Objectives fr den Prozess Manage Changes dar.
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.

107

2 IT Service Management
AI6: Manage Changes

AI6.1: Standard-Changes und Prozeduren


AI6.2: Bewertung von Auswirkungen, Priorisierung und Freigabe
AI6.3: Notfall-Changes
AI6.4: Statusverfolgung und Reporting
AI6.5: Abschluss und Dokumentation
Abbildung 39:
COBIT
gliedert die
PerformanceMessung in
Kriterien fr
Effektivitt
und Effizienz

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

108

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

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

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

KGI

KPI

Abbildung 40:

IT Key Goal Indicators


treiben

% der aufgezeichneten
und mit automatisierten Tools verfolgten
nderungen
% der nderungen, die
formale nderungskontrollprozesse
befolgen

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

KGI

Ziele, Prozesse und Metriken in COBIT

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

109

2 IT Service Management
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.
COBIT definiert KPIs und KGIs auf Ebene der Prozesse und der IT-Ziele. Dabei
wird aus einem KGI der Prozessebene ein KPI auf Ebene der IT-Ziele.

Die Metriken und deren Ebenen stellen sich in COBIT wie folgt dar (hier
verdeutlicht am Beispiel Manage Changes, vgl. [COBIT, 2005], siehe
Abbildung 40).
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 Process 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 41):

110

2.7 COBIT
Anforderung
Prozessmanagement

Control
Objectives

KPI

KGI

Prozess

Input

Ziele

Output

Aktivitten

Abbildung 41:

2.7.4

Prozess, Ziele und Kontrollebenen in COBIT

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.

111

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.

2 IT Service Management
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, so dass aus beiden Anstzen die Strken zusammengefhrt werden
knnen.

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

PO:
Plan and
Organise

AI:
Acquire
and
Implement

Prozesse
- Definiere stragischen IT-Plan
- Def. Informationsarchitektur
- Def. technolog. Ausrichtung
- Definiere die IT-Prozesse,
Organisation, Beziehungen
- Manage IT-Investitionen
- Kommuniziere Ziele und
Ausrichtung des Mgmts.
- Manage IT-PersonalRessourcen
- Manage die 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

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

112

2.7 COBIT
Die bereinstimmenden IT Service Management-Prozesse zwischen den
ITIL Best Practices Version 2 und COBIT wurden seitens des IT Governance Institute analysiert und dokumentiert (vgl. [COBIT, 2007]). Der folgenden Abbildung 42 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 42) der Prozess
DS 5 Stelle Systemsicherheit sicher ebenfalls hervorgehoben.
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]).

113

2 IT Service Management

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

114

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

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:

115

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

116

2.7 COBIT
dieses als Service Level-Ziele) sind zu vereinbaren und deren Einhaltung
ist zu berwachen.
Die in COBIT dokumentierten KPIs sind:
Anzahl der 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
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

117

2 IT Service Management
umfasst die Betrachtung der Kosten, des Nutzens und der Priorisierung
von Investitionen innerhalb des geplanten Budgets.
Die in COBIT dokumentierten KPIs sind:
Prozent der Projekte mit einem definierten Nutzen
Prozent der Projekte, fr die ein Review nach dem Abschluss
durchgefhrt werden
Die in COBIT dokumentierten KGIs sind:
Anzahl von Budgetabweichungen
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

118

2.8 Monitoring und Reporting von SLAs

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

119

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

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.

120

2.8 Monitoring und Reporting von SLAs


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

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

121

Von der
System- zur
ServiceOrientierung.

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

Michael E. Porter, Professor fr Wirtschaftswissenschaften an der Harvard


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

122

2.8 Monitoring und Reporting von SLAs


wird von IT Service Providern mithilfe einer geeigneten Kombination aus
Personen, Prozessen und Informationstechnologie durchgefhrt.

IT Service Management
Unternehmensinfrastruktur

IT-Service

Personalwirtschaft

IT-Service

IT-Service

IT-Service

Beschaffung

Produktion

Wertschpfung

IT-Service

IT-Service

Marketing &
Vertrieb

= Primre Prozesse / Aktivitten

KundenService

= sekundre Prozesse / Aktivitten


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

Abbildung 43:

Wertschpfungskette nach Porter

Innerhalb des Glossars wird diese Gesamtsicht zum IT Service nochmals


deutlich herausgestellt; Die Erbringungskriterien der IT Service Organisation
aus Sicht der Kunden, die Services, umfassen nicht nur die Bereitstellung von
Computerressourcen zur Verwendung durch die Kunden (vgl. [OGC, 2006b]).
IT Service
Ein Service, der fr einen oder mehrere Kunden von einem IT Service Provider
bereitgestellt wird. Ein IT Service basiert auf dem Einsatz der Informationstechnologie und untersttzt die Business-Prozesse des Kunden. Ein IT Service besteht aus einer Kombination von Personen, Prozessen und Technologie und sollte in einem Service Level Agreement definiert werden.

Diese Anforderungen an einen IT Service unterscheiden sich in Abhngigkeit der Bedeutung der Geschftsprozesse fr das Unternehmen stark in

123

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

2.8.2

Service Level Agreements

Das Service Level Management hat die Kundenanforderungen an einen IT


Service aufzunehmen. Diese Anforderungen werden in Service Level Requirements (SLRs, Service Level Anforderungen) dokumentiert.
Auf der Basis dieser Anforderungen wird vom IT Service Provider die
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]):
Service Level Agreement:
Eine Vereinbarung zwischen einem IT Service Provider und einem Kunden.
Das SLA beschreibt den jeweiligen IT Service, dokumentiert Service Level-Ziele
und legt die Verantwortlichkeiten des IT Service Providers und des Kunden fest.
Ein einzelnes SLA kann mehrere IT Services oder mehrere Kunden abdecken.

Zur Absicherung des SLAs werden intern Operational Level Agreements


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

124

2.8 Monitoring und Reporting von SLAs


COBIT nimmt bei der Definition von Control Objectives und Leistungsindikatoren (KGI, KPI) Bezug auf den Servicekatalog, die SLAs, die OLAs
und die UCs. Aber: Anforderungen an deren inhaltliche Gestaltung sind in
COBIT nicht dokumentiert. So weist lediglich das Control Objective
DS1.3 Service Level Agreement darauf hin, dass die Rahmenbedingungen 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 Abschnitt 2.8.5 beschrieben.
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 44 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.

125

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

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

2.8.4
Die Struktur
der SLAs ist
unternehmensspezifisch.

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

IT Services
werden system- und organisationsbergreifend
erbracht.

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.

126

2.8 Monitoring und Reporting von SLAs


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.
Um die Aufwendungen fr das Monitoring und Reporting zu reduzieren,
bietet eine mehrschichtige SLA-Struktur viele Vorteile (siehe Abbildung
45). Hinzu kommen weitere Vorteile wie zum Beispiel geringere Aufwendungen 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 45:

Beispiel fr mehrschichtige SLAs

Mehrschichtige SLAs bilden ein hierarchisches System. Auf der obersten


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

127

SLA-Strukturen reduzieren Aufwendungen.

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

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


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

Die ISO 20000-1 beschreibt die Mindestanforderungen an die Dokumentation von IT Services mittels SLAs. So fordert die ISO 20000-1: Der gesamte
Umfang der gelieferten Services mit den zugehrigen Service Levels 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 Servicekatalog und ein Leitfaden fr die inhaltliche Gestaltung der SLAs dokumentiert. Im Zusammenspiel zwischen Servicekatalog und SLA empfiehlt die ISO 20000-2, eine Referenzierung vom SLA zum Servicekatalog
aufzubauen.

128

2.8 Monitoring und Reporting von SLAs


Die ISO 20000-2 empfiehlt die folgenden Inhalte 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 Level-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 Level-Zielen (Service Targets). Service Level-Ziele machen die vereinbarten Ziele fr einen
Service Level messbar. Mgliche Service Level-Ziele knnten zum Beispiel
eine Verfgbarkeit von x % pro Woche oder eine Erstlsungsquote von
x % pro Woche sein.

129

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

Zur Definition der Service Level-Ziele empfiehlt die ISO 20000-2: The
targets, against which the delivered service should be measured, should be defined
from a customer perspective. (vgl. [ISO 20000-2, 2005]). Daraus resultiert die
Anforderung, die SLAs und insbesondere die Service Level und Service
Level-Ziele in einer Sprache zu verfassen, die der Kunde versteht und die
seiner Perspektive entspricht. So sollten zum Beispiel in einem SLA Begriffe wie 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.

Konzentration
auf die wesentlichen
Service Level

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

130

2.8 Monitoring und Reporting von SLAs


-

Datumsangaben: Anfang, Ende, Review


Geltungsbereich der Vereinbarung, was wird zugesichert
und was ist ausgenommen
- Pflichten des IT Service Providers und des Kunden
- Beschreibung des zugesicherten IT Service
Service-Zeiten
- Die Zeiten, in denen der Service gewhnlich bentigt wird
- Vereinbarungen fr die Anforderung von Service-Erweiterungen, 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 Support-Erweiterungen, 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 der
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

131

2 IT Service Management
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 Reportings in die Verantwortung des
Service Level Managements. Dabei werden die SLAs und die damit in
Verbindung stehenden OLAs und UCs gemessen und die Ergebnisse den
jeweiligen Organisationsbereichen berichtet.
In der ISO 20000-1 heit es hierzu: Service Level sind zu berwachen und
gegenber den vereinbarten Zielen (Service Level-Zielen) zu berichten. (vgl.
[ISO 20000-1, 2005]).
Die in den SLAs, OLAs und UCs spezifizierten Vereinbarungen sind hinsichtlich
der Zielerreichung 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 Abschnitt

132

2.8 Monitoring und Reporting von SLAs


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

133

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

2 IT Service Management
und den Nachweis der Einhaltung der Service-Ziele einfordert, ist der
Streit vorprogrammiert.
Bei der Messbarkeit von SLAs darf nicht 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.
Die ISO 20000
verlangt auch
die Darstellung von
Trends.

In der ISO 20000-1 wird aber nicht nur verlangt, dass die Service Level zu
messen und 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 (d.h. Unterschreitung) der festgelegten Service-Ziele.

134

2.9 Integrationsinstrument: Balanced Scorecard

2.8.7

Abgrenzung der Kennzahlen

Die SLAs mit den Service Level und den entsprechenden Service-Zielen
definieren die vereinbarte IT-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 von Robert S. Kaplan und David P. Norton Anfang der 90er Jahre
entwickelte Balanced Scorecard 6 ist nicht nur ein Messsystem, sondern
vielmehr ein exzellentes Management- und Steuerungssystem. Sie kann in
unterschiedlichen Unternehmensbereichen eingesetzt werden. Nach unserer Erfahrung eignet sie sich besonders gut als Management- und Reporting-Instrument 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

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

135

Die Balanced
Scorecard ist
ein Kennzahlen- und
ManagementSystem.

2 IT Service Management
damit nicht nur das operative IT-Geschft, sondern insbesondere die strategische Ausrichtung der IT-Organisation bis hin zum IT-Marketing in der
Balance.

2.9.1

Kernideen

Die Kernideen der Arbeiten von Robert S. Kaplan und David P. Norton
sind einfach und faszinierend. Liest man die ersten Seiten aus [Kaplan et
al., 1996], 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, die zur Steuerung der Maschine reported wird, nicht
ausreicht selbst wenn der Pilot mit dieser Methode in der Vergangenheit
gute Erfahrungen gemacht hat.
Ein Ansatzpunkt der Balanced Scorecard ist gerade die Kritik an der tradierten strategischen 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

136

2.9 Integrationsinstrument: Balanced Scorecard


ergnzt daher die traditionelle finanzielle Perspektive um drei weitere
Perspektiven. Auf diese Weise erhlt man ein 4-dimensionales Modell, das
ein und dasselbe Objekt, z.B. einen Unternehmensteilbereich, aus verschiedenen Blickwinkeln beleuchtet und bewertet.
Die von Kaplan und Norton vorgeschlagene Balanced Scorecard ist 4-dimensional. Sie enthlt die 4 Perspektiven: Finanzen, Kunden, Prozesse7 und Potenziale8.

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

Die Balanced
Scorecard ist
ein mehrdimensionales
und ausgewogenes Zielsystem.

Nach dem Prinzip der Balanced Scorecard macht es keinen Sinn, eine Perspektive in den Vordergrund zu schieben und 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.

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 Prozessperspektive wird im Original Interne Geschftsprozesse genannt.

Die Potenzialperspektive wird im Original Lernen und Entwicklung genannt.

137

Es geht nicht
um kurzfristige Gewinne
sondern um
Kontinuitt.

2 IT Service Management
Die Balanced
Scorecard ist
ein top downInstrument
zur Strategieumsetzung.

Wichtigstes Ziel der Balanced Scorecard ist die Umsetzung von Unternehmenszielen auf allen Ebenen. Dies wird dadurch erreicht, dass sich, ausgehend von der Vision, die Strategie des Unternehmens ableiten 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
Schlagworten translating strategy into action und measures that drive
(future) performance herausgestellt.
Finanzperspektive
Ziel

Kenn- Vorzahl gabe

Manahme

Prozessperspektive

Kundenperspektive
Ziel

Kennzahl

Vorgabe

Vision
und
Strategie

Manahme

Ziel

Kenn- Vorzahl gabe

Manahme

Protenzialperspektive
Ziel

Abbildung 46:

Kenn- Vor- Mazahl gabe nahme

Allgemeine Balanced Scorecard

Um den Kern von Vision und Strategie ranken sich vier Betrachtungsweisen (vgl. Abbildung 46):
Finanzielle Ziele: Wie soll das Unternehmen gegenber Teilhabern
und Kapitalgebern auftreten, um finanziellen Erfolg zu erreichen?
Kundenbezogene Ziele: Wie soll das Unternehmen gegenber Kunden auftreten, um seine Vision zu verwirklichen?

138

2.9 Integrationsinstrument: Balanced Scorecard


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?
Diese Ziele lassen sich beispielsweise folgendermaen detaillieren:9

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

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

139

2 IT Service Management

Finanzperspektive

Kundenperspektive

Prozessperspektive

Potentialperspektive
Abbildung 47:

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

Kundentreue

Qualitt der
Prozesse

Qualifizierte
Mitarbeiter

Geschwindigkeit
der Prozesse

Motivierte
Mitarbeiter

Ursache-Wirkungskette

Unternehmensziele
Strategien

Kundenperspektive
Finanzperspektive

interne Prozessperspektive
Lern- & Entwicklungsperspektive

operative Umsetzung
Erfolgskontrolle
Abbildung 48:

Stellung der BSC im Unternehmensplanungsprozess

Es sollen nicht mehr als 25 Kennzahlen (4 bis 7 je Perspektive) verwendet


werden. Die Kennzahlen sollen Vergangenheit, Gegenwart und Zukunft
messen. Vor allen Dingen sollen die Kennzahlen strategisch dimensioniert
sein, denn das Konzept der Balanced Scorecard dient der beschleunigten
Strategieumsetzung.

140

2.9 Integrationsinstrument: Balanced Scorecard


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

2.9.2

Anwendung auf den IT-Bereich

Die Anwendung der Balanced Scorecard-Methode in IT-Bereichen ist inzwischen weitgehend akzeptiert. Der Nutzen im Hinblick auf Performance-Steigerung und Strategie-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-Prozessen 10
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 --

10

Hier ist insbesondere die Vereinheitlichung im Sinne der Etablierung eines


allgemein akzeptierten Sprachstandards gemeint.

141

2 IT Service Management
Die Grundidee von ITIL V3 ist richtig und besttigt unsere Arbeiten in
vielen Projekten, in denen es darum ging, Kennzahlensysteme zur Steuerung und zum Reporting einzusetzen:
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 entwickeln11, so bietet es sich an, das Beste aus allen Welten zu nehmen. Dies
verdeutlichen wir spter in unserem Kennzahlenmodell und in den Praxisbeispielen.

11

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.

142

2.9 Integrationsinstrument: Balanced Scorecard


Entwicklungsstufen zur IT Balanced Scorecard

Ansatz
von

Perspektiven

Jahr

Anmerkung

Kaplan
und
Norton

1996

Kein expliziter Bezug


zur IT.

Van
Grembergen
und
Saull

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

Finanzen
Kunden
Geschftsprozesse
Lernen u. Entwicklung

143

2 IT Service Management

2.10 Konsequenzen
Die Auswahl der richtigen Kennzahlen ist in der Praxis ein schwieriger
und mehrstufiger Prozess. Die Fragestellung, welcher Ansatz12 der geeignete zum Aufbau eines Kennzahlensystems ist, 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
sind fr ein
wirksames
ProzessManagement
unabdingbar.

Kennzahlen (KGIs und KPIs) und der Aufbau eines Kennzahlensystems


sind kein Selbstzweck. Die Kennzahlen sind nicht zu definieren und zu
berichten, weil COBIT und ITIL entsprechende KPIs bzw. KGIs beinhalten.
Es geht auch nicht darum, diese Kennzahlen zu definieren, weil es die
ISO 20000 verlangt. COBIT und ITIL empfehlen bzw. die ISO 20000 verlangt vielmehr die Definition von Kennzahlen fr jeden IT Service Management-Prozess, weil die Kennzahlen unentbehrliche Informationen fr
das Management von Prozessen darstellen. Das Prozess-Management
(Service Manager, Process 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.

12

Beispielsweise ITIL oder COBIT, aber auch andere.

144

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

145

Es gilt, die
jeweiligen
Strken von
ITIL und
COBIT zu
nutzen.

2 IT Service Management

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

146

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 explizit auf ein Regelsystem zur kontinuierlichen Verbesserung von
Prozessen und Services ein. Normen, wie die ISO 20000 IT Service Management, die ISO 27001 Information Security Management oder die
ISO 9001 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 Deming13 zum PDCA-Zyklus (Plan, Do, Check, Act), der als Deming-Zyklus
international bekannt geworden ist. Deming selbst wies jedoch darauf hin,
dass Walter A. Shewhart14 diesen Zyklus als Erster beschrieben hatte. Da-

13

William Edwards Deming, 1900 - 1993

14

Walter Andrew Shewhart, amerikanischer Wissenschaftler, 1891 - 1967

147

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

Act
Verbessern

Plan
Planen

Stndige
Verbesserung
Check
berprfen

Abbildung 49:

Do
Ausfhren

PDCA-Zyklus

Der PDCA-Zyklus basiert auf einem prozessorientierten Managementansatz, der aus den folgenden Phasen besteht (vgl. [ISO 20000-1, 2005]):
Plan (Planen):
Die Phase dient der 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

148

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 fortlaufende, 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, Process Owners und Prozess-Managers werden, dass die Kennzahlen ein unverzichtbares Werkzeug im
Rahmen des Prozess-Managements sind. Ohne Kennzahlen ist letztendlich keine
Prozessoptimierung und letztendliche Leistungssteigerung 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.

149

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

150

3.3 Etablierung des Prozess-Managements


Mit dem fortschreitenden Out-Tasking wird das notwendige Spezialwissen teilweise durch externe Lieferanten beigestellt. Die Entscheidung 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 Vertragsabschluss erfolgen.
In diese Struktur gilt es die IT Service Management-Prozesse nachhaltig zu
etablieren.

3.3.1

Der Charakter von IT-Prozessen

Ein Prozess kann wie folgt definiert werden (vgl. Service Design, [OGC,
2007b]):
Prozess:
Ein strukturierter Satz an Aktivitten, mit deren Hilfe ein bestimmtes Ziel
erreicht werden soll. Ein Prozess wandelt einen oder mehrere definierte Inputs in
definierte Outputs um. Ein Prozess kann beliebige Rollen, Verantwortlichkeiten,
Hilfsmittel und Steuerungen fr das Management enthalten, die fr eine zuverlssige Bereitstellung der Outputs erforderlich sind. Ein Prozess kann den Anforderungen entsprechend Richtlinien, Standards, Leitlinien, Aktivitten und
Arbeitsanweisungen definieren.

Am Beispiel des Incident Managements soll diese Begriffsdefinition veranschaulicht werden.


Die Zielsetzung des Incident Managements besteht darin, den normalen
Service-Betrieb so schnell wie 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.

151

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

Incident
Service Desk

Client Systeme

Daten und
Systeme

Serversysteme

Netze und
Kommunikation

Datenbanken

LAN

WAN

Externer
Onsite Support

Abbildung 50:

Exemplarische Darstellung der Bearbeitung eines Incidents

In dem abgebildeten Beispiel wird der Incident dem Service Desk gemeldet und dort registriert. Nach einer ersten Untersuchung leitet der
Service Desk den Incident-Record zur weiteren Bearbeitung an die Gruppe
LAN weiter. In dieser Gruppe wird festgestellt, dass das LAN keine
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.

152

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

Incident Management
Problem Management

Service Desk

Daten und
Systeme

Netze und
Kommunikation

Change Management
Release Management

Client Systeme

Service Level
Management
Capacity Management

Serversysteme

Datenbanken

LAN

Externer
Onsite Support

Security Management

Abbildung 51:

IT-Prozesse und bestehende Aufbauorganisation

153

WAN

3 IT Prozess-Management
Damit ergibt sich letztendlich eine Matrixorganisation mit den bekannten
strukturellen Problemen. Die Mitarbeiter sind einerseits einer Linienorganisation zugehrig und unterstellt, andererseits haben sie Aktivitten innerhalb von einem oder mehreren IT Service Management-Prozessen
durchzufhren, wofr jeweils ein Process 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 Vernderungsmanagement 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 muss. 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 beizutra-

154

3.3 Etablierung des Prozess-Managements


gen. Dies erfolgt sowohl durch ein begleitendes Vernderungsmanagement, als
auch durch Konsequenzen bei der Nichteinhaltung von getroffenen Vorgaben.

Damit das IT Service Management erfolgreich innerhalb einer hierarchischen Organisationsstruktur betrieben werden kann, sind die Verantwortlichkeiten eindeutig zu definieren. Diese Definition betrifft einerseits die
Abgrenzung zwischen der Linien- und Prozessverantwortung. Andererseits sind auch 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-Organisationen 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 ProzessManager und einen Process Owner etablieren, sondern diese Aufgaben
zusammenfhren.
Die hier beschriebenen Rollen entsprechen den ITIL Best Practices (vgl.
[OGC, 2007b) bzw. der ISO 20000 (vgl. [ISO 20000-2, 2005):

3.3.2.1 Service Manager


Obwohl es bereits seit vielen Jahren eine offizielle Ausbildung und eine
international anerkannte Zertifizierung zum ITIL Service Manager (vgl.
[KESS, 2007a]) gibt, war diese Rolle in der ITIL Version 2, abgesehen von
der Publikation Business Perspective Volume 2, nicht explizit beschrieben. In einigen Textpassagen wurde zwar auf einen Service Manager hingewiesen, aber eine Rollenbeschreibung hierfr lag nicht vor.
In der ITIL Version 3 ist auch die Rolle des Service Managers beschrieben
(vgl. [OGC, 2007e]):
Service Manager:
Ein Manager, der fr das Management des gesamten Lebenszyklus von einem
oder mehreren IT Services verantwortlich ist. Zudem wird der Begriff Service
Manager fr alle Manager verwendet, die im Bereich des IT Service Providers
beschftigt sind. Am hufigsten wird der Begriff fr Business Relationship Ma-

155

3 IT Prozess-Management
nager, Prozess-Manager, Account Manager oder leitende Manager verwendet,
die allgemein fr IT Services verantwortlich sind.

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.
Daraus folgt, dass es eine den einzelnen Process Ownern und ProzessManagern 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 Process Owner und Prozess-Manager entsprechende
Vorgaben, die in die Prozessziele eingehen und letztendlich auch Auswirkungen auf das Kennzahlensystem haben. Diese Vorgaben werden vom
oberen Management getroffen und liegen in der Verantwortung des Service Managers.
Eine weitere Aufgabe des Service Managers besteht darin, eine Eskalationsebene fr die Process 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 Process Owner und Prozess-Manager die Architekten und
die Bauaufsicht darstellen. Dieser Vergleich trifft aber die Aufgabenstellung nur zum Teil. Whrend die Ttigkeiten der Architekten und der Bau-

156

3.3 Etablierung des Prozess-Managements


aufsicht mit der Fertigstellung des Gebudes abgeschlossen sind, ist das
Prozess-Management eine stetige Managementttigkeit.

3.3.2.2 Process Owner


Der Process Owner ist fr die Zielerreichung des jeweiligen Prozesses
verantwortlich. Der Process 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, Consulted 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 52). 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 52:

Ausschnitt der RACI-Matrix zum Change Management (vgl.


[OGC, 2007c])

157

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

Die Definition der zu erreichenden Ziele wird mit dem Service Manager
abgestimmt und entsprechend dokumentiert.
In der ITIL Version 3 wird die Rolle des Process Owners wie folgt definiert
(vgl. [OGC, 2007b):
Process Owner:
Eine Rolle, verantwortlich fr die Sicherstellung der Zweckmigkeit eines Prozesses. Zu den Verantwortlichkeiten des Process Owners gehren das Sponsorship, das Design, das Change Management sowie die kontinuierliche Verbesserung des Prozesses und seiner Messgren. Diese Rolle wird hufig derselben
Person zugewiesen, der bereits die Rolle des Prozess-Managers zugewiesen ist.
In greren Organisationen knnen diese Rollen jedoch separat zugewiesen
sein.

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

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

158

3.3 Etablierung des Prozess-Managements

3.3.2.3 Prozess-Manager
Die Verantwortung des Prozess-Managers besteht in der erfolgreichen
Umsetzung des Prozesses auf Basis der definierten Ziele. Der ProzessManager ist fr die Durchfhrung des Prozesses verantwortlich.
In der ITIL Version 3 wird die Rolle des Prozess-Managers wie folgt definiert (vgl. [OGC, 2007b):
Prozess-Manager:
Eine Rolle, die fr das operative Management eines Prozesses verantwortlich
ist. Zu den Verantwortlichkeiten des Prozess-Managers gehren die Planung
und die Koordination aller Aktivitten, die zur Ausfhrung, dem Monitoring
und der Berichtserstellung in Bezug auf einen Prozess erforderlich sind. Es knnen mehrere Prozess-Manager fr einen Prozess vorhanden sein, z. B. regionale
Change Manager oder IT Service Continuity Manager fr jedes Rechenzentrum.
Die Rolle des Prozess-Managers wird hufig der Person zugewiesen, der bereits
die Rolle des Process Owners zugewiesen ist. In greren Organisationen knnen diese Rollen jedoch separat zugewiesen sein.

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

159

Kennzahlen
sind die Arbeitsinstrumente des
ProzessManagers.

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

160

3.4 Definition der Prozessziele und -Kennzahlen


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

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.

161

Kennzahlen
sind informations- und/
oder mitbestimmungspflichtig

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

162

3.4 Definition der Prozessziele und -Kennzahlen


Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

SLA
(OLA/UC)

Kapazitten

Abbildung 53:

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 ImprovementPlan (PIP) des jeweiligen Prozesses dokumentiert (siehe Abbildung 54).
In der ISO 20000 werden zwar Reviews in den Prozessen und deren Dokumentation gefordert, aber nicht 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.

163

3 IT Prozess-Management
Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

SLA
(OLA/UC)

Kapazitten
Service
Improvement
Plan
(SIP)
Verbesserungspotenzial

Abbildung 54:

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

164

3.4 Definition der Prozessziele und -Kennzahlen


Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

Neue oder
vernderte
IT-Services

SLA
(OLA/UC)

Kapazitten
Service
Improvement
Plan
(SIP)
Verbesserungspotenzial

Abbildung 55:

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

Prozess
Improvement
Plne
(PIP)

Definition der Prozessziele Kundenanforderungen

165

3 IT Prozess-Management
Auf Basis der geschftspolitischen Ziele des Unternehmens, die grtenteils bereits in den zuvor genannten Anforderungen beschrieben sind,
wird die IT-Strategie entwickelt (siehe Abbildung 57). Im Rahmen der
Entwicklung und Weiterentwicklung der IT Service Management-Prozesse
sind diese strategischen Ziele ebenfalls zu 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 57:

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.

166

3.4 Definition der Prozessziele und -Kennzahlen


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 58). Der Verbesserungsbedarf wird im Rahmen von Audits und Reviews sowie anhand der vorliegenden Prozess-Kennzahlen, deren Sollwerte und der
nachfolgenden Analysen des Prozesses ermittelt.
Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

SLA
(OLA/UC)

Neue oder
vernderte
IT-Services

KundenAnforderungen

GeschftsAnforderungen

ITStrategie

Kapazitten
Service
Improvement
Plan
(SIP)
Verbesserungspotenzial

Prozess
Improvement
Plne
(PIP)
Verbesserungspotenzial

IT Service
ManagementProzesse

Abbildung 58:

Definition der Prozessziele Prozess Improvement-Plan

167

3 IT Prozess-Management
Diese Informationen sind der Input fr die Planung und Implementierung des IT Service Managements (siehe Abbildung 59). Im Rahmen der
Planung und Implementierung des IT Service Managements wird die
Ausgestaltung des gesamten Systems durchgefhrt. Dazu zhlt auch die
Festlegung der Ziele fr die einzelnen Service Management-Prozesse.
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 59:

Definition der Prozessziele Planung und Implementierung

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.

Mit diesem bergeordneten Management-Prozess wird sichergestellt, dass


die IT Service Management-Prozesse auf die Geschftsziele und daraus

168

3.4 Definition der Prozessziele und -Kennzahlen


abgeleitete IT-Strategie ausgerichtet sind. Durch die kontinuierliche Anpassung an eine sich ndernde Umgebung und durch die laufende 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 Management-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 60).
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.
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.

169

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

Planung und
Implementierung
des IT Service
Managements
Anforderungen

Service
Management
Plan
(SMP)

Abbildung 60:

Prozess
Improvement
Plne
(PIP)
Verbesserungspotenzial

Anforderungen

IT Service
ManagementProzesse

Prozess
Management
Plne
(PMP)

Definition der Prozessziele Service Management-Plan

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

170

3.4 Definition der Prozessziele und -Kennzahlen


Business

Business-Anforderungen
IT-Services

Messung
Service Level
(Ziele)

SLA
(OLA/UC)

Neue oder
vernderte
IT-Services

KundenAnforderungen

GeschftsAnforderungen

ITStrategie

Kapazitten
Service
Improvement
Plan
(SIP)
Verbesserungspotenzial

Konformitt

ISO 20000
IT Service
Management

Abbildung 61:

Planung und
Implementierung
des IT Service
Managements
Anforderungen

Service
Management
Plan
(SMP)

Prozess
Improvement
Plne
(PIP)
Verbesserungspotenzial

Anforderungen

Prozess
Management
Plne
(PMP)

IT Service
ManagementProzesse

Konformitt des Managementsystems

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.

3.4.2

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

171

Die Prozessdokumentation stellt die


Leitlinien dar.

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

Prozess
Management
Plan
(PMP)

IT Service
ManagementProzesse

Wird sichergestellt durch

Aktivitten
Kritische Erfolgsfaktoren
Control Objectives
Abbildung 62:

Prozess-Management Prozessdesign

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

172

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

Reviews/
Audits

Prozess-Management berprfung

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.

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

173

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

COBIT

ITIL

Abbildung 64:

Prozess-Management Nutzung von COBIT und ITIL

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

174

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

Abbildung 65:

ITIL

ISO 20000

Prozess-Management Konformitt

175

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

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
ITIL

COBIT

Abbildung 66:

176

ISO 20000

Prozess-Management Prozess Improvement-Plan

3.4 Definition der Prozessziele und -Kennzahlen


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

Vision
Mission
Ziele
Objectives

CSFs

KPIs

Metriken
Messungen
Abbildung 67:

Entwicklung von Kennzahlen

177

3 IT Prozess-Management

3.4.3

Dokumentation der Prozess-Kennzahlen

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.

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

178

3.4 Definition der Prozessziele und -Kennzahlen

3.4.4

Reporting der Prozess-Kennzahlen

An der Zieldefinition und der Ausrichtung der IT Service ManagementProzesse sind verschiedene Management-Ebenen beteiligt. In einem top
down-Ansatz erstreckt sich dieser Prozess vom Top-Management bis zum
Prozess-Manager.
So unterschiedlich die beteiligten Managementebenen sind, so unterschiedlich ist auch deren Informationsbedarf hinsichtlich der etablierten IT
Service Management-Prozesse und der erbrachten Services. Der ProzessManager 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 Process 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 d.h. 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 68):

179

Kennzahlen
mssen ebenengerecht sein.

3 IT Prozess-Management
Anteil fehlerfreier
Changes
Anteil termingerechter Changes

60%

20%

Effektivitt
Change Management

Anteil kostengerechter Changes

20%

Anteil zurckgewiesener Changes

40%
Effizienz
Change Management

Anteil der
Notfall-Changes
Abbildung 68:

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

Abbildung 69:

180

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

3.4 Definition der Prozessziele und -Kennzahlen


Die operativen Systeme, wie zum Beispiel die Tool-Untersttzung fr das
Change Management, liefern die notwendigen Basis-Informationen, aus
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 70).

Top Management

Prozess
Management

gewichtete
Kennzahlen

ProzessKennzahlen
(KGI, KPI)

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

Service
Service
Improvement Management
Plan
Plan

Das IT Service Management Kennzahlensystem

Generell empfiehlt es sich, auf allen Hierarchieebenen 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.

181

3 IT Prozess-Management
Werden zu den absoluten Werten noch die Sollwerte und ein Trend ausgewiesen, so knnen die Prozess-Kennzahlen kompakt und dennoch informativ dargestellt werden.
Abbildung 71 und Abbildung 72 zeigen ein anonymisiertes Projektbeispiel
zum Reporting von Prozess-Kennzahlen. Die erste Seite zeigt die Gesamtbetrachtung und den Trend des Prozesses, 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 71:

182

Exemplarischer Prozess-Bericht Deckblatt zum Report

3.4 Definition der Prozessziele und -Kennzahlen

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

Exemplarischer Prozess-Bericht Darstellung der Kennzahlen

183

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

Abbildung 73:

184

Darstellung des Management Cockpits von iET Solutions

3.5 Von der Kennzahl zur Verbesserungsmanahme

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

Abbildung 74:

Beispiel fr eine Trenddarstellung

Der Prozess-Manager hat durch detaillierte Auswertung festzustellen,


warum sich die Erstlsungsquote verschlechtert. Hierzu muss der ProzessManager 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,

185

3 IT Prozess-Management
knnte die Betrachtung der Erstlsungsquote in Abhngigkeit von dem
durch die aufgetretene Strung betroffenen IT Service sein hilfreich sein
(siehe Abbildung 75).

Abbildung 75:

Beispiel 1 fr eine Analyse mglicher Ursachen

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.

186

3.5 Von der Kennzahl zur Verbesserungsmanahme


In einem weiteren Analyseschritt knnte der Prozess-Manager dann zum
Beispiel auswerten, ob sich hierzu die zugrunde liegenden Fehlerursachen
verndert haben (siehe Abbildung 76).

Abbildung 76:

Beispiel 2 fr eine Analyse mglicher Ursachen

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, so dass Analysen und deren
Richtung situativ durchgefhrt werden knnen.

187

3 IT Prozess-Management

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

188

3.7 Der Umgang mit Kennzahlen


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 10-15 Kennzahlen liegen.

3.7 Der Umgang mit Kennzahlen


Die Kennzahlen dienen primr als Management-Werkzeug fr den Prozess-Manager und den Process 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.

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

189

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

190

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

191

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
Fragebgen15 oder CAPIs16.
Aber mit welcher Fragestellung lsst sich die Anwenderzufriedenheit ermitteln?

15

Diese werden auch User Quality Surveys genannt.

16

CAPI steht fr Computer Assisted Personal Interview.

192

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

193

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

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.

17

Wegen des Verhltnisses von Grenzkosten und Grenznutzen.

194

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

195

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

Beispiele

Fazit

196

Management

Anwender

IT-Entwicklung

IT-Betrieb

Kosten

Leistungen

Nutzen

Sonstige

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.

197

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, so dass sie sich gut praktisch nutzen und einfach
abwandeln lassen.
Zudem sind einige Kennzahlen enthalten, die ntzliche
Hintergrundinformationen liefern, beispielsweise ber
die Struktur der Leistungserstellung.

198

4.3 berblick

4.3.4 Van der Zee 1996


Herkunft

Han van der Zee

Quelle

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


Dissertation, Katholische 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.

199

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 kann18, 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: Keines19.
In der Praxis zeigt sich:
Der berdeckungsgrad der Kennzahlensysteme ist eher gering, d.h.
jedes Kennzahlensystem liefert neue Aspekte.
Die Anforderung, dass Prozessmodelle des IT Service Managements
zu bercksichtigen sind, liefert nicht weniger, sondern mehr Kennzahlen.
Kein Kennzahlensystem ist ohne Modifikation in der Praxis einsetzbar:
Zu viele Kennzahlen werden genannt.

18

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

19

Vielleicht etwas hoffnungsvoller, vershnlicher (und diplomatischer): Keines


ohne Modifikation.

200

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

201

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.

203

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

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.

204

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

205

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. 20
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 78). Die Kennzahlen knnen
Key Performance-Indikatoren21 oder Customer Satisfaction Indices aus der
Ebene des IT-Managements sein, die durch Aggregation entstehen. Im
Folgenden geben wir einen Ausschnitt aus einem solchen Kennzahlensystem an:

20

ROI im Sinne Return on IT.

21

KPIs im Sinne einer betriebswirtschaftlichen Begriffsbestimmung (vgl. den


Exkurs zum Begriff KPI in Kapitel 5.2.2.)

206

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

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 79).
Meistens benutzen wir zwischen 5 7 Perspektiven und damit auch 5 7
Key Success-Faktoren, die die IT insgesamt darstellen. Nicht zu viel und
nicht zu wenig gerade geeignet, um die Lage der IT dem Top Management transparent zu machen.
Jeder Key Success-Faktor sollte mit einem kurzen Text versehen werden,
der den Verlauf der Kennzahlen interpretiert und sich auf die aktuelle

207

5 IT Praxisleitfaden 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 79:

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.

208

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 80 zeigt
zum einen, wie kompliziert die Wahrnehmungsprozesse sind, und zum
anderen, dass es viele Schnittstellen gibt, an denen die Kunden- und Providersicht unterschiedlich sein kann.

Customer
Satisfaction
Index

Customer
Satisfaction
Index
Abbildung 80:

Beispiele fr Lcken zwischen Kunden- und Providersicht

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


man CSIs messen kann:

209

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Zwischen Leistungserwartung und Servicewahrnehmung kann es
eine Lcke 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 Lcke 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 Lcken (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 Abbildung 81 ist angelehnt an Continual Service Improvement [OGC, 2007e] und stellt diese Gaps dar. Interessant ist, dass sie
beim Kunden, beim Provider und auch zwischen Kunde und Provider
auftreten 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 dasteht. Andere Quellen sind natrlich das Service Level Management, aber
auch der Service Desk sowie das Projekt Management.

210

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

GAP 10

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

Exkurs: Zum Begriff Key Performance Indicator (KPI)


Es sei an dieser Stelle angemerkt, dass der Begriff Key Performance Indicator (KPI) in vielen 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.

211

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

5.2.3

IT-Controls und Controls on Demand

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

212

5.2 Klassifikationsschema fr IT-Kennzahlen


Beispiele fr IT-Controls sind:

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

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

22

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

23

Dito.

24

Dito.

213

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen

Anwendungen
Datensicherungsprotokolle
Anzahl Datenstze in SAP BW

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

214

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

215

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

216

5.3 Prozess-Kennzahlen

5.3.1

Service Strategy

5.3.1.1 Financial Management


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

217

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

218

5.3 Prozess-Kennzahlen

5.3.2.1 Service Portfolio Management


Dieser Prozess ist fr das Management des Serviceportfolios 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 Serviceportfolios

Name der Kennzahl

Anteil gelieferter Services

Definition

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

Relevanz

Diese Kennzahl zeigt die Nachfrage der angebotenen Services auf.

Messwert

Auswertung der Services im Servicekatalog und


im Serviceportfolio.

Name der Kennzahl

Anteil Relationen IT Services zu 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 Serviceportfolios.

Name der Kennzahl

Anteil Vernderungen im Serviceportfolio

Definition

Anteil der im Serviceportfolio vorgenommenen


Vernderungen an den enthaltenen Services.

Relevanz

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

Messwert

Auswertung des Serviceportfolios.

219

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Name der Kennzahl

Status der Services im Serviceportfolio

Definition

Status der Services im Serviceportfolio

Relevanz

Die Kennzahl zeigt den Anteil der produktiven


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

Messwert

Auswertung des Serviceportfolios und Gruppierung anhand des Status.

Bemerkung

Die Services knnen den folgenden Status annehmen


Servicekatalog,
Servicepipeline (Service noch nicht produktiv) und Retired Services

5.3.1.3 Demand Management


Das Demand Management hat die Kundenanforderungen an die IT Services aufzunehmen und zu beeinflussen, so dass die notwendigen 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

220

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

Definition

Anzahl und Anteil der im Betrieb befindlichen


Services, die im Servicekatalog beschrieben
sind.

Relevanz

Der Servicekatalog soll alle im Betrieb befindlichen Services enthalten. Diese Kennzahl zeigt
die Qualitt und Aktualitt des Servicekatalogs
auf.

Messwert

Vergleich der SLAs mit dem Servicekatalog.

Bemerkung

Bei der Messung wird vorausgesetzt, dass fr


alle im Betrieb befindlichen Services SLAs existieren.

Name der Kennzahl

Inhaltliche Abweichungen zum Servicekatalog

Definition

Anteil der inhaltlichen Abweichungen der im


Betrieb befindlichen Services gegenber den
Spezifikationen im Servicekatalog.

Relevanz

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

Messwert

Vergleich der SLAs mit dem Servicekatalog.

Bemerkung

Bei der Messung wird vorausgesetzt, dass fr

221

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


alle im Betrieb befindlichen Services SLAs existieren.

5.3.2.2 Service Level Management


Der Prozess Service Level Management (SLM) ist 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 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.

222

5.3 Prozess-Kennzahlen
Bemerkung

Hierzu muss definiert werden, wann ein SLA


als eingehalten zhlt. Zum Beispiel, wenn alle
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 bzw. Contracts entstanden sind.

Relevanz

Knnen SLAs nicht eingehalten werden, weil


der Lieferant seine Zusagen nicht einhlt, so

223

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


mssen entsprechende Folgeaktivitten eingeleitet werden.
Messwert

Hier sollte auf ein professionelles SLM-Tool


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.

224

5.3 Prozess-Kennzahlen
Messwert

Auswertung der offenen Manahmen im SIP.

Bemerkung

Die Manahmen sollten im Plan mit einem Status versehen werden. Dadurch knnen offene
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-Ziele, 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

225

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Messwert

Die Auslastungen werden in der Regel aus dem


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

Name der Kennzahl

Prozentsatz unzureichender Antwortzeiten

Definition

Prozentsatz der Antwortzeiten, die dem SLA


nicht entsprechen.

Relevanz

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

226

5.3 Prozess-Kennzahlen
Messwert

Die Anzahl ist dem System Management zu


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

Name der Kennzahl

Kosteneinsparung durch das Capacity Management pro Bereich oder Technologie

Definition

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

Relevanz

Capacity wird in immer mehr Unternehmen


nicht nur in der Prognose von 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.

227

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Messwert

Vergleich ber mehrere Tage, Wochen, Monate


der Anzahl der eingehenden zu den ausgehenden Mails.

5.3.2.4 Availability Management


Der Prozess ist verantwortlich 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.

228

5.3 Prozess-Kennzahlen
Name der Kennzahl

Nicht-Verfgbarkeit innerhalb kritischer Geschftszeiten

Definition

Nicht-Verfgbarkeit innerhalb kritischer Geschftszeiten fr einen IT Service.

Relevanz

Wurden mit dem Kunden kritische Geschftszeiten 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 ver-

229

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


bundenen Kosten. Von der Auswertung von
Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel ber MessPCs.
Bemerkung

Zum Teil wird diese Zeit als MTTR Mean


Time to Restore bezeichnet. Hufiger wird die
Abkrzung 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.

230

5.3 Prozess-Kennzahlen

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

231

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


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

Auswertung der durchgefhrten Testprotokolle.

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

232

5.3 Prozess-Kennzahlen
genber dem IT Service Provider hat und die Handhabung von Schriftstcken, Gebudezugngen, Telefonanrufe usw. fr die gesamte Organisation
beinhaltet.
Name der Kennzahl

Anzahl und Auswirkungen Security Incidents

Definition

Anzahl und Auswirkungen der festgestellten


Security Incidents.

Relevanz

Aufgabe des Security Managements ist die Analyse mglicher 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.

233

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Messwert

Auswertung durchgefhrter Audits und Revisionen.

Bemerkung

Festgestellte Verletzungen von ComplianceAnforderungen sind besonders herauszustellen.

Name der Kennzahl

Anzahl vergeblicher Login-Versuche

Definition

Anzahl der festgestellten vergeblichen LoginVersuche.

Relevanz

Eine hohe Anzahl vergeblicher Login-Versuche


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

234

5.3 Prozess-Kennzahlen

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

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

235

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


schieden 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


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.

236

5.3 Prozess-Kennzahlen
Bemerkung

5.3.3

Es kann auch der Lieferant zur Zufriedenheit


befragt werden.

Service Transition

5.3.3.1 Transition Planning and Support


Der Prozess Transition Planning und Support ist verantwortlich 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.

237

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Name der Kennzahl

Kundenzufriedenheit Service Transition-Plne

Definition

Ergebnis der Kundenzufriedenheit bezglich


der Service Transition-Plne.

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.

238

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

239

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-

240

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

241

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


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

Relevanz

RfCs knnen zurckgewiesen werden, wenn sie

242

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

243

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


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

Name der Kennzahl

Auswirkungen fehlerhafter CIs

Definition

Anzahl der fehlerhaften Changes, deren Ursa-

244

5.3 Prozess-Kennzahlen
chen auf fehlerhafte CIs und CI-Informationen
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.

245

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

246

5.3 Prozess-Kennzahlen
Name der Kennzahl

Fehlerhafte CMS

Definition

Anzahl der durch das Release Management


verursachten Abweichungen zwischen dem
CMS und dem Ist-Bestand.

Relevanz

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

247

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

248

5.3 Prozess-Kennzahlen
Name der Kennzahl

Anzahl Incident fehlendes Anwender-Wissen

Definition

Anzahl der Incidents mit der Kategorisierung


fehlendes Anwender-Wissen.

Relevanz

Das fehlende Anwender-Wissen 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 verbundenen 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.

249

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-

250

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.

251

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

252

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-

253

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

254

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

255

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-

256

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

257

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen

5.3.4.3 Request Fulfilment


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.

Messwert

Dem Service Request muss ein Workflow mit

258

5.3 Prozess-Kennzahlen
einer geplanten Bearbeitungszeit hinterlegt sein.
Auf dieser Basis kann die Einhaltung berwacht
werden.
Bemerkung

Diese Kennzahl kann als Service Level in Service-Berichte 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.

259

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

260

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.

261

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.

262

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 Incidents und Service Requests und wickelt auch die Kommunikation mit den Anwendern ab.
Der Service Desk beschreibt die funktionalen Anforderungen an eine Organisation und ist kein Service Management-Prozess. Der Service Desk ist
in verschiedene Prozesse eingebunden, mit dem Schwerpunkt in den Prozessen Incident Management und Request Fulfilment. In diesem Kapitel
werden die Kennzahlen ausgewiesen, die nicht zu den bereits ausgewiesenen Prozess-Kennzahlen, wie zum Beispiel der 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-

263

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.

264

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 messen wollen werden durchzufhrende Aktivitten bis zur Implementierung korrigierende Aktionen beschrieben.
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.

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.

265

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Name der Kennzahl

Kundenzufriedenheit Service Reporting

Definition

Ergebnis der Kundenzufriedenheit mit dem


Service Reporting.

Relevanz

Das Service Reporting und die enthaltenen sowie dargestellten Informationen 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.

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 eines Servers oder einer Applikation zu messen und zu berichten. Die IT muss in der Lage sein, end-to-end-Services zu messen
und zu berichten. Hierzu gibt es mit der Verfgbarkeit, Zuverlssigkeit
und Performance drei Grundmessungen, von denen die meisten Organisationen Gebrauch machen.

266

5.3 Prozess-Kennzahlen
Name der Kennzahl

Anteil SLAs mit end to end-Messung

Definition

Anteil der SLAs, deren Service Level und die


Erreichung der Service Level-Ziele auf Basis
einer end to end-Messung gemessen werden.

Relevanz

Eine end to end-Messung stellt die Sicht des


Business auf den Service dar und 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

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

267

5 IT Praxisleitfaden fr die Entwicklung von Kennzahlensystemen


Name der Kennzahl

Mehrwert Business

Definition

Mehrwert der durchgefhrten 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 Abschnitt 5.3.2.2 (Prozess Service Level Management innerhalb von
Service Design) beschrieben.
Speziell die Service Improvement-Programme (SIP) und die damit verbundenen Kennzahlen betreffen die Manahmen innerhalb des Continual
Service Improvements.

268

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.

269

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

270

6.2 ITIL-Einfhrung
Ihrer Einschtzung, aber auch mit Ihren Mitarbeitern und dem gewhlten
Berater befllen, analysieren, vergleichen und bewerten knnen.
Die ITIL-Prozesslandkarte soll aus den Prozessbedrfnissen der IT-Organisation
im Bezug auf die Unternehmensstrategie entwickelt werden, ggf. unter Beteiligung eines Coaches. Dadurch lernen Sie und Ihre Mitarbeiter die ITIL Best
Practices erheblich besser kennen.

Fr die Einstufung der Prozesse ist ausreichendes internes oder externes


Prozesswissen 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 ist die mangelnde Akzeptanz der geplanten Manahmen und die damit verbundene Verzgerung
bei der Umsetzung.

271

Initiierung
der geplanten
Manahmen

6 Lessons learned: Empfehlungen und Ratschlge


Konsequenz hieraus: Der eigenen Organisation muss nun die Chance gegeben werden, sich weiterzuentwickeln und ITIL zu adaptieren.
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. Hierzu gibt es verschiedene Mglichkeiten, beispielsweise der Besuch
von Kongressen, Inhouse-Seminare oder Workshops fr Ihre Mitarbeiter.

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

272

6.2 ITIL-Einfhrung
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. Wir werden in Zukunft Ihre Businessprozesse
noch optimaler untersttzen knnen.

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

273

6 Lessons learned: Empfehlungen und Ratschlge


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.
Wertschtzung des
Bestehenden

Fr eine erfolgreiche Etablierung der geplanten IT Service ManagementProzesse ist die Akzeptanz seitens Ihrer Mitarbeiter eine unabdingbare
Voraussetzung.
Bei der Analyse der ITIL-Prozesslandkarte werden Sie wahrscheinlich
feststellen, dass die bestehenden Prozesse die Anforderungen der ITIL
Best Practices nicht 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, aus den Best
Practices zu lernen und sich 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 sie unbedingt selbst erarbeiten.

274

6.2 ITIL-Einfhrung
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)
Kenntnisse verfgen, sondern auch Erfahrungen aus vergleichbaren Projekten und vergleichbaren Organisationen mitbringen. Nicht zuletzt ist die
Sozialkompetenz des Beraters dabei ein weiterer wichtiger Erfolgsfaktor:
Die Chemie muss stimmen.
Der Berater muss in der Lage sein, ggf. mit anderen Beratern zusammenzuarbeiten. Hierbei kann es sich unter Umstnden um Berater handeln, die
im Rahmen von IT Governance-Projekten ttig sind oder die Vernderungsprozesse Ihrer 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 von Incidents oder Dauer der Nichtbearbeitung
der Tickets aus dem Incident-Prozess oder aus Tools gewonnen.
Nach deutschem Recht ist der Betriebsrat zumindest ber diese 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

275

Einbeziehung
des Betriebsrats

6 Lessons learned: Empfehlungen und Ratschlge


Prozesse gemessen werden und keine Auswertung auf Mitarbeiterebene erfolgt.
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 ProzessManager 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 Managementvorgehensweise
in der IT-Organisation: 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 ITOrganisation.
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 Ihren Zielen fr Ihr Unternehmen und bezogen auf die Businessprozesse.
Ebenso sollte der Reifegrad, d.h. 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.

276

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.

277

6 Lessons learned: Empfehlungen und Ratschlge


Zur Identifizierung der verschiedenen Motivationsgrnde ist es hilfreich, ber
einen externen Berater mit entsprechenden Erfahrungen zu verfgen.

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 oft in
IT Rechenzentren 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. In von uns beratenen Unternehmen konnte zum
Beispiel mit Hilfe des Prozesses Capacity Management dargestellt werden,
welche Kosteneinsparungen durch die Konsolidierung der ITInfrastruktur erzielt wurden.

6.2.4
Die Rollen
gem der
ITIL Best
Practices

Rollenbeschreibungen

Innerhalb der ITIL Best Practices bis Version 2 finden Sie Rollenbeschreibungen zu den einzelnen Prozess-Managern der IT Service ManagementProzesse. Schauen Sie sich hierzu [OGC, 2005b], [OGC, 2006b] und [OGC,
2006a] an:
OGC Best Practice for Service Support,
OGC Best Practice for Service Delivery und
Best Practice fr Security Management.
Generelle Rollenbeschreibungen fr den Prozess-Manager und den Process 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
Process Owner und Prozess-Manager. Diese generischen Rollenbeschreibungen sind im Rahmen der Umsetzung entsprechend der jeweiligen Organisation zu operationalisieren.

278

6.2 ITIL-Einfhrung
Diesen Empfehlungen gem ist der Prozessinhaber (Process Owner) fr
die Prozessergebnisse verantwortlich, whrend der Prozess-Manager fr
die Durchfhrung und die Einrichtung des Prozesses verantwortlich ist.
Der Process Owner dient dem Prozess-Manager primr als Coach.

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


ProzessManagers

Die Prozess-Ziele werden nicht nur primr vom Process Owner vorgegeben, sondern auch durch ihn aus der IT-Strategie und der Balanced Scorecard abgeleitet. Aus diesen Anforderungen heraus definiert der ProzessManager die notwendigen Prozess-Ziele und die damit verbundenen
Kennzahlen.
Es muss sichergestellt werden, dass die Prozess-Manager ein 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 (natrlich auch den Process Owner)
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.

279

Die Rolle des


Service
Managers

6 Lessons learned: Empfehlungen und Ratschlge


Fr die Einfhrung der IT Service Management-Prozesse und der identifizierten Optimierungsmanahmen ist der Service Manager richtungsweisend, er erstellt den Bebauungsplan.
Die Rolle des Service Managers muss mit einem erfahrenen Manager besetzt
werden.
Die Rolle
des TopManagements

Aufgabe des Top-Managements ist es, den zu etablierenden IT Service


Management-Prozessen den 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 ProzessManager 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 Process 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 ProzessManager steuern auf Qualittsebene die operative Arbeit der Mitarbeiter.

280

6.3 Kontinuierlicher Verbesserungsprozess


Stellen Sie sicher, dass Ihre Mitarbeiter sich in dieser Situation nicht verloren vorkommen. Die Hierarchie, insbesondere das mittlere Management,
muss die Prozesse aktiv untersttzen, um damit die Ziele der ITIL-Einfhrung nachhaltig zu untersttzten.
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 82.
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.

281

6 Lessons learned: Empfehlungen und Ratschlge


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.

Abbildung 82:

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

282

6.3 Kontinuierlicher Verbesserungsprozess

6.3.1

KVP der bestehenden Prozesse

Ausgangspunkt ist die oben beschriebene Analyse der bereits innerhalb


der IT-Organisation bestehenden IT Service Management-Prozesse.
Prozess-Manager von bereits bestehenden IT Service Management-Prozessen befinden sich dabei in einer vermeintlich komfortablen Ausgangsposition: Whrend andere Prozesse noch zu definieren und zu entwickeln sind,
bestehen deren Prozesse bereits.
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 ProzessManager 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.

283

6 Lessons learned: Empfehlungen und Ratschlge


Dem Prozess-Manager mit dem bereits am weitesten entwickelten Prozess
kommt hierbei eine besondere Rolle zu. Er muss auf die anderen ProzessManager zugehen und die Vernetzung der einzelnen Prozesse aktiv vorantreiben und sicherstellen.
Planen Sie zum Beispiel die Etablierung des Incident, Problem und Change Managements und ist der Prozess des Incident Managements am weitesten fortgeschritten, so muss der Prozess-Manager des Incident Managements die fhrende Rolle bei der erforderlichen Vernetzung der drei Prozesse einnehmen.
Bei den bestehenden Prozessen zeichnet sich der KVP dadurch aus, dass
die Prozesse gleichmig (vertikal) entwickelt werden und kein Process
Owner oder Manager die Entwicklung isoliert vorantreibt.

6.3.2
Nicht zu frh
beginnen

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 wirklich 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 Vernderungsmanagements.
Der Soziologe Kurt Lewin gilt als Wegbereiter der Organisationsentwicklung. Aufbauend auf seiner Grundannahme, dass sich eine Organisation
ndert, wenn sich ihre Akteure ndern, entwickelte er sein Phasenmodell
(vgl. Abbildung 83) zum Vernderungsmanagement (vgl. [Lewin, 1958]).

284

6.3 Kontinuierlicher Verbesserungsprozess

Neue Welt

Alte Welt

Einfrieren

Auftauen

Bewegen
Abbildung 83:

3-Phasen-Modell nach Lewin

Im Ausgangszustand befindet sich eine Organisation im Gleichgewicht.


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

285

6 Lessons learned: Empfehlungen und Ratschlge


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.
Beginnen Sie zu frh mit den nchsten Verbesserungsmanahmen, so
nehmen Sie ihrer IT-Organisation und Ihren Mitarbeitern die Chance, die
bisher erzielten Vorteile zu erleben.
Das Service
ImprovementProgramm

Innerhalb der ITIL Best Practices wird lediglich im Rahmen des Service
Level Management-Prozesses auf ein Service Improvement-Programm
(SIP) eingegangen. Die ISO 20000 IT Service Management ist hier konsequenter. Dort wird zu den jeweiligen Prozess-Reviews gefordert, dass ein
erkanntes Verbesserungspotenzial zu Prozessen oder Services der Input
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 ITOrganisation beitragen.

286

6.3 Kontinuierlicher Verbesserungsprozess


Damit entsteht eine Kombination aus formellen Reviews zur Service- und
Prozessoptimierung und einem betrieblichen Vorschlagswesen. In Ihrer
Organisation existiert damit ein Verbesserungsprozess, der Input fr neue
und eingefhrte IT Service Management-Prozesse aus der IT-Organisation
(Reviews) und von den Mitarbeitern bezieht.
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.

ITILEinfhrung
erfordert ein
Release

Diese Verbesserungsttigkeit 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.
Bndeln Sie die einzelnen Verbesserungs- und Erweiterungsmanahmen zu einem Aufgabenpaket (Release).

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

287

Der
Entfaltungsprozess

6 Lessons learned: Empfehlungen und Ratschlge


Es ist hilfreich, wenn die Process 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.
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 initiiert
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 in vollem Umfang 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 (auch die Process
Owner und die IT-Leitung) und damit indirekt auch das gesamte Management ber ein gutes Fhrungssystem zur berwachung der geplanten
Manahmen und der erzielten Prozessreife.

288

6.3 Kontinuierlicher Verbesserungsprozess


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.

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

289

6 Lessons learned: Empfehlungen und Ratschlge


rungsprozess und der damit verbundenen Planung entsteht so auch ein
internes Benchmarking.

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 Knowhow. Der Berater muss daher unbedingt als Coach auftreten. Erfahrene
Berater sind in der Lage, sich durch eine kurze Bestandsaufnahme einen
Eindruck zu verschaffen, der 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.

290

6.4 Kennzahlen
Die Abstimmung des IT Service Managements auf die Business-Strategie
sollte so frh wie mglich erfolgen. Klren Sie zunchst innerhalb der ITOrganisation, welche IT Services, welche Service Level und welche Messungen realistisch zugesichert werden knnen. Sie vermeiden dadurch
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 mssen 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.

291

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 (vgl. [OGC, 2005b])
fhrt hierzu aus: 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.

292

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.

293

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 Process Owner geben. Aufgrund der Anforderungen und seinen Erfahrungen aus dem Tagesgeschft ist der Process Owner
der ideale Partner, um die notwendigen Kennzahlen zu diskutieren und
zu definieren.
Interessante Kennzahlen fr den Beginn eines Kennzahlenmonitorings
knnen sein:
Anzahl der mit Ihren Kunden vereinbarten SLAs
Anzahl der Notfall / BCM-bungen pro Jahr in Bezug auf das IT
Service Continuity Management
Anzahl der vorhandenen Assets pro Gruppe (Windows, Unix, Host
etc.) in Bezug auf das Configuration Management
Anzahl der 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.
Im Rahmen dieser schrittweisen Erweiterung knnen Sie dann auch auf
Best Practices wie ITIL oder COBIT zurckgreifen. Prfen Sie die dort

294

6.4 Kennzahlen
dokumentierten Kennzahlen auf sinnvolle Nutzung in Ihrer IT-Organisation, und bernehmen Sie sie nur bei einer positiven Bewertung.
Wollen Sie eine Revision Ihrer IT Service Management-Prozesse auf der
Basis von COBIT sicherstellen, so sollten Sie die Umsetzung dieser Anforderung als Stufe Ihres KVP planen und nicht zu Beginn des Prozesses integrieren.
Im weiteren Reifegrad der ITIL-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
Volumina (z.B. < 100.000 Euro; < 500.000 Euro) und damit eine
Gruppierung nach A,B,C Kunden.

6.4.2

ITIL abgestimmt auf Business- und IT-Strategie

Charakteristisch 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
Service wahrnimmt. Dies ist in der Regel der Arbeitsplatz, und dieser Ansatz fhrt damit zu einer end-to-end-Messung des IT Service.

295

Den Kunden
rechtzeitig
einbinden.

6 Lessons learned: Empfehlungen und Ratschlge


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, d.h. die Realisierung einer end-to-end-Messung, sollte zumindest mittelbis 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 Kundenservice-Manager und dem Relationship-Manager, 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
mit Ihrem Kunden besprechen. Es besteht ansonsten die Gefahr, dass der
Kunde einige von Ihnen nicht umsetzbare Anforderungen definiert, was in
der Folge zu (vermeidbarer) Unzufriedenheit und 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.

296

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

297

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 erreichten Service Level zu berichten.
Es gilt die Maxime, dieses Reporting in einer Sprache und Darstellung vorzunehmen, die der Kunde versteht, also in der Sprache des Kunden, nicht
in der Sprache des Technikers. Beispielsweise kann es sinnvoll sein, darzustellen, welche Folgen Strungen hatten, welche Konsequenzen ein Ausfall
einzelner Standorte hatte und welche Verbesserungsmanahmen eingeleitet wurden, um diese Ausflle in Zukunft zu vermeiden.
Ein monatlicher Report knnte beispielsweise folgende Informationen
enthalten:
Im Monat Mrz hatten wir am 12.3.2007 eine Strung in der Anwendung
XYZ. Diese Strung wurde hervorgerufen durch den Austausch einer
technischen Komponente, die zu einem Ausfall des Netzwerkes 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 Hardware-Wechsels vor Ort verfgbar zu haben, um damit
eine schnellere Reparatur zu ermglichen und so die Verfgbarkeit zu
erhhen.
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.
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 Management hat die
Weiterentwicklung zur
Aufgabe

Das Top-Management, der Service Manager, die Process Owner und die
Prozess-Manager sollen beobachten, wie sich die Umsetzung der ITIL Best
Practices im Unternehmen weiterentwickelt. Hierbei ist auch relevant, wie
sich vergleichbare andere IT-Organisationen weiter entwickeln und wie
sich diese Weiterentwicklung in Bezug auf Ihre Organisation darstellt.

298

6.4 Kennzahlen
Die dokumentierten ITIL Best Practices unterliegen zwar einer stetigen
Weiterentwicklung, aber diese geht erst mit einem Zeitverzug in die offiziellen Publikationen ein. Auf Kongressen, wie dem ITIL-Forum oder dem
Jahreskongress der itSMF Deutschland e.V., wird aktuell ber Erfahrungen mit der Umsetzung der ITIL Best Practices und ber in Unternehmen
vollzogene Ausgestaltungen und Erweiterungen berichtet.
Auf diesen Kongressen knnen Sie nicht nur vergleichen, wo Ihre IT-Organisation 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 Process 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 IT-Organisationen beobachten, andere Anstze prfen und mehrwertschaffende Konzepte
adaptieren.

Auf 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 ProzessManager die Mitarbeiter in denjenigen Prozessen schulen, in denen
diese eingebunden sind. Hierbei wird insbesondere geschult, wie
die jeweiligen Prozesse innerhalb der jeweiligen Organisation des
Unternehmens ihre Anwendung finden (von der Theorie zur Praxis).
Sind die IT Service Management-Prozesse auf Basis der ITIL Best
Practices 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.

299

Mitarbeiter
mssen geschult werden

6 Lessons learned: Empfehlungen und Ratschlge


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

300

6.4 Kennzahlen
Logische Konsequenz hieraus ist, dass sich auch die Kennzahlen und deren Soll-Werte aus der IT-Strategie ergeben.
Um alle Bereiche auf die IT-Strategie auszurichten, sollten sie 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 Process Owner


In den vorhergehenden Kapiteln wurde bereits auf die Rolle des Service
Managers, des Prozess-Managers und des Process Owners eingegangen.
Oft knnen Process Owner und Prozess-Manager organisatorisch ber
Kreuz besetzt werden dass heit, der Process 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
Process Owner allein aufgrund der hierarchischen Stellung den ProzessManager.

Service Manager
In den ITIL Best Practices finden sich zwar an einigen Stellen Hinweise
zum Service Manager, aber eine 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.

301

Die Balanced
Scorecard ermglicht die
Ausrichtung
auf die ITStrategie

6 Lessons learned: Empfehlungen und Ratschlge


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

Process Owner
Innerhalb des RZs hat es sich als vorteilhaft erwiesen, die Rolle des Process Owners rotieren zu lassen. Durch die wechselnden Process Owner
wird der Blickwinkel des Prozess-Managers im Laufe der Zeit erweitert.
Wenn mglich, wird die Rolle des Process Owners aus dem Bereich besetzt, der die grten Auswirkungen des Prozesses erfhrt. So kommt zum
Beispiel der Process 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 Process Owner werden aus einer Hierarchieebene besetzt, die gegenber der IT-Organisation weisungsbefugt ist. Innerhalb des Rechenzentrums unseres Beispiels sind die Process Owner Bereichs- und Abteilungsleiter, die direkt der Geschftsfhrung berichten.

302

6.4 Kennzahlen

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

303

6 Lessons learned: Empfehlungen und Ratschlge


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

304

7 Praxisbeispiel: ALTANA Pharma AG


IT Service Management im regulierten Umfeld
am Beispiel der ALTANA Pharma AG

Dr. Jan Hadenfeld


IT Change und Configuration Manager
ALTANA Pharma AG, ein Unternehmen der Nycomed Gruppe
www.nycomed.com

Firmenportrait
Nycomed ist ein internationales pharmazeutisches Unternehmen, das
Arzneimittel 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.

305

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

306

7 Praxisbeispiel: ALTANA Pharma AG


Hier haben sich so genannte Best Practices wie
Good Automated Manufacturing Practice (GAMP)
Control objectives for information and related technology (CobiT)
IT Infrastructure Library (ITIL)
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 den IT Service Support Prozessen
und verfolgte die folgende Zielsetzung:
Erstellung eines ALTANA Pharma spezifischen Konzepts zum IT
Service Management nach ITIL (bzgl. der betrachteten Disziplinen)
Aufbau eines Account Managements fr interne Kunden der IT
Aufbau eines Service Level Management-Prozesses, insbesondere
Einfhrung eines Leistungs- und Servicekatalogs
berarbeitung der Incident- und Problem Management-Prozesse sowie deren inhaltliche Trennung
Finetuning des Change Management-Prozesses sowie die Erstellung
der Grobstruktur 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 dienten
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

307

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.

308

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-

309

7 Praxisbeispiel: ALTANA Pharma AG


dung werden die monatlichen Reporte teilweise auch automatisiert
erzeugt.

Change Management
Aus den genannten Gremien heraus wurden immer wieder Informationen
ber den Change Management-Prozess bentigt. Die Kennzahlen wurden
meistens nach der Bottom-up Methode erstellt, d.h. dort wo der Schuh
am meisten drckte. Dies sind mengenorientierte Kennzahlen wie
Anzahl RfCs pro Kalenderwoche / Monat (siehe Abbildung 84) /
Jahr / Workgroup / Priorisierung / Service
32
28
24

# of RfCs

20
16
12
8
4

07

7
M

ai

20

20
0

07
A

z
r

pr
il

20

00
r2
M

Fe

br

ua

ar
nu
Ja

be

07
20

00
r2

r2
D

ez

em

em
ov
N

6
00

06
be

er
kt
ob

m
te
ep
S

be

us
ug
A

20

00

6
t2

r2

00

6
00

li
2

ni
Ju

Ju

20
0

06
20
ai
M

Abbildung 84:

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 85) 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 vorgegebene
Datum des nderungsanforderers berschritten ist
Anzahl RfCs mit verknpften Incidents oder Problems

310

7 Praxisbeispiel: ALTANA Pharma AG


Rejected

New
Assessed
Authorized
Developm ent Com pleted
Release to Production
Technically Completed
User Acceptance

New
4
2,2%
Ass ess ed
1
0,6%
Authorized
6
3,3%
Developm ent C om pleted
1
0,6%
Releas e to Production
6
3,3%
Tec hnic ally Com pleted
3
1,7%
Us er Ac ceptanc e
3
1,7%
Finished
132 72,9%
Rejected
25 13,8%
Summ e:
181 100,0%

Finished

Abbildung 85:

Status aller RfCs (Demo-Daten)

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

311

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.

312

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-

313

8 Praxisbeispiel: Autobahn Tank & Rast GmbH


lichkeit im Focus der mittel- und langfristigen Ziele. Um dies zu gewhrleisten wurde ein IT-Kennzahlensystem entwickelt, das 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, das explizit auf die Anforderungen
des Unternehmens abgestimmt ist. Dieses Konzept wurde im weiteren
Verlauf des Projekts gemeinsam mit der Victor GmbH erfolgreich umgesetzt und implementiert.
Die Umsetzung des Projekts erfolgte in folgenden Schritten:
Im ersten Step wurden Interviews mit IT-Mitarbeitern aus 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.

314

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.

315

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-

317

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.

318

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 in der folgenden Abbildung 86 dargestellt.
Servicebereich
IT

Projekte und
Entwicklung
ITE

Operation
& Service
ITO

ITEA - AS Aviation
ITEG - AS GroundHandling

ITOS - Systems
Management

Schichtleiter 1

ITOP - Plattforms

Schichtleiter 3

ITET - AS Technik

ITOC - Communications

ITEP - AS Personal

ITOR - Rollout
Management

ITES - SAP-CCC und


AS Rechnungsw.

Field
Service
ITF

Interne
Services
ITS

Controlling
& Sales
ITK

Schichtleiter 2

ITOI - Internal Services

ITEV - AS Vertrieb
ITED - CC-Anwendungsentwicklung
ITEC - CC Basistools

Abbildung 86:

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

319

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

320

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

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

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

321

9 Praxisbeispiel: Flughafen Mnchen

Abbildung 88:

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 SiloSpezialisten zu Integrations-Spezialisten entwickeln. Das Wissen in der
Breite und die guten Kenntnisse der Standards werden wichtiger als das
extrem tiefe Spezialisten-Know-how fr individuelle Systeme.

322

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

323

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

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

324

9 Praxisbeispiel: Flughafen Mnchen

Abbildung 90:

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

325

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

326

9 Praxisbeispiel: Flughafen Mnchen

Abbildung 91:

Das ITSM-Portal des Servicebereichs IT

Trainings
Um die Mitarbeiter in die Lage zu versetzen, die ITIL Prozessanforderungen auf den Servicebereich IT zu adaptieren, galt es in einer ersten Trainingsphase den Process Ownern und deren Mitarbeiter die notwendigen
ITIL Best Practices zu vermitteln.
Prozesse knnen nur dann erfolgreich implementiert werden, wenn die
beteiligten Mitarbeiter die Notwendigkeit dieser Prozesse, deren Aktivit-

327

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 Process Ownern
ITSM-Praxistrainings mit Fallbeispielen und Toolnutzung fr die
Prozesse Incident-, Problem- und Change-Management , durchgefhrt von den Process 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

328

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, d.h. entsprechende Messindikatoren
sind zu implementieren.
In der Euphorie der Prozessdefinition werden gerne Kennzahlen definiert,
die beiden Kriterien nicht gerecht werden. In der Praxis hat sich im Servicebereich IT gezeigt, dass die Anzahl der 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 Process Owner Problem-Management und seinen Linienverantwortlichen von groem Interesse, jedoch
weniger fr die Geschftsfhrung des Unternehmens.
Die folgende Tabelle (Abbildung 92) zeigt einen Auszug der ersten Ebene
der Prozess-Kennzahlen:

329

9 Praxisbeispiel: Flughafen Mnchen

Abbildung 92:

Auszug der ersten Ebene der Kennzahlen des SB IT

Im Rahmen der jhrlichen IT-Strategie werden konkrete Prozessziele und


die Sollwerte fr die einzelnen Kennzahlen mit dem Process Owner festgeschrieben.

Der Prozess Improvement-Plan


Im Laufe der Vorbereitung auf die Zertifizierung wird sehr schnell klar,
dass es viele Prozessdetails gibt, die eine gewisse Reifezeit brauchen, bis
sie in der Organisation wirklich umgesetzt sind und Wirkung zeigen. Zum
Zeitpunkt der Zertifizierung wird in den meisten Unternehmen noch nicht
alles absolut perfekt laufen.
Diese Erfahrung hat auch der Servicebereich IT des Flughafens Mnchen
gemacht. Um dennoch zertifizierungsfhig zu sein, ist zum Zeitpunkt der
Zertifizierung eine klare Aussage zur Weiterentwicklung der Prozesse und

330

9 Praxisbeispiel: Flughafen Mnchen


die Definition von angestrebten Zielzustnden erforderlich; der so genannte Prozess Improvement-Plan (Schema siehe Abbildung 93).
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 93:

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.

331

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

332

10 Praxisbeispiel: VOSS Gruppe


IT Management Report
der VOSS Gruppe

Gottfried Weibler
Leiter Informationstechnologie
VOSS Automotive GmbH
www.voss.de

Firmenportrait
VOSS ist eine 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

333

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

334

10 Praxisbeispiel: VOSS Gruppe


Die Struktur unseres IT Management Reports haben wir in Form einer
Balanced Scorecard entwickelt, allerdings haben wir diese auf unsere firmenspezifischen 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.

335

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

337

11 Anhang
[COBIT, 2004a]
IT Governance Institute
COBIT Mapping - Overview of International IT Guidance
www.isaca.org, Rolling Meadows, IL 60008 USA,
2004, ISBN 1-893209-57-1
[COBIT, 2004b]
IT Governance Institute
COBIT Mapping - Mapping of ISO/IEC 17799:2000
With COBIT
www.isaca.org, Rolling Meadows, IL 60008 USA,
2004, ISBN 1-893209-62-8
[COBIT, 2005]
IT Governance Institute
COBIT 4.0 - Control Objectives, Management Guidelines,
Maturity Models
www.isaca.org, Rolling Meadows, IL 60008 USA, 2005,
ISBN 1-933284-37-4
[COBIT, 2006]
IT Governance Institute
IT Control Objectives for Sarbanes-Oxley, 2nd Edition The Role of IT in the Design and Implementation of
Internal Control Over Financial Reporting
www.isaca.org, Rolling Meadows, IL 60008 USA,
2006, ISBN 1-933284-76-5
[COBIT, 2007]
IT Governance Institute
Mapping of ITIL With COBIT 4.0
www.isaca.org, Rolling Meadows, IL 60008 USA,
2007, ISBN 1-933284-77-3

338

11.1 Quellenverzeichnis
[Gartner, 2006]
Gartner Research
ISO/IEC 20000 Has an Important Role in Sourcing
Management
Gartner Research, 2006, ID Number: G00136652
[Harvard, 2004]
Harvard Business Manager
Balanced Scorecard Unternehmen erfolgreich steuern
Manager Magazin Verlagsgesellschaft, Hamburg,
Auflage 1, 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

339

11 Anhang
[itSMF, 2001]
itSMF The IT Service Management Forum
IT Service Management Ein Begleitband zur IT
INFRASTRUCTURE LIBRARY, Version 2.1.b
itSMF Ltd., Winnersh, 2001, ISBN 0-9524706-2-4
[itSMF, 2007]
ITIL V3 Glossary
Arbeitskreis Publikation ITIL Version 3 Translation Project
itSMF Deutschland e.V., (Englische Basisversion: 3.1.24),
Version: 31.08.2007
[Kaplan et al., 1996]
Kaplan, Robert S.; Norton, David P.
The Balanced Scorecard. Translating Strategy Into Action
Mcgraw-Hill Professional, 1996, ISBN 0875846513
[Kaplan et al., 1997]
Kaplan, Robert S.; Norton, David P.
Balanced Scorecard Strategien erfolgreich umsetzen
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

340

11.1 Quellenverzeichnis
Download-Bereich
http://www.kess-dv.de/Wir-Ueber-Uns/Beschreibungenund-Downloads/beschreibungen-und-downloads.html,
10.03.2007
[KESS, 2007a]
KESS DV-Beratung GmbH
Beschreibung zum ITIL Service Manager Seminar
http://www.kess-dv.de/Seminare/Service-Manager/service-manager.html,
17.03.2007
[KESS, 2007b]
KESS DV-Beratung GmbH
IT Service Management Simulationen
http://www.kess-dv.de/Seminare/seminare.html,
16.06.2007
[KESS, 2007c]
KESS DV-Beratung GmbH
Workshop Unterlage ITIL V3 - was ist neu
http://www.kess-dv.de/Seminare/seminare.html,
16.06.2007
[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

341

11 Anhang
[Lewin, 1958]
Lewin, Kurt
Group decision and social change
In: Maccoby, Newcomb, Hartley (Hrsg.): Readings in
social Psychology, 3. Auflage, New York, 1958, S. 197-211.
[OGC, 2005a]
OGC
Best Practice 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

342

11.1 Quellenverzeichnis
[OGC, 2007b]
OGC
Service Design
The Stationery Office Books, London, 2007,
ISBN 9780113310470
[OGC, 2007c]
OGC
Service Transition
The Stationery Office Books, London, 2007,
ISBN 9780113310487
[OGC, 2007d]
OGC
Service Operation
The Stationery Office Books, London, 2007,
ISBN 9780113310463
[OGC, 2007e]
OGC
Continual Service Improvement
The Stationery Office Books, London, 2007,
ISBN 9780113310494
[OGC, 2007f]
OGC
The Official Introduction to Service Lifecycle
The Stationery Office Books, London, 2007,
ISBN 9780113310617
[Preiner, 2006]
Preiner, Andreas
Balanced Scorecard anwenden
Kennzahlengesttzte Unternehmenssteuerung
Hanser Wirtschaft, 2. Auflage, 2006, ISBN: 3446407383

343

11 Anhang
[van Bon, 2006]
van Bon, Jan
ISO/IEC 20000 - Das Taschenbuch
Van Haren Publishing, Zerwole (Niederlande), 2006,
ISBN 90 77212 87 6
[Victor et al., 2005]
Victor, Frank; 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

344

11.2 Abkrzungsverzeichnis

11.2 Abkrzungsverzeichnis
ACD

Automatic Call Distribution

BCM

Business Continuity Management

BIA

Business Impact Analysis

BS

British Standard

BSC

Balanced Scorecard

CAB

Change Advisory Board

CAPI

Computer Assisted Personal Interview

CCTA

Central Computer and Telecommunications Agency

CI

Configuration Item

CMDB

Configuration Management Database

CMS

Configuration Management System

COBIT

Control Objectives for Information and related Technology

CSF

Critical Success Factor

CSI

Continual Service Improvement

CSI

Customer Satisfaction Index

DHS

Definitive Hardware Store

DML

Definitive Media Library

DSL

Definitive Software Library

ISACA

Information Systems Audit and Control Association

ISACF

Information Systems Audit and Control Foundation

ISO

International Standardization Organization

ITGI

IT Governance Institute

ITIL

IT Infrastructure Library (Version 2),


in Version 3 Synonym fr Service Management

ITSC

IT Service Continuity

ITSCM

IT Service Continuity Management

ITSM

IT Service Management

itSMF

IT Service Management Forum

ISO

International Organization for Standardization

345

11 Anhang
KGI

Key Goal Indicator

KPI

Key Performance Indicator

KSF

Key Success Factor

KVP

Kontinuierlicher Verbesserungsprozess

OGC

Office of Government Commerce

OLA

Operational Level Agreement

PDCA

Plan, Do, Check, Act

PIP

Prozess Improvement-Plan

PMP

Prozess-Management-Plan

RfC

Request for Change

ROI

Return of Investment

SCM

Service Catalogue Management

SIP

Service Improvement-Program

SIP

Service Improvement-Plan

SKMS

Service Knowledge Management System

SLA

Service Level Agreement

SLM

Service Level Management

SLR

Service Level Requirements

SMP

Service Management-Plan

SPOC

Single Point of Contact

UC

Underpinning Contract

346

11.3 Abbildungsverzeichnis

11.3 Abbildungsverzeichnis
Abbildung 1:

ITIL Rahmenstruktur...............................................................8

Abbildung 2:

Die 10 ITIL-Prozesse und der Service Desk..........................9

Abbildung 3:

Generisches ITIL-Prozessmodell..........................................10

Abbildung 4:

Die Ausrichtung der IT Services auf das Business ............14

Abbildung 5:

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

Abbildung 6:

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

Abbildung 7:

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

Abbildung 8:

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

Abbildung 9:

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

Abbildung 10: Verbindung zwischen IT Service und BusinessService......................................................................................25


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

347

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

348

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

349

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

350

11.4 Glossar

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

Der Prozess, der fr die Zulassung der Nutzung von


IT Services, Daten und anderen Assets durch Anwender verantwortlich ist. Das Access Management
bietet Untersttzung beim Schutz der Vertraulichkeit, Integritt und Verfgbarkeit von Assets,
indem sichergestellt wird, dass nur berechtigte Anwender auf die jeweiligen Assets zugreifen oder
nderungen an diesen vornehmen knnen. Das
Access Management kann auch als BerechtigungsManagement oder Identitts-Management (Identity
Management) bezeichnet werden.

Asset

Bezeichnung fr jede Ressource oder Fhigkeit. Die


Assets eines Service Providers umfassen alle Elemente, die zur Erbringung eines Service beitragen
knnen. Assets knnen folgende Typen einschlieen: Management, Organisation, Prozess, Wissen,
Mitarbeiter, Informationen, Anwendungen, Infrastruktur und finanzielles Kapital.

Asset
Management

Das Asset Management ist der Prozess, der fr die


Verfolgung der Werte und Besitzverhltnisse in
Bezug auf finanzielle Assets sowie deren Erfassung
in Berichten whrend ihres gesamten Lebenszyklus
verantwortlich ist. Das Asset Management ist Teil
des umfassenden Prozesses Service Asset and Configuration Management.

Availability
Management

Der Prozess, der fr die Definition, Analyse, Planung, Messung und Verbesserung smtlicher Aspekte in Bezug auf die Verfgbarkeit von IT Services verantwortlich ist. Im Availability Management
muss sichergestellt werden, dass die gesamte ITInfrastruktur, sowie smtliche Prozesse, Hilfsmittel,
Rollen etc. fr die vereinbarten Service Level-Ziele
eine entsprechende Verfgbarkeit ermglichen.

351

11 Anhang
Balanced
Scorecard

Ein Management-Hilfsmittel, das von Dr. Robert


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

Benchmark

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

Best Practice

Aktivitten oder Prozesse, deren Einsatz in mehreren Organisationen nachweislich zum gewnschten
Erfolg gefhrt hat. ITIL ist ein Beispiel fr Best Practice.

Business Case

Rechtfertigung fr einen umfassenden Ausgabenposten. Beinhaltet Informationen zu Kosten, Nutzen, Optionen, offenen Punkten, Risiken und mglichen Problemen.

Business
Continuity
Management

Der Business-Prozess, der fr den Umgang mit Risiken verantwortlich ist, die zu schwerwiegenden
Auswirkungen auf das Business fhren knnen. Das
BCM sichert die Interessen der wichtigsten Stakeholder, das Ansehen, die Marke und die wertschpfenden Aktivitten des Business. Fr den Fall einer
Unterbrechung der Geschftsablufe werden im
BCM-Prozess die Risiken auf ein akzeptables Ma
reduziert und eine Planung der Wiederherstellung
von Business-Prozessen vorgenommen. Das BCM
legt die Ziele, den Umfang und die Anforderungen

352

11.4 Glossar
fr das IT Service Continuity Management fest.
Business Impact
Analyse

Die BIA ist die Aktivitt im Business Continuity


Management, die die Vital Business Functions und
deren Abhngigkeiten identifiziert. Diese Abhngigkeiten knnen zwischen Suppliern, Mitarbeitern,
anderen Business-Prozessen, IT Services etc. bestehen. Die BIA definiert die Wiederherstellungsanforderungen fr IT Services. Zu diesen Anforderungen
gehren die maximale Wiederherstellungszeit nach
einem Ausfall, der tolerierte Datenverlust aufgrund
von Ausfllen und die mindestens erforderlichen
Service Level-Ziele fr die jeweiligen IT Services.

Business Service
Management

Im Kontext von ITSM die verantwortliche Aktivitt,


um zuknftige Business-Anforderungen fr die
Verwendung im Capacity-Plan nachzuvollziehen.

Capacity
Management

Der Prozess, bei dem sichergestellt wird, dass die


Kapazitt der IT Services und die IT-Infrastruktur
ausreicht, um die vereinbarten Service Level-Ziele
wirtschaftlich und zeitnah erreichen zu knnen.
Beim Capacity Management werden alle Ressourcen, die fr die Erbringung von IT Services erforderlich sind, sowie Plne fr kurz-, mittel- und langfristige Business-Anforderungen bercksichtigt.

Change Advisory
Board

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

Change
Management

Der Prozess, der fr die Steuerung des Lebenszyklus aller Changes verantwortlich ist. Wichtigstes
Ziel des Change Management ist es, die Durchfhrung von lohnenden Changes bei einer minimalen
Unterbrechung der IT Services zu ermglichen.

CMDB

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

353

11 Anhang
COBIT

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

Component
Capacity
Management

Verantwortlich fr die Aspekte der Kapazitt, Auslastung und Performance von Configuration Items
Hier werden Daten im Capacity-Plan gesammelt,
erfasst und analysiert.

Configuration
Item

Alle Komponenten, die verwaltet werden mssen,


um einen IT Service bereitstellen zu knnen. Informationen zu den einzelnen CIs werden in einem
Configuration Record innerhalb des Configuration
Management Systems erfasst und ber den gesamten Lebenszyklus hinweg vom Configuration Management verwaltet. CIs unterstehen der Steuerung
und Kontrolle des Change Management. CIs umfassen vor allem IT Services, Hardware, Software, Gebude, Personen und formale Dokumentationen,
beispielsweise zum Prozess und SLAs.

Configuration
Management
System

Ein Satz an Hilfsmitteln und Datenbanken, der fr


die Verwaltung der Configuration-Daten eines IT
Service Providers verwendet wird. Das CMS enthlt
darber hinaus Informationen zu Incidents, Problemen, Known Errors, Changes und Releases und
kann auch Daten zu Mitarbeitern, Suppliern, Standorten, Geschftsbereichen, Kunden und Anwendern
beinhalten. Das CMS umfasst Hilfsmittel zum
Sammeln, Speichern, Verwalten, Aktualisieren und
Prsentieren von Daten zu allen Configuration Items und deren Beziehungen. Das CMS untersteht
der Zustndigkeit des Configuration Management
und wird von allen IT Service ManagementProzessen eingesetzt.

Critical Success
Factor

Ein Bestandteil, das fr einen erfolgreichen Prozess,


(ein erfolgreiches) Projekt, Plan oder IT Service erforderlich ist. Um das Erreichen eines CSF zu messen, werden KPIs eingesetzt. Ein CSF in Bezug auf
den Schutz von IT Services bei der Durchfhrung
von Changes knnte von KPIs wie Verringerung
des Anteils nicht erfolgreicher Changes und Ver-

354

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

Eine Phase im Lebenszyklus eines IT Service und


Titel einer der ITIL-Kernpublikationen. Das Continual Service Improvement ist verantwortlich fr die
Verwaltung von Verbesserungen in IT Service Management-Prozessen und IT Services. Dabei werden
die Performance des IT Service Providers kontinuierlich gemessen und Verbesserungen an Prozessen,
IT Services und der IT-Infrastruktur vorgenommen,
um die Effizienz, Effektivitt und Wirtschaftlichkeit
zu steigern.

Definitive Media
Library

Ein oder mehrere Standorte, an denen die endgltigen und genehmigten Versionen aller Software Configuration Items sicher gespeichert sind. Die DML
kann darber hinaus zugehrige CIs wie Lizenzen
und Dokumentationen beinhalten. Die DML ist als
einzelner logischer Speicherbereich definiert, auch
wenn sie auf verschiedene Speicherorte aufgeteilt
ist. Die gesamte Software in der DML untersteht der
Steuerung des Change und Release Management
und wird im Configuration Management System
erfasst. Fr ein Release ist ausschlielich der Einsatz
von Software aus der DML akzeptabel.

Demand
Management

Aktivitten, die sich mit dem Bedarf des Kunden an


Services befassen und auf diesen Bedarf sowie auf
die Bereitstellung der Kapazitt Einfluss nehmen,
um diesem Bedarf gerecht zu werden. Auf strategischer Ebene kann das Demand Management die
Analyse von Business-Aktivittsmustern und Anwenderprofilen einbeziehen. Auf taktischer Ebene
kann es eine differenzierte Leistungsverrechnung
einsetzen, um die Nutzung von IT Services bei den
Kunden zu Zeiten mit einer geringeren Auslastung
zu frdern.

Deployment

Die Aktivitt, die fr den bergang neuer oder genderter Hardware, Software, Dokumentation, Prozesse etc. in die Live-Umgebung verantwortlich ist.
Das Deployment ist Teil des Release and Deployment Management-Prozesses.

355

11 Anhang
Effektivitt

Ein Ma dafr, ob die Ziele eines Prozesses, eines


Service oder einer Aktivitt erreicht wurden. Bei
einem effektiven Prozess oder einer effektiven Aktivitt werden die zugehrigen vereinbarten Ziele
erreicht.

Effizienz

Ein Ma dafr, ob die richtige Menge an Ressourcen


eingesetzt wurde, um einen Prozess, einen Service
oder eine Aktivitt bereitzustellen. Ein effizienter
Prozess erreicht seine Ziele innerhalb der krzest
mglichen Zeit bei einem minimalen Einsatz von
Geldmitteln, Mitarbeitern oder anderen Ressourcen.

Emergency
Change

Ein Change, der so bald wie mglich eingefhrt


werden muss, beispielsweise um einen Major Incident zu lsen oder ein Sicherheits-Patch zu installieren. Der Change Management-Prozess bietet in der
Regel ein bestimmtes Verfahren fr die Behandlung
von Notfall-Changes.

Evaluation

Der Prozess, der fr die Bewertung eines neuen


oder genderten IT Service verantwortlich ist, um
sicherzustellen, dass Risiken verwaltet wurden, und
festlegen zu knnen, ob mit dem Change fortgefahren werden soll. Eine Evaluierung bezeichnet darber hinaus den Vergleich eines Ist-Ergebnisses mit
dem beabsichtigten Ergebnis oder den Vergleich
unterschiedlicher Alternativen.

Event

Eine Statusnderung, die fr die Verwaltung eines


Configuration Item oder IT Service von Bedeutung
ist. Der Begriff Event bezeichnet darber hinaus
einen Alarm oder eine Benachrichtigung durch einen IT Service, ein Configuration Item oder ein Monitoring Tool. Bei Events mssen in der Regel die
Mitarbeiter des IT-Betriebs aktiv werden, und hufig fhren Events zur Erfassung von Incidents.

Event
Management

Der Prozess, der fr die Verwaltung von Events


whrend ihres Lebenszyklus verantwortlich ist. Das
Event Management ist eine der wichtigsten Aktivitten des IT-Betriebs.

Financial
Management

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

356

11.4 Glossar
Governance

Sicherstellen, dass Richtlinien und Strategien auch


tatschlich implementiert werden und erforderliche
Prozesse korrekt eingehalten werden. Die Governance umfasst die Definition von Rollen und Verantwortlichkeiten, Manahmen und Berichte sowie
Aktionen zur Lsung aller identifizierten Anliegen.

Incident

Eine nicht geplante Unterbrechung eines IT Service


oder eine Qualittsminderung eines IT Service.
Auch ein Ausfall eines Configuration Item ohne bisherige Auswirkungen auf einen Service ist ein Incident. Beispiel: Ein Ausfall einer oder mehrerer Festplatten in einer gespiegelten Partition.

Incident
Management

Der Prozess, der fr die Verwaltung des Lebenszyklus aller Incidents verantwortlich ist. Wichtigstes
Ziel des Incident Management ist eine schnellstmgliche Wiederherstellung des IT Service fr die Anwender.

Information
Security
Management

Der Prozess, bei dem die Vertraulichkeit, Integritt


und Verfgbarkeit der Assets, Informationen, Daten
und IT Services einer Organisation sichergestellt
werden. Das Information Security Management ist
in der Regel Teil eines organisatorischen Ansatzes
fr das Security Management, der ber den Aufgabenbereich des IT Service Providers hinausgeht, und
bercksichtigt die Verwaltung papierbasierter Dokumente, Zutrittsrechte, Telefonanrufe etc. fr die
gesamte Organisation.

Integritt

Ein Sicherheitsprinzip, das sicherstellt, dass Daten


und Configuration Items nur durch autorisierte
Mitarbeiter und Aktivitten modifiziert werden. Die
Integritt bercksichtigt alle mglichen Ursachen
einer Modifikation, wie Ausflle von Software oder
Hardware, Umgebungs-Events und Eingriffe durch
Personen.

ISO

Die International Organization for Standardization


(ISO) ist der weltweit grte Entwickler von Standards. Die ISO ist eine regierungsunabhngige Organisation, die aus einem Netzwerk nationaler
Standardisierungsinstitute aus 156 Lndern besteht.
Weitere Informationen zu ISO finden Sie unter
http://www.iso.org/.

357

11 Anhang
ITIL

Ein Satz an Best Practice-Leitlinien fr das IT Service


Management. Inhaber von ITIL ist das OGC. ITIL
umfasst eine Reihe von Publikationen, die Leitlinien
zur Bereitstellung von qualittsbasierten IT Services
sowie zu den Prozessen und Einrichtungen bieten,
die zur Untersttzung dieser Services erforderlich
sind.

IT Service

Ein Service, der fr einen oder mehrere Kunden von


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

IT Service
Continuity
Management

Der Prozess, der fr die Verwaltung von Risiken


verantwortlich ist, die zu schwerwiegenden Auswirkungen auf IT Services fhren knnen. Das ITSCM
stellt sicher, dass der IT Service Provider stets ein
Mindestma an vereinbarten Service Level bereitstellen kann, indem die Risiken auf ein akzeptables
Ma reduziert werden und eine Wiederherstellungsplanung fr IT Services erfolgt. Das
ITSCM sollte so konzipiert sein, dass es das Business
Continuity Management untersttzt.

IT Service
Management

Die Implementierung und Verwaltung von qualittsbasierten IT Services, die den Anforderungen
des Business gerecht werden. Das IT Service Management wird von IT Service Providern mithilfe einer
geeigneten Kombination aus Personen, Prozessen
und Informationstechnologie durchgefhrt. Siehe
Service Management.

IT Service
Provider

Ein Service Provider, der IT Services fr interne


Kunden oder externe Kunden bereitstellt.

itSMF

Beim IT Service Management Forum handelt es sich


um eine unabhngige Organisation, die sich der
Frderung und Verbreitung eines professionellen
Ansatzes fr das IT Service Management widmet.
Das itSMF ist eine nicht gewinnorientierte Mitgliederorganisation mit Vertretern aus zahlreichen
Lndern weltweit (itSMF Verbnde). Das itSMF und

358

11.4 Glossar
seine Mitglieder untersttzen die Entwicklung von
ITIL sowie der zugehrigen IT Service Management
Standards. Weitere Informationen dazu finden Sie
unter http://www.itsmf.de/.
Key Performance
Indicator

Eine Messgre, die einen Prozess, einen IT Service


oder eine Aktivitt untersttzen soll. Es knnen
Messungen anhand von zahlreichen Messgren
erfolgen, es werden jedoch nur die wichtigsten dieser Gren als KPIs definiert und fr eine aktive
Verwaltung und Berichtserstellung in Bezug auf den
Prozess, den IT Service oder die Aktivitt eingesetzt.
Bei der Auswahl der KPIs sollte die Sicherstellung
von Effizienz, Effektivitt und Wirtschaftlichkeit
bercksichtigt werden.

Knowledge
Management

Der Prozess, der fr die Sammlung, die Analyse,


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

Known Error

Ein Problem, fr das die zugrunde liegende Ursache


und ein Workaround dokumentiert wurden. Das
Problem Management ist verantwortlich fr die
Erstellung und Verwaltung von bekannten Fehlern
whrend ihres gesamten Lebenszyklus. Bekannte
Fehler knnen auch von der Entwicklung oder den
Suppliern identifiziert werden.

Lifecycle

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

359

11 Anhang
Monitoring

Wiederholte Beobachtung eines Configuration Item,


IT Service oder Prozesses, um Events zu ermitteln,
und sicherzustellen, dass der aktuelle Status bekannt ist.

OGC

Das OGC ist Inhaber der Marke ITIL (Copyright


und Handelsmarke). Beim OGC handelt es sich um
eine Behrde der britischen Regierung, die die Bereitstellung der Beschaffungsplanung fr die britische Regierung untersttzt, indem ein gemeinschaftlicher Ansatz fr Beschaffungsmglichkeiten
und die Steigerung der Fhigkeiten fr die Beschaffung von Behrden und Abteilungen gefrdert
wird. Es bietet darber hinaus Untersttzung fr
komplexe Projekte aus dem ffentlichen Bereich.

Operational Level
Agreement

Eine Vereinbarung zwischen einem IT Service Provider und einem anderen Teil derselben Organisation. Ein OLA untersttzt die Bereitstellung von IT
Services durch den IT Service Provider fr den Kunden. Das OLA definiert zu liefernde Waren oder
Services und die Verantwortlichkeiten der beiden
Parteien. Ein OLA knnte beispielsweise bestehen
zwischen: dem IT Service Provider und einer Einkaufsabteilung, um Hardware innerhalb vereinbarter Zeitspannen zu erhalten, oder dem Service Desk
und einer Support-Gruppe, um eine Incident-Lsung innerhalb der vereinbarten Zeit zu erreichen.

Outsourcing

Einsatz eines externen Service Providers fr die


Verwaltung von IT Services.

PDCA

Ein Zyklus in vier Phasen fr das Prozessmanagement, der auf Edward Deming zurckgefhrt wird.
Plan-Do-Check-Act wird auch als Qualittszyklus
nach Deming bezeichnet.
PLAN (Planen): Design oder berarbeitung von
Prozessen, die die IT Services untersttzen.
DO (Durchfhren): Implementierung des Plans und
Verwaltung der Prozesse.
CHECK (berprfen): Messung der Prozesse und IT
Services, Vergleich mit den Zielen und Erstellung
von Berichten.
ACT (Handeln): Planung und Implementierung von
Changes, um die Prozesse zu verbessern.

360

11.4 Glossar
Problem

Die Ursache fr einen oder mehrere Incidents. Zum


Zeitpunkt der Erstellung eines Problem Record ist
die Ursache in der Regel unbekannt. Fr die weitere
Untersuchung ist der Problem Management-Prozess
verantwortlich.

Problem
Management

Der Prozess, der fr die Verwaltung des Lebenszyklus aller Probleme verantwortlich ist. Wichtigstes
Ziel des Problem Management ist es, Incidents zu
verhindern bzw. die Auswirkungen von Incidents
zu minimieren, die nicht verhindert werden knnen.

Process Owner

Eine Rolle, verantwortlich fr die Sicherstellung der


Zweckmigkeit eines Prozesses. Zu den Verantwortlichkeiten des Process Owners gehren das
Sponsorship, das Design, das Change Management
sowie die kontinuierliche Verbesserung des Prozesses und seiner Messgren. Diese Rolle wird hufig
derselben Person zugewiesen, der bereits die Rolle
des Prozess-Managers zugewiesen ist. In greren
Organisationen knnen diese Rollen jedoch separat
zugewiesen sein.

Prozess

Ein strukturierter Satz an Aktivitten, mit deren


Hilfe ein bestimmtes Ziel erreicht werden soll. Ein
Prozess wandelt einen oder mehrere definierte Inputs in definierte Outputs um. Ein Prozess kann
beliebige Rollen, Verantwortlichkeiten, Hilfsmittel
und Steuerungen fr das Management enthalten,
die fr eine zuverlssige Bereitstellung der Outputs
erforderlich sind. Ein Prozess kann den Anforderungen entsprechend Richtlinien, Standards, Leitlinien,
Aktivitten und Arbeitsanweisungen definieren.

Prozess-Manager

Eine Rolle, die fr das operative Management eines


Prozesses verantwortlich ist. Zu den Verantwortlichkeiten des Prozess-Managers gehren die Planung und die Koordination aller Aktivitten, die zur
Ausfhrung, dem Monitoring und der Berichtserstellung in Bezug auf einen Prozess erforderlich
sind. Es knnen mehrere Prozess-Manager fr einen
Prozess vorhanden sein, z. B. regionale Change Manager oder IT Service Continuity Manager fr jedes
Rechenzentrum. Die Rolle des Prozess-Managers
wird hufig der Person zugewiesen, der bereits die
Rolle des Process Owners zugewiesen ist. In gre-

361

11 Anhang
ren Organisationen knnen diese Rollen jedoch separat zugewiesen sein.
Prozesssteuerung

Die Aktivitt der Planung und Regulierung eines


Prozesses, mit dem Ziel, den Prozess effektiv, effizient und konsistent auszufhren.

RACI

Ein Modell, auf dessen Grundlage Rollen und Verantwortlichkeiten definiert werden. RACI steht fr
Responsible (zustndig fr die Durchfhrung),
Accountable (letztlich verantwortlich fr die Aktivitt), Consulted (muss/soll beteiligt werden,
liefert Input) und Informed (muss ber den Fortschritt informiert werden).

Reifegrad

Eine bestimmte Ebene im Reife-Modell, wie die


Capability Maturity Model Integration von der Carnegie Mellon University in den USA.

Release

Eine Zusammenstellung von Hardware, Software,


Dokumentation, Prozessen oder anderen Komponenten, die fr die Implementierung eines oder
mehrerer genehmigter Changes an IT Services erforderlich sind. Die Inhalte jedes Releases werden
als eine Einheit verwaltet, getestet und implementiert.

Release and
Deployment
Management

Der Prozess, der sowohl fr das Release Management als auch fr das Deployment verantwortlich
ist.

Release Management

Der Prozess, der fr die Planung, den zeitlichen


Ablauf und die Steuerung des bergangs von Releases in Test- und Live-Umgebungen verantwortlich ist. Das wichtigste Ziel des Release Management
ist es, sicherzustellen, dass die Integritt der LiveUmgebung aufrechterhalten wird und dass die richtigen Komponenten im Release enthalten sind. Das
Release Management ist Teil des Release and
Deployment Management-Prozesses.

Release Unit

Komponenten eines IT Service, die blicherweise im


selben Release verffentlicht werden. Eine Release
Unit umfasst in der Regel gengend Komponenten,
um eine ntzliche Funktion auszufhren. Eine Release Unit knnte z. B. ein Desktop-PC mit Hardware, Software, Lizenzen, Dokumentation usw. sein.
Eine weitere Release Unit knnte die gesamte An-

362

11.4 Glossar
wendung fr die Lohnbuchhaltung sein, einschlielich IT-Betriebsverfahren und Anwendertrainings
Request for
Change

Der formale Antrag zur Durchfhrung eines Change. Ein RfC beinhaltet Details zum beantragten
Change und kann auf Papier oder elektronisch erfasst werden. Der Begriff RfC wird hufig flschlicherweise fr einen Change Record oder den Change selbst verwendet.

Request Fulfilment

Der Prozess, der fr das Management des Lebenszyklus aller Service Requests verantwortlich ist.

Return of
Investment

Eine Messgre fr den erwarteten Nutzen einer


Investition. Einfach ausgedrckt handelt es sich
beim ROI um Nettoerls dividiert durch den Nettowert der investierten Assets.

Risikomanagement

Der Prozess, der fr die Identifizierung, Bewertung


und Steuerung von Risiken verantwortlich ist.

Security
Management

Synonym fr Information Security Management.

Service

Eine Mglichkeit, einen Mehrwert fr Kunden zu


erbringen, indem das Erreichen der von den Kunden angestrebten Ergebnisse erleichtert oder gefrdert wird. Dabei mssen die Kunden selbst keine
Verantwortung fr bestimmte Kosten und Risiken
tragen.

Service Asset

Jedwede Fhigkeit oder Ressource eines Service


Providers. Siehe Asset.

Service Asset &


Configuration
Management

Der Prozess, der sowohl fr das Configuration Management als auch das Asset Management verantwortlich ist.

Service Capacity
Management

Dient der Gewinnung von Erkenntnissen zur Performance und Kapazitt von IT Services. Die Ressourcen, die von jedem IT Service verwendet werden,
werden fr die Nutzung im Capacity-Plan erfasst,
aufgezeichnet und analysiert.

Service Design

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

Service Desk

Der Single Point of Contact fr die Kommunikation

363

11 Anhang
zwischen Service Provider und Anwendern. Ein
Service Desk bearbeitet in der Regel Incidents und
Service Requests und ist fr die Kommunikation mit
den Anwendern zustndig.
Service Improvement-Plan (SIP)

Ein formeller Plan zur Implementierung von Verbesserungen fr einen Prozess oder IT Service.

Service Knowledge
Management
System

Eine Sammlung von Hilfsmitteln und Datenbanken,


die zur Verwaltung von Wissen und Informationen
verwendet werden.
Das SKMS umfasst das Configuration Management
System sowie andere Hilfsmittel und Datenbanken.
Das SKMS speichert, verwaltet, aktualisiert und
prsentiert alle Informationen, die ein IT Service
Provider zur Verwaltung des gesamten Lebenszyklus von IT Services bentigt.

Service Level

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

Service Level
Agreement

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

Service Level
Requirement

Eine Kundenanforderung fr einen Aspekt eines IT


Service. SLRs basieren auf Business-Zielen und werden zur Aushandlung vereinbarter Service LevelZiele eingesetzt.

Service Level
Management

Der Prozess, der fr das Verhandeln von Service


Level Agreements sowie deren Einhaltung verantwortlich ist. Das SLM soll sicherstellen, dass alle IT
Service Management-Prozesse, Operational Level
Agreements und Underpinning Contracts fr die
vereinbarten Service Level-Ziele angemessen sind.
SLM ist fr das Monitoring und die Berichterstattung in Bezug auf Service Level sowie fr die
regelmige Durchfhrung von Kunden-Reviews

364

11.4 Glossar
zustndig.
Service Level-Ziel

Eine Verpflichtung, die in einem Service Level


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

Service
Management

Das Service Management ist die Gesamtheit der


spezialisierten organisatorischen Fhigkeiten, die
zur Generierung eines Mehrwerts fr Kunden in
Form von Services verfgbar sind.

Service Manager

Ein Manager, der fr das Management des gesamten Lebenszyklus von einem oder mehreren IT Services verantwortlich ist. Zudem wird der Begriff
Service Manager fr alle Manager verwendet, die
im Bereich des IT Service Providers beschftigt sind.
Am hufigsten wird der Begriff fr Business Relationship Manager, Prozess-Manager, Account Manager oder leitende Manager verwendet, die allgemein
fr IT Services verantwortlich sind.

Service Operation

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

Service Owner

Eine Rolle, die fr die Bereitstellung eines bestimmten IT Service verantwortlich ist.

Service Portfolio
Management

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

Service Reporting

Der Prozess, mit dem Berichte zu Ergebnissen und


Trends hinsichtlich bestimmter Service Level erstellt
und bereitgestellt werden. Beim Service Reporting
sollte das Format, der Inhalt und die Hufigkeit der
Berichte zuvor mit den jeweiligen Kunden abgesprochen werden.

Service Request

Eine Anfrage eines Anwenders nach Informationen,


Beratung, einem Standard-Change oder nach
Zugriff auf einen IT Service. Dabei knnte es sich

365

11 Anhang
beispielsweise um das Zurcksetzen eines Passworts oder die Bereitstellung standardmiger IT
Services fr einen neuen Anwender handeln. Service Requests werden in der Regel von einem Service Desk bearbeitet und erfordern blicherweise
nicht die Einreichung eines RfC.
Service Strategy

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

Service Transition

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

Service Validation
and Testing

Der Prozess, der fr die Validation und das Testen


eines neuen oder genderten IT Service verantwortlich ist. Service Validation and Testing stellt sicher,
dass der IT Service den jeweiligen Designspezifikationen entspricht und den Bedrfnissen des Business gerecht wird.

Servicekatalog

Eine Datenbank oder ein strukturiertes Dokument


mit Informationen zu allen Live IT Services, einschlielich der Services, die fr das Deployment
verfgbar sind. Der Servicekatalog ist der einzige
Bestandteil des Serviceportfolios, der an die Kunden
ausgehndigt wird. Er untersttzt den Vertrieb und
die Bereitstellung von IT Services. Der Servicekatalog enthlt Angaben zu Lieferergebnissen, Preisen,
Bestellungen und Anfragen sowie Kontaktinformationen.

Serviceportfolio

Die Gesamtheit aller Services, die von einem Service


Provider verwaltet werden. Das Serviceportfolio
wird fr das Management des gesamten Lebenszyklus aller Services genutzt. Es umfasst drei Kategorien: Servicepipeline (beantragt oder in der Entwicklung), Servicekatalog (Live oder bereit zum Deployment) und auer Kraft gesetzte Services. Siehe Service Portfolio Management und Vertragsportfolio.

Single Point of
Contact

Der Single Point of Contact dient als einzige, konsistente Schnittstelle fr die Kommunikation mit einer
Organisation oder einem Geschftsbereich. Der Sin-

366

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

Der Prozess ist verantwortlich dafr sicherzustellen,


dass alle Vertrge mit Suppliern die Anforderungen
des Business untersttzen und alle Supplier ihre
vertraglichen Verpflichtungen erfllen.

Supplier- und
Vertragsdatenbank

(Supplier and Contract Database, SCD). Eine Datenbank oder ein strukturiertes Dokument, das verwendet wird, um Supplier-Vertrge whrend ihres gesamten Lebenszyklus zu verwalten. Die SCD enthlt
die wichtigsten Attribute aller Supplier-Vertrge
und sollte Teil des Service Knowledge Management
Systems sein.

System
Management

Der Bereich des IT Service Management, bei dem


nicht das Management von Prozessen, sondern das
Management der IT-Infrastruktur im Vordergrund
steht.

Transition Planning and Support

Der Prozess, der fr die Planung aller Service Transition-Prozesse und die Koordinierung der hierfr
bentigten Ressourcen verantwortlich ist. Zu diesen
Service Transition-Prozessen zhlen Change Management, Service Asset and Configuration Management, Release and Deployment Management,
Service Validation and Testing, Evaluation und
Knowledge Management.

Underpinning
Contract

Ein Vertrag zwischen einem IT Service Provider und


einer Drittpartei. Die Drittpartei stellt Waren oder
Services zur Verfgung, die die Bereitstellung eines
IT Service fr einen Kunden untersttzen. Der Underpinning Contract definiert Ziele und Verantwortlichkeiten, um die in einem SLA vereinbarten
Service Level-Ziele zu erreichen.

Verfgbarkeit

Fhigkeit eines Configuration Item oder IT Service,


bei Bedarf die dafr vereinbarte Funktion auszufhren. Die Verfgbarkeit wird durch Aspekte in Bezug
auf Zuverlssigkeit, Wartbarkeit, Servicefhigkeit,
Performance und Sicherheit bestimmt. Die Verfgbarkeit wird in der Regel als Prozentwert ausgedrckt, der hufig basierend auf der vereinbarten
Servicezeit und der Ausfallzeit berechnet wird. Gem der Best Practice wird die Verfgbarkeit mithil-

367

11 Anhang
fe von Messgren aus dem Business-Ergebnis des
IT Service berechnet.
Verification and
Audit

Die Aktivitten, mit denen sichergestellt wird, dass


die Informationen in der CMDB przise sind und
dass alle Configuration Items identifiziert und in
der CMDB erfasst wurden. Die Verifizierung beinhaltet routinemige Prfungen im Rahmen von
anderen Prozessen. Zum Beispiel die Verifizierung
der Seriennummer eines Desktop-PCs, wenn ein
Anwender einen Incident meldet. Ein Audit ist eine
periodisch durchgefhrte, formale Prfung.

Vertraulichkeit

Ein Sicherheitsprinzip, das fordert, dass ausschlielich autorisierte Personen auf Daten zugreifen knnen.

Workaround

Die Reduzierung oder Beseitigung der Auswirkungen von Incidents oder Problemen, fr die noch
keine vollstndige Lsung verfgbar sind, z. B.
durch den Neustart eines ausgefallenen Configuration Item. Workarounds fr Probleme werden in
Known Error Records dokumentiert. Workarounds
fr Incidents, die nicht ber zugeordnete Problem
Records verfgen, werden in Incident Records dokumentiert.

368

11.5 Sachwortverzeichnis

11.5 Sachwortverzeichnis
A

Event Management 82, 250

Access Management 87, 262

Asset 59

Financial Management 55, 59,


217

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

G
Governance 12, 104

Balanced Scorecard 3, 5, 135

Improvement Prozess 90

Benchmark 208

Incident 53

Best Practice 1, 3
Business Case 59

Incident Management 6, 52, 84,


151, 252

Business Continuity
Management 56, 68

Information Security
Management 69, 147, 232

Business-Servicekatalog 63

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


128

C
Capacity Management 55, 65,
225

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

Change Management 53, 54, 74,


239

IT Service Continuity
Management 56, 68, 231

COBIT 2, 5, 103

IT Service Management 5, 52

Configuration Management 53,


75

IT Service Provider 13, 42, 124,


125, 133, 134

Continual Service Improvement


15, 42, 90, 265

IT-Controls 212

Controls on Demand 212

ITIL Best Practice 130

Critical Success Factor 110, 159

ITIL Refresh 298

Definitive Media Library 247

Kennzahlen 1, 7, 11, 52, 57, 102,


135, 147, 161, 171, 178, 188, 189,
191, 203, 214, 291

Demand Management 47, 61,


220
E
Evaluation 80, 247

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

Kennzahlensystem 2, 5, 141, 191,


195, 203, 206, 209

369

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

Request Fulfilment 85, 101, 215,


258

Knowledge Management 81, 237,


248

Return on Investment 96, 136,


267

Kontinuierlicher
Verbesserungsprozess 281

Risiko Management 16

Lifecycle 6, 15, 16

Security Management 56, 113,


119

Service 12

Metriken 113

Service Asset 75

Monitoring 119
O

Service Asset and Configuration


Management 75, 215, 237, 243

Operational Level Agreement 56,


124, 222

Service Catalogue Management


63, 221

Outsourcing 273, 306

Service Design 15, 27, 62, 221

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


263

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

Service Improvement-Plan 102,


163, 169, 181, 287

Problem Management 53, 86,


111, 114, 120, 260

Service Level 38

Process Owner 10, 50, 51, 144,


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

Service Level Agreement 13, 61,


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

Release Management 54, 245

Service Portfolio Management


47, 60, 63, 219

Reporting 119

Service Reporting 94, 265

Request for Change 53, 120

370

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

Service Strategy 11, 20, 59, 101,


161, 217

The 7 Step Improvement Process


265

Service Transition 15, 32, 47, 72,


237

Transition Planning and Support


72, 237

Service Validation and Testing


78, 237

Technischer Servicekatalog 63

Servicekatalog 22, 63, 128

Underpinning Contract 56, 124,


222

Serviceportfolio 22, 60, 63, 219

Single Point of Contact 263

Verification and Audit 242

Supplier Management 71, 235

System Management 191

Workaround 129

371