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

Transkript

1

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

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

4 Ralf Buchsein Frank Victor Holger Günther Volker Machmeier IT-Management mit ITIL V3 Strategien, Kennzahlen, Umsetzung Mit 77 Abbildungen

5 Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über < abrufbar. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne von Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen. Höchste inhaltliche und technische Qualität unserer Produkte ist unser Ziel. Bei der Produktion und Auslieferung unserer Bücher wollen wir die Umwelt schonen: Dieses Buch ist auf säurefreiem und chlorfrei gebleichtem Papier gedruckt. Die Einschweißfolie besteht aus Polyäthylen und damit aus organischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffe freisetzen. 1. Auflage 2007 Alle Rechte vorbehalten Friedr.Vieweg & Sohn Verlag GWV Fachverlage GmbH, Wiesbaden 2007 Lektorat: Günter Schulz / Andrea Broßler Der Vieweg Verlag ist ein Unternehmen von Springer Science+Business Media. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Umschlaggestaltung: Ulrike Weigel, Druck und buchbinderische Verarbeitung: MercedesDruck, Berlin Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier. Printed in Germany ISBN

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

7 Vorwort Ein Buch, wie dieses, entsteht nur, wenn ausgezeichnete Leute dazu beitragen. Besonders bedanken möchten wir uns bei Frau Dr. Manuela Claßen, Victor GmbH, Bonn Herrn Jürgen Esterle, München Herrn Flavio Gaj, Mailand Herrn Gerhard Göttert, Autobahn Tank & Rast GmbH, Bonn Herrn Dr. Jan Hadenfeld, Altana Pharma AG Herrn Karl-Heinz Herfs, KESS DV-Beratung GmbH Frau Jacqueline Jordan, London Herrn Sascha Kurth, KESS DV-Beratung GmbH Herrn Hans Joachim Lohr, Rohrbach Herrn Peter Pieronczyk, KESS DV-Beratung GmbH Frau Gabriele Ruf, München Herrn Mirko Seithe, Bonn Herrn Gottfried Weibler, VOSS Automotive GmbH, Wipperfürth Herrn Michael Zaddach, Flughafen München GmbH Für Ann-Kathrin Für Manuela, Christina und Luisa Für meine Eltern, Inge und Heinz Für Anna Elisabeth und Gustav Ralf Buchsein Hagen, im Juni 2007 Frank Victor Bonn, im Juni 2007 Holger Günther Aachen, im Juni 2007 Volker Machmeier Mailand, im Juni 2007 Haben Sie Fragen zum IT Service Management oder zu Kennzahlen? Wir helfen Ihnen gerne persönlich weiter: 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 by the IT Governance Institute (ITGI) VI

8 Inhaltsverzeichnis 1 Einführung und Überblick IT Service Management Management Summary ITIL und ISO Die Struktur gemäß ITIL Version Das Service Management auf Basis der ITIL Version Der prozessorientierte Ansatz von ITIL Version Die Struktur gemäß ITIL Version ITIL und der Service Lifecycle Service Strategy Service Design Service Transition Service Operation Continual Service Improvement Der prozessorientierte Ansatz von ITIL Version ITIL Kennzahlen für IT Service Management-Prozesse Ausgewählte Kennzahlen der ITIL Version Ausgewählte Kennzahlen der ITIL Version ISO Die Geschichte der ISO Der Aufbau der ISO Die Inhalte der ISO Die ISO und Kennzahlen COBIT Entwicklung von COBIT Struktur von COBIT Prozess-Management gemäß COBIT COBIT und die IT Service Management-Prozesse Metriken für IT Service Management-Prozesse COBIT Metriken für IT Service Management-Prozesse...66 VII

9 Inhaltsverzeichnis 2.8 Monitoring und Reporting von SLAs Definition und Interpretation des Begriffs IT Service Service Level Agreements Das Zusammenwirken von SLAs, OLAs und UCs Der Aufbau von SLAs Die Inhalte von SLAs Monitoring und Reporting von SLAs, OLAs und UCs Abgrenzung der Kennzahlen Integrationsinstrument: Balanced Scorecard Kernideen Anwendung auf den IT-Bereich Ausprägungen der Balanced Scorecard Konsequenzen IT Prozess-Management Management Summary PDCA-Zyklus Etablierung des Prozess-Managements Der Charakter von IT-Prozessen Rollen im Prozess-Management Definition der Prozessziele und -Kennzahlen Definition der Prozessziele Definition der Prozess-Kennzahlen Dokumentation der Prozess-Kennzahlen Reporting der Prozess-Kennzahlen Von der Kennzahl zur Verbesserungsmaßnahme Kennzahlen müssen reifen Der Umgang mit Kennzahlen IT Kennzahlensysteme Management Summary Ziele Überblick SVD VIII

10 Inhaltsverzeichnis Diebold Kargl Van der Zee Bewertung Konsequenzen IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Management Summary Klassifikationsschema für IT-Kennzahlen Key Success Factors Key Performance und Customer Satisfaction IT-Controls und Controls on Demand Prozess-Kennzahlen Service Strategy Service Design Service Transition Service Operation Continual Service Improvement Lessons learned: Empfehlungen und Ratschläge Management Summary ITIL-Einführung Analyse der bestehenden Prozesse Prozess-Einführungen Die Organisation gewinnen Rollenbeschreibungen Kontinuierlicher Verbesserungsprozess KVP der bestehenden Prozesse KVP der neuen Prozesse Wettbewerb der Prozesseinführung Reifegradanalyse der Prozesse im laufenden Betrieb Kennzahlen IT-Prozesse am Tagesgeschäft ausrichten ITIL abgestimmt auf die Business- und IT-Strategie IX

11 Inhaltsverzeichnis ITIL Refresh oder wie geht es weiter? Praxisbeispiel: ALTANA Pharma AG Praxisbeispiel: Autobahn Tank & Rast GmbH Praxisbeispiel: Flughafen München Praxisbeispiel: VOSS Gruppe Anhang Quellenverzeichnis Abkürzungsverzeichnis Abbildungsverzeichnis Sachwortverzeichnis X

12 1 Einführung und Überblick 1955 hatte Frank Sinatra einen Welterfolg mit seinem Song Love and Marriage : Love and marriage, love and marriage, Go together like a horse and carriage, This I tell you brother, You can t have one without the other. Ein halbes Jahrhundert später mag sich einiges im gesellschaftlichen Leben geändert haben. Für ein modernes und erfolgreiches IT-Management gehören jedoch (mindestens) zwei Dinge zusammen: ITIL und Kennzahlen: You can t have one without the other. Kennzahlen dienen im Allgemeinen zur Steuerung von Bereichen und Prozessen. Für die IT sind von jeher IT-Controls als auch Prozess-Kennzahlen vorgeschlagen und eingesetzt worden. ITIL als Best Practice Ansatz unterstützt explizit die Steuerung der IT-Prozesse auf der Basis von Kennzahlen. In ITIL V3 werden für jeden Prozess die Key Performance Indicators bzw. Metrics genannt. Verwendet man die Kennzahlen des IT Service Managements, so ergänzt man einerseits die Steuerung der IT um wichtige Stellgrößen, andererseits hat man auch eine viel größere Anzahl von Kennzahlen zu erheben, um diese in Reports darzustellen. Sie werden sich fragen: Und, ist das schlimm? In unseren Projekten haben wir die interessante Beobachtung gemacht, dass fast alle IT-Organisationen über eine beachtliche Anzahl von Kennzahlen verfügen. In einem kleinen mittelständischen Unternehmen haben wir die Kennzahlen bei der Ist-Aufnahme einfach einmal gezählt: In der IT-Organisation mit 12 Personen wurden in der Tat monatlich ca. 500 (!) Kennzahlen gemessen und an den CIO weitergegeben. Dieses Phänomen haben wir in fast allen Unternehmen gesehen und schließen daraus: Es gibt kaum eine Organisationseinheit, die über so viele Kennzahlen verfügt wie die IT. Dies liegt vor allen Dingen daran, dass die IT es gewohnt ist, mit Kennzahlen zu arbeiten hier vor allen Dingen mit technischen Kennzahlen aus dem System- und Netzmanagement. ITIL und Kennzahlen: You can t have one without the other. ITIL V3 enthält Prozess- Kennzahlen. Vielleicht denken Sie, man könne auf die Mehrzahl der Kennzahlen verzichten? Da müssen wir Sie enttäuschen: 95 % der Kennzahlen sind notwendig und sinnvoll. Sie müssen erhoben werden! Aber wie kann man sie in dieser Komplexität managen und beherrschbar machen? 1

13 1 Einführung und Überblick Das A und O ist und dies gilt für alle komplexen Systeme, dass man sich Gedanken über das Design des Systems macht. Möchte man ein IT- Kennzahlensystem entwickeln und einführen, so sollte man im Vorfeld die richtigen Fragen stellen: Welche Ziele verfolgen wir mit dem Kennzahlensystem? Welche Kennzahlensysteme sind für meine IT relevant? Wen adressiert das Kennzahlensystem? Welche Kennzahlen können (nicht) gemessen werden? Welchen Aufwand darf das Kennzahlensystem verursachen? Die Beantwortung dieser oder ähnlicher Fragen führt zu einem top down Ansatz für IT-Kennzahlensysteme, den wir oft in Praxisprojekten eingesetzt haben. Aber dies ist nur die eine Seite der Medaille: Für die reale Einführung eines IT-Kennzahlensystems ist es enorm wichtig, die IT- Organisation dort abzuholen, wo sie steht. Hier bietet sich ein bottom up- Verfahren an, durch das ermittelt wird, welche Kennzahlen bereits in verschiedenen Bereichen erhoben und genutzt werden. In unserem Buch beschreiben wir diesen Ansatz in einem Praxisleitfaden, der beide Aspekte enthält. bottum up Verfahren zur Erhebung von Kennzahlen. top down Verfahren zur Entwicklung von IT- Kennzahlensystemen. IT- Kennzahlensysteme sind Guidelines. Die Frage, ob man mit der Entwicklung eines IT-Kennzahlensystems auf der grünen Wiese beginnt, stellt sich in der Praxis nicht! Es gibt keine kennzahlenlose IT. Wir haben ca. 15 IT-Kennzahlensysteme identifiziert, die veröffentlicht worden sind und in der Praxis eingesetzt werden. Herauszustellen ist, dass COBIT 4 die größte Überdeckung mit IT Service Management-Ansätzen, wie ITIL, liefert. Aus der Tradition der IT-Revision heraus und zum Nachweis von Compliance-Anforderungen seitens der Wirtschaftsprüfer wird COBIT in sehr vielen Unternehmen eingesetzt. In unseren Projekten haben wir uns allerdings nie nur auf COBIT und ITIL beschränkt, sondern immer verschiedene Kennzahlensysteme nebeneinander gelegt. Auffallend dabei ist, dass der Überdeckungsgrad der Kennzahlensysteme eher gering ist: Jedes Kennzahlensystem liefert neue Aspekte! Die Quintessenz: IT Kennzahlensysteme sagen, was man messen könnte, aber nicht, was man messen sollte! Sie sind damit Guidelines nicht mehr und nicht weniger! Im Wesentlichen hängt diese Tatsache davon ab, dass ein Kennzahlensystem sich in der Praxis aus dem Zielsystem der IT ableiten muss und daher strategische und taktische Dimensionen hat. 2

14 Eine IT-Organisation ist gut beraten, ihr eigenes IT-Kennzahlensystem aufzubauen und es nicht nur zur reinen Steuerung der IT einzusetzen, sondern über das Kennzahlensystem Teile der IT-Strategie umzusetzen. 1 In diesem Zusammenhang verstehen wir Kennzahlensysteme etwas überspitzt formuliert als mögliche Instrumente des Ist-Marketings. Dies ist insbesondere dann der Fall, wenn als Adressat das Top Management angesprochen werden soll und es darum geht, über die Lage der IT im Unternehmen bzw. im Konzern und die Unterstützung der Business Prozesse und Anforderungen zu berichten. Im Buch stellen wir die wichtigsten Kennzahlensysteme kurz vor und zeigen auf, wie man zu einem eigenen Kennzahlensystem kommt. Hierbei spielt die Balanced Scorecard eine tragende Rolle. 1 Einführung und Überblick Wir glauben, dass das IT Service Management einen der wichtigsten Meilensteine für die IT darstellt. Wir glauben auch, dass IT Service Management ohne IT-Kennzahlen, und IT-Kennzahlen ohne IT Service Management keinen Sinn machen. Unser Buch ist gedacht als Brücke zwischen diesen beiden Ansätzen. Ein wesentlicher Teil unserer Ausführungen beschäftigt sich daher mit Steuerungsmechanismen, die von ITIL, COBIT und ISO bereitgestellt werden, so wie mit den Kernideen des ITIL-basierten Prozess- Managements. Michael Hammer: The Balanced Scorecard A Landmark Achievement Die in ITIL V3 verfügbaren IT-Kennzahlen werden in entsprechende Zusammenhänge eingeordnet und nach ihrem Einsatz in der Praxis klassifiziert. Unser Buch füllt damit in den ersten 5 Kapiteln eine Toolbox, die IT- Verantwortliche zum Aufbau eines Kennzahlensystems einsetzen können. Insbesondere mit der ITIL Version 3 werden die Best Practices für das IT Service Management in Richtung Business Integration beschrieben. Damit steht das Management häufig vor der Herausforderung, in einer bestehenden Organisation die Prozesse zu verankern und die Mitarbeiter von den notwendigen Veränderungen zu überzeugen. Wir haben die Erfahrung gemacht, dass keine noch so gut ausgestattete Toolbox ein Garant für den Erfolg eines Projekts ist. Unabdingbar ist die Tatsache, dass man die Menschen mitnimmt. In den Projekten, die wir begleitet haben, waren Ängste, Hoffnungen, persönliche Schicksale, Präferenzen, Einstellungen, Interessen, Flexibilität und 1 Kaplan und Norton haben dies als Translating Strategy into Action bezeichnet (vgl. [Kaplan et al., 1996]). 3

15 1 Einführung und Überblick Fähigkeiten einzelner Personen wesentliche Determinanten für Erfolg oder Misserfolg. Die Qualität und Ausprägung der Veränderungs- und Überleitungsprozesse und das damit verbundene Vorgehen sind wichtige kritische Erfolgsfaktoren für IT Service Management und Kennzahlen-Projekte. Change und Veränderungs-Prozesse sind wesentliche Bestandteile des Vorgehensmodells. Unser Buch beschäftigt sich mit diesem sensiblen und interessanten Thema im 6. Kapitel, das wir mit Lessons learned überschrieben haben. Basierend auf unseren Projekterfahrungen stellen wir ein Vorgehensmodell vor, mit dem die notwendigen Veränderungs- und Überleitungsprozesse auch im Hinblick auf einen kontinuierlichen Verbesserungsprozess besser und erfolgreicher gesteuert werden können. Überblick über das Buch ein Leseleitfaden Unser Buch ist umfangreicher geworden als wir anfangs gedacht haben. Im Laufe der Zeit ist es von der geplanten kurzen Darstellung unserer Erfahrungen in den Bereichen IT Service Management und Kennzahlen zu einem kleinen Nachschlagewerk geworden. Wir haben uns daher bemüht, die Kapitel weitgehend unabhängig voneinander zu formulieren. Springen Sie einfach in ein Kapitel, das Sie interessiert: Kapitel 2: IT Service Management und verwandte Themen aus Sicht der Praxis mit ISO 20000, ITIL V3, COBIT 4, SLAs und Balanced Scorecard. Kapitel 3: IT Prozess-Management mit Rollen, Zielen, Kennzahlen und kontinuierlichem Verbesserungsprozess. Kapitel 4: Die wichtigsten IT-Kennzahlensysteme in der Praxis und die Konsequenzen hinsichtlich der Fragestellung: Welche IT- Kennzahlen setzen wir ein? Kapitel 5: Praxisleitfaden zur Entwicklung von IT-Kennzahlensystemen mit Klassifikationsschemata und Prozess-Kennzahlen aus ITIL V3 und unseren Projekterfahrungen. Kapitel 6: Wie geht man am besten in IT Service Management Projekten vor? Empfehlungen aus unseren Projekten für Transition und Change Prozesse. Praxisbeispiele: Kapitel 7: IT Service Management im regulierten Umfeld am Beispiel der ALTANA Pharma AG Kapitel 8: Autobahn Tank & Rast GmbH mit einem Kennzahlensystem, das gemeinsam mit dem Controlling entwickelt wurde. Kapitel 9: IT Service Management beim Flughafen München Kapitel 10: IT Management Report in der VOSS Gruppe. 4

16 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 und die Balanced Scorecard gelten gemäß ihrer konzeptionellen Ansätze heute als Best Practice. Dabei weisen COBIT und ITIL eine große Überstimmung hinsichtlich der IT Service Management- Prozesse auf, während die Balanced Scorecard als Integrationsinstrument prädestiniert ist. In diesem Kapitel gehen wir auf diese Best Practices ein und stellen heraus, wie die einzelnen Ansätze im Hinblick auf die Entwicklung von Kennzahlensystemen zu positionieren sind. Bezüglich der Kennzahlen nehmen wir die Beschränkung vor, dass wir nur die behandeln, die aus unserer Sicht eine hohe Praxisrelevanz haben. Die Fragestellung, welcher Ansatz der geeignete zum Aufbau eines Kennzahlensystems ist, führt im Allgemeinen nicht zum Ziel. Es geht vielmehr darum, herauszufinden, wie die Komponenten der verschiedenen Ansätze in einem Puzzle zusammengefügt werden können, um das bestmögliche Kennzahlensystem für die jeweilige IT-Organisation aufzubauen. Wichtige Voraussetzung ist dabei immer, dass es definierte Ziele für die jeweiligen IT Service Management-Prozesse gibt und dass das Prozessund IT-Management das Kennzahlensystem als Führungsinstrument versteht und aktiv einsetzt. 2.2 ITIL und ISO ITIL und ISO IT Service Management sind zwei international bewährte Practices zur erfolgreichen Etablierung eines IT Service Managements. Die Zielsetzung eines IT Service Managements besteht in der Bereitstellung von IT-Leistungen (IT Services) zur Unterstützung der Geschäftsprozesse. Hierzu sind die notwendigen Leistungen zu planen, bereitzustellen, zu überprüfen und bei Bedarf zu optimieren. 5

17 2 IT Service Management Um die Ziele des IT Service Managements zu erreichen, haben sich in den letzten Jahren IT-Prozesse etabliert, die ein wirksames Management sicherstellen und grundsätzlich in allen IT-Organisationen etabliert werden können. Diese IT Service Management-Prozesse sind in den ITIL Best Practices sowie der ISO dokumentiert. Der Ansatz von ITIL Version 2 bestand in der Bereitstellung von Best Practices zur Gestaltung, Implementierung, Betrieb und Optimierung der notwendigen IT Service Management-Prozesse. Mit der Veröffentlichung der ITIL Version 3 wurden die Ausrichtung und der Inhalt umfangreich erweitert. ITIL deckt nun den Service Lifecycle ausgehend von der Strategie bis zu einer ständigen Verbesserung des Service Managements ab. Hierzu werden nicht nur Prozesse beschrieben, sondern vollständige Modelle für den Service und das Service Management. ITIL beinhaltet ein generisches Prozessmodell und bewährte Vorgehensweisen zur Einführung und zum Management des Service Management und dessen Integration in das Business. Die ISO enthält dagegen die Anforderungen an ein IT Service Management. Daher ergänzen sich ITIL und die ISO ideal. Während die ISO die Mindestanforderungen an ein IT Service Management definiert, liefert ITIL hierzu Best Practices für den Aufbau des organisationsspezifischen IT Service Managements. Die Prozessorientierung von ITIL und der ISO stellt eine weitgehende Unabhängigkeit von Organisationsstrukturen sicher. Das IT Service Management auf der Basis von ITIL und der ISO ist ein prozessorientierter Ansatz. Innerhalb der ITIL Best Practices und der ISO werden die relevanten IT-Prozesse zur Bereitstellung professioneller IT Services beschrieben. Kennzahlen dienen dem Prozess-Management und ermöglichen unter anderem die Überprüfung der Prozesse hinsichtlich ihrer Wirksamkeit. Das Verständnis der Prozessziele ist die wichtigste Grundvoraussetzung für die richtige Interpretation von Kennzahlen. Ohne ausreichende Kenntnisse der Prozessziele und der damit verbundenen Prozessaktivitäten besteht die Gefahr einer Fehlinterpretation von Kennzahlen. Als Beispiel hierfür soll der Prozess des Incident Managements dienen. Das Ziel des Incident Managements besteht in der schnellstmöglichen Wiederherstellung des vereinbarten Service für den Geschäftsablauf. Hierzu wird in der Regel als Kennzahl Anzahl der Störungen oder Dauer bis zur Wiederherstellung des Service gemessen. Steigt die Anzahl von Störungen oder die Dauer bis zur Wiederherstellung des Service an, so wäre es eine Fehlinterpretation, das Incident Management hierfür verantwortlich zu machen. Die Kennzahl Anzahl von Störungen wird zwar in 6

18 2.3 Die Struktur gemäß ITIL Version 2 diesem Prozess gemessen, aber die Identifizierung von Störungsursachen und deren nachhaltige Behebung liegen nicht in der Verantwortung des Incident Management-Prozesses. Daher hat das Incident Management den Anstieg der Störungen nicht zu verantworten. Die Definition und Interpretation von Kennzahlen für IT Service Management- Prozesse setzt voraus, dass die Prozessziele dokumentiert und insbesondere dem Management bekannt sind. ITIL Version 2 und ITIL Version 3 Innerhalb der ITIL Best Practices sind bewährte Umsetzungsmaßnahmen für die Einführung, Etablierung und Optimierung der IT Service Management-Prozesse dokumentiert. ITIL ist ein De-facto-Standard für das IT Service Management, da die meisten IT-Organisationen nach ITIL ausgerichtet sind. Heute muss man 2 Versionen von ITIL unterscheiden: ITIL Version 2 (wurde am 1. Juni 2007 durch die Version 3 abgelöst) ITIL Version 3 Im Folgenden stellen wir die Struktur dieser beiden Versionen vor. Gehen aber schwerpunktmäßig auf Version 3 ein, da ITIL Version 2 den meisten Lesern bekannt sein dürfte und Anfang Juni 2007 durch die Version 3 abgelöst wurde. 2.3 Die Struktur gemäß ITIL Version Das Service Management auf Basis der ITIL Version 2 Die wichtigsten Aspekte der ITIL Best Practices in der Version 2 sind in sieben Publikationen dokumentiert. Dabei beinhalten die Publikationen Service Support, Service Delivery und Security-Management die relevanten IT Service Management-Prozesse. Die Rahmenstruktur in Abbildung 1 aus [OGC, 2005a] beschreibt die ITIL Best Practices auf Basis des Standardwerks Best Practice Einführung in ITIL. An dieser Stelle möchten wir auf ein sehr gutes Buch verweisen. In Optimiertes IT Management mit ITIL [Victor et al., 2005] werden die wesentlichen Aspekte von ITIL 2 und ein Einführungsleitfaden beschrieben. 7

19 2 IT Service Management T h e B u s i n e s s Planning to Implement Service Management Service Management Service Support ICT The Infra- Business structure Perspective Management Service Delivery Security Management Application Management T h e T e c h n o l o g i e Abbildung 1: ITIL Rahmenstruktur Abbildung 2 stellt einen Überblick über die 10 ITIL Prozesse der Version 2 dar Der prozessorientierte Ansatz von ITIL Version 2 Bei den ITIL Best Practices handelt es sich um einen prozessorientierten Ansatz. Für das IT Service Management sind in den ITIL-Publikationen der ITIL V2 Service Support, Service Delivery und Security-Management hierzu insgesamt elf erforderliche IT-Prozesse dokumentiert. Gemäß ITIL ist ein Prozess eine zusammenhängende Folge von Aktivitäten mit dem Ziel, einen gegebenen Input in einen definierten Output zu transformieren. Der Output eines Prozesses muss aus der geschäftlichen Zielsetzung abgeleitet werden und kann Input für einen anderen Prozess darstellen. So nimmt zum Beispiel der Prozess des Capacity Managements in enger Zusammenarbeit mit dem Service Level Management (SLM) die Kundenanforderungen an einen IT Service auf. Insofern ist das SLM der Anfang des ITIL Prozessmodells und steht in enger Verbindung mit dem Kunden. Die Anforderungen bezüglich der Verfügbarkeit sind der Input für das Availability Management zur Planung und Überprüfung der IT-Verfügbarkeit. Jeder IT Service Management-Prozess hat eine charakteristische Ziel- 8

20 2.3 Die Struktur gemäß ITIL Version 2 richtung und trägt im Zusammenwirken mit den anderen IT Service Management-Prozessen dazu bei, dass dem Kunden die notwendigen IT Services zur wirkungsvollen Unterstützung seiner Geschäftsprozesse geliefert werden. Die ITIL Best Practices beinhalten Prozessbeschreibungen mit wechselseitigen Aktivitäten. Service Level Management Continuity Management Service Delivery Financial Management Availability Management Capacity Management Configuration Management Incident Management Service Support Problem Management Release Management Change Management Abbildung 2: Die 10 ITIL-Prozesse und der Service Desk Gemäß der ITIL Best Practices ist die Aufgabe der Prozesssteuerung bzw. des Prozess-Managements der Prozess der Planung und Regelung; mit dem Ziel, einen Prozess in einer effektiven und effizienten Weise durchzuführen. Hierzu sind in einem generischen Prozessmodell die wichtigsten Aufgaben beschrieben (siehe Abbildung 3, aus Best Practice Einführung in ITIL, [OGC, 2005a]). 9

21 2 IT Service Management Prozess- Owner Ziele des Prozesses Qualitätsparameter und KPIs Prozessmanagement Input Aktivitäten und Subprozesse Prozessausführung Output Ressourcen Rollen Prozessbedingungen Abbildung 3: Generisches ITIL-Prozessmodell Der Prozess Owner gibt die Prozessziele vor und kann anhand der KPIs die Erreichung der Ziele feststellen. Auf Basis der vom Prozess Owner vorgegebenen Prozessziele gilt es, die notwendigen Aktivitäten und Subprozesse der jeweiligen IT Service Management-Prozesse zu designen und zu implementieren. Angesichts der Komplexität der Prozessdurchführung in IT-Organisationen muss eine formelle Überprüfung der Zielerreichung sichergestellt werden. Dazu dienen die definierten Qualitätsparameter und Leistungsindikatoren (Key Performance Indicators, KPIs). Zielsetzung von ITIL war die Beschreibung von (weitgehend) organisationsneutralen Best Practices. Daher werden zur Durchführung von Prozessaktivitäten Rollen definiert, die mit den erforderlichen Ressourcen zu unterstützen sind. Die Leistungsindikatoren (KPIs) dienen auch zum Management der eingesetzten Ressourcen. Ohne Qualitätsparameter und Leistungsindikatoren (KPIs) ist ein wirksames Prozess-Management unmöglich. Um ein wirksames Prozess-Management zu erreichen, muss kontinuierlich überprüft werden, ob die definierten Prozessziele wirkungsvoll erreicht werden (Effektivität) und mit welchem Aufwand dieses Ergebnis erzielt wird (Effizienz). 10

22 2.4 Die Struktur gemäß ITIL Version 3 ITIL und insbesondere die ISO fordern, für jeden IT Service Management-Prozess ein wirksames Prozess-Management zu etablieren. Bei der Definition von ITIL Kennzahlen gilt es, IT Service Management-Prozesse zu messen und so die Voraussetzung für deren Management zu schaffen. Die ITIL Best Practices sind als Guidelines für die Implementierung und Etablierung des IT Service Managements in einer IT-Organisation gedacht. Die ITIL Best Practices beschreiben was zu tun ist. Die Festlegung, wie die Maßnahmen konkret umzusetzen sind, ist Aufgabe des Prozessdesigns. Die Umsetzung erfolgt immer organisationsspezifisch, in Abhängigkeit von den Geschäftsanforderungen der Kunden und unter Berücksichtigung sozialer Belange. Demzufolge liefert ITIL generische Empfehlungen für das IT Service Management, aber die Prozesse mit ihren konkreten Zielen und Aktivitäten sind immer auf die spezifischen Belange der IT-Organisation auszurichten. Diese Philosophie hat auch Auswirkungen auf die ITIL Best Practices für Kennzahlen. ITIL Kennzahlen sind lediglich Empfehlungen. Die ITIL Best Practices für Kennzahlen sind Guidelines. Die Definition von ITIL Kennzahlen muss immer auf die organisationsspezifischen Prozesse mit ihren Zielen und Aktivitäten ausgerichtet sein. Die ungeprüfte Übernahme von empfohlenen Kennzahlen ist nicht zielführend. Die Version 2 der ITIL Best Practices wurde über einen Zeitraum von sechs Jahren herausgegeben angefangen von Service Support im Juni 2000 bis zu The Business Perspective Part 2 im November Daher sind in den einzelnen ITIL-Publikationen geringfügige Abweichungen in den ausgewiesenen Leistungsindikatoren (KPIs) festzustellen. 2.4 Die Struktur gemäß ITIL Version 3 Mit der Publikation von ITIL Version 3 richten sich die ITIL Best Practices noch stärker auf die Business-Anforderungen aus. Speziell mit der zentralen Publikation Service Strategy wird ein wichtiger Betrag zum IT Governance geliefert. Die Zielsetzung von ITIL mit der Version 3 besteht in der Business Integration. Mit der neuen Version von ITIL ist nicht mehr die Abkürzung für IT Infrastructure Library verbunden, sondern ITIL ist nun ein Synonym für Service Management. 11

23 2 IT Service Management Hierzu definiert die ITIL Version 3 den Begriff ITIL wie folgt: A set of Best Practice guidance for IT Service Management. ITIL is owned by the OGC and consists of a series of publications giving guidance on the provision of Quality IT Services, and on the Processes and facilities needed to support them. Mit der Herausgabe der ITIL Version 3 hat sich auch der Fokus des Service Managements erweitert. Während in der früheren Version von ITIL das Service Management noch als das zur Erfüllung der Kundenanforderungen erforderliche Management definiert wurde, lautet die Definition jetzt wie folgt (vgl. Service Strategy, [OGC, 2007a]): Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services. Sinngemäß würde dies bedeuten: Service Management ist die Gesamtheit spezialisierter organisatorischer Fähigkeiten, um den Kunden in Form von Services einen Wert zu liefern. Den Service definiert ITIL (Version 3) als: Service: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. Sinngemäß bedeutet damit der Begriff Service: Ein Service ist eine Dienstleistung, die einen Nutzen für den Kunden bringt und die Ergebnisse liefert, die er erwartet. Dabei kann er sich entspannen, denn die durch den Service verursachten Kosten und Risiken liegen im Allgemeinen nicht bei ihm sondern beim Service Provider." Innerhalb der Publikation Service Strategie wird der Bezug eines Service zu den Geschäftsprozessen des Business deutlich herausgestellt. Letztendlich stellen die Services die Geschäftsprozesse des Business sicher bzw. stellen zum Teil den Service aus Sicht des Kunden dar (Abbildung 4, aus Service Strategy, [OGC, 2007a]). Damit verbunden ist auch die Erweiterung der Definition für den IT Service (aus Service Strategy, [OGC, 2007a]): IT Service: A Service provided to one or more Customers by an IT Service Provider. An IT Service is based on the use of Information Technology and supports the Customer's Business Processes. An IT Service is made up from a combination of people, processes and technology and should be defined in a Service Level Agreement." 12

24 2.4 Die Struktur gemäß ITIL Version 3 Services Business Service Business Service Abstraktion und Zusammensetzung Business Prozesse Services Ressourcen und Fähigkeiten Internet Zerlegung Personal Abbildung 4: Die Ausrichtung der Services auf das Business Sinngemäß lässt sich der IT Service wie folgt definieren. IT Services werden von einem IT Service Provider für einen oder mehreren Kunden bereitgestellt. IT Services nutzen die Informationstechnologie und unterstützen die Business Prozesse der Kunden. IT Services definieren sich aus Personen, Prozessen und Technologien. IT Services sind in Service Level Agreements zu definieren. 13

25 2 IT Service Management IT Services bestehen in der Regel aus verschiedenen Systemen und Teilleistungen mit unterschiedlichen Verantwortungen und Zuständigkeiten. Da dies in der Vergangenheit zu Kompetenzproblemen geführt hat, wird in ITIL Version 3 auch die Rolle des Service Owners spezifiziert (vgl. [OGC, 2007e]): Der Service Owner ist verantwortlich für einen spezifischen Service, unabhängig davon, wo innerhalb der Organisation die zugrundeliegenden technologischen Komponenten, Prozesse oder professionellen Fähigkeiten angesiedelt sind. In der ITIL Version 3 sind nicht nur Prozesse für das Service Management beschrieben, sondern der gesamte Service Lifecycle. Angefangen von der Strategie (Service Strategy), über das Design (Service Design), der Überführung in den Betrieb (Service Transition) und der operationelle Betrieb (Service Operation). Diese Phasen und damit verbundenen Aktivitäten unterliegen einem kontinuierlichen Verbesserungsprozess (Continual Service Improvement). Hierzu werden nicht nur Service Management-Prozesse beschrieben, sondern zum Beispiel auch die strategische Ausrichtung der IT, Methoden oder notwendige Aufgaben wie das Risiko Management. ITIL mit der Version 3 ist mehr als eine Sammlung von Prozessen. ITIL Version 3 ist ein ganzheitlicher integrierter Ansatz von Best Practices für das Service Management ITIL und der Service Lifecycle Die ITIL Library besteht aus den folgenden Komponenten: DerITIL Core als Leitfaden für alle Organisationen, die Dienstleistungen anbieten. Die ITIL Complementary Guidance als ergänzender Leitfaden für industrielle Bereiche, Organisationstypen, Betriebsmodelle und technologische Architekturen. Die ITIL Web Support Services mit Zusatzprodukten, Prozessmodellen, Templates und Studien. Der ITIL Core besteht aus fünf Publikationen: Service Strategy (vgl. [OGC, 2007a]) Service Design (vgl. [OGC, 2007b]) Service Transition (vgl. [OGC, 2007c]) Service Operation (vgl. [OGC, 2007d]) Continual Service Improvement (vgl. [OGC, 2007e]) Ergänzt werden diese Publikationen um eine allgemeine Einführung The Official Introduction to Service Lifecycle ([OGC, 2007e]). 14

26 2.4 Die Struktur gemäß ITIL Version 3 Die fünf Core Publikationen bilden die Phasen eines iterativen und mehrdimensionalen Lifecycles für die Services. Lernen und Reifen der Organisationen sollen ermöglicht werden. Ziele sind: Struktur, Stabilität und Stärke auf der Basis dauerhafter Prinzipien, Methoden und Werkzeuge. Dies soll dem Schutz von Investitionen dienen. Was hier angestrebt wird ist ein Kreislauf aus Messen, Lernen und Verbesserung. Abbildung 5 verdeutlicht das Zusammenspiel dieser 5 Phasen. Continual Service Improvement Service Transition Service Design Service Strategy Service Operation Abbildung 5: Die 5 Phasen des Service Lifecycles nach ITIL V Service Strategy Im Zentrum des dargestellten Service Lifecycles steht die Phase Service Strategy (vgl. [OGC, 2007a]). Hier werden die strategischen Entscheidungen getroffen. Es gut um das Design, die Entwicklung und Implementierung des Service Managements nicht nur im organisatorischen sondern vielmehr im strategischen Sinne. Service Management Richtlinien (Policies), Anleitungen und Prozesse über den gesamten ITIL Service Lebenszyklus hinweg werden hier entwickelt und unterstützt. Service Strategy bildet im Kern des Kreislaufs das zentrale 15

27 2 IT Service Management strategische Fundament für die Phasen Service Design, Service Transition, Service Operation und den alles umfassenden permanenten Verbesserungskreislaufs des Continual Service Improvement. Ausgangspunkt der Phase Service Strategy sind die Identifizierung, Auswahl und Priorisierung von Geschäftschancen und Marktplätzen. Betrachtungen und Analysen der Marktentwicklung und die Definition von Zielen und Erwartungen führen zur Formulierung von Serviceleistungen gegenüber Kunden und Marktplätzen. Mit Unterstützung des Finanzmanagements wird ein Service Portfolio definiert und die Entwicklung eines Service Katalogs vorbereitet. Auch Themen wie Organisationsentwicklung sowie Kosten- und Risikobetrachtungen im Hinblick auf das Service Portfolio werden angegangen. Neben dem Faktor operationelle Effizienz geht es entscheidend um ganzheitliche, nachhaltige und effektvolle Entscheidungen und Leistungen und deren Entwicklung. Strategische Reviews helfen, Fähigkeiten zu verbessern tragen zum weiteren Ausbau von Geschäftsstrategien und -chancen bei. Das Fazit in einem kurzen Satz wäre wohl folgendermaßen zu formulieren: Erst das WAS, dann das WIE! Im gesamten Service Lifecycle wird eines sehr deutlich: die Ausrichtung der Services an den Anforderungen und am wirklichen Bedarf des Kunden und seines Geschäftes. Dieses Ziel wird stringent verfolgt. Services der Lieferanten werden auf die Business Services fokussiert, damit deren Leistungen zur direkten Unterstützung der Geschäftsziele dienen. Business Service Management liefert hierfür ein Modell mit den entsprechenden Metriken (vgl. Abbildung 6). Business Service Management is the ongoing practice of governing, monitoring and reporting on the IT and the business services it impacts. 16

28 2.4 Die Struktur gemäß ITIL Version 3 Business Service IT Service C Business Prozesse Management Informationen ermöglicht D IT Applikationen Management Informationen Personen Knowledge Applikationen Infrastruktur lose Koppelung Personen Knowledge Workflow Workflow Applikationen Infrastruktur A Nutzen A Nutzen B Service Plattform Availability Capacity Continuity Security Gewährleistung Schließt ein B Service Plattform Availability Capacity Continuity Security Gewährleistung A B C D Bündelung Business Prozess und IT Applikation zu einem Service. Bereitstellung einer Service- Schnittstelle und sicherstellen, dass der Service für die Nutzung verfügbar ist, mit einer adäquaten Kapazität, Kontinuität und Sicherheit. Verbessern der Business Prozesse um den Nutzen für die Business Service zu verbessern. Verbessern der IT Applikationen um die Gewährleistung der IT Services zu steigern. Abbildung 6: Verbindung zwischen IT Service und Business Service Wurde das Service Management bisher als taktische oder operative Aufgabe angesehen, so stellt das Service Management jetzt einen geschlossenen Regelkreis dar, wobei die Phase Service Strategie die Basis bildet (siehe Abbildung 7, aus Service Strategy, [OGC, 2007a]). 17

29 2 IT Service Management Strategie Implementierung Messung und Bewertung Service Design Anforderungen Service Design Service Strategy Service Portfolio Service Katalog Service Transition Anforderungen Service Transition Service Service Operation Operation Anforderungen Continual Service Improvement Messung und Bewertung Abbildung 7: Service Strategy Prozesse Service Design Die Phase Service Design (vgl. [OGC, 2007b]) dient dem Design und der Entwicklung von Services und Service Management-Prozessen. Ausgehend von den strategischen Zielen, die in der Phase Service Strategy definiert wurden, findet hier die Transformation zu einem Portfolio von Services statt. Wichtigstes Ergebnis dieser Stufe ist das Design einer effektiven und effizienten Service-Lösung. Die sich ständig verändernden Anforderungen des Business und der IT erfordern eine ständige Interaktion mit allen anderen Bereichen und Prozessen. Abbildung 8 verdeutlicht dies. Beim Design werden diese Bereiche und Prozesse in den Service Design Aktivitäten berücksichtigt, um alle Service- Lösungen mit existierenden Lösungen konsistent und kompatibel zu gestalten. Dies beinhaltet auch Änderungen und Verbesserungen, die notwendig werden, um sowohl den Wert der Services für den Kunden über den Lebenszyklus der Services hinweg zu erhalten, als auch die Kontinuität der Services, das Erreichen der Service Qualität (Level) und die Konformität zu Standards und Regeln. 18

30 2.4 Die Struktur gemäß ITIL Version 3 Siehe hierzu Abbildung 8, die Service Design Prozesse aus Service Design, [OGC, 2007b]. Neue Anforderungen Betrieb Neue Anforderungen Service Strategy Strategie und Bedingungen Service Design Package Service Transition Service Operation Analyse Anforderungen, dokumentieren & vereinbaren Design Service Lösung Beurteilung alternativer Lösungen Bereitstellung vorgezogene Lösung Entwicklung der Lösung Service Design Architekturen Messmethoden Service Portfolio Key Service Design Prozesse Service Katalog SLM: Policy, Pläne, SIP, SLRs, SLAs, OLAs, Reports Capacity: Policy, Pläne, CIMS,Reports, Sizing, Forecast Availability: Policy, Pläne, Designkriterien, AMIS,.. IT SCM: Policy, Pläne, BCPs, IT SCPs, Risiko-Analyse,.. Security: Policy, Pläne, Controls, Reports, Klassifizierung,. Supplier: Policy, Pläne, contracts, SCD, Reports. Service Katalog M. Service Level Management Capacity Management Availability Management ITSC Management Security Management Supplier Management Input aus anderen Bereichen wie Incidents, Probleme, Request Fulfillment, Access, Change, Configuration, Knowledge, Release Planning, Risk Evaluation, Testing, Abbildung 8: Service Design Prozesse Service Transition Die Phase Service Transition (vgl. [OGC, 2007c]) umfasst das Management und die Koordination von Prozessen, Systemen und Funktionen, um ein Release zu paketieren, zu bauen, zu testen, auszuliefern und in die Produktion zu übernehmen und die durch Kunden und Stakeholder spezifizierten Anforderungen umzusetzen. 19

31 2 IT Service Management Hierzu werden die Anforderungen aus den Phasen Service Stategy und Service Design für einen effektiven Service Betrieb realisiert. Hier findet das Management komplexer Änderungen bei den Services und Service Management-Prozessen und die Verhinderung unerwünschter Konsequenzen statt: Risiken sollen kontrollierbar bleiben; gleichzeitig der Versuch, Raum zu lassen für Innovation. Ein wesentlicher Aspekt ist auch die kontrollierte Übergabe von Verantwortung für Services vom Service-Lieferanten zum Kunden. Die Aufgaben der Phase Service Transition sind Abbildung 9 zu entnehmen ( Service Transition, [OGC, 2007c]). Continual Service Improvment Change Management RFC1 RFC2 RFC3 RFC4 RFC5 RFC6 Service Asset and Configuration Management BL BL BL BL BL BL BL Service Transition Planning and Support Oversee Management of Organisation and Stakeholder Change Evaluation of a Change or Service E1 E2 E3 Service Strategy Service Design Plan and Build prepare and Release Test Service Testing and Pilots Release and Deployment Management Plan and Transfer, Review and Prepare for Deploy, Close Service Deployment Retire Transition Early Life Support Service Operation other ITIL Core Book Service Validation and Testing Knowledge Management ITIL process in this Focus of Activity Book that supports Related to the whole service Service Transition Life Cycle Ex = Point to Evaluate RFCx = Request f. Change BL = Capture Baseline Abbildung 9: Service Transition Prozesse 20

32 2.4.5 Service Operation 2.4 Die Struktur gemäß ITIL Version 3 In dieser Phase geht es um das Management des Service Betriebs (Service Operation). Sie enthält Anleitungen für effektive und effiziente Lieferung und Support der Services, um den gewünschten Wert für die Kunden und den Service-Lieferanten sicherzustellen. Die strategischen Ziele werden in dieser letzten Stufe letztendlich durch Service Operation realisiert, was seine kritische Bedeutung erkennen lässt. Angestrebt wird ein stabiler Service Betrieb, um Änderungen an Design, Skalierung, Inhalt und Service Level zu erlauben. Inhalte sind u. a.: Management der Service-Verfügbarkeit Anforderungsmanagement und -Kontrolle Optimierung der Kapazitätsnutzung Einplanung und Scheduling von Betriebsoperationen Problemlösung Unterstützung des Betriebs durch neue Modelle und Architekturen (z. B. Shared Services, Utility Computing, Web Services und Mobile Computing) fortlaufendes Management der zugrunde liegenden Technologien tägliche Überwachung der Leistungsparameter und -werte (Monitoring). Auch in dieser Phase des Service Lifecycle steht nach wie vor im Vordergrund, die Services am Bedarf des Business auszurichten. Hierzu müssen Aktivitäten und Prozesse so koordiniert und ausgeführt werden, dass die vereinbarten Service Level eingehalten werden. Das Zusammenwirken der Service Operation Prozesse ist in der Abbildung 10 aus [KESS, 2007c] dargestellt. 21

33 2 IT Service Management Problem Management Event Management Filter Change Management Incident Management Request Fulfilment Self Help Access Management Prozess aus Service Transition Deployment Abbildung 10: Service Operation Prozesse Continual Service Improvement ITIL fordert IT Service Provider nicht nur dazu auf, konsistente und wiederholbare Prozessaktivitäten anzustreben, um Service Qualität zu demonstrieren, sondern geht darüber hinaus und fordert als Teil der angestrebten Service Qualität einen Prozess permanenten Strebens nach Verbesserungen. Primärer Zweck des Continual Service Improvement (CSI) (vgl. [OGC, 2007e]) ist die kontinuierliche Anpassung der IT Services an die sich ständig verändernden Anforderungen aus den Geschäftsprozessen. Ziel ist es, sowohl Prozess-Effektivität und -Effizienz als auch Kosten-Effektivität zu verbessern. Insofern geht es um die Aufrechterhaltung und Verbesserung des Business Value für den Kunden im Hinblick auf Design, Einführung und Betrieb der Services. Für eine optimale Unterstützung der Geschäftsprozesse müssen die IT Service Management-Prozesse nach klar definierten Zielen und mit relevanten Messsystemen implementiert, verwaltet und unterstützt werden. 22

34 2.4 Die Struktur gemäß ITIL Version 3 Hierfür ist es außerordentlich kritisch und wichtig, zu verstehen, was gemessen und warum es gemessen werden muss, und Erfolgsfaktoren sorgfältig zu definieren. Siehe hierzu die übergreifende Aufgabenstellung des Continual Service Improvement auf Basis der Darstellung in Continual Service Improvement, [OGC, 2007e] (siehe Abbildung 11). Business / Kunden Service Strategy Anforderungen Service Portfolio Service Design Service Katalog Service Transition Service Operation Operationelle Services Abbildung 11: Continual Service Improvement Continual Service Improvement Improvement Pläne u. Aktionen Der prozessorientierte Ansatz von ITIL Version 3 Mit der aktuellen ITIL Version 3 hat sich nicht nur der Scope des Service Managements erweitert, sondern auch die Anzahl der beschriebenen Service Management-Prozesse. Diese Erweiterung der bestehenden Prozesse betrifft insbesondere die Phase Service Transition. Bei den ITIL-Publikationen der Version ITIL Version 3 sind dies in den Publikationen Service Design, Service Transition, Service Operation und Continual Service Improvement insgesamt 26 IT Service Management-Prozesse vgl. [OGC, 2007b-e]). Hinzu kommen aus der Phase Service Strategy noch die Aufgaben des Financial Managements, des 23

35 2 IT Service Management Service Portfolio Managements und des Demand Managements, die ebenfalls als Prozesse anzusehen sind. Diese umfangreiche Erweiterung mag den Leser vielleicht zunächst erschrecken, dabei darf aber nicht außer Acht gelassen werden, dass ein Teil dieser Prozesse in ITIL Version 2 bereits in anderen weniger beachteten Publikationen, wie zum Beispiel Applikation Management oder ICT Infrastructure Management beschrieben waren. Andererseits sind nun Prozesse dokumentiert, die in vielen Organisation bereits so implementiert sind, wie zum Beispiel das Event Management zur Entdeckung und Interpretation von Ereignissen, die über entsprechend Tools generiert und behandelt werden. Mit der ITIL Version 3 werden das notwendige Prozess-Management und die damit verbundenen Aspekte stärker hervorgehoben. Als Prozess wird definiert (vgl. Service Design, [OGC, 2007b]): Ein Prozess ist eine strukturierte Folge von Aktivitäten, die geplant werden, um ein bestimmtes Ziel zu erreichen. Ein Prozess benötigt einen oder mehrere definierte Inputs und transformiert diese Inputs zu definierten Outputs. Ein Prozess beinhaltet die notwendigen Rollen, die Verantwortlichkeiten, die Tools und die Management Controls, um den Output zu liefern. Ein Prozess definiert dazu die notwendigen Grundsätze (Policies), Standards, Richtlinien, Aktivitäten und Arbeitsanweisungen. Prozesse weisen gemäß ITIL Version 3 die folgenden Merkmale auf: Messbar: Die Prozesse sind in einer relevanten Art zu messen. Prozesse sind leistungsgetrieben. Manager wollen Kosten, Qualität und andere Variable messen, während sich die Ausführenden mit Dauer und Produktivität beschäftigen. Spezifizierte Ergebnisse: Prozesse existieren, um ein bestimmtes Ergebnis zu liefern: Dieses Ergebnis muss individuell identifizierbar und zählbar sein. Kunden: Jeder Prozess liefert einem Kunden oder einer Interessengruppe seine Ergebnisse. Der Prozess muss den Erwartungen der internen oder externen Kunden entsprechen. Reagieren auf bestimmte Ereignisse: Da ein Prozess fortlaufend oder sich wechselseitig beeinflussend sein kann, sollte er zu einem spezifischen Trigger verfolgbar sein. Mit der ITIL Version 3 wurde das bestehende Prozessmodell umfassender beschrieben und dargestellt (im Hauptteil des Buches und nicht im Anhang) vgl. Service Design, [OGC, 2007b] (siehe Abbildung 12). 24

36 2.4 Die Struktur gemäß ITIL Version 3 Prozess- Befähigungen Prozess- Policy Prozess- Owner Prozess- Dokumentation Prozess- Ziele Prozess- Feedback Trigger Prozess-Steuerung Prozess-Arbeits -anweisungen Prozess- Aktivitäten Prozess- Input Prozess- Prozeduren Prozess-Durchführung Prozess- Metriken Prozess- Rollen Prozess- Improvement Prozess- Output inklusive Prozess-Reports und -Reviews Prozess-Bedingungen Prozess- Ressourcen Abbildung 12: ITIL Version 3 Prozessmodell Die Betrachtungsbereiche Prozess-Steuerung (Process Control), Prozess-Durchführung (Process) und Prozess-Bedingungen (Process E- nablers) sind zwar gegenüber der Version 2 grundsätzlich gleich geblieben, aber die zugehörigen Aspekte wurden detaillierter ausgewiesen. Die Definition, Steuerung und Verbesserung des Prozesses erfolgt innerhalb des Bereichs der Prozess-Steuerung. ITIL Version 3 definiert diesen Aufgabenbereich wie folgt (vgl. Service Design, [OGC, 2007b): Die Prozess-Steuerung ist die Aktivität, einen Prozess zu planen und zu regulieren, mit dem Ziel, den Prozess effektiv, effizient und in einer einheitlichen Art und Weise auszuführen. Sobald die Prozesse definiert sind, werden deren Dokumentation und Steuerung erforderlich. Hierzu sind entsprechende Metriken zu entwickeln und als Messpunkte in den Prozess zu integrieren. Mithilfe der implementierten Messpunkte werden Kennzahlen generiert, die in Prozess- Reports einfließen und eine Steuerung des Prozesses sicherstellen. 25

37 2 IT Service Management ITIL Version 3 sieht in den Prozessen entsprechende Metriken vor, die als Prozesskennzahlen in Service-Reports enthalten sind und ein Feedback zur Prozess- Durchführung liefern. Effektivität und Effizienz eines Prozesses Der Output eines Prozesses muss den betrieblichen Anforderungen entsprechen, die aus den Geschäftszielen abgeleitet sind. Werden diese Anforderungen hinsichtlich des Outputs erreicht, so ist die Effektivität des Prozesses sichergestellt. Werden die damit verbundenen Aktivitäten mit einem minimalen Ressourceneinsatz durchgeführt, so ist die notwendige Effizienz gegeben. Prozessanalysen, Metriken und Prozessergebnisse sind in Management- Reports darzustellen und bieten die Basis für gegebenenfalls notwendige Verbesserungsmaßnahmen. Die mit der ITIL Version 3 beabsichtigte Business-Integration findet sich ausdrücklich in den Prozesszielen wieder. So wird in ITIL herausgestellt, dass der erforderliche Output eines Prozesses aus den Geschäftszielen abgeleitet wird. Um diese Ziele zu erreichen, müssen die notwendigen Rollen definiert und die Verantwortlichkeiten in der Organisation zugewiesen werden. Hierzu stellt die ITIL Version 3 folgende Anforderungen (vgl. Service Design, [OGC, 2007b): Jedem Prozess ist ein Prozess Owner zugeordnet, der für die Zielereichung und die Verbesserung verantwortlich ist. Die Prozessziele sind in messbarer Hinsicht zu definieren und stehen in Bezug mit den Vorteilen für das Business und der zugrunde liegenden Unternehmensstrategie. Prozess Owner und Prozess Manager Während in der ITIL Version 2 keine exakte Definition und Beschreibung für den Prozess Owner und Prozess Manager existieren, werden in der ITIL Version 3 diese Rollen definiert und unterschieden: Die Prozess Owner ist dafür verantwortlich, dass ein Prozess zweckmäßig ist. Die Verantwortung des Prozess Owners schließt die Unterstützung, das Design, das Change Management und die beständige Verbesserung des Prozesses und der damit verbunden Messsysteme ein. Die Prozess Manager ist für das operationelle Managements des Prozesses verantwortlich. Die Verantwortung des Prozess Managers umfasst die Planung und Koordinierung aller Aktivitäten, deren Monitoring und deren Berichterstattung. In größeren Organisationen kann es durchaus mehrere Prozess Manager für einen Prozess geben, wie zum Beispiel regionale Change Manager pro Niederlassung. 26

38 2.5 ITIL Kennzahlen für IT Service Management-Prozesse In kleineren Organisationen übernimmt der Prozess Owner auch die Aufgaben des Prozess Managers. 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Mit der veröffentlichten Version 3 der ITIL Best Practices befindet sich das IT Service Management in einer Übergangsphase. Unternehmen, die bereits IT Service Management-Prozesse implementiert haben, nutzen hierzu die Version 2. Eine Aktualisierung dieser implementierten Prozesse wird kontinuierlich erfolgen, aber nicht kurzfristig umzusetzen sein. Unternehmen, die vor der Implementierung stehen, werden dahingehend wahrscheinlich die Version 3 als Basis für das IT Service Management heranziehen. Um beiden Interessengruppen gerecht zu werden, werden in diesem Buch ausgewählte Kennzahlen aus beiden Versionen dargestellt. Die in diesem Kapitel dargestellten Kennzahlen sind beispielhafte Kennzahlen und erheben keinen Anspruch auf Vollständigkeit. Sie sollen die Inhalte der Version 2 bzw. Version 3 beispielhaft wiedergeben. Innerhalb des Kapitels 5 Entwicklung von IT-Kennzahlensystemen geben wir Kennzahlen an, die sich in der Praxis bewährt haben und gehen insbesondere darauf ein, wie diese Kennzahlen in ein übergeordnetes Kennzahlensystem zu integrieren sind. Aufgrund des generischen Ansatzes werden in ITIL mögliche Leistungsindikatoren und Metriken aufgezeigt. Die konkrete Ausgestaltung der Metrik mit detaillierter Spezifikation und Bedeutung für das Prozess- Management ist Aufgabe des Prozessdesigns. In ITIL und COBIT sind viele Kennzahlen dokumentiert. Wir beschränken uns in diesem Kapitel aber auf die, die im Rahmen unserer Projekterfahrung eine wichtige Rolle spielen bzw. gespielt haben. Später werden diese Praxis- Kennzahlen näher spezifiziert und ihre Bedeutung wird für den jeweiligen Prozess dargestellt. In ITIL und COBIT sind viele Kennzahlen dokumentiert Ausgewählte Kennzahlen der ITIL Version 2 Incident Management Ziel des Incident Managements ist die schnellstmögliche Wiederherstellung des normalen Service-Betriebs bei minimaler Störung des Geschäftsbetriebs. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: 27

39 2 IT Service Management Anzahl der aufgetretenen Störungen Durchschnittliche Zeitdauer bis zur Behebung oder Umgehung der Störung in Relation zur Priorität Anteil der Störungen, die innerhalb der vereinbarten Reaktionszeit bearbeitet wurden Höhe der durchschnittlichen Kosten pro Störung Lösungsrate von Störungen im Service Desk Anzahl der bearbeiteten Störungen pro Arbeitsplatz im Service Desk Anzahl und Anteil der Störungen die remote ( ohne Vor-Ort-Support) behoben werden konnten Bei der Auswertung entsprechender Leistungsindikatoren ist zu beachten, dass ITIL Incident als Oberbegriff für Störungen und Service-Requests nutzt. Im Incident Management-Prozess werden daher auch Service-Requests erfasst und bearbeitet. Für die Aussagekraft der obigen Kennzahlen müssen daher im Rahmen der Kennzahlenermittlung Störungen und Service-Requests differenziert betrachtet werden. Problem Management Das Problem Management hat die Stabilisierung der IT Services durch die Vermeidung von Incidents zum Ziel. Hierzu werden vom Prozess reaktive und proaktive Aktivitäten durchgeführt. Zu den reaktiven Aufgaben zählen die Aktivitäten von der Identifizierung von Problemen bis zu einer möglichen Umsetzung über das Change Management. Die proaktiven Aktivitäten sollen dagegen sicherstellen, Störungen zu verhindern bevor sie auftreten. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: Anzahl der vom Problem Management eröffneten RFCs (Request for Change) und Auswirkung dieser RFCs Durchschnittlicher Zeitaufwand für die Feststellung von Bekannten Fehlern (Known Error); Zeitdauer vom Auftreten eines entsprechenden Problems bis zur Identifizierung des Bekannten Fehlers Anzahl und Auswirkung von Störungen bevor das zugrunde liegende Problem gelöst ist Häufigkeit der Probleme unterteilt nach Status, IT Service, Auswirkung, Kategorie und Kunde Durchschnittliche und maximale Zeitdauer bis zum Abschluss des Problems 28

40 Configuration Management 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Das Configuration Management dient der Definition, Kontrolle, Pflege und Verifizierung der Service- und Infrastrukturkomponenten sowie der Verwaltung korrekter Konfigurationsinformationen. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: Anteil der Konfigurationen, die nicht dem autorisierten Zustand entsprechen Anteil fehlerhafter Changes aufgrund falscher Daten in der CMDB (Configuration Management Database) Bearbeitungsdauer bis zur Aktualisierung der CMDB Anteil und Anzahl nicht genutzter Lizenzen Anteil nicht autorisierter IT-Komponenten Darüber hinaus werden unter anderem die folgenden Berichte an das Management empfohlen: Anzahl der erfassten CIs (Configuration Item) aufgeschlüsselt nach Kategorien, Typ und Status Dokumentationsqualität der CIs Angaben zum Wachstum des CI-Bestandes Wert der CIs Change Management Das Ziel des Change Managements ist es, sicherzustellen, dass durch standardisierte Methoden und Verfahren durchzuführende Änderungen effizient und schnellstmöglich umgesetzt werden. Dabei ist darauf zu achten, dass die Änderungen möglichst geringe Auswirkungen auf die Qualität der IT Services haben. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: Anzahl durchgeführter Änderungen, als Summe und gegliedert in IT Service, CI-Typ usw. Anteil zurückgewiesener RFCs Anteil erfolgreicher Änderungen Anteil termingerechter Änderungen Anteil Backouts (Fallback; zurückgesetzte Änderungen) Anteil Änderungen innerhalb des geplanten Budgets Release Management Das Release Management hat die Bereitstellung, Verteilung und Verfolgung eines oder mehrerer Changes in einem Release in der Produktionsumge- 29

41 2 IT Service Management bung zum Ziel und soll durch die Anwendung formeller Verfahren und Prüfungen die Produktionsumgebung schützen. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: Anteil eingehaltener Release-Termine Anteil eingehaltener Release-Budgets Anteil zurückgesetzter Releases (Backout) Anzahl von Problemen aufgrund neuer Releases Größe und Kapazität der DSL (Definierte Softwarebibliothek) Service Level Management Das Ziel des Service Level Managements ist es, Servicequalität zu sichern und kontinuierlich zu verbessern. Dies erfolgt in einem fortlaufenden Zyklus von Definition, Verhandlung, Vereinbarung, Messung, Berichterstattung und Reviews der IT Services. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: Anzahl bzw. Anteil von Services mit SLAs Anteil von SLAs mit OLAs und UCs Anteil eingehaltener SLAs Kundenzufriedenheit Einhaltung von Review-Terminen Financial Management für IT Services Ziel des Financial Managements für IT Services ist die kostenwirksame Verwaltung der IT-Komponenten, die für die Erbringung der IT Services benötigt werden. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: Die Budgetpläne werden termingerecht erstellt Die monatlichen, vierteljährlichen und jährlichen finanziellen Geschäftsziele werden erreicht Verringerung des Anteils der indirekten Kosten Die Leistungsverrechnungen werden vom Kunden als angemessen bzw. fair akzeptiert Capacity Management Ziel des Capacity Managements ist die Sicherstellung ausreichender IT- Kapazitäten zu vertretbaren Kosten, um den aktuellen und zukünftigen Geschäftsanforderungen des Kunden gerecht zu werden. 30

42 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: Anteil von Störungen durch nicht ausreichende Kapazitäten Anteil von SLA-Verletzungen aufgrund mangelnder Performance Anzahl der Kapazitätsanforderungen, die nicht im Kapazitätsplan enthalten sind Reduzierung von Überkapazitäten IT Service Continuity Management Das Ziel des IT Service Continuity Managements ist die Unterstützung des übergreifenden Business Continuity Managements, durch die gesicherte Wiederherstellbarkeit von IT Services innerhalb der erforderlichen und vereinbarten Zeit. Wesentliche Leistungsindikatoren gemäß der ITIL Best Practices sind: Anzahl festgestellter Mängel am IT Service Continuity-Plan Zeitspanne zwischen Änderungen mit Auswirkungen auf den IT Service Continuity-Plan und der Aktualisierung des Plans Anzahl durchgeführter Übungen / Tests des IT Service Continuity- Plans Availability Management Zielsetzung des Availability Managements ist die Gewährleistung der Service-Verfügbarkeit, um die Verpflichtungen gegenüber dem Business erfüllen zu können. Die seitens der ITIL Best Practices dokumentierten wesentlichen Leistungsindikatoren sind: Anzahl von Störung aufgrund der Nicht-Verfügbarkeit Abweichung zwischen geplanter und tatsächlicher Verfügbarkeit Dauer der Nichtverfügbarkeit Security Management Ziel des Security Managements ist es, einen definierten Grad an Sicherheit für die Informationen und IT Services zu gewährleisten. Hierzu zählt einerseits die Erfüllung der Sicheranforderungen aus den SLAs und anderer externer Anforderungen. Andererseits ist ein definierter Grundschutz zu schaffen. Die Publikation ITIL Best Practice für Security-Management spezifiziert für diesen Prozess keine Leistungsindikatoren (vgl. [OGC, 2006a]). Die ITIL Best Practices zum Security-Management verfolgen das Konzept, dass die Sicherheitsanforderungen, bestehend aus Verfügbarkeit, Vertrau- 31

43 2 IT Service Management lichkeit und Integrität, als Service Level innerhalb der SLAs mit dem Kunden vereinbart werden. Diese Sicherheitsanforderungen gehen ein in die OLAs (Operational Level Agreements) und UCs (Underpinning Contracts). Die Leistungsindikatoren des Security-Managements entsprechen demzufolge den übrigen Service Level eines SLA / OLA / UC und sind eine Ausprägung der Service-Berichte. Aus der Prozessaktivität Berichtswesen können folgende Leistungsindikatoren abgeleitet werden: Anteil von SLAs, OLAs und UCs mit Sicherheitsverletzungen Anzahl von Security-Incidents Reaktionszeit auf Security-Incidents Ausgewählte Kennzahlen der ITIL Version 3 Wenn man sich mit den Kennzahlen der ITIL Version 3 beschäftigt, spielen die 5 Phasen des Service Lifecycle mit ihren entsprechenden Prozessen die grundlegende Rolle. Die aus der ITIL Version 2 bekannten Prozesse haben wir in Abbildung 13 hervorgehoben. Dabei wird deutlich, dass einige Prozesse der ITIL Version 2 teilweise hinsichtlich der Ziele und Aufgabenstellung verändert wurden. So werden zum Beispiel die Service Requests nicht mehr im Incident Management aufgenommen oder Aufgaben des Service Level Managements aus der ITIL Version 2 finden sich in anderen, neuen Prozessen wieder. Diese durchgeführten Anpassungen gegenüber der ITIL Version 2 haben auch Auswirkungen auf die damit verbundenen Kennzahlen und Metriken, deren Definition und deren Vergleichbarkeit. 32

44 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Continual Service Improvement Service Asset Release and and Configuration M. Deployment M. Change Management Transition Planning and Support Service Supplier M. Level Manage- Information ment Security M. Service Continuity M. Availability M. Service Design Service Transition Service Portfolio Demand M. M. Service Strategy Financial Management Service Validation and Testing Evaluation Capacity M. Problem M. Service Level M. Access Management The 7 Step Improvement Process Knowledge Mgmt. Event Management Incident Management Request Fulfilment Service Operation Service The Catalogue M. Service Desk Service Business Measurement Questions for CSI Return on Investment (ROI) for CSI Service Reporting Abbildung 13: Die 5 Phasen des Service Lifecycles und ihre Prozesse Im Folgenden werden die 5 Phasen des Service Lifecycle mit ihren Prozessen vorgestellt und die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren beispielhaft beschrieben. 33

45 2 IT Service Management Service Strategy Service Portfolio M. Service Strategy Demand M. Financial Management Abbildung 14: Service Strategy Die Publikation Service Strategy ([OGC, 2007a]) weicht von den übrigen vier Publikationen dahingehend ab, dass sie kein Kapitel Prozesse enthält. Im Rahmen des Kapitels Service Economics werden Aspekte beschrieben, die einen Charakter von Prozessen haben. Als Prozesse sind dabei das Financial Management, das Service Portfolio Management und das Demand Management anzusehen. Financial Management Financial Management quantifiziert IT Services, ihre zugrunde liegenden Assets und sogar operationelle Vorhersagen mit Metriken aus der Finanz- Terminologie. Die Frage, die hier im Raum steht, ist die nach dem Wert für das Business und die IT. Es gibt einen Wandel in der Wahrnehmung der IT und ihres Wertes für das Business. Financial Management hilft bei der Identifizierung, Dokumentation und Akzeptanz des Wertes der erhaltenen Serviceleistungen und ermöglicht die Modellierung und das Management von Service-Anforderungen. Service Portfolio Management Ein Service Portfolio beschreibt die Services eines Providers im Hinblick auf deren Wert für die Geschäftsprozesse (Business Value). Service Portfolio Management formuliert die geschäftlichen Anforderungen und die Antwort des IT Service Providers auf diese Bedürfnisse. 34

46 Demand Management 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Demand Management (Anforderungsmanagement) behandelt kritische Aspekte des Service Managements: Unsicherheiten bei der Anforderungsaufnahme bergen Risiken für IT Service Provider, wie Überkapazitäten oder ungenügende Kapazitäten mit Auswirkung auf die Qualität der Services. Service Level Agreements, Vorhersagen, Planung und feste Koordination mit dem Kunden können die Unsicherheiten bei den Anforderungen reduzieren, diese aber nicht vollständig eliminieren Service Design Supplier M. Information Security M. Service Continuity M. Availability M. Service Design Capacity M. Service Level M. Service Catalogue M. Abbildung 15: Service Design Service Catalogue Management Ziel des Prozesses Service Catalogue Management (SCM) ist die Erstellung und Pflege eines Service Katalogs mit genauen Informationen über alle aktuellen und geplanten operationalen Services. Hierzu werden die vom Service Portfolio Management definierten Services entsprechend spezifiziert und sind als Teilmenge bzw. konkrete Ausprägung des Service Portfolios anzusehen. 35

47 2 IT Service Management Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: die Anzahl der aufgenommenen und verwalteten Services innerhalb des Service Katalogs als Prozentsatz der Services, die ausgeliefert und übergeben wurden und sich in der Live-Umgebung befinden die Anzahl von Abweichungen zwischen den Informationen im Service Katalog und der realen Welt. Service Level Management Der Service Level Management Prozess definiert und vereinbart für alle aktuellen und zukünftigen IT Services die damit verbundenen Service Level und die erreichbaren Zielwerte (Service Level Targets). Außerdem stellt er sicher, dass Services auf diesem Level ausgeliefert werden. Proaktive Messungen und Reports helfen bei den notwendigen Verbesserungen zur Zufriedenheit der Kunden. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: prozentuale Verringerung nicht erfüllter SLA-Ziele prozentuale Verringerung bedrohter SLA-Ziele prozentualer Anstieg der Kunden-Wahrnehmung und -Zufriedenheit von SLA-Leistungen via Service Reviews und Kunden Zufriedenheits-Befragungen prozentuale Verringerung von SLA-Verletzungen, die durch Unterauftragnehmer verletzt wurden. Capacity Management Das Capacity Management (Kapazitätsmanagement) stellt sicher, dass IT- Kapazitäten zu gerechtfertigten Kosten jederzeit in allen IT-Bereichen existieren und rechtzeitig die abgestimmten aktuellen und zukünftigen Anforderungen des Business abdecken. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: akkurate Business Vorhersagen (Vorhersagen über Arbeitsauslastungen in der Produktion; prozentuale Genauigkeit der Vorhersagen von Business Trends, etc.) Wissen über aktuelle und zukünftige Technologien (Fähigkeit, Performance und Durchsatz aller Services und Komponenten zu monitoren; rechtzeitige Ausrichtung und Implementierung neuer Technologien, abgestimmt auf die Business-Anforderungen, etc.) 36

48 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Fähigkeit, Kosten-Effektivität zu demonstrieren (eine Verringerung von Käufen in letzter Minute für die Behebung dringender Performance-Probleme; Verringerung von Überkapazitäten der IT, etc.) Fähigkeit zur Planung und Implementierung der angemessenen IT- Kapazitäten zur Befriedigung der Business-Anforderungen (prozentuale Verringerung der Anzahl von Incidents, die durch schlechte Performance ausgelöst werden; prozentuale Verringerung verlorener Geschäftschancen aufgrund unzulänglicher Kapazitäten, etc.). Availability Management Der Availability Management-Prozess (Verfügbarkeitsmanagement) stellt sicher, dass die Verfügbarkeit aller ausgelieferten Services die aktuellen und zukünftigen Anforderungen kosteneffektiv befriedigt oder übertrifft. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: prozentuale Verringerung in der Nichtverfügbarkeit von Services und Komponenten prozentualer Anstieg in der Verlässlichkeit von Services und Komponenten effektives Review und Verfolgung aller Verletzungen bei SLAs, OLAs und UCs prozentuale Verbesserung in der allumfassenden end-to-end Verfügbarkeit von Services. IT Service Continuity Management Das IT Service Continuity Management (ITSCM) unterstützt den allumfassenden Business Continuity Management Prozess. Es stellt sicher, dass die IT-technischen Betriebsmittel und Services (einschließlich Rechnersysteme, Netzwerke, Anwendungen, Datenbestände, Telekommunikationsanlagen, technischer Support und Service Desk) nach einem Ausfall oder einer Störung innerhalb der erforderlichen und vereinbarten Zeitgrenzen wieder in Betrieb gehen und verfügbar sind. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: regelmäßige Audits der ITSCM Pläne, um das Erreichen der vereinbarten Wiederherstellungsanforderungen des Business sicherzustellen alle Service-Wiederherstellungsziele sind in SLAs vereinbart und dokumentiert und sind erreichbar innerhalb der ITSCM-Pläne regelmäßige und umfassende Tests der ITSCM-Pläne 37

49 2 IT Service Management regelmäßige, mindestens jährliche Reviews der Business- und IT Continuity-Pläne mit den Geschäftsbereichen. Information Security Management IT Sicherheit muss auf das Sicherheitsbedürfnis des Business abgestimmt werden. Information Security Management verfolgt dieses Ziel über ein effektives Management der Informations-Sicherheit in allen Services und Service Management-Aktivitäten. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: prozentuale Verringerung der im Service Desk berichteten Sicherheits-Verletzungen prozentuale Verringerung bei den Auswirkungen von Sicherheits- Verletzungen und Incidents prozentualer Anstieg der SLA-Konformität zu den Sicherheitsbestimmungen Abnahme der Anzahl von Abweichungen des Information Security Management-Prozesses von Business Security-Policy und -Prozess. Supplier Management Supplier Management ist das Management von Lieferanten und ihren Services, um dem Business die vereinbarte Service-Qualität zukommen zu lassen und sicherzustellen, dass Ausgaben bei den Lieferanten wieder eingenommen werden können. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: Anstieg der Anzahl von Lieferanten, die vertraglich vereinbarte Ziele einhalten Anstieg der Anzahl der mit Lieferanten durchgeführten Serviceund Vertrags-Reviews Reduzierung der Anzahl von durch Lieferanten verursachten Service-Verletzungen Anstieg der Anzahl von Lieferanten mit ernanntem Lieferanten-Manager. 38

50 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Service Transition Service Transition Service Asset and Configuration M. Change Management Transition Planning and Support Release and Deployment M. Service Validation and Testing Evaluation Knowledge Mgmt. Abbildung 16: Service Transition Transition Planning and Support Transition Planning and Support plant und koordiniert Ressourcen für eine effektive Realisierung der in Service Strategy definierten und in Service Design entwickelten und umgesetzten Anforderungen. Potentielle Risiken und Störungen der Transitions-Aktivitäten werden identifiziert und kontrolliert. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: die Anzahl implementierter Releases, die im Hinblick auf Kosten, Qualität, Scope und Release-Zeitplan die mit dem Kunden vereinbarten Anforderungen erfüllen Reduzierung von Abweichungen der aktuellen gegen die vorhergesagten Werte Inhalt (Scope), Qualität, Kosten und Zeit gestiegene Kunden- und Anwender-Zufriedenheit mit Plänen und der Kommunikation, die das Business in die Lage versetzen, seine Aktivitäten mit den Service Transition Plänen in Einklang zu bringen Reduzierung der Anzahl von Problemen, Risiken und Verzögerungen, die durch unzulängliche Planung verursacht werden. Change Management Die Anforderungen im Business des Kunden verändern sich fortlaufend. Change Management reagiert auf diese Änderungsanforderungen und maximiert den Wert für den Kunden, während gleichzeitig Incidents, Störungen und Überarbeitungen reduziert werden. Die Reaktionen auf die Än- 39

51 2 IT Service Management derungsanforderungen des Business und der IT sorgen für eine Ausrichtung der Services am Bedarf des Business. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: Anzahl der Änderungen (Changes) an den Services, die die mit den Kunden vereinbarten Anforderungen z. B. hinsichtlich Qualität/Kosten/Zeit erfüllten (ausgedrückt als Prozentsatz an allen Änderungen) der Nutzen der Änderungen, ausgedrückt als Wert der durchgeführten Verbesserungen + verhinderte oder beendete negative Auswirkungen, verglichen mit den Kosten des Änderungsprozesses Reduzierung der Anzahl von Störungen am Service, Mängel und Überarbeitungen, die durch nicht exakte Spezifikation oder schlechte/unvollständige Bewertung der Auswirkungen verursacht wurden. Reduzierung der Anzahl nicht autorisierter Änderungen Reduzierung des Rückstands von Änderungsanträgen. Service Asset and Configuration Management Service Asset und Configuration Management liefert ein logisches Modell der IT Infrastruktur und stellt falls erforderlich den Zusammenhang zwischen den IT Services mit notwendigen IT-Komponenten her. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: prozentuale Verbesserung bei der Zeitplanung für Wartungsarbeiten eines Assets (nicht zu viel, nicht lange) Grad der Abstimmung zwischen unterstützter Wartung und Business Support als Ursache von Service-Ausfällen identifizierte Assets verbesserte Geschwindigkeit für das Incident Management zur I- dentifizierung fehlerhafter Cis und die Wiederherstellung des Service Auswirkung von Incidents und Fehlern mit Bezug auf bestimmte CI-Typen, z. B. von bestimmten Lieferanten oder Entwicklungsgruppen. Release and Deployment Management Das Ziel von Release und Deployment Management ist die Auslieferung und Überführung von Releases in die Produktion. Hier werden die Services 40

52 2.5 ITIL Kennzahlen für IT Service Management-Prozesse den Kunden zur Verfügung gestellt und sichergestellt, dass die Services sinnvoll und produktiv genutzt werden können. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: Abweichung von der vom Kunden geforderten Service Performance (Service Leistung) Anzahl von Incidents bzgl. des Service Reduzierter Einsatz von Ressourcen und Kosten für die Diagnose und die Behebung von Incidents und Problemen in Entwicklung und Produktion Verstärkte Umstellung des Service Transition Common Framework auf Standards, wiederverwendbare Prozesse und Support. Service Validation and Testing Service Validation and Testing überprüft und sichert den Wert der Services für die Kunden und ihr Business. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: Vertrauen, dass ein Release die erwarteten Ergebnisse und den Wert für die Kunden innerhalb der projektierten Kosten, Kapazitäten und Beschränkungen liefert Die Bestätigung, dass ein Service seinen Zweck und die geforderte Performance ohne unerwünschte Beschränkungen erfüllt Sicherstellen, dass ein Service bestimmte Spezifikationen innerhalb der spezifizierten Rahmen- und Nutzungsbedingungen erfüllt Bestätigung, dass Anforderungen der Kunden und Stakeholder für neue oder veränderte Services korrekt definiert sind und die Beseitigung jeglicher Fehler oder Abweichungen möglichst früh im Service Lebenszyklus erfolgt, da dies beträchtlich billiger ist als die Fehlerbeseitigung in der Produktion. Evaluation Evaluation bewertet Performance-Veränderungen bei einer Service-Änderung. So können Abweichungen zu gewünschten und vorhergesagten Performance-Werten entsprechend behandelt werden. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: Abweichung der Service Performance Anzahl von Incidents bzgl. des Service Anzahl fehlerhafter Designs, die überführt wurden Zykluszeit für die Durchführung der Evaluation. 41

53 2 IT Service Management Knowledge Management Knowledge Management liefert die Grundlage für fundierte Entscheidungen. Die im Verlauf des Lebenszyklus der Services gewonnenen Informationen und Daten werden bereitgestellt. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: Incidents und verlorene Zeiten, kategorisiert als Mangel an Anwender-Wissen durchschnittliche Diagnose- und Reparatur-Zeit für Fehler, die inhouse behoben werden Incidents bzgl. neuer oder veränderter Services, die durch Referenz auf die Wissensbasis behoben wurden Service Operation Problem M. Access Management Service Desk Event Management Incident Management Request Fulfilment Service Operation Abbildung 17: Service Operation Event Management Event Management befähigt zur Entdeckung und Interpretation von Ereignissen (Events) und ermöglicht deren Steuerung. Deshalb ist Event Management die Basis für Operational Monitoring and Control. 42

54 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: Anzahl von Ereignissen je Kategorie Anzahl von Ereignissen nach Signifikanz Anzahl und Prozentsatz an Ereignissen, die menschliche Intervention erforderten und ob dies durchgeführt wurde Anzahl und Prozentsatz an Ereignissen, die in Incidents oder Änderungen resultierten. Incident Management Das primäre Ziel des Incident Management-Prozesses ist die schnelle Wiederherstellung des Service Betriebs mit der Qualität, wie sie in den Service Level Agreements (SLA) vereinbart wurde. Hierbei soll die Auswirkung des Incidents auf die Geschäftsprozesse minimiert werden. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: Gesamtzahl der Incidents (als Kontroll-Wert) Aufschlüsselung der Incidents in jeder Stufe (z. B. aufgezeichnet, in Bearbeitung, geschlossen) Rückstand aktueller Incidents Anzahl und Prozentsatz schwerwiegender (major) Incidents mittlere Ablaufzeit bis zur Lösung/Wiederherstellung oder Umgehungslösung, aufgeschlüsselt nach Auswirkung (impact code). Request Fulfilment Request Fulfilment ist der für die Behandlung der Service Requests verantwortliche Prozess. Er stellt definierte Informationskanäle für die Anwender bereit, mit denen Anforderungen gestellt und Services entgegengenommen werden können. Darüber hinaus werden Informationen über die Verfügbarkeit von Services und Prozeduren für deren Nutzung bereitgestellt. Standardleistungen, wie z. B. Lizenzen und Software-Medien, werden beschafft und ausgeliefert. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: Gesamtzahl an Service Requests Aufschlüsselung der Service Requests auf die einzelnen Stufen (z. B. aufgezeichnet, in Bearbeitung, geschlossen) Rückstand bei der Bearbeitung von Service Requests mittlere Ablaufzeit bei der Behandlung der verschiedenen Typen von Service Requests. 43

55 2 IT Service Management Problem Management Der Prozess Problem Management ist verantwortlich für den Lebenszyklus aller Probleme 1. Das Problem Management hat hierzu die Ursachen zu i- dentifizieren und sicherzustellen, dass die erarbeiteten Lösungen über die Control Prozesse hauptsächlich Change Management implementiert werden. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: Gesamtzahl der Probleme (als Kontroll-Wert) Prozentsatz von Problemen, die innerhalb der SLA-Ziele gelöst bzw. nicht gelöst wurden Anzahl und Prozentsatz von Problemen, die ihre maximalen Lösungszeiten überschritten haben der Rückstand bei ausstehenden Problemen und ihr Trend (statisch, verringernd oder ansteigend?). Access Management Access Management berechtigt Anwender, einzelne Services oder Gruppen von Services zu nutzen. Insofern ist es für die Ausführung der im Securityund Availability Management definierten Richtlinien und Aktionen zuständig. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: Gesamtzahl der Zugriffsanforderungen (Service Request, RFC, etc.) Instanzen gewährter Zugriffe, nach Service, Anwender, Abteilung, etc. Instanzen gewährter Zugriffe nach Abteilung oder individuellen Zugriffsrechten Anzahl an Incidents, die ein Zurücksetzen der Zugriffsrechte erfordern. Service Desk Beim Service Desk handelt es sich um keinen Prozess, sondern um eine organisatorische Anforderung an die Organisation. 1 Ein Problem bezeichnet in der ITIL-Terminologie die Ursache für einen oder mehrere Incident. Die Ursache ist normalerweise bei der Eröffnung eines Problems nicht bekannt. Der Prozess des Problem Managements ist für die weitere Untersuchung der Ursache verantwortlich. 44

56 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Der Service Desk als Anforderung an die Organisation ist im Kapitel Organizing Service Operation beschrieben. Primäres Ziel des Service Desk ist die Wiederherstellung des normalen Service so schnell wie möglich (siehe auch Incident Management). Dies kann neben der Behebung eines technischen Fehlers ebenso die Erfüllung eines Service Requests bzw. grundsätzlich alles sein, was erforderlich ist, damit der Anwender seine Arbeit wieder so erledigen kann, wie dies sein Geschäftsprozess erfordert. Zur Verantwortung des Service Desk gehört auch die Dokumentation eingehender Incidents und Service Requests, deren Kategorisierung und Priorisierung, die Durchführung einer ersten Diagnose und Eskalationsschritte, falls vereinbarte Zeitgrenzen überschritten werden. Die seitens der ITIL Best Practices dokumentierten Key Performance Indikatoren sind zum Beispiel: Prozentsatz von Calls (Anrufen), deren Requests bzw. Störungen sofort während des ersten Kontaktes am Service Desk gelöst werden konnten Prozentsatz gelöster Calls ohne die Unterstützung anderer Gruppen Prozentsatz gelöster Calls mit Unterstützung anderer Gruppen. 45

57 2 IT Service Management Continual Service Improvement Continual Service Improvement The 7 Step Improvement Process Service Level Management The Business Questions for CSI Return on Investment (ROI) for CSI Service Reporting Service Measurement Abbildung 18: Continual Service Improvement The 7 Step Improvement Process Hier werden Fragen gestellt nach den Business Treibern hinter der ITIL- Implementierung, der finanziellen Bewertung von IT-Investitionen, dem Reifegrad, der Effektivität und Effizienz aktueller Prozesse, den Gaps und Problemen bei der Bereitstellung von Services, der Bewertung von Ressourcen (Time and Budget) zum Schließen der Lücken und schließlich nach den Ergebnissen der Aktivitäten beim Streben nach Service Improvement ROI. Der 7 Step Improvement Process umfasst die folgenden Forderungen: 1. Definieren, was gemessen werden soll 2. Definieren, was gemessen werden kann 3. Daten sammeln 4. Daten bearbeiten 46

58 5. Daten analysieren 2.5 ITIL Kennzahlen für IT Service Management-Prozesse 6. Informationen präsentieren und nutzen 7. Korrekturen durchführen Abbildung 19 aus Continual Service Improvement (vgl. [OGC, 2007e]) veranschaulicht diesen Prozess: Identifiziere: Vision Strategie Taktische Ziele Operative Ziele 1. Definiere, was Du messen solltest 7. Implementiere Korrekturmaßnahmen 6. Präsentiere und nutze die Informationen Ziele 2. Definiere, was Du messen kannst 3. Sammle Daten 5. Analysiere Daten 4. Bearbeite Daten Abbildung 19: 7 Step Improvement Prozess Key Performance Indikatoren sind zu diesem Prozess nicht ausgeführt, sondern allgemeine Anforderungen an die Metriken. Dabei wird unterschieden zwischen technischen Metriken und Metriken für Prozesse und Services. Technische Metriken sind häufig mit den eingesetzten Komponenten und Applikationen verbunden und betrachten technische Aspekte wie Performance, Verfügbarkeit etc. Prozess Metriken erfassen CSFs, KPIs und Messgrößen für Tätigkeiten der Service Management-Prozesse. Diese Metriken ermöglichen eine Beurteilung der Prozesse. Die Metriken sollten die vier Aspekte Qualität, Performance, Nutzen und Compliance abdecken. Service Metriken sind das Ergebnis einer end-to-end Betrachtung der Services. 47

59 2 IT Service Management Innerhalb The 7 Step Improvement sind allgemeine Fragestellungen hinsichtlich der Definition von KPIs dokumentiert: Was sagt uns der KPI über die Zielerreichung aus? Wie leicht ist es, den KPI zu interpretieren? Wann brauchen wir die Information? Wie oft? Wie rasch sollte die Information verfügbar sein? In welchem Maß ist der KPI stabil und genau? Ist er von externen unkontrollierbaren Einflüssen abhängig? Wie leicht ist es, den KPI selbst zu ändern? Wie leicht ist es, das Maßsystem an sich verändernde Umstände anzupassen oder Änderungen in Bezug zu den Zielen durchzuführen? Wer ist der Owner des KPIs? Wer ist verantwortlich für das Sammeln und die Analyse der Daten? Wer ist für Verbesserungen basierend auf den gewonnenen Informationen verantwortlich? Service Reporting Das Service Reporting liefert die notwendigen korrekten Berichte, die den Kundenerwartungen entsprechen. Aus der Vielzahl der vorliegenden Daten sind hierzu die Daten so aufzubereiten, dass das Business die notwendigen Informationen erhält. Dazu gehört auch die Berichterstattung der letzten Periode. Key Performance Indikatoren sind zu diesem Prozess nicht ausgeführt. Service Measurement Das Service Measurement stellt sicher, dass die Services bezüglich der Aspekte der Verfügbarkeit (Availability), Zuverlässigkeit (Reliability) und Performance gemessen werden können. Dabei ist die Kundensicht auf den Service ( end-to-end) von großer Bedeutung, da hiervon die Geschäftsprozesse des Business abhängig sind. Als Key Performance Indikatoren für das Service Management werden aus Kundensicht demzufolge herausgestellt: Verbesserte Verfügbarkeit (durch Service / Systems / Applikationen) Verringerung der Service Level Verletzungen (durch Service / Systems / Applikationen) Verringerung mean time to repair (gemessen anhand von Prioritäten) Verringerung Major Incidents 48

60 Return on Investment (ROI) for CSI 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Um die Aufgabe des Return on Investments (ROI) für das Continual Service Improvement (CSI) erfüllen zu können, sind viele Faktoren in Betracht zu ziehen. Auf der einen Seite sind dies die Kosten für die Durchführung dieser Phase des Service Lifecyle, bestehend zum Beispiel aus den Personalkosten, Tools, Beratungskosten, etc. Auf der anderen Seite ist zu bewerten, welche geschäftlichen Vorteile durch diese Tätigkeiten erzielt werden. Letztlich geht es um eine geschäftliche ROI Betrachtung. Daher sind die Vorteile auch nicht nur aufseiten der IT zu bewerten, sondern primär aus Sicht des Business. Eine mögliche Betrachtung wäre zum Beispiel die Kosten von Ausfallzeiten auf der Seite des Business. Key Performance Indikatoren sind zu diesem Prozess nicht ausgeführt The Business Questions for CSI Die Business Integration von ITIL Version 3 wird auch dadurch zum Ausdruck gebracht, dass das Business in das Continual Service Improvement einzubinden ist. Mögliche Verbesserungen sind dahingehend zu bewerten, welche Maßnahmen den größten Vorteil für das Business mit sich bringen. Hierzu ist zu bewerten Wo stehen wir heute? und gemeinsam zu definieren Was wollen wir? Key Performance Indikatoren sind zu diesem Prozess nicht ausgeführt. Service Level Management Service Level Management ist ein für das CSI kritischer und wichtiger Prozess. Das Service Level Management entscheidet darüber, was gemessen wird, welche Anforderungen an die Überwachungen gestellt werden, wie das Erreichen von Service Level berichtet wird und wo mit dem Business bei neuen Service Requests oder Änderungen an existierenden Services zusammengearbeitet wird. So werden die Aktivitäten des CSI unterstützt und Verbesserungsprojekte priorisiert. Das Service Level Management stellt einen wichtigen Trigger für den Service Plan (SIP) dar. Key Performance Indikatoren sind zu diesem Prozess nicht ausgeführt. 49

61 2 IT Service Management 2.6 ISO Nach der umfassenden Akzeptanz und Verbreitung der ITIL Best Practices innerhalb von IT-Organisationen geht das Thema Professionelle Serviceorientierung in der IT in die nächste Runde. Mit der seit dem 15. Dezember 2005 gültigen ISO Information Technology - Service Management haben IT-Organisationen nun erstmalig die Möglichkeit, ihre IT Service Management-Prozesse durch eine unabhängige Auditierungs-Organisation auf der Basis einer internationalen Qualitätsnorm zertifizieren zu lassen. Mit dieser Norm wird dem steigenden Bedarf des Nachweises eines wirksamen IT Service Managements Rechnung getragen. In diesem Zusammenhang muss nochmals die Zielsetzung von ITIL herausgestellt werden. Innerhalb der IT Infrastructure Library sind bewährte Vorgehensweisen (Best Practices) dokumentiert. Sie sind als Leitfaden (Guidelines) für die Implementierung von IT Service Management-Prozessen gedacht. Dabei bleibt es den Organisationen überlassen, wie und in welchem Maße dieser Leitfaden zur Gestaltung der unternehmensspezifischen IT Service Management-Prozesse genutzt wird. Aufgrund der steigenden internationalen Anerkennung und Nutzung wird ITIL auch als De-facto-Standard für das IT Service Management bezeichnet und zum Teil irrtümlich als Standard im Sinne einer Norm verstanden. ITIL ist kein Standard im Sinne einer Norm. Eine ITIL Zertifizierung für Organisationen ist nicht möglich. Demzufolge können die implementierten IT Service Management-Prozesse einer IT-Organisation nicht nach ITIL zertifiziert werden. Nur Personen können sich auf Basis der ITIL Best Practices zertifizieren lassen. Damit wird das Know-how der Person um die ITIL Best Practices dokumentiert. Der Nachweis ITIL-zertifizierter Mitarbeiter ist jedoch noch keine Garantie dafür, dass die IT Service Management-Prozesse tatsächlich implementiert sind und den Mindestanforderungen genügen, zumal in den ITIL Best Practices keine Mindestanforderungen spezifiziert sind. Daher wurde mit der ISO IT Service Management eine gemeinsame internationale Referenz (Norm) für alle IT-Organisationen bereitgestellt, die IT Services für interne oder externe Kunden erbringen. 50

62 2.6 ISO Die ISO beinhaltet sämtliche Aspekte, die für IT-Organisationen gültig sind und die es umzusetzen gilt. Die ISO kann so als international definierte Mindestanforderung an das IT Service Management angesehen werden. Mit der ISO existiert seit dem 15. Dezember 2005 eine international anerkennte Norm für das IT Service Management. Auf der Basis dieser Norm ist eine Zertifizierung der implementierten IT Service Management-Prozesse einer Organisation möglich. Eine Zertifizierung von Organisationen ist nur auf Basis der ISO möglich In einer Analyse kommt Gartner zu dem Ergebnis, dass " bis Ende 2008 mindestens 60 % der relevanten Beschaffungsvorhaben der öffentlichen Hand und mindestens 30 % des privaten Sektors in entwickelten Volkswirtschaften eine ISO Zertifizierung verlangen werden" (vgl. [Gartner, 2006]) Die Geschichte der ISO Die im September 2005 veröffentliche ISO geht zurück auf einen British Standard, den BS (vgl. [BS , 2002] und [BS , 2002]). Bereits auf der Basis des BS konnte das IT Service Management einer IT-Organisation zertifiziert werden. Die erste Version des BS wurde im November 2000 veröffentlicht. An der Definition dieses Standards haben die Autoren der ITIL Best Practices maßgeblich mitgewirkt. Dadurch ist eine weitgehende Überstimmung zwischen den ITIL Best Practices für das IT Service Management und BS bzw. ISO sichergestellt. Auch viele deutsche Unternehmen, wie zum Beispiel die Siemens AG IT Operations (ITO), haben auf Basis des BS ihr IT Service Management zertifizieren lassen. Da es sich aber um einen Britischen Standard handelt und die dort beschriebenen Ansätze internationale Anerkennung finden sollten, wurde der BS in die ISO übergeleitet. Die dabei durchgeführten Änderungen waren sehr gering, sodass die ISO weitestgehend dem BS entspricht Der Aufbau der ISO Die ISO besteht aus den beiden Dokumenten ISO und ISO Der erste Teil der Norm ISO : Specification (vgl. [ISO , 2005]) enthält die formelle Spezifikation des Standards. In der ISO sind die Vorgaben dokumentiert, die eine Organisation einhalten, sicherstellen und nachweisen muss, um die Zertifizierung zu erhalten. Die ISO enthält die Muss-Anforderungen 51

63 2 IT Service Management ISO enthält die Soll-Anforderungen ITIL und ISO stehen nicht im Wettbewerb, sondern ergänzen sich zweckmäßig ISO enthält die Muss-Kriterien des Standards und umfasst inklusive Deckblatt und Inhaltsverzeichnis insgesamt 36 Seiten. Teil zwei der Norm ISO : Code of Practice (vgl. [ISO , 2005]) ergänzt die Anforderungen des ersten Teils um Erläuterungen. Die ISO bietet die Leitlinien und die Empfehlungen für IT Service Management-Prozesse im Rahmen des formellen Standards. Die ISO umfasst 44 Seiten. Anhand des Umfangs der Dokumentation kann die Zielsetzung der ISO leicht nachvollzogen werden. Die Norm definiert Anforderungen an die Prozesse (ISO ) und Umsetzungsempfehlungen (ISO ), liefert aber keine generischen Prozessbeschreibungen, wie sie durch die ITIL Best Practices zur Verfügung gestellt werden. Als Beispiel hierzu soll das Service Level Management dienen. Die ISO fordert für das Service Level Management unter anderem, die IT Services mittels SLAs zu definieren und zu vereinbaren (vgl. [ISO , 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 enthält Empfehlungen zu den Inhalten der SLAs (vgl. [ISO , 2005], Kapitel Service Level Agreements ): The minimum content that should be in an SLA or that can be directly referenced from an SLA is: brief service description; validity period and/or SLA change control mechanism; authorization details.. Die ITIL Best Practices beschreiben dagegen die Prozessaktivitäten zur Definition und Vereinbarung von SLAs (vgl. [OGC, 2005b], Kapitel Planen der SLA-Struktur ): muss das Service Level Management eine SLA Struktur planen, die am besten geeignet ist, sicherzustellen, dass alle Services. Wie das Beispiel zeigt, stehen die ITIL Best Practices und die ISO nicht in Konkurrenz zueinander, sondern ergänzen sich zweckmäßig. Ungeachtet einer möglichen Zertifizierung liefern die ITIL Best Practices Guidelines zum Aufbau der IT Service Managements. Die notwendigen IT Service Management-Prozesse werden beschrieben, Rollen definiert, Dokumente wie SLAs, RFCs werden beschrieben, kritische Erfolgsfaktoren identifiziert und mögliche Leistungsindikatoren beschrieben. Mithilfe von ITIL können Organisationen wirkungsvoll und mit einer größeren Planungssicherheit ihr IT Service Management etablieren. IT-Organisationen, die die ITIL Best Practices als Leitfaden zum Design ihrer IT Service Management-Prozesse nutzten, haben so eine gute Basis für eine ISO Zertifizierung geschaffen. Die ISO definiert Mindestanforderungen und hilft dadurch, sich zunächst auf die Mindestanforderungen zu konzentrieren. Hierzu die Presseerklärung des Flughafens München zur er- 52

64 2.6 ISO folgreichen ISO Zertifizierung um die Prozessneugestaltung mit der erforderlichen Motivation durchzuführen, wurde die Zertifizierung des Servicebereichs nach BS15000 (jetzt ISO 20000) als Meilenstein definiert. Die Zertifizierung als erste Zielmarke zu definieren, um einerseits das Augenmerk des Bereichsmanagements und aller betroffenen Mitarbeiter klar zu fokussieren, andererseits die Bearbeitungstiefe in den Prozessen zu begrenzen und eine pragmatische 'Flughöhe' zu halten, erwies sich dabei als sehr hilfreich und gab allen beteiligten Mitarbeitern eine klare Zielorientierung (vgl. [KESS, 2006a]). Die ITIL Version 2 ist nicht mit der ISO gleichzusetzen. Es lassen sich strukturelle Unterschiede zwischen den ITIL Best Practices der Version 2 und der ISO 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 gefordert werden. Allerdings sind in der ITIL Version 3 die Prozesse gegenüber der ISO erweitert worden, wie zum Beispiel durch die Aufteilung des alten Incident Managements in Incident Management und Request Fulfilment. Ungeachtet dieser geringfügigen Unterschiede lassen sich die Anforderungen der ISO mit der ITIL Version 3 einfacher umsetzen. Die ISO definiert die Mindestanforderungen an das IT Service Management, die ITIL Best Practices liefern hierzu generische Prozessbeschreibungen Die Inhalte der ISO In der ISO (Specification) und der ISO (Code of practice) sind die zu implementierenden IT Service Management-Prozesse sowie die übergeordneten Prozesse und Aufgaben dokumentiert. Insbesondere mit den Anforderungen an ein übergeordnetes Managementsystem enthält die ISO eine wichtige Ergänzung zu ITIL Version 2. Mit der ITIL Version 3 ist mit der Service Strategy und dem Continual Service Improvement das übergeordnete Managementsystem ebenfalls beschrieben. Explizit fordert die ISO einen strategischen Planungsprozess für das IT Service Management. Er soll unter anderem kurz-, mittel und langfristige Planungen miteinander vereinen. Damit wird die Integration des IT Service Managements in die IT-Strategie sichergestellt. Innerhalb der folgenden Abbildung 20 werden die geforderten IT Service Management-Prozesse, ergänzt um das übergeordnete Managementsystem der ISO 20000, dargestellt (vgl. [ISO , 2005]). 53

65 2 IT Service Management Anforderungen an ein Management System Planung und Implementierung des Service Managements Planen und Implementieren neuer oder geänderter Services Capacity Management Service Continuity and Availability Management Release Prozesse Release Management Service Delivery Prozesse Service Level Management Service Reporting Control Prozesse Configuration Management Change Management Resolution Prozesse Incident Management Problem Management Information Security Management Budgeting and accounting for IT services Relationship Prozesse Business Relationship Management Supplier Management Abbildung 20: IT Service Management-Prozesse der ISO Unternehmen, die eine ISO Zertifizierung anstreben, müssen sämtliche dargestellten Prozesse implementieren. Eine Zertifizierung für einzelne Prozesse ist nicht möglich. Dagegen können einzelne IT-Bereiche zertifiziert werden, sofern in diesen Bereichen sämtliche Prozesse verantwortlich durchgeführt werden Die ISO und Kennzahlen Innerhalb der ISO werden keine Kennzahlen für die IT Service Management-Prozesse vorgeben bzw. empfohlen. Die ISO verlangt allerdings eine Etablierung der Prozessverantwortung und das Prozess-Management (Management Control) für sämtliche IT Service Management-Prozesse. Es ist innerhalb der eigenen Organisation für alle Prozesse der ISO nachzuweisen: Kenntnis und Steuerung des Inputs Kenntnis, Nutzung und Interpretation des Outputs Festlegung und Bewertung von Metriken Objektiver Nachweis über die Prozessfunktionalität in Übereinstimmung mit der Norm ISO

66 2.6 ISO Bestimmung, Messung und Prüfung von Prozessverbesserungen (Service Improvement Plan) Die geforderte Kenntnis des Inputs / Outputs sowie die Festlegung und Bewertung von Metriken hat zur Folge, dass für sämtliche IT Service Management-Prozesse Kennzahlen zu definieren sind. Hinzu kommt, dass der kontinuierliche Verbesserungsprozess integraler Bestandteil der ISO ist. Hierzu wird in der Norm die Plan-Do- Check-Act-Methodik beschrieben (aus [van Bon, 2006], vgl. Abbildung 21). Management von Services Management von Verantwortlichkeiten PLAN Planen des Service Managements DO ACT Implementieren des Kontinuierliche Service Managements Verbesserung CHECK Überwachung, Messen und Review Geschäfts- Anforderungen Kunden- Anforderungen Anforderungen neue/geänderte Services Weitere Prozesse, z.b. Geschäfts-, Lieferanten-, Kundenprozesse Service Desk Weitere Teams, z.b. Security, IT-Betrieb Geschäfts- Ergebnisse Kunden- Zufriedenheit Neue oder geänderte Services Weitere Prozesse, z.b. Geschäfts-, Lieferanten-, Kundenprozesse Zufriedenheit im Team und bei den Beteiligten insgesamt Abbildung 21: PDCA-Methodik Dieser kontinuierliche Verbesserungsprozess ist nicht nur für die übergeordneten Managementaufgaben, sondern auch für die einzelnen IT Service Management-Prozesse zu etablieren. Wie in Kapitel 3 IT Prozess-Management ausgeführt, ist die Messung von Prozessen die unabdingbare Voraussetzung dafür, deren Wirksamkeit sicherzustellen (vgl. [van Bon, 2006]): You cannot control what you cannot measure. 55

67 2 IT Service Management Im Rahmen einer ISO Zertifizierung werden Prozesskennzahlen überprüft. Im Rahmen einer ISO Zertifizierung muss dieser Nachweis für sämtliche IT Service Management-Prozesse sowie für das übergeordnete Managementsystem erbracht werden. Dabei wird von der Zertifizierungsorganisation auch überprüft, wie die ermittelten Kennzahlen mit den Zielen korrespondieren und welcher Handlungsbedarf aus den Kennzahlen abgeleitet werden kann. Die Anforderungen und Empfehlungen der ISO hinsichtlich Monitoring und Reporting von SLAs beschreiben wir in Kapitel Monitoring und Reporting von SLAs, OLAs und UCs. 2.7 COBIT Je bedeutender und kritischer die IT-Unterstützung für die Geschäftsprozesse einer Organisation ist, umso wichtiger ist der Einsatz eines geeigneten Steuerungsinstruments für die Aktivitäten der IT. Vor diesem Hintergrund wurde COBIT (Control Objectives for Information and Related Technology) als Steuerungsmodell der gesamten IT konzipiert. Ursprünglich wurde COBIT von der Information Systems Audit and Control Foundation (ISACF) entwickelt, dem Forschungsinstitut der Information Systems Audit and Control Association (ISACA). Wie der Organisationsname bereits verrät, war COBIT speziell für den Einsatz bei Wirtschaftsprüfern vorgesehen. Aufgrund der Ausrichtung an der Auditierung liegen die Stärken von COBIT naturgemäß in den definierten Steuerungszielen, und insbesondere in der damit verbundenen Überprüfung und Auditierung von IT-Prozessen. Vergleichbar mit den ITIL Best Practices konzentriert sich COBIT darauf, zu dokumentieren Was erreicht werden soll. Dabei wird in COBIT ausdrücklich betont, dass die praktische Ausgestaltung organisationsspezifisch und durch die Integration mit anderen eingesetzten Methoden und Verfahren erfolgen sollte (vgl. [COBIT, 2005]). Häufig wird COBIT im Zusammenhang mit IT Governance genannt. Es existiert keine einheitliche Definition des Begriffs IT Governance. Allgemein werden unter dem Thema IT Governance Grundsätze, Verfahren und Maßnahmen zusammengefasst, die sicherstellen, dass mit Hilfe der eingesetzten IT die Geschäftsziele abgedeckt, die Ressourcen verantwortungsvoll eingesetzt und Risiken angemessen überwacht werden. COBIT, aber auch die ITIL Best Practices, sollen diese Maßgaben der IT Governance sicherzustellen. ITIL Version 3 definiert den Begriff IT Governance und bezieht sich dabei auf eine Definition des IT Governance Instituts (vgl. [OGC, 2007e]): 56

68 2.7 COBIT IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership, organizational structures and processes that ensure that the organization s IT sustains and extends the organization s strategies and objectives. (Board Briefing on IT Governance, 2nd Edition, 2003, IT Governance Institute ITGI) Entwicklung von COBIT Auslöser für die Entwicklung von COBIT war der Wunsch, eine gemeinsame Basis für die Auditierung von IT-Organisationen innerhalb von Prüfungsorganisationen zu schaffen. Hierzu wurden analog zu der Entwicklung von ITIL entsprechende Best Practices von Experten unterschiedlicher Organisationen zusammengeführt und dokumentiert. Die erste Version von COBIT wurde bereits 1996 veröffentlicht. Mit der stärkeren Ausrichtung auf die IT Governance wurde die Weiterentwicklung im Jahr 1999 an das unabhängige IT Governance Institute übertragen. Bei der Entwicklung von Version 4.0 wurden unter anderem die ITIL Best Practices (vgl. [COBIT, 2004a] und [COBIT, 2004b]) und die ISO (vgl. [ISO 17799, 2005]) berücksichtigt, sodass diese verschiedenen Best Practices besser aufeinander abgestimmt sind. Speziell im Zusammenhang mit der Nachweispflicht des Sarbanes-Oxley Acts (SOX) 2 (vgl. [COBIT, 2006]) für an der amerikanischen Börse notierte Unternehmen hat die Nutzung von COBIT zugenommen. Bis zum Jahr 2008 soll die COBIT Version 5 entwickelt werden, wobei strategische Betrachtungen größere Berücksichtigung finden sollen als bisher. So ist unter anderem die Zusammenfassung von IT-Prozessen in einem Bereich (Domain) IT Governance geplant. Die im folgenden Kapitel beschriebenen Prozesse und Kennzahlen basieren auf der COBIT Version Struktur von COBIT Analog zu ITIL definiert COBIT Best Practices, die sicherstellen, dass die eingesetzte IT die Geschäftsziele unterstützt, dass Ressourcen verantwortungsvoll eingesetzt und Risiken angemessen überwacht werden. COBIT sind Best Practices. 2 Der Sarbanes-Oxley Act wurde benannt nach seinen Verfassern, dem Senator Paul S. Sarbanes und dem Abgeordneten Michael Oxley, die ein Gesetz zur Verschärfung der Rechnungslegungsvorschriften in Folge der Bilanzskandale von Unternehmen wie Enron oder Worldcom erließen. 57

69 2 IT Service Management Speziell beim Aufbau eines internen Steuerungssystems in der IT und bei der Messung der Zielerreichung soll COBIT die zuvor genannten Aufgaben der IT Governance unterstützen. COBIT identifiziert und dokumentiert insgesamt 34 Prozesse, die für ein erfolgreiches Management der IT erforderlich sind. Diese 34 IT-Prozesse werden in vier übergeordneten Domains gruppiert, die einen geschlossenen Lebenszyklus (Life Cycle) bilden (vgl. [COBIT, 2005], Abbildung 22): Prozesse - Überwache und bewerte IT-Performance - Überwache und bewerte interne Controls - Stelle die angeordnete Compliance sicher - Sorge für IT-Governance ME: Monitor and Evaluate Prozesse - Def. u. Manage Service Level - Manage Services von Dritten - Manage Performance und Kapazitäten DS: Deliver - Manage kontinuierliche and Support Services - Stelle Systemsicherheit sicher - Identifiz. u. verrechne Kosten - Schule u. trainiere Anwender - Manage Service Desk und Incidents - Manage die Konfigurationen - Manage Probleme - Manage Daten - Manage technisches Umfeld - Manage den Betrieb Geschäftsziele PO: Plan and Organise AI: Acquire and Implement Prozesse - Definiere stragischen IT-Plan - Def. Informationsarchitektur -Def. technolog. Ausrichtung - Definiere die IT-Prozesse, Organisation, Beziehungen - Manage IT-Investitionen - Kommuniziere Ziele und Ausrichtung des Mgmts. - Manage IT-Personal- Ressourcen - Manage die Qualität - Beurteile und Manage die Risiken - Manage Projekte Prozesse - Identifiziere automatisierte Lösungen - Beschaffe und warte Anwendungssoftware - Beschaffe und warte technische Infrastruktur - Ermögliche Betrieb und Nutzung - Beschaffe IT-Ressourcen - Manage Changes - Installiere u. genehmige Lösungen und Changes Abbildung 22: COBIT Prozess-Übersicht 58

70 2.7 COBIT Für jeden der 34 IT-Prozesse dokumentiert COBIT die jeweilige Best Practice in folgender Form: Generische Prozessbeschreibung Prozessziele Wichtigste Aktivitäten Input und Output des Prozesses Mögliche organisatorische Verantwortlichkeiten Wichtigste Metriken Verknüpfte IT-Ziele Zusätzlich bietet COBIT die Möglichkeit, den Reifegrad dieser Prozesse zu bestimmen. Hierzu sind zu jedem Prozess die Reifegradanforderungen spezifiziert Prozess-Management gemäß COBIT In COBIT sind für jeden Prozess Control Objectives definiert. COBIT versteht Control Objectives als Minimalanforderungen für ein wirkungsvolles Prozess-Management (vgl. [COBIT, 2005]). Control wird häufig mit Kontrolle übersetzt, wodurch die eigentliche Bedeutung der Steuerung bzw. des Managements verfälscht wird. Aus diesem Grund wird im Folgenden der englische Begriff verwendet. Control Objectives dienen der Steuerung, nicht der Kontrolle Die Control Objectives dokumentieren das Ziel oder den Zweck eines Prozesses und definieren so die Mindestanforderung, die zu erreichen ist. Pro Prozess existiert immer ein übergeordnetes Control Objective. Die Prozesse sind so bezeichnet, dass sich das übergeordnete Control Objective direkt aus dem Prozessnamen ergibt. Zu jedem Prozess stellt COBIT eingangs das übergeordnete Control Objective gemeinsam mit den wichtigsten Prozesszielen und Metriken dar. Zusätzlich sind anschließend zu jedem Prozess mehrere daraus abgeleitete, detaillierte Control Objectives beschrieben. Diese detaillierten Control Objectives können als Best Practice für das Management des jeweiligen Prozesses angesehen werden. Es sind Minimalanforderungen, die die Zielerreichung sicherstellen. Beispiel Manage Changes (AI6 Manage Changes): Innerhalb des übergeordneten Control Objective wird als Zielsetzung für das Manage Changes gefordert, dass sämtliche Changes an der Infrastruktur und den Applikationen in der produktiven Umgebung nach standardisierten Methoden und Verfahren vorgenommen werden. Zu diesen Changes zählen auch Notfall-Changes und Patches. Jeder Change muss vor der Implementierung aufgezeichnet, bewertet und autorisiert 59

71 2 IT Service Management sowie nach der Implementierung anhand der geplanten Ergebnisse überprüft werden. Diese Aktivitäten schließen Changes an Verfahren, an Prozessen, an Systemen und an Services ein. Durch diese Aktivitäten sollen die Risiken von Changes minimiert werden, die sich negativ auf die Stabilität und Integrität der Produktivumgebung auswirken. COBIT definiert für den Prozess Manage Changes insgesamt 6 detaillierte Control Objectives. Ein detailliertes Control Objective lautet Notfall Changes (AI6.3: Emergency Changes). Dieses Control Objective fordert, einen Prozess für die Definition, Aufnahme, Beurteilung und Genehmigung von Notfall-Changes zu erstellen. Dokumentationen und Tests können unter Umständen auch nach der Implementierung erfolgen. Die folgende Abbildung 23 (textuell angelehnt an [COBIT, 2005]) stellt die detaillierten Control Objectives für den Prozess Manage Changes dar. AI6: Manage Changes AI6.1: Standard-Changes und Prozeduren AI6.2: Bewertung von Auswirkungen, Priorisierung und Freigabe AI6.3: Notfall-Changes AI6.4: Statusverfolgung und Reporting AI6.5: Abschluss und Dokumentation Abbildung 23: Zusammenhang zwischen Control Objectives in COBIT Die COBIT Control Objectives sind den Prozesszielen und Prozessaufgaben der ITIL Best Practices gleichzusetzen. Durch definierte Prozessaktivitäten soll sichergestellt werden, dass die Control Objectives erreicht werden, was gleichbedeutend damit ist, dass der Prozess die gewünschten Zwecke erfüllt. 60

72 2.7 COBIT Während ITIL die Leistungsindikatoren der Prozesse pauschal als Key Performance Indikators (KPIs) bezeichnet, betrachtet COBIT die Leistungsmessung der Prozesse als Performance Messung und unterscheidet bei den Metriken zwischen den Key Goal Indicators (KGIs) und den Key Performance Indicators (KPIs). Mit den KGIs wird gemessen, ob ein Prozess seine definierten Ziele erreicht (Effektivität). KGIs sind daher an dem jeweiligen Prozess-Output orientiert. Mit den KPIs wird dagegen die Leistungsfähigkeit eines Prozesses in Relation zu den eingesetzten Ressourcen gemessen (Effizienz). Der Fokus der KPIs liegt also auf einer Messung der prozessinternen Aktivitäten. Die KGIs sind demzufolge die wichtigeren Kennzahlen für die Bewertung eines Prozesses, da sie dem Management aufzeigen, ob ein Prozess die definierten Anforderungen erfüllt. COBIT gliedert die Performance- Messung in Kriterien für Effektivität und Effizienz Die KGIs messen die Effektivität eines Prozesses, während die KPIs die Effizienz betrachten. Hauptaugenmerk sollte zunächst auf den KGIs liegen. COBIT beschreibt aber nicht nur Metriken für die einzelnen IT-Prozesse, sondern legt auch Ziele und Metriken für den gesamten IT-Bereich fest. Dabei werden die Ziele und Metriken von den Geschäftsanforderungen bestimmt. Die Vorgehensweise erfolgt top down. Aus den Geschäftsanforderungen ergeben sich die Ziele für den IT-Bereich. Diese übergeordneten Ziele bestimmen dann die jeweiligen Prozessziele und mit den Prozesskennzahlen (KGIs, KPIs) erfolgt die Messung, ob die Prozesse die Zielsetzungen erfüllen. Prozessziele und Kennzahlen für Prozesse werden top down definiert. Sie ergeben sich aus den IT-Zielen aus den Geschäftsanforderungen. Die Messgrößen für die übergeordneten IT-Ziele bezeichnet COBIT als IT Key Goal Indicators. Da die Prozessziele mit den übergeordneten IT-Zielen korrespondieren bzw. aus ihnen abgeleitet werden, stehen die Prozesskennzahlen mit den IT Key Goal Indicators in einem unmittelbaren Zusammenhang. Bei den Metriken auf Basis der COBIT Best Practices wird so aus dem KGI für die Prozessmessung ein KPI für die Messung der IT-Ziele. COBIT definiert dies als Performance Messung. So ist zum Beispiel Nacharbeiten an Applikationen, die durch mangelnde Spezifikation hervorgerufen werden ein KGI für den Prozess Manage Changes. Für das zugeordnete IT-Ziel Reduziere Mängel und Nacharbeiten bei Lösungen und dem Servicebetrieb ist diese Kennzahl dagegen ein KPI. 61

73 2 IT Service Management COBIT definiert KPIs und KGIs auf Ebene der Prozesse und der IT-Ziele. Dabei wird aus einem KGI der Prozessebene ein KPI auf Ebene der IT-Ziele. Die Metriken und deren Ebenen stellen sich in COBIT wie folgt dar (hier verdeutlicht am Beispiel Manage Changes, vgl. [COBIT, 2005], siehe Abbildung 24): Definierte Ziele Ziel der Aktivitäten Ziel des Prozesses Ziel der IT Messung der Zielerreichung Definition und Kommunikation der Verfahren für Changes inklusive Notfalländerungen - patches Werden gemessen durch Key Performance Indicators % der aufge-zeichneten und mit automatisierten Tools verfolgten Änderungen % der Änderungen, die formale Änderungskontrollpro zesse befolgen treiben treiben Führe genehmigte Änderungen an der IT-Infrastruktur und Anwendungen durch Bewerte die Auswirkungen der Changes auf die IT- Infrastruktur, Werden gemessen durch Key Goal Indicators % der nicht erfolgreichen Änderungen der Infrastruktur, die durch ungeeignete Änderungsspezifikationen hervorgerufen sind Reagiere auf Geschäftsanforderungen in Übereinstimmung mit der Unternehmensstrategie Reduziere Mängel und Nacharbeit bei Lösungen Werden gemessen durch IT Key Goal Indicators Anzahl der Unterbrechungen oder Datenfehler, die durch ungenaue Spezifikation oder unvollständige Beurteilung der Auswirkungen hervorgerufen ist KPI Metriken für Prozesse KGI KPI Metriken für IT-Ziele KGI Abbildung 24: Ziele, Prozesse und Metriken in COBIT 62

74 2.7 COBIT Während COBIT Version 3.0 (vgl. [COBIT, 2000]) für die einzelnen Prozesse noch die kritischen Erfolgsfaktoren (Critical Success Factors, CSFs) dokumentierte, werden die CSFs in der Version 4.0 nicht mehr gesondert ausgewiesen. Die CSFs wurden aufgeteilt in die Input-Beschreibung ( was benötige ich von anderen ) und in die Aktivitätenbeschreibung ( was muss ich in meinem Prozess durchführen ). COBIT enthält darüber hinaus generelle Anforderungen an das Management von Prozessen. Die folgenden Kriterien sind für jeden Prozess zu erfüllen: Für jeden Prozess ist der Prozess Owner und dessen Verantwortung zu definieren Jeder Prozess muss wiederholbar sein Für die Prozesse sind klare Ziele und Vorgaben zu definieren Die Rollen, Aktivitäten und Verantwortlichkeiten sind zu definieren Die Prozesse sind hinsichtlich ihrer Zielerreichung zu messen Die dokumentierten, überprüften, aktuellen und unterzeichneten Grundsätze (Policy), Pläne und Verfahren sind allen Beteiligten zu kommunizieren. Die hier beschriebenen Best Practices von COBIT für das Prozess-Management stellen sich wie folgt dar (siehe Abbildung 25): Anforderung Prozessmanagement Control Objectives KPI KGI Prozess Input Ziele Output Aktivitäten Abbildung 25: Prozess, Ziele und Kontrollebenen in COBIT 63

75 2 IT Service Management Mit der Version 4.0 hat sich COBIT stärker an den ITIL Best Practices ausgerichtet. Es gilt, die Vorteile von ITIL und COBIT zu nutzen COBIT und die IT Service Management-Prozesse COBIT enthält relevante Prozesse und Metriken für den gesamten IT-Bereich. Die Prozesse, die innerhalb der ITIL Best Practices für das IT Service Management beschrieben sind, können als eine echte Teilmenge des Spektrums der in COBIT dargestellten Prozesse betrachtet werden. Die in COBIT beschriebenen Prozesse stehen somit nicht im Widerspruch zu den ITIL Best Practices. Mit der Veröffentlichung von COBIT Version 4.0 hat sich COBIT den ITIL Best Practices sogar noch weiter angenähert. Während in älteren Versionen von COBIT zum Beispiel das Incident und Problem Management in einem gemeinsamen Prozess beschrieben wurden, hat COBIT Version 4.0 die ITIL Prozessstruktur mit getrennten Prozessen für das Incident und Problem Management übernommen. Es geht daher nicht um den Wettstreit konkurrierender Best Practices, sondern vielmehr darum, wie die verschiedenen Best Practices konvergieren und gewinnbringend genutzt werden können. Die Vorteile und Stärken von ITIL liegen zum einen in der generischen und sehr ausführlichen Beschreibung von Prozessaktivitäten und in den Empfehlungen zur Gestaltung und Umsetzung der Prozesse. Zum anderen erhöht die enge Verbindung zur ISO die praktische Relevanz des ITIL Ansatzes. Bei der Prozessbeschreibung begnügt sich COBIT hingegen mit einer kurzen Aufzählung von Aktivitäten. Für den Prozess Manage Changes beispielsweise sind die Prozessaktivitäten in fünf Sätzen dokumentiert. COBIT liefert jedoch im Gegensatz zu ITIL, gute Ansätze für die Definition von Metriken, die zum Teil Wirtschaftsprüfern bekannt sind und bei einer Auditierung hilfreich sind. Während die Vorteile von ITIL in den Prozessbeschreibungen und Empfehlungen für die Umsetzung liegen, bietet COBIT gute Ansätze für Metriken. Die Prozesse für das IT Service Management stimmen in den Best Practices grundsätzlich überein, sodass aus beiden Ansätzen die Stärken zusammengeführt werden können. Eine Analyse der COBIT Best Practice und der IT Service Management- Prozesse auf Basis der ITIL Best Practices zeigt eine große Überstimmung von Prozessen und deren Ziele bzw. Aktivitäten (vgl. [Kurth, 2006]). Die übereinstimmenden IT Service Management-Prozesse zwischen den ITIL Best Practices Version 2 und COBIT wurden seitens des IT Governance Institute analysiert und dokumentiert (vgl. [COBIT, 2007]). Der fol- 64

76 2.7 COBIT genden Abbildung 26 können diese übereinstimmenden Prozesse für das IT Service Management entnommen werden. Innerhalb des dokumentierten Mappings zwischen ITIL und COBIT wird der Prozess DS 5 Stelle Systemsicherheit sicher nicht als übereinstimmend ausgewiesen. Im Rahmen der ISO ist aber das Security Management als Prozess des IT Service Managements definiert. Daher wurde in der folgenden Darstellung aus [COBIT, 2007] (Abbildung 26) der Prozess DS 5 Stelle Systemsicherheit sicher ebenfalls hervorgehoben. Prozesse - Überwache und bewerte IT-Performance - Überwache und bewerte interne Controls - Stelle die angeordnete Compliance sicher - Sorge für IT-Governance ME: Monitor and Evaluate Prozesse - Def. u. Manage Service Level - Manage Services von Dritten - Manage Performance und Kapazitäten DS: Deliver - Manage kontinuier- and 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 Geschäftsziele PO: Plan and Organise AI: Acquire and Implement Prozesse - Definiere stragischen IT-Plan - Def. Informationsarchitektur - Def. technolog. Ausrichtung - Definiere die IT-Prozesse, Organisation, Beziehungen - Manage IT-Investitionen - Kommuniziere Ziele und Ausrichtung des Mgmts. - Manage IT-Personal- Ressourcen - Manage die Qualität - Beurteile und Manage die Risiken - Manage Projekte Prozesse - Identifiziere automatisierte Lösungen - Beschaffe und warte Anwendungssoftware - Beschaffe und warte technische Infrastruktur - Ermögliche Betrieb und Nutzung - Beschaffe IT-Ressourcen - Manage Changes - Installiere u. genehmige Lösungen und Changes Abbildung 26: Mapping der Prozesse in ITIL Version 2 und COBIT 65

77 2 IT Service Management Mit der ITIL Version 3 wird eine noch größere Abdeckung erreicht. Ein entsprechendes Mapping ist aber zurzeit noch nicht publiziert Metriken für IT Service Management-Prozesse Zu jedem Prozess sind in Klammern die Originalbezeichnung, die übergeordnete Domain, sowie die Nummer innerhalb der Domain dargestellt. Die Bezeichnungen der Domains lauten folgendermaßen: - Plan and Organise (PO) - Acquire and Implement (AI) - Deliver and Support (DS) - Monitor and Evaluate (ME). Aufgrund des generischen Ansatzes werden in COBIT zweckmäßige KGIs und KPIs aufgezeigt. Die konkrete Ausgestaltung der Metriken mit detaillierten Spezifikationen und die Bedeutung für das Prozess-Management sind dagegen nicht in COBIT dokumentiert. Diese Festlegungen und Ausgestaltungen sind Aufgabe des Prozessdesigns. In Kapitel 5 sind die Best Practices auf der Basis von ITIL, COBIT, ISO und unserer Projekterfahrungen dokumentiert. Für die Definition von Metriken hat COBIT pragmatische Anforderungen: Es ist ein gutes Verhältnis zwischen Aussagekraft und Aufwand zur Generierung der Messdaten sicherzustellen. Es ist besser, wenige gute Metriken zu etablieren, als umfangreiche Kennzahlen mit einer niedrigen Qualität. Die Kennzahlen sollten extern vergleichbar sein. Die Kennzahlen sollten intern vergleichbar sein Im folgenden Abschnitt werden die in COBIT dokumentierten Prozessziele und die daraus resultierenden KPIs und KGIs ausgewiesen (vgl. [COBIT, 2005]) COBIT Metriken für IT Service Management-Prozesse Manage Service Desk und Incidents (Manage Service Desk and Incidents: DS8) Zielsetzung dieses Prozesses ist die wirkungsvolle Nutzung der IT-Systeme durch die Lösung und Analyse von Anwenderanfragen und Incidents. Zur Zielerreichung ist die Etablierung eines Service Desks und eines Incident Managements notwendig. Die in COBIT dokumentierten KPIs sind: 66

78 2.7 COBIT Anzahl der pro Mitarbeiter im Service Desk stündlich bearbeiteten Anrufe (Calls) Anteil der Incidents, die einen Vor-Ort-Support benötigen Arbeitsrückstand ungelöster Anfragen Die in COBIT dokumentierten KGIs sind: Durchschnittliche Bearbeitungszeit nach Gewichtung (severity) Anteil wieder geöffneter (reopen) Incidents Durchschnittliche Reaktionszeit Die in COBIT dokumentierten IT Key Goal Indicators sind: Anwenderzufriedenheit mit dem Service Desk Anteil der innerhalb der vereinbarten Zeit gelösten Incidents Manage Probleme (Manage Problems: DS10) Das Ziel des Problem Managements ist die Gewährleistung der Anwenderzufriedenheit und die Reduzierung von Mängeln an Services. Dies soll durch die Ermittlung der zugrunde liegenden Ursachen für alle wichtigen Probleme und durch die Definition von Lösungen für die identifizierten Probleme erreicht werden. Die in COBIT dokumentierten KPIs sind: Durchschnittliche Dauer zwischen Problemerfassung und der Identifizierung der Ursache Anteil der Probleme, für die eine Ursachenanalyse betrieben wurde Häufigkeit der Berichte oder Aktualisierung über anhaltende Probleme, basierend auf deren Gewichtung (severity) Die in COBIT dokumentierten KGIs sind: Anteil der Probleme, die innerhalb der vorgeschriebenen Zeit gelöst wurden Mittelwert und Standardabweichung der Zeitdauer zwischen der Identifizierung und der Problemlösung Mittelwert und Standardabweichung der Zeitdauer zwischen der Problemlösung und dem Abschluss Die in COBIT dokumentierten IT Key Goal Indicators sind: Anzahl der wiederkehrenden Probleme mit Auswirkung auf das Business Anzahl der Geschäftsunterbrechungen aufgrund operationeller Probleme 67

79 2 IT Service Management Manage die Konfigurationen (Manage the configuration: DS9) Das Configuration Management hat die Optimierung der IT-Infrastruktur, der Ressourcen und Kapazitäten sowie den Nachweis der IT-Anlagen zum Ziel. Basis hierfür ist die fehlerfreie und vollständige Erfassung und Speicherung der Konfigurationsattribute der IT-Anlagen und der Baselines, sowie die Prüfung, ob sie mit den tatsächlichen Konfigurationen übereinstimmen. Die in COBIT dokumentierten KPIs sind: Anzahl der Abweichungen in Bezug auf unvollständige oder fehlende Konfigurationsinformationen Durchschnittliche Zeitdauer zwischen der Identifizierung einer Abweichung und deren Korrektur Die in COBIT dokumentierten KGIs sind: Anzahl der Abweichungen zwischen den gespeicherten und tatsächlichen Konfigurationsdaten Anteil der erworbenen Lizenzen und der nicht in der Datenbank gespeicherten Lizenzen Die in COBIT dokumentierten IT Key Goal Indicators sind: Anteil der Compliance Probleme aufgrund unzulässiger Konfigurationen von IT-Anlagen Manage Changes (Manage Changes: AI6) Das Ziel des Manage Changes ist, Änderungen innerhalb der Produktivumgebung auf eine formell gesteuerte Art und Weise durchzuführen. Zu Changes zählen neben Änderungen an der Infrastruktur und an bestehenden Anwendungen auch Notfall-Changes und Patches. Die in COBIT dokumentierten KPIs sind: Verhältnis zwischen den akzeptierten und den abgelehnten RFCs Anzahl und Art der Notfall-Changes Anzahl und Art der Patches Die in COBIT dokumentierten KGIs sind: Anteil der Notfall-Changes am gesamten Change-Aufkommen Reduzierter Aufwand und Zeitaufwand zur Durchführung von Changes Anteil nicht erfolgreicher Changes, aufgrund von untauglichen Change-Spezifkationen Die in COBIT dokumentierten IT Key Goal Indicators sind: 68

80 2.7 COBIT Anteil der Serviceunterbrechungen durch ungenaue Spezifikationen oder fehlerhafte Beurteilung der Auswirkungen Installiere und genehmige Lösungen und Changes (Install and accredit solutions and changes: AI7) Dieser Prozess hat das Ziel, sicherzustellen, dass neue oder geänderte Systeme nach der Installation ohne größere Probleme betrieben werden können. Dieses Ziel soll unter anderem durch eine Releaseplanung und die Etablierung von Testmethoden erreicht werden. Die in COBIT dokumentierten KPIs sind: Anteil der Fehler, die während des Qualitätsmanagement-Reviews bei der Installations- und Zulassungsprüfung gefunden werden Anzahl der beim Post-Implementation-Review erkannten Verbesserungen Anteil der Projekte mit dokumentierten und genehmigten Testplänen Die in COBIT dokumentierten KGIs sind: Anteil der Installations- und Zulassungsfehler, die während Audits gefunden werden Nacharbeiten nach der Implementierung, die auf ungenügende Akzeptanztests zurückzuführen sind Ausfallzeiten der Anwendung, die durch ungenügende Tests hervorgerufen werden Die in COBIT dokumentierten IT Key Goal Indicators sind: Anteil der Interessenvertreter, die mit der Daten-Integrität der neuen Systeme zufrieden sind Definiere und Manage Service Level (Define and manage service levels: DS1) Das Service Level Management hat die Ausrichtung der wesentlichen IT Services an der Geschäftsstrategie zum Ziel. Hierzu sind Serviceanforderungen zu identifizieren, die Service Level sind zu vereinbaren und deren Einhaltung ist zu überwachen. Die in COBIT dokumentierten KPIs sind: Anzahl der jährlichen SLA-Reviews mit dem Business Anteil der berichteten Service Level Anteil der automatisch berechneten Service Level Die in COBIT dokumentierten KGIs sind: Anzahl der erbrachten Services, die nicht im Katalog enthalten sind 69

81 2 IT Service Management Anteil der eingehaltenen Service Level Anteil der gemessenen Service Level Die in COBIT dokumentierten IT Key Goal Indicators sind: Anteil der Interessenvertreter, die mit den erreichten Service Level zufrieden sind Identifiziere und verrechne Kosten (Identify and allocate cost: DS6) Dieser Prozess soll die Transparenz und das Verstehen von IT-Kosten gewährleisten und auf der Basis dieser Informationen eine Steigerung der Kosteneffizienz durch kostenbewusste Verwendung der IT Services erreichen. Hierzu sind die IT-Kosten vollständig und genau zu erfassen, ein faires Verrechnungssystem ist zu vereinbaren und über die IT-Kosten und die IT-Nutzung ist rechtzeitig zu berichten. Die in COBIT dokumentierten KPIs sind: Anteil der Kosten, die automatisch / manuell verrechnet werden Häufigkeit der Überprüfung des Verrechnungsmodells Die in COBIT dokumentierten KGIs sind: Anteil der Abweichungen zwischen Budget, vorhergesagten und aktuellen Kosten Anteil der Gesamtkosten, die nach dem vereinbarten Kostenmodell verrechnet wurden Anteil der Kosten die mit dem Business umstritten sind Die in COBIT dokumentierten IT Key Goal Indicators sind: Anteil der vom Business akzeptierten, verrechneten Services Kundenzufriedenheit mit dem Verrechnungsmodell für IT Services Manage die IT-Investitionen (Manage the IT-Investment PO5) Innerhalb dieses Prozesses ist ein System zum Management der Investitionsplanung zu etablieren und zu betreiben. Dieses Managementsystem umfasst die Betrachtung der Kosten, des Nutzens und der Priorisierung von Investitionen innerhalb des geplanten Budgets. Die in COBIT dokumentierten KPIs sind: Prozent der Projekte mit einem definierten Nutzen Prozent der Projekte, für die ein Review nach dem Abschluss durchgeführt werden Die in COBIT dokumentierten KGIs sind: Anzahl von Budgetabweichungen 70

82 2.7 COBIT Prozentuale Darstellung der Budgetabweichung gegenüber dem Gesamtbudget Prozentualer Anteil der IT-Investitionen, die den zuvor definierten Nutzen erzielen Die in COBIT dokumentierten IT Key Goal Indicators sind: Prozentualer Anteil der IT-Investitionen, die den zuvor definierten Geschäftsnutzen erzielen oder übertreffen Prozent der IT-Werttreiber, abgebildet auf die Business-Werttreiber Manage Performance und Kapazitäten (Manage performance and capacity DS3) Das Ziel des Capacity Managements liegt in der Performanceoptimierung der IT-Infrastruktur, der Ressourcen und Kapazitäten in Übereinstimmung mit den Geschäftsanforderungen. Hierzu sind die im SLA vereinbarten Antwortzeiten einzuhalten, die Ausfallzeiten zu minimieren und eine kontinuierliche Verbesserung der IT-Perfomance und Kapazitäten durch Monitoring und Messungen sicherzustellen. Die in COBIT dokumentierten KPIs sind: Häufigkeit der Performance- und Kapazitätsprognosen Anteil der Anlagen, die in Kapazitäts-Reviews betrachtet werden Anteil der Anlagen, die durch zentrale Systeme überwacht werden Die in COBIT dokumentierten KGIs sind: Lastspitzen und Auslastungsrate Anteil der Spitzenlastzeiten, die über die Zielauslastung hinausgehen Anteil der Antwortzeiten, die nicht den SLAs entsprechen Die in COBIT dokumentierten IT Key Goal Indicators sind: Anzahl der Ausfallstunden pro Anwender und Monat aufgrund unzureichender Kapazitätsplanung Manage kontinuierliche Services (Ensure continuous service: DS4) Dieser Prozess soll sicherstellen, dass mögliche Ausfälle der IT Services minimale Auswirkungen auf die Geschäftsprozesse haben. Die in COBIT dokumentierten KPIs sind: Zeitdauer zwischen den Tests aller Bestandteile des IT-Kontinuitätsplans Häufigkeit der Reviews des IT-Kontinuitätsplans Anteil der kritischen IT-Komponenten mit automatisierter Verfügbarkeitsüberwachung 71

83 2 IT Service Management Die in COBIT dokumentierten KGIs sind: Anteil der SLAs, die die Verfügbarkeitszeit erfüllen Anteil der erfolgreichen Tests der IT-Kontinuitätspläne Häufigkeit der Serviceunterbrechung bei kritischen Systemen Die in COBIT dokumentierten IT Key Goal Indicators sind: Anzahl der Ausfallstunden pro Anwender und Monat aufgrund ungeplanter Unterbrechungen Stelle Systemsicherheit sicher (Ensure system security: DS5) Das Security Management hat die Aufrechterhaltung der Integrität von Informationssystemen und die Minimierung der Auswirkungen von Sicherheitsschwachstellen und Security Incidents zum Ziel. Die in COBIT dokumentierten KPIs sind: Häufigkeit und Art der gemeldeten Security Incidents Anzahl und Art von veralteten Benutzerkonten Anzahl der Zugriffsberechtigungen, die autorisiert, widerrufen, gelöscht oder geändert wurden Die in COBIT dokumentierten KGIs sind: Anzahl und Art der vermuteten und tatsächlichen Zugangsverstöße Anzahl und Art von verhinderten bösartigen Codes Anteil der Anwender, die die Password-Standards nicht einhalten Die in COBIT dokumentierten IT Key Goal Indicators sind: Anzahl der Incidents mit Auswirkungen auf das Business 2.8 Monitoring und Reporting von SLAs Die drei Hauptziele des IT Service Managements bestehen darin, die IT Services auf die gegenwärtigen und zukünftigen Anforderungen des Unternehmens und seiner Kunden auszurichten, die Qualität der erbrachten IT Services zu verbessern sowie die langfristigen Kosten der Service- Tätigkeit zu reduzieren (vgl. [itsmf, 2001]). Um diese Ziele zu erreichen, haben sich international anerkannte Best Practices für IT-Prozesse durchgesetzt. Diese sind in ITIL und COBIT dokumentiert. Es handelt sich dabei jedoch nicht um die Best Practices einzelner isolierter Prozesse, sondern vielmehr um einen integrierten Prozessansatz. Die dokumentierten Prozesse sind über definierte Schnittstellen und gemeinsame Dokumente und Daten miteinander verknüpft. Der Output eines Prozesses dient als Input für einen anderen Prozess. Dieses Grundprinzip kann anhand der Prozesse des Problem und Change Managements verdeutlicht 72

84 2.8 Monitoring und Reporting von SLAs werden: Werden innerhalb des Problem Managements notwendige Maßnahmen zur Behebung von Problemen bzw. Fehlern identifiziert, so erstellt der Problem Management-Prozess als Output einen RFC (Request for Change), der dem Change Management als Input dient und von diesem Prozess weiter bearbeitet wird. Die volle Leistungsfähigkeit der ITIL und COBIT Best Practices ergibt sich erst dann, wenn sämtliche Prozesse umgesetzt werden. Daher verlangt die ISO auch die nachweisliche Implementierung aller dokumentierten Prozesse mit ihren in der ISO definierten Mindestanforderungen. In der ersten Version von ITIL, die Ende der 80er Jahre herausgegeben wurde, erfolgte die Betrachtung der Best Practices für das IT Service Management noch aus IT-Sicht. Diese Sichtweise wandelte sich mit der Herausgabe der ITIL Version 2, bei der sich die ITIL Best Practices auf die Ausrichtung des IT Service Managements und die Gestaltung der entsprechenden Prozesse im Hinblick auf die bestmögliche Unterstützung der Geschäftsziele einer Organisation konzentrieren. Mit der vorliegenden Version 3 wird diese Entwicklung konsequent in Richtung der Business Integration und des Service Lifecycle fortgesetzt. Die Prozesse des IT Service Managements stellen mit ihren jeweiligen Prozesszielen und ihrer unternehmensspezifischen Ausrichtung sicher, dass die geschäftlich notwendigen IT Services wirkungsvoll erbracht werden und so die Ziele des IT Service Managements erreicht werden können. Das Hauptaugenmerk der Kunden liegt auf der Lieferung der geschäftlich notwendigen und mit der IT-Organisation vereinbarten IT Services. Die Betrachtung der damit verbundenen IT-Prozesse ist für den Kunden sekundär. Sie ist primär an deren Output im Rahmen der gelieferten IT Services und der Sicherstellung von internen und externen Anforderungen (Compliance) orientiert. Demzufolge ist die Definition der IT Services und deren Sicherstellung eine Schlüsselfunktion für eine professionelle IT-Organisation. Der Fokus der Kunden liegt auf den IT Services. Technologische Lösungen können ausgetauscht und ersetzt werden. Aber das Verständnis der Business-Anforderungen, die professionelle Ausrichtung der IT Services an die Business-Anforderungen und deren Sicherstellung differenziert eine professionelle IT-Organisation von Technologiebetreibern Definition und Interpretation des Begriffs IT Service Bedingt durch die historische Entwicklung innerhalb der IT konzentrierte sich die IT-Organisation zunächst auf die Bereitstellung von technischen Systemen. Diese Systeme, zum Beispiel eine auf dem Host implementierte 73

85 2 IT Service Management Applikation, unterstützten die Durchführung geschäftlicher Aktivitäten. Mit der steigenden Komplexität der Applikationen und deren zunehmender Bedeutung für einen reibungslosen Geschäftsprozess wurde offensichtlich, dass die ausschließliche Betrachtung des technischen Betriebs eines Systems nicht mehr ausreichend ist. Hieraus hat sich zum Beispiel der Aufbau eines Service Desk als Unterstützungssystem für den Anwender entwickelt. Mit der Weiterentwicklung innerhalb der Informations- Technologie greifen eine Vielzahl von einzelnen Systemen ineinander, um die Durchführung von Geschäftsprozessen des Kunden zu gewährleisten. Damit wandelte sich auch die Sicht des Kunden auf die IT. Der Kunde sieht nur den Output der miteinander in Verbindung stehenden Systeme. Hierzu führt ITIL aus Bei der Erbringung von Services steht die Wahrnehmung des Kunden im Mittelpunkt (vgl. [OGC, 2005a]). Die heutige Interpretation des IT Service-Begriffes konzentriert sich demzufolge auf die konsequente Ausrichtung der IT und ihrer Prozesse auf die Unterstützung der Geschäftsprozesse eines Unternehmens. ITIL, ISO und COBIT stellen ausdrücklich heraus, dass die beschriebenen Prozesse die Geschäftsziele der Organisation und die Kundenanforderungen zu unterstützen haben. So betont die ISO in der Einleitung: ISO promotes the adoption of an integrated process approach to effectively deliver managed services to meet the business and customer requirements. (vgl. [ISO , 2005]). ITIL, ISO und COBIT stellen heraus, dass die dokumentierten Prozesse primär der Bereitstellung von IT Services bzw. der notwendigen IT-Unterstützung zur Erfüllung der Geschäfts- und Kundenanforderungen dienen. Von der System- zur Service- Orientierung. Die IT ist in vielen Branchen und Bereichen zu einem wichtigen, teilweise zum wichtigsten Produktionsfaktor geworden. Zum Teil laufen heute einzelne Geschäftsprozesse vollständig IT-gestützt ab und benötigen keinerlei manuelle Eingriffe mehr, wie zum Beispiel das Online-Banking. Um sich der Bedeutung der IT für die geschäftlichen Tätigkeiten eines Unternehmens bewusst zu werden, ist die Frage was würde beim Ausfall der IT-Systeme geschehen sehr hilfreich. Damit die geschäftlichen Aktivitäten entsprechend unterstützt werden können, ist in der Regel das Zusammenwirken verschiedener IT-Systeme notwendig. In IT-Organisation herrscht heute aber zum Teil noch eine technologische Betrachtung vor. Systemspezialisten fokussieren sich auf ihr System. Dieses System stellt aber nur ein Rädchen im Getriebe dar und die Funktionalität des Gesamtsystems ist für die Unterstützung der Geschäftsprozess entscheidend. Die IT-Organisation muss erkennen, dass der Systembetrieb keinen Selbstzweck darstellt, sondern zweckdienliche Geschäftsprozesse mit der notwendigen IT-Unterstützung für den Unternehmenserfolg entscheidend sind. 74

86 2.8 Monitoring und Reporting von SLAs Für das Selbstverständnis der IT ist es wichtig zu erkennen, dass die Bereitstellung der IT Services in erster Linie der Unterstützung der betrieblichen Primäraktivitäten bzw. der Kerngeschäftsprozesse dient und damit über den Erfolg eines Unternehmens entscheidet. So führt Porter 3 in seinem Wertschöpfungsdiagramm aus, dass die primären Aktivitäten eines Unternehmens die Kundenanforderungen bedienen und die Wertschöpfung eines Unternehmens sicherstellen. Die unterstützenden Prozesse oder sekundären Aktivitäten unterstützen die Durchführung der primären Aktivitäten bzw. Geschäftsprozesse. Die IT gehört in der Regel zu den unterstützenden Aktivitäten und muss demzufolge in erster Linie die übergeordneten Wertschöpfungsprozesse sicherstellen (vgl. Abbildung 27). IT Service Management Unternehmensinfrastruktur IT-Service IT-Service Personalwirtschaft IT-Service IT-Service IT-Service IT-Service Wertschöpfung Beschaffung Produktion Marketing & Vertrieb Kunden- Service = Primäre Prozesse / Aktivitäten = sekundäre Prozesse / Aktivitäten = geforderte und gelieferte IT-Unterstützung (IT-Service) Abbildung 27: Wertschöpfungskette nach Porter 3 Michael E. Porter, Professor für Wirtschaftswissenschaften an der Harvard Business School und einer der führenden Ökonomen auf dem Gebiet des strategischen Managements. 75

87 2 IT Service Management ITIL stellt den IT Service in direkten Bezug zum Geschäftsprozess Aus Sicht der IT gibt es eine Vielzahl von unterschiedlichen Business- und Kundenanforderungen, die aus den primären und sekundären Prozessen bzw. Aktivitäten resultieren. Die erforderliche IT-Unterstützung für die Geschäftsprozesse definiert ITIL Version 2 prägnant als einen IT Service; der IT Service ist ein oder mehrere IT-Systeme, die einen Geschäftsprozess ermöglichen (vgl. [OGC, 2006b]). Mit ITIL Version 3 wird der Kundenbezug des Service noch stärker herausgestellt (vgl. [OGC, 2007a]): IT Service Management ist eine Menge von spezialisierten organisatorischen Fähigkeiten, um den Kunden einen Nutzen für das Business in Form von IT Services zu liefern. Innerhalb der IT wird der Begriff des Systems häufig mit einem technischen System gleichgesetzt. Ein System ist vielmehr ein integrierter Komplex, der eine oder mehrere Komponenten, zum Beispiel Prozesse, Hardware, Software, Einrichtungen und Personen umfasst und das Erfüllen bzw. Erreichen einer erklärten Anforderung bzw. Zielsetzung ermöglicht (vgl. [OGC, 2006b]). Hiermit wird deutlich, dass der IT Service aus ein oder mehrere Prozessen, Hardware, Software, Einrichtungen und Personen besteht, die einen Geschäftsprozess ermöglichen. Innerhalb des Glossars wird diese Gesamtsicht zum IT Service nochmals deutlich herausgestellt; Die Erbringungskriterien der IT Service Organisation aus Sicht der Kunden, die Services, umfassen nicht nur die Bereitstellung von Computerressourcen zur Verwendung durch die Kunden (vgl. [OGC, 2006b]). Ein IT Service ergibt sich aus der Sicht des Kunden und unterstützt die optimale Durchführung von Geschäftsprozessen. Dazu ist ein bestmögliches Zusammenwirken von Personen, Produkten, Prozessen und Partnern erforderlich. Diese Anforderungen an einen IT Service unterscheiden sich in Abhängigkeit der Bedeutung der Geschäftsprozesse für das Unternehmen stark in ihrer Art der Leistung und Qualität. Das Kundeninteresse liegt primär in der notwendigen Unterstützung der Geschäftsprozesse. Damit nimmt der Kunde die IT-Organisation mit den geleisteten IT Services als maßgeblichen Output wahr. Die damit verbundenen IT Service Management-Prozesse sind in der Regel eine interne Betrachtung der IT-Organisation. Die Kunden- und Geschäftssicht ist bei der Definition der notwendigen IT-Unterstützung entscheidend. Die geleisteten IT Services sind der maßgebliche Output und bestimmen die Wahrnehmung der IT. 76

88 2.8.2 Service Level Agreements 2.8 Monitoring und Reporting von SLAs Das Service Level Management hat die Kundeanforderungen an einen IT Service aufzunehmen. Diese Anforderungen werden in Service Level Requirements (SLRs, Service Level Anforderungen) dokumentiert. Auf der Basis dieser Anforderungen wird vom IT Service Provider die Möglichkeit der Leistungserbringung geprüft. Mit dem Kunden werden daraufhin Verhandlungen geführt und es kommt zu einem iterativen Prozess, in dem die Kundenanforderungen auf die zu erbringende Servicequalität abgestimmt werden. Letztendlich wird zwischen dem Kunden und dem IT Service Provider eine Vereinbarung getroffen und in einem Service Level Agreement (SLA) dokumentiert. Die ITIL Best Practices definieren einen SLA als eine schriftliche Vereinbarung zwischen einem Service-Anbieter und einem Kunden, in der vereinbarte Service Level für einen Service dokumentiert sind. (vgl. [OGC, 2006b] und [OGC, 2007b]): Ein IT Service stellt die notwendige, ganzheitliche IT-Unterstützung für einen Geschäftsprozess des internen oder externen Kunden sicher. Die Qualität eines IT Service und somit das Maß der gewünschten IT-Unterstützung des Geschäftsprozesses werden in einem SLA (Service Level Agreement) dokumentiert. Zur Absicherung des SLAs werden intern Operational Level Agreements (OLAs) und extern Lieferantenverträge (Underpinning Contracts, UCs) abgeschlossen. Die Struktur und die möglichen Inhalte von SLA, OLA und UC werden im nächsten Kapitel erläutert. Sowohl in ITIL, als auch in COBIT wird die Aufgabe der Erstellung und Pflege der erforderlichen Dokumente, bestehend aus Service Katalog, Service Level Agreement (SLA), Operational Level Agreement (OLA) und Underpinning Contract (UC) dem Prozess des Service Level Managements zugewiesen. COBIT nimmt bei der Definition von Control Objectives und Leistungsindikatoren (KGI, KPI) Bezug auf den Service Katalog, die SLAs, die OLAs und die UCs. Aber: Anforderungen an deren inhaltliche Gestaltung sind in COBIT nicht dokumentiert. So weist lediglich das Control Objective DS1.3 Service Level Agreement darauf hin, dass die Rahmenbedingungen für Verfügbarkeit, Performance, Verlässlichkeit, Wachstumsfähigkeit, Support-Level, Kontinuitätsplanung, Sicherheit und Nachfrage im SLA zu berücksichtigen sind. Dagegen umfassen ITIL und die ISO die Best Practices zu den notwendigen Inhalten von SLAs. Diese Inhalte werden in Kapitel beschrieben. ITIL und ISO enthalten Best Practices für die Inhalte von SLAs. 77

89 2 IT Service Management Die ITIL Best Practices und die ISO enthalten Empfehlungen für die inhaltliche Gestaltung der SLAs. Weiterhin sind Anforderungen an deren Messung sowie an das Reporting beschrieben Das Zusammenwirken von SLAs, OLAs und UCs In einem SLA werden die Geschäftsanforderungen an einen IT Service zwischen dem Kunden und dem IT Service Provider vereinbart. Der Kunde ist der Auftraggeber des IT Service. Der IT-Provider ist der für die Bereitstellung des IT Service verantwortliche Auftragnehmer. Die ISO definiert ein Service Level Agreement (SLA) als written agreement between a service provider and a customer that documents services and agreed service levels. Um die mit dem Kunden vereinbarte IT Servicequalität dauerhaft sicherstellen zu können, bedient sich das Service Level Management weiterer Absicherungsverträge wie OLAs (mit internen Erbringungseinheiten) und UCs (mit externen Lieferanten). Die Summe der vereinbarten OLAs und UCs sichern die SLAs. Die folgende Abbildung 28 dient der Erläuterung und zeigt, wie zum Beispiel für einen IT Service Gehaltsabrechnung die Anforderungen an die Verfügbarkeit in einzelne OLAs und UCs einfließen könnten. 78

90 2.8 Monitoring und Reporting von SLAs SLA Gehaltsabrechnung Leistungsgegenstand: Beschreibung der Funktionalität des IT-Service Leistungsumfang: SAP-HR inkl. Lizenzen für 25 Benutzer, Support und Anpassungen Servicezeit: gem. Betriebskalender 7:00 18:00 Uhr Verfügbarkeit: 96% p.w. am Arbeitsplatz Kontinuität: max. 2 Stunden Totalausfall Lösungszeiten Prio 1: 80% in 2 Stunden OLA HR / Server Leistungsgegenstand: Bereitstellung Server für Modul SAP-HR Verfügbarkeit: 99,8% p.w. OLA HR / LAN Leistungsgegenstand: Bereitstellung LAN Verfügbarkeit: 99,6% p.w. UC HR / WAN Leistungsgegenstand: Anbindung Niederlassung X Verfügbarkeit: 99,4% p.w. Abbildung 28: Zusammenhang zwischen SLAs, OLAs und UCs Der Aufbau von SLAs Es ist wichtig zu betonen, dass die Inhalte und die Struktur der IT Services und der damit verbundenen SLAs unternehmensspezifisch sind. Es gibt nicht den SLA, der für jede Organisation passend ist. Dies vorzugeben ist nicht die Intention der ITIL Best Practices. ITIL stellt ausdrücklich heraus:... es ist nicht leicht, generelle Aussagen zu machen, da jede Situation einzigartig ist. (vgl. [OGC, 2006b]). Vor dem Aufbau und der inhaltlichen Gestaltung von SLAs gilt es zunächst, die bestehenden Kundenanforderungen aufzunehmen sowie das existierende Leistungsportfolio, also die bestehenden IT Services zu erfassen und zu strukturieren (vgl. [Victor et al., 2005]). Erst im Anschluss, das heißt wenn die Strukturierung der IT Services vorliegt, sollten die einzelnen SLAs mit den Kunden vereinbart werden. IT Services entsprechen der Sicht der Kunden bzw. der zu unterstützenden Geschäftsprozesse auf die notwendige IT-Unterstützung. IT Services müssen sich daher über (bestehende) organisatorische und systemtechnische Grenzen innerhalb der IT-Organisation hinwegsetzen. Die Struktur der SLAs ist unternehmens spezifisch. IT Services werden System- und organisationsübergreifend erbracht. 79

91 2 IT Service Management Die ISO dokumentiert die Vorgehensweise aus Kunden- und Geschäftssicht wie folgt: the customer s business needs and budget should be the defining force for the content, structure and targets of the SLA. Von entscheidender Bedeutung für die Definition der IT Services und für die Vereinbarung von SLAs, OLAs und UCs ist die Serviceorientierung eines IT Service im Sinne der ITIL-Definition. Die ISO empfiehlt darüber hinaus, dass die Kundenanforderungen nicht nur die Ziele und den Inhalt, sondern auch die Struktur der SLAs bestimmen sollten. Mehrschichtige SLAs bilden ein hierarchisches System. Auf der obersten Ebene werden allgemeine Regelungen getroffen, die für das gesamte Un- SLA-Strukturen reduzieren Aufwendungen. Im Einklang mit der ISO empfiehlt ITIL vor der Vereinbarung von SLAs die notwendige SLA-Struktur zu planen. Hierzu wird in ITIL eine serviceorientierte und kundenbasierte und eine mehrschichtige SLA- Struktur beschrieben. Um die Aufwendungen für das Monitoring und Reporting zu reduzieren, bietet eine mehrschichtige SLA-Struktur viele Vorteile (siehe Abbildung 29). Hinzu kommen weitere Vorteile wie zum Beispiel geringere Aufwendungen für die Aktualisierung und die Reduzierung von Inkonsistenzen. - Unternehmens-Ebene: - Unternehmensweite SLA- Vereinbarungen - Allgemeine Definitionen und Regelungen zum Monitoring - Kunden-Ebene: - Kundenbezogene SLA- Vereinbarungen - Unterstes Level: - Servicebezogene SLA- Vereinbarungen - Ausgestaltung des auf Unternehmens-Ebene definierten Monitoring Abbildung 29: Beispiel für mehrschichtige SLAs 80

92 2.8 Monitoring und Reporting von SLAs ternehmen gültig sind. Damit werden Redundanzen und Widersprüche vermieden, wie zum Beispiel mehrfache, unterschiedliche Definitionen von Verfügbarkeit. In der nächsten Ebene der SLA-Struktur können dann zum Beispiel übergreifende Vereinbarungen mit den einzelnen Kunden beschrieben werden, um dann auf der dritten Ebene die einzelnen IT Services zu vereinbaren. Bei mehrschichtigen SLAs können auf der obersten Ebene, der Unternehmens-Ebene, allgemeine Regelungen für das Monitoring und Reporting der IT Services vereinbart werden. So kann zum Beispiel beschrieben werden, wie generell die Verfügbarkeit von Applikationen gemessen wird. Zusätzlich kann auch das einzusetzende Messwerkzeug definiert werden. Auf Ebene der einzelnen IT Services sind dann nur noch die konkreten Messkriterien, die Messpunkte und die Messtermine mit dem Kunden zu vereinbaren. Durch diese Struktur wird sichergestellt, dass die SLAs nach einheitlichen Messverfahren und mit standardisierten Messwerkzeugen gemessen werden. Dies reduziert nicht die Aufwendungen für die konkreten Messungen, stellt aber die Vergleichbarkeit der einzelnen IT Services sicher. Innerhalb der ISO wird dagegen auf die inhaltliche Gestaltung der notwendigen Dokumente eingegangen. So sind Best Practices zum Service Katalog und ein Leitfaden für die inhaltliche Gestaltung der SLAs dokumentiert. Im Zusammenspiel zwischen Service Katalog und SLA empfiehlt die ISO , eine Referenzierung vom SLA zum Service Katalog aufzubauen. Messwerkzeuge und einheitliche Messverfahren sollten einheitlich vorgegeben werden Die Inhalte von SLAs Vorgaben / Empfehlungen der ISO Die ISO beschreibt die Mindestanforderungen an die Dokumentation von IT Services mittels SLAs. So fordert die ISO : Der gesamte Umfang der gelieferten Services mit den zugehörigen Service Levesl und Auslastungs-Kriterien müssen zwischen den Parteien vereinbart und aufgezeichnet werden oder Jeder gelieferte Service muss in einem oder mehreren SLAs definiert, vereinbart und dokumentiert werden. (vgl. [ISO , 2005]). Vorgaben zur inhaltlichen Gestaltung der SLAs macht die ISO nicht. Service Level und Auslastungs-Kriterien sind zu vereinbaren und aufzuzeichnen. Die ISO enthält Mindestanforderungen an die Verwendung von SLAs. Im Fokus stehen dabei die Anforderungen an den Prozess des Service Level Managements. 81

93 2 IT Service Management Die ISO empfiehlt die folgenden Inhalte für einen SLA: Kurze Beschreibung des Service Gültigkeitsdauer und / oder Change-Mechanismen Detaillierte Vollmachten Kurzbeschreibung der Kommunikation inklusive des Reportings Nähere Angaben über Ansprechpartner, die dazu bevollmächtigt sind, in Notfällen zu handeln und die bei Incidents, Problembehebungen, Recovery und Workarounds mitwirken Servicezeiten (zum Beispiel 09:00-17:00 Uhr), festgelegte kritische Geschäftszeiten (zum Beispiel Wochenenden, gesetzliche Feiertage und Ferien), Ausnahmen und unterstützter Systembetrieb Geplante und vereinbarte Unterbrechungen, inklusive festgelegter Ankündigungsprozedur und Anzahl pro Periode Verantwortlichkeiten des Kunden, zum Beispiel Sicherheit Verantwortlichkeiten und Verpflichtungen des IT Service Providers, zum Beispiel in Bezug auf die IT Sicherheit Richtlinien für Auswirkungen und Prioritäten (Zuordnung) Eskalations- und Benachrichtigungsprozess Beschwerdeverfahren Service-Ziele (Service Targets) Workload-Begrenzungen, zum Beispiel die Fähigkeit, eine vereinbarte Anzahl von Anwendern / Arbeitsvolumen / Systemdurchsatz zu unterstützen Übergeordnete Finanzinformationen, zum Beispiel Kostenschlüssel etc. Notwendige Aktionen im Fall einer Serviceunterbrechung Organisatorische Abläufe Begriffsdefinitionen Unterstützte und zugeordnete Services Jede Ausnahme zu den angegebenen Bedingungen des SLA Die ISO dokumentiert international anerkannte Best Practices für das IT Service Management. Eine Organisation ist daher gut beraten, die in der ISO beschriebenen Inhalte für ein Service Level Agreement (SLA) umzusetzen. Die ISO beinhaltet die Definition von Service-Zielen (Service Targets). Service-Ziele machen die vereinbarten Ziele für einen Service Level messbar. Mögliche Service-Ziele könnten zum Beispiel eine Verfügbarkeit von x % pro Woche oder eine Erstlösungsquote von x % pro Woche sein. 82

94 2.8 Monitoring und Reporting von SLAs Die Einhaltung von Service Level und SLAs wird mittels vereinbarter Service- Ziele definiert, überwacht und berichtet. Zur Definition der Service-Ziele empfiehlt die ISO : The targets, against which the delivered service should be measured, should be defined from a customer perspective. (vgl. [ISO , 2005]). Daraus resultiert die Anforderung, die SLAs und insbesondere die Service Level und Service-Ziele in einer Sprache zu verfassen, die der Kunde versteht und die seiner Perspektive entspricht. So sollten zum Beispiel in einem SLA Begriffe wie Buchungsvorgänge und Anzahl gespeicherter Artikel verwendet werden. Messgrößen wie CPU-Auslastung oder Datenbankgröße entsprechen dagegen in der Regel nicht der Kundenperspektive und sind zu vermeiden. Es können nicht alle Geschäfts- und Kundenanforderungen in einem SLA vereinbart werden. Insbesondere wenn innerhalb einer Organisation noch keine Erfahrungen mit SLAs vorliegen, sollte man sich zunächst auf die wichtigsten Aspekte begrenzen, Erfahrungen sammeln und diese Erfahrungen bei der nächsten Version umsetzen. Hinzu kommt, dass SLAs verwaltet werden müssen. Die Einhaltung muss gemessen und berichtet werden. Diese Aktivitäten führen zu Aufwendungen und Kosten für den IT Service. Die ISO empfiehlt daher: The SLAs should include only an appropriate subset of the targets to focus attention on the most important aspects of the service. Service-Ziele sind aus der Kundenperspektive zu definieren. Konzentration auf die wesentlichen Service Level In einem SLA sollte eine angemessene Anzahl der wichtigsten Aspekte eines IT Service enthalten sein 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 sind an den Prozessbeschreibungen der ITIL Best Practices ausgerichtet und ergänzen diese komplementär (zum Teil wurden die Texte von den gleichen Autoren verfasst). Daher sind die in ITIL und die in der ISO dokumentierten Empfehlungen weitestgehend deckungsgleich. Allerdings sind die Beschreibungen in den ITIL Best Practices umfangreicher gegenüber denen aus der ISO ITIL definiert die gebräuchlichen Inhalte eines SLA wie folgt: Einleitung - Parteien der Vereinbarung - Bezeichnung und Kurzbeschreibung der Vereinbarung - Unterzeichnende 83

95 2 IT Service Management - Datumsangaben: Anfang, Ende, Review - Geltungsbereich der Vereinbarung, was wird zugesichert und was ist ausgenommen - Pflichten des IT Service Providers und des Kunden - Beschreibung des zugesicherten IT Service Service-Zeiten - Die Zeiten, in denen der Service gewöhnlich benötigt wird - Vereinbarungen für die Anforderung von Service- Erweiterungen, inklusive der erforderlichen Mitteilungszeiten - Besondere Zeiten (zum Beispiel Feiertage) - Service-Kalender Verfügbarkeit - Verfügbarkeits-Ziele während der vereinbarten Zeiten - Normalerweise als Prozentsatz definiert - Festgeschriebene Messperioden und -verfahren Zuverlässigkeit - Wird üblicherweise als Anzahl der Service-Unterbrechungen oder als MTBF (Mean Time Between Failures) bzw. als MTBSI (Mean Time Between System Incidents) ausgedrückt Support - Support-Zeiten (sofern diese nicht mit den Service-Zeiten identisch sind) - Vereinbarungen für die Anforderung von Support- Erweiterungen, inklusive der erforderlichen Mitteilungszeiten - Besondere Zeiten (zum Beispiel Feiertage) - Ziel für die Reaktionszeit - Ziel für die Lösungszeiten, abgestuft nach den Prioritäten der Incidents Durchsatz - Angaben des voraussichtlichen Datenvolumens und Durchsatzaktivitäten (zum Beispiel Anzahl der Transaktionen, die Anzahl der gleichzeitig aktiven Anwender) Antwortzeitverhalten - Zielvorgaben für durchschnittliche oder maximale Antwortzeiten am Arbeitsplatz (zum Beispiel 95 % innerhalb von 2 Sekunden) Batch-Bearbeitungszeiten - Zeiten für die Lieferung von Input und Output und Ort für die Lieferung des Outputs 84

96 2.8 Monitoring und Reporting von SLAs Changes - Zielvorgaben für die Genehmigung, Bearbeitung und Implementierung von RFCs; üblicherweise bezogen auf Kategorie oder Dringlichkeit/Priorität Kontinuität und Sicherheit der IT Services - Eine kurze Benennung des IT Service Continuity Plans und wie er aktiviert wird - Ausführungen zu Sicherheitsfragen, insbesondere Verantwortungen des Kunden (zum Beispiel Backup von nicht angebundenen PCs, Passwort-Änderungen) - Einzelheiten zu verminderten oder geänderten Service- Zielen für den Katastrophenfall (falls kein separates SLA für solche Situationen existiert) Leistungsverrechnung - Einzelheiten zum Verteilungsschlüssel und zu den Zeiträumen der Leistungsverrechnung (sofern die Leistungen in Rechnung gestellt werden) Service-Berichte und Reviews - Der Inhalt, die Häufigkeit und Verteilung der Service-Berichte - Die Häufigkeit der Service-Review Besprechungen Leistungs-Anreize / Strafen - Einzelheiten zu Vereinbarungen über finanzielle Anreize oder Strafen in Abhängigkeit der Service Level Monitoring und Reporting von SLAs, OLAs und UCs Der Prozess Service Level Management ist nicht nur für die Vereinbarung der IT Services mit den Kunden und der Absicherung dieser SLAs durch entsprechende OLAs und UCs verantwortlich. Weiterhin gehören auch die Aufgaben des Monitorings und des Reporting in die Verantwortung des Service Level Managements. Dabei werden die SLAs und die damit in Verbindung stehenden OLAs und UCs gemessen und die Ergebnisse den jeweiligen Organisationsbereichen berichtet. In der ISO heißt es hierzu: Service Level sind zu überwachen und gegenüber den vereinbarten Zielen (Service Targets) zu berichten. (vgl. [ISO , 2005]). Die in den SLAs, OLAs und UCs spezifizierten Vereinbarungen sind hinsichtlich der Zielerreichung vollständig zu überwachen und die Ergebnisse sind zu berichten. Um das Monitoring der SLAs, OLAs und UCs sicherzustellen, müssen sämtliche beschriebenen Service Level messbar sein (siehe Kapitel

97 2 IT Service Management Service Level sind dort zu messen, wo der Service wahrgenommen wird. und ). Werden im SLA zum Beispiel Regelungen für Changes, wie etwa Genehmigungszeiten getroffen, so sind diese Bearbeitungszeiten zu messen und zu berichten. In einem SLA werden Service-Ziele für einen IT Service vereinbart und sind im Rahmen des Monitorings zu messen. Um die daraus resultierenden Anforderungen an die Messbarkeit zu verstehen, erfolgt hier nochmals die Darstellung der Kundensicht auf den IT Service. Der Kunde benötigt die IT Services zur Durchführung seiner geschäftlichen Aktivitäten dort, wo die Aufgaben durchzuführen sind. Er erwartet, dass zum Beispiel die Finanzverwaltungsaktivitäten am Arbeitsplatz seines Mitarbeiters durchgeführt werden können. In der Regel ist dieser Arbeitsplatz der PC des Mitarbeiters. Diese Anforderung mag an dieser Stelle trivial und selbstverständlich klingen, aber welcher IT Service Provider garantiert dem Kunden heute die Bereitstellung des IT Service mit garantierten Service Level am PC- Arbeitsplatz? Den Kunden interessiert es nicht, ob die Applikation am Server verfügbar ist. Sie muss am Arbeitsplatz seines Mitarbeiters verfügbar und nutzbar sein. Welche verschiedenen IT-Systeme dazu betrieben werden müssen und ineinander greifen, sollte für den Kunden nicht von Belang sein. Der Kunde benötigt eine ganzheitliche IT-Unterstützung zur Durchführung seiner Aktivitäten und nicht ein Puzzle von Einzelvereinbarungen. Es ist sinnlos, Service Level und Service-Ziele zu definieren, wenn diese nicht überprüfbar sind. So ist zum Beispiel die Zusicherung eines Service Level mit dem Ziel einer Verfügbarkeit von 95 % überflüssig, wenn die Verfügbarkeit nicht gemessen werden kann. Daher muss die IT überlegen, wie geeignete Messungen vorgenommen werden können. Zum Beispiel könnten Messroboter eingesetzt werden, die an vereinbarten Lokationen und zu vereinbarten Zeiten die Verfügbarkeit des IT Service messen. Die festgelegten Messverfahren und Messkriterien sind dem Kunden zu erläutern und als Anlage zum SLA zu vereinbaren. Ist ein Service Level nicht messbar, stellt sich die Frage, ob dieser Service Level überhaupt wichtig ist. Wäre der Service Level wichtig, so würden auch Anstrengungen unternommen diese Messung sicherzustellen bzw. den Service Level so zu spezifizieren, dass die Messung möglich wird. Gegebenenfalls kann statt einer Messung auch eine Bewertung, wie zum Beispiel im Rahmen einer Kundenzufriedenheitsumfrage herangezogen werden. Nicht messbare Service Level bergen ein Konfliktpotenzial zwischen IT Service Provider und Kunde in sich. Solange der Kunde zufrieden ist, mögen noch keine Probleme auftreten. Aber wenn der Kunde unzufrieden ist 86

98 2.8 Monitoring und Reporting von SLAs und den Nachweis der Einhaltung der Service-Ziele einfordert, ist der Streit vorprogrammiert. Bei der Messbarkeit von SLAs darf nicht außer Acht gelassen werden, dass Kunden und Anwender die IT in der Regel nur dann bemerken, wenn sie ausfällt. Diese Ausfälle bestimmen daher häufig das Erscheinungsbild der IT. Durch das Monitoring und Reporting kann der IT Service Provider dazu beigetragen, diese negative Kundenwahrnehmung der IT zu verändern. Das Monitoring und Reporting der Service Level und der Nachweis der Einhaltung der Service-Ziele tragen zur Steigerung der Kundenzufriedenheit bei. Das Monitoring und das Reporting der Service Level und der eingehaltenen Service-Ziele muss im Eigeninteresse des IT Service Providers liegen. Daher sind die SLAs, OLAs und UCs eindeutig zu formulieren, dürfen keine mehrdeutigen Interpretationen zulassen und sind gegenüber den festgelegten Service-Zielen zu messen. In der ISO wird aber nicht nur verlangt, dass die Service Level zu messen und gegenüber den Service-Zielen zu berichten sind, sondern die Forderung wird fortgeführt: showing both current and trend information. The reasons for non-conformance shall be reported and reviewed. (vgl. [ISO , 2005]). Aus dieser Empfehlung ergeben sich weitere Anforderungen an die Aufzeichnung und das Reporting von SLAs. Die erreichten Service Level sind chronologisch aufzuzeichnen und im Rahmen der Service-Berichte als Trend darzustellen. Die Qualität eines IT Service kann so an der Einhaltung der definierten Service-Ziele und anhand des Trends bewertet werden. Die Trenddarstellung macht es für die Beteiligten offensichtlich, ob die Qualität gleich bleibend, steigend oder unter Umständen sinkend ist. Die ISO verlangt auch die Darstellung von Trends. Die ISO erfordert eine Trenddarstellung der erreichten Service Level gegenüber den Service-Zielen. Darüber hinaus fordert die ISO 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 besteht in der Darstellung und Bewertung der Ursachen für die Nichterreichung ( Unterschreitung) der festgelegten Service-Ziele. 87

99 2 IT Service Management Abgrenzung der Kennzahlen Die SLAs mit den Service Level und den entsprechenden Service-Zielen definieren die vereinbarte IT-Unterstützung für die Aktivitäten und Geschäftsprozesse einer Organisation. Sie stellen die Außensicht auf die IT- Organisation dar. Das Kundeninteresse besteht in der Einhaltung der zugesicherten Service-Ziele. Eine Betrachtung der IT-internen Prozesse steht nicht im Fokus des Kunden. Im Außenverhältnis berichtet die IT-Organisation über die Einhaltung der definierten Service Level und der Auslegungskriterien. Die Einhaltung dieser Kriterien und des Trends sind vom IT Service Provider nachzuweisen. Hierzu werden entsprechende Service-Ziele im SLA definiert. Innerhalb der IT ist ein Management der IT Service Management-Prozesse erforderlich. Mittels Kennzahlen wird überprüft, ob die Prozesse die definierten Ziele hinsichtlich der Effektivität und Effizienz erreichen. So wird zum Beispiel die Effektivität des Prozesses Service Level Management mittels der Kennzahl Anteil eingehaltener Service Level gemessen. Im Innenverhältnis benötigt das Management Kennzahlen, um die IT-Prozesse zu steuern. Hierzu dienen die jeweiligen Key Goal Indicators (KGIs) und die Key Performance Indicators (KPIs). 2.9 Integrationsinstrument: Balanced Scorecard Die Balanced Scorecard ist ein Kennzahlen- und Management- System. Die von Robert S. Kaplan und David P. Norton Anfang der 90er Jahre entwickelte Balanced Scorecard 4 ist nicht nur ein Messsystem, sondern vielmehr ein exzellentes Management- und Steuerungssystem. Sie kann in unterschiedlichen Unternehmensbereichen eingesetzt werden. Nach unserer Erfahrung eignet sie sich besonders gut als Management- und Reporting-Instrument für IT-Organisationen bzw. deren Bereiche. Wir verwenden die Balanced Scorecard als Integrationsinstrument, das in der Lage ist, Kennzahlen aus unterschiedlichen Systemen zusammenzuführen, zu verknüpfen und für entsprechende Adressatenkreise geeignet darzustellen. In den Projekten, die wir in IT-Organisationen unterschiedlicher Größen und Branchen durchgeführt haben, hat sich immer wieder gezeigt, dass es durch Anwendung der Balanced Scorecard möglich ist, die Lage der IT in ihrem jeweiligen Geschäftsumfeld realitätsnah, transparent und korrekt darzustellen. Richtig eingesetzt, hält die Balanced Scorecard damit nicht nur das operative IT-Geschäft sondern insbesondere die stra- 4 Häufig abgekürzt als BSC, für den IT-Bereich als IT-BSC. 88

100 2.9 Integrationsinstrument: Balanced Scorecard tegische Ausrichtung der IT-Organisation bis hin zum IT-Marketing in der Balance Kernideen Die Kernideen der Arbeiten von Robert S. Kaplan und David P. Norton sind einfach und faszinierend. Liest man die ersten Seiten aus [Kaplan et al., 1996], fällt es schwer, das Buch zur Seite zu legen. -- Zitatanfang -- Imagine entering the cockpit of a modern jet airplane and seeing only a single instrument there. How would you feel about boarding the plane after the following conversation with the pilot? Question: I m surprised to see you are operating the plane with only a single instrument. What does it measure? Answer: Air speed. I m really working on air speed this flight. Question: That s good. Air speed certainly seems important. But what about altitude. Wouldn t an altimeter be helpful? Answer: I worked on altitude for the last few flights and I ve gotten pretty good on it. Now I have to concentrate on proper air speed. Question: But I noticed you don t even have a fuel gauge. Wouldn t that be useful? Answer: You are right: fuel is significant, but I can t concentrate on doing too many things well at the same time. So, on this flight I m concentrating on air speed. -- Zitatende -- Die Frage, ob man nach diesem Gespräch hier mitfliegen würde, lässt sich leicht beantworten: Unabhängig vom Können des Piloten und unabhängig von der Qualität des Flugzeugs bleibt der fade Nachgeschmack, dass eine einzige Kennzahl, dir zur Steuerung der Maschine reported wird, nicht ausreicht selbst wenn der Pilot mit dieser Methode in der Vergangenheit gute Erfahrungen gemacht hat. Ein Ansatzpunkt der Balanced Scorecard ist gerade die Kritik an der tradierten strategischen Unternehmensführung, die sich im Wesentlichen an finanziellen Kennzahlen (z. B. Return on Investment oder Eigenkapitalrentabilität) orientiert. Diese Kennzahlen werden als eindimensional und vergangenheitsorientiert kritisiert. Sie würden außerdem zu einer kurzfristig orientierten Investitionspolitik führen, da Zukunftsmaßnahmen, z. B. im Bereich Forschung und Entwicklung, sich kurzfristig in der Erfolgsrechnung nur auf der Kostenseite niederschlagen. Die Balanced Scorecard in der von Kaplan und Norton vorgestellten Form ergänzt daher die traditionelle finanzielle Perspektive um drei weitere 89

101 2 IT Service Management Perspektiven. Auf diese Weise erhält man ein 4-dimensionales Modell, dass ein und dasselbe Objekt, z. B. einen Unternehmensteilbereich, aus verschiedenen Blickwinkeln beleuchtet und bewertet. Die von Kaplan und Norton vorgeschlagene Balanced Scorecard ist 4-dimensional. Sie enthält die 4 Perspektiven: Finanzen, Kunden, Prozesse 5 und Potenziale 6. Die Balanced Scorecard ist ein mehrdimensionales und ausgewogenes Zielsystem. Neben der Mehrdimensionalität des Zielsystems basiert die Balanced Scorecard auf einer weiteren Idee, die sich leicht im täglichen Leben wiederfinden lässt. Der Begriff balanced sagt aus, dass die Perspektiven ausgeglichen bzw. ausgewogen sein müssen. Bemüht man weitere wörtliche Übersetzungen des Begriffs, so bietet sich die technische Interpretation ausgewuchtet an, die verdeutlicht, dass das Gesamtsystem der Scorecard nur dann Sinn macht, wenn die einzelnen Komponenten richtig auf einander abgestimmt sind. Nach dem Prinzip der Balanced Scorecard macht es keinen Sinn, eine Perspektive in den Vordergrund zu schieben und dafür andere zu vernachlässigen. Es handelt sich um ein Zielsystem, in dem die Mehrdimensionalität nicht nur als Option enthalten ist sondern explizit gefordert und garantiert wird. Wendet man die Balanced Scorecard auf den IT-Bereich an, so hat dies eine gravierende Konsequenz: Die alleinige Bewertung der IT anhand von Kostenzahlen ist nicht mehr state of the art. Es geht nicht um kurzfristige Gewinne sondern um Kontinuität. Die Balanced Scorecard ist ein top down- Instrument zur Strategieumsetzung. Die Balanced Scorecard berücksichtigt insbesondere strategische Aspekte. Ein wesentliches Ziel ist in diesem Zusammenhang die Garantie des mittel- und langfristigen Erfolgs der zu betrachtenden Unternehmenseinheit. Es geht damit weniger um kurzfristig realisierbare Unternehmensgewinne sondern mehr um Kontinuitätsgesichtspunkte. Die Balanced Scorecard versucht, Wertschöpfungsprozesse mit dem richtigen Augenmaß zu bewerten und herauszufinden, welche Faktoren für den langfristigen Erfolg des Unternehmens ausschlaggebend sind. Wichtigstes Ziel der Balanced Scorecard ist die Umsetzung von Unternehmenszielen auf allen Ebenen. Dies wird dadurch erreicht, dass sich, ausgehend von der Vision, die Strategie des Unternehmens ableiten lässt und sich daraus konkrete Ziele definieren lassen. Der Aspekt der Vision und Strategie steht damit im Mittelpunkt einer jeden Balanced Scorecard. In [Kaplan et al., 1996] wird dies mit den 5 Die Prozessperspektive wird im Original Interne Geschäftsprozesse genannt. 6 Die Potenzialperspektive wird im Original Lernen und Entwicklung genannt. 90

102 2.9 Integrationsinstrument: Balanced Scorecard Schlagworten translating strategy into action und measures that drive (future) performance herausgestellt. Um den Kern von Vision und Strategie ranken sich vier Betrachtungsweisen (vgl. Abbildung 30): Finanzielle Ziele: Wie soll das Unternehmen gegenüber Teilhabern und Kapitalgebern auftreten, um finanziellen Erfolg zu erreichen? Kundenbezogene Ziele: Wie soll das Unternehmen gegenüber Kunden auftreten, um seine Vision zu verwirklichen? Prozessbezogene Ziele: In welchen Geschäftsprozessen muss das Unternehmen an der Spitze stehen, um seine Teilhaber und Kunden zu befriedigen? Mitarbeiter- und Innovationsbezogene Ziele: Wie kann das Unternehmen Veränderungs- und Wachstumspotenziale fördern, um seine Vision zu verwirklichen? Finanzperspektive Kundenperspektive Vision und Strategie Prozessperspektive Protenzialperspektive Kenn- Vor- Maß- Ziel zahl gabe nahme Kenn- Vor- Maß- Ziel zahl gabe nahme Kenn- Vor- Maß- Ziel zahl gabe nahme Kenn- Vor- Maß- Ziel zahl gabe nahme Abbildung 30: Allgemeine Balanced Scorecard 91

103 2 IT Service Management Diese Ziele lassen sich beispielsweise folgendermaßen detaillieren: 7 Finanzielle Ziele Kostenreduktion Strategische Ausrichtung von Investitionen Umsatzsteigerung Kundenbezogene Ziele Gewinnung neuer Kundensegmente Umsatzerhöhung pro Kunde Festigung der Kundentreue Prozessbezogene Ziele Lean Management realisieren Best of breed Technologien einsetzen Grundideen des Business Process Re-engineering umsetzen Mitarbeiter- und Innovationsbezogene Ziele Erhöhung der Mitarbeiterzufriedenheit Etablieren eines Unternehmenswerte-Systems Durchführung von Qualifikationsmaßnahmen Die Verknüpfung der Unternehmensstrategie und der operativen Maßnahmenplanung erfolgt über Ursache-Wirkungsketten (siehe Abbildung 31). In der Praxis können diese Wirkungszusammenhänge sehr kompliziert, ja sogar konfliktär sein. In [Kaplan et al., 1996] sind die Schritte dargestellt, die notwendig sind, um ein Balanced Scorecard Konzept zu erstellen. Dabei sind 10 Teilaufgaben zu lösen, ausgehend von Aufgabe 1: Select the appropriate organizational unit bis zu Aufgabe 10: Finalize the implementation plan. Es sollen nicht mehr als 25 Kennzahlen (4 bis 7 je Perspektive) verwendet werden. Die Kennzahlen sollen Vergangenheit, Gegenwart und Zukunft messen. Vor allen Dingen sollen die Kennzahlen strategisch dimensioniert sein, denn das Konzept der Balanced Scorecard dient der beschleunigten Strategieumsetzung. 7 Die Detaillierung leitet sich aus der IT-Strategie und dem Zielsystem des Unternehmens ab. 92

104 2.9 Integrationsinstrument: Balanced Scorecard Finanzperspektive Finanzielles Ergebnis (Gewinn, Rentabilität,...) Kundenperspektive Kundentreue Prozessperspektive Kosten der Prozesse Qualität der Prozesse Geschwindigkeit der Prozesse Potentialperspektive Qualifizierte Mitarbeiter Motivierte Mitarbeiter Abbildung 31: Ursache-Wirkungskette Dass sich die Balanced Scorecard immer aus den Unternehmenszielen und der Strategie ableitet, verdeutlicht Abbildung 32 aus [Preißner, 2006]. Unternehmensziele Strategien Kundenzufriedenheit Kundenperspektive interne Prozessperspektive Finanzperspektive Lern- & Entwicklungsperspektive operative Umsetzung Erfolgskontrolle Abbildung 32: Stellung der BSC im Unternehmensplanungsprozess 93

105 2 IT Service Management Anwendung auf den IT-Bereich Die Anwendung der Balanced Scorecard Methode in IT-Bereichen ist inzwischen weitgehend akzeptiert. Der Nutzen im Hinblick auf Performance-Steigerung und Strategie-Überprüfung liegt auf der Hand. Es geht darum, die IT-Organisation als Ganzes über ihre verschiedenen Funktionen hinweg zu steuern. Es geht darum, dass dies konform mit der IT- Strategie geschieht und darum, dass diese aus der Geschäftsstrategie abgeleitet ist. So ist es nicht verwunderlich, dass die Balanced Scorecard als empfohlenes Werkzeug explizit Eingang in ITIL V3 gefunden hat, da ITIL V3 gerade die Verzahnung von Business und IT sowie der Beitrag der IT zur Wertschöpfung des Unternehmens am Herzen liegen. Auch ITIL V3 liefert natürlich keine Balanced Scorecard für die IT, die eins zu eins in einer IT-Organisation einsetzbar ist und damit auch kein Kennzahlensystem, das diesen Zweck erfüllt. Nach [Kütz, 2007] kann es wegen der Vielzahl der Steuerungsobjekte in der IT und Verschiedenheit der Rahmenbedingungen ein Standard-Kennzahlensystem nicht geben... Umfang und Ausprägungen müssen dann im konkreten Fall spezifisch erarbeitet werden. ITIL V3 kommt jedoch mit seinem erweiterten und modifizierten Prozessmodell dem Ziel der Vereinheitlichung von IT Service-Prozessen 8 einen gewaltigen Schritt näher. Dies wird zumindest zu einer weiteren Vereinheitlichung von IT-Kennzahlensystemen führen. ITIL V3 schlägt in Anlehnung an Kaplan und Norton vier Perspektiven für eine IT Balanced Scorecard vor (vgl. [OGC, 2007e]): -- Zitatanfang -- Financial: As customers how do we view the costs of IT provision? Customer: What do we as customers expect of IT provision? Innovation: Does our IT infrastructure enable us to continue to improve the business? Internal: What must our IT providers (internally) excel at? -- Zitatende -- Die Grundidee von ITIL V3 ist richtig und bestätigt unsere Arbeiten in vielen Projekten, in denen es darum ging, Kennzahlensysteme zur Steuerung und zum Reporting einzusetzen: 8 Hier ist insbesondere die Vereinheitlichung im Sinne der Etablierung eines allgemein akzeptierten Sprachstandards gemeint. 94

106 2.9 Integrationsinstrument: Balanced Scorecard Es gibt viele Möglichkeiten, Perspektiven für eine IT Balanced Scorecard zu definieren. Allerdings wird sich in der Praxis beweisen müssen, ob die in ITIL V3 genannten vier Perspektiven für die IT die geeigneten sind und ob es nicht mehr oder weniger als vier sind Ausprägungen der Balanced Scorecard Mit der Fragestellung, was die geeigneten Perspektiven der Balanced Scorecard für den IT-Bereich sind und welche Kennzahlen man für jede dieser Perspektiven erhebt, haben sich einige Ansätze beschäftigt. In der lesenswerten Masterarbeit von Jakob Bung werden einige dieser Ansätze gegenübergestellt [Bung, 2006]. Wir gehen hier nicht auf die Details ein, sondern geben das Ergebnis in Form einer Tabelle an (siehe folgende Seite, in Anlehnung an [Bung, 2006], Seite 27). Die Gegenüberstellung der verschiedenen Ansätze zeigt, dass es schwerfällt, einen allgemein gültigen Ansatz zur Strukturierung der Perspektiven einer Balanced Scorecard anzugeben. Es fällt auf, dass es keinen Sprachstandard gibt. Möchte man in der Praxis eine Balanced Scorecard für den IT-Bereich entwickeln 9, so bietet es sich an, das Beste aus allen Welten zu nehmen. Dies verdeutlichen wir später in unserem Kennzahlenmodell und in den Praxisbeispielen. 9 Wir sprechen hier immer von einer (!) Balanced Scorecard, um den Sprachgebrauch einfach zu halten. Für IT-Bereiche können auch mehrere Balanced Scorecards existieren, die gegebenenfalls zusammenhängen. 95

107 2 IT Service Management Entwicklungsstufen zur IT Balanced Scorecard Ansatz von Kaplan und Norton Perspektiven Jahr Anmerkung Finanzen Kunden Geschäftsprozesse Lernen u. Entwicklung 1996 Kein expliziter Bezug zur IT. Van Grembergen und Saull Beitrag zum Kerngeschäft Kundenorientierung Operative Leistungen Zukunftsorientierung Kütz Finanzmanagement Kundenmanagement Prozess-Management Innovationsmanagement Mitarbeitermanagement Lieferantenmanagement Wiggers, Kok und de Boerde Wit Schmid- Kleemann ITIL 2 und ITIL V3 Finanzen Kunden Geschäftsprozesse Lernen u. Entwicklung Unternehmensbeitrag Kunden IT-Leistungserstellung IT-Einsatz Zukunft Finanzen Kunden Interne Prozesse Innovation (bzw. Lernen und Entwicklung) 2001 Die Kundenorientierung wird beibehalten, drei neue Perspektiven werden vorgeschlagen, insb. die Bestimmung des Added Values der IT Zusätzlich wird die Lieferantenperspektive eingeführt. Die Potenzialperspektive wird in Mitarbeiter- und Innovationsmanagement aufgeteilt Enthält die gleichen Perspektiven wie Kaplan et al., diese werden allerdings inhaltlich an die IT angepasst Auch hier der Versuch, den Wertbeitrag der IT zu bestimmen. Die Zukunftsperspektive und der IT-Einsatz leiten sich aus der Potenzialperspektive ab und Perspektiven, die mit denen der Original BSC übereinstimmen. Die Beschreibung der Perspektiven ist in V 3 wesentlich differenzierter als in V 2. 96

108 2.10 Konsequenzen 2.10 Konsequenzen Die Auswahl der richtigen Kennzahlen ist in der Praxis ein schwieriger und mehrstufiger Prozess. Die Fragestellung, welcher Ansatz 10 der geeignete zum Aufbau eines Kennzahlensystems ist, führt im Allgemeinen nicht zum Ziel. Es geht vielmehr darum, herauszufinden, wie verschiedene Komponenten der Best Practices als Puzzle zusammengefügt werden können, um das bestmögliche durchgängige Kennzahlensystem für die jeweilige Organisation aufzubauen. ITIL führt hierzu aus (Service Strategy [OGC, 2007a]): Ein wirkungsvolles IT Service Management entsteht durch die Nutzung von Best Practices (Standards) und deren Ausrichtung an den spezifischen Fähigkeiten der eigenen Organisation. Kennzahlen (KGIs und KPIs) und der Aufbau eines Kennzahlensystems sind kein Selbstzweck. Die Kennzahlen sind nicht zu definieren und zu berichten, weil COBIT und ITIL entsprechende KPIs bzw. KGIs beinhalten. Es geht auch nicht darum diese Kennzahlen zu definieren, weil es die ISO verlangt. COBIT und ITIL empfehlen bzw. die ISO verlangt vielmehr die Definitionen von Kennzahlen für jeden IT Service Management-Prozess, weil die Kennzahlen unentbehrliche Informationen für das Management von Prozessen darstellen. Das Prozess-Management (Service Manager, Prozess Owner und Prozess Manager) und das gesamte IT-Management müssen diese Kennzahlen als Führungsinstrument verstehen und dieses Werkzeug aktiv nutzen. Ziel des Prozess-Managements ist es, die Prozesse so zu gestalten und zu steuern, dass die definierten Ziele erreicht werden. Die Kennzahlen liefern dem gesamten Management die notwendigen Informationen darüber, ob die zuvor definierten Prozess-Ziele erreicht werden. Demzufolge müssen sich die Kennzahlen an den Prozesszielen ausrichten. Kennzahlen sind für ein wirksames Prozess- Management unabdingbar. Voraussetzung für die Definition von Kennzahlen sind definierte Ziele für die jeweiligen IT Service Management-Prozesse. Die beschriebenen Best Practices sind daher als Guidelines für mögliche Kennzahlen zu verstehen. Ihre Nutzung oder die gegebenenfalls notwendige Definition ergänzender und anderer Kennzahlen muss immer in Bezug auf die spezifischen Prozess-Ziele einer IT-Organisation erfolgen. 10 Beispielsweise ITIL oder COBIT, aber auch andere. 97

109 2 IT Service Management Die in ITIL und COBIT spezifizierten KGIs und KPIs stellen kein unumstößliches Dogma dar. Sie sind Best Practice Empfehlungen und liefern einen Input für die Definition von Kennzahlen. Es empfiehlt sich, die in ITIL und COBIT dokumentierten KPIs und KGIs zu berücksichtigen. Sie sollten aber grundsätzlich hinsichtlich ihrer Anwendbarkeit für die jeweilige IT-Organisation bzw. für die Prozessziele kritisch hinterfragt und nicht ungeprüft übernommen werden. Bei Bedarf ist die Definition abweichender oder zusätzlicher Kennzahlen notwendig. Bei der Definition von KGIs und KPIs ist auch zu prüfen, ob die notwendigen Informationen vorliegen, mit welchem Aufwand die Kennzahlen gewonnen bzw. generiert werden können und welche Datenqualität die Ausgangsinformationen haben. Werden COBIT, ITIL, ISO und die BSC gemäß ihres konzeptionellen Ansatzes als Best Practice verstanden und wird die große Überstimmung der IT Service Management-Prozesse zwischen COBIT und ITIL erkannt (vgl. [Kurth, 2006]), so können diese Ansätze hinsichtlich ihrer Vorteile und Nutzungsmöglichkeit unvoreingenommen bewertet werden. Die folgende Darstellung (auf Basis von [Kurth, 2006], nachfolgende Seite) zeigt, dass es nicht den besten Best Practice Ansatz gibt. Sie zeigt auch, dass die Balanced Scorecard als integratives Instrument in Bezug auf Kennzahlen eingesetzt werden kann, um Ansätze zu verbinden. Es gilt, die jeweiligen Stärken von ITIL und COBIT zu nutzen. COBIT und ITIL haben aufgrund ihrer Entwicklungsgeschichte und Betrachtungsbereiche unterschiedliche Stärken und Schwächen. Es gilt, die jeweiligen Vorteile beider Best Practices zu nutzen. Eine Festlegung auf einen der Best Practice-Ansätze ignoriert die Stärken des anderen Ansatzes und ist nicht zielführend. Werden die IT-Ziele aus der BSC abgeleitet, so können die Prozessziele und die damit in Verbindung stehenden Kennzahlen in die BSC integriert werden. Damit erhält eine Organisation ein durchgängiges Kennzahlensystem. ITIL, ISO und COBIT sind als Bausteine für ein übergreifendes Steuerungssystem zu verstehen. Die jeweiligen Stärken der einzelnen Best Practices können so optimal für die eigene Organisation genutzt werden. In einem durchgängigen Managementsystem können die Prozess-Ziele aus der BSC abgeleitet und mit Best Practices KPIs/KGIs aus ITIL und COBIT hinterlegt werden. 98

110 2.10 Konsequenzen Prozessbeschreibung Enthält keine Prozessbeschreibungen Bekanntheitsgrad Anerkennung Templates Enthält Best Practices für Kennzahlensysteme Kennzahlen ITIL ISO COBIT IT-BSC Detaillierte (generische) Prozessbeschreibungen Seit Mitte der 80er Jahre nachhaltig steigende Bekanntheit und Beliebtheit ITIL Zertifizierung relevant bei Stellenbesetzung; noch verlangte ITIL Konformität wird durch ISO abgelöst Enthält Best Practices für SLA, RFC, Incident- Record etc. Schwache generische Beschreibung der Prozess- Kennzahlen Enthält keine Prozessbeschreibungen, sondern Mindestanforderungen an die ITSM-Prozesse Als internationaler Standard weltweit anerkannt, einzige Möglichkeit einer Zertifizierung Enthält Best Practices für SLA-Inhalte Enthält Anforderungen an Vorhandensein von Kennzahlen, gibt keine vor Enthält keine detaillierten Prozessbeschreibungen Erfährt zunehmende Bedeutung, insbesondere für IT Service Provider Bekanntheitsgrad weiter steigend, insbesondere durch SOX In den USA bei Wirtschaftsprüfern weit verbreitet und zunehmend auch in Europa Enthält Best Practices für IT-Prozesse Bekanntheitsgrad weiter steigend Weltweit anerkannter Managementansatz zur Strategieumsetzung Kennzahlen (-systematik) auch in der Praxis effektiv Integrationswerkzeug für Kennzahlen Eine IT Balanced Scorecard kann verschiedene Ansätze integrieren. 99

111 3 IT Prozess-Management 3.1 Management Summary Die Best Practice-Ansätze von COBIT und ITIL sowie der ISO IT Service Management sind Ansätze für ein prozessorientiertes Management. In diesem Kapitel nun werden die damit verbundenen Anforderungen und Voraussetzungen an das Prozess-Management beschrieben. Von wesentlicher Bedeutung ist dabei die Verankerung des Service Managements und der damit verbundenen IT Service Management-Prozesse in das IT-Management. Wirksame Prozessziele und die damit verbundenen Kennzahlen sowie deren Zielwerte können nur in einem top down-ansatz definiert und verfolgt werden. In diesem Kapitel wird ein praxisbewährtes und konzeptionelles Vorgehen bei der Definition vorgestellt. Die Etablierung von Prozessen erfordert darüber hinaus das Commitment des Managements und die Festlegung der Verantwortlichkeiten. Hierzu werden die Rollen und Verantwortlichkeiten beim Management der IT Service Management-Prozesse beschrieben. Zum Schluss gehen wir auf das Reporting von Prozess-Kennzahlen ein und widmen uns der Frage, wie unterschiedliche Hierarchieebenen Berücksichtigung finden können. 3.2 PDCA-Zyklus ITIL Version 3 geht innerhalb der Publikation Continual Service Improvement expliziert auf ein Regelsystem zur kontinuierlichen Verbesserung von Prozessen und Services ein. Normen, wie die ISO IT Service Management, die ISO Information Security Management oder die ISO 9001 Qualitäts-Management beinhalten die Anforderungen an ein integriertes Managementsystem. Die in diesen Normen und Best Practices beschriebenen Qualitäts-Managementsysteme gehen zurück auf die Managementlehren des amerikanischen Wissenschaftlers W. Edwards Deming 1 zum PDCA-Zyklus (Plan, Do, Check, Act), der als Deming-Zyklus international bekannt geworden ist. Deming selbst wies jedoch darauf hin, dass Walter A. Shewhart 2 diesen Zyklus als Erster beschrieben hatte. 1 William Edwards Deming, Walter Andrew Shewhart, amerikanischer Wissenschaftler,

112 3 IT Prozess-Management Daher wird der PDCA-Zyklus gelegentlich auch als Shewhart-Zyklus bezeichnet (siehe Abbildung 33). Act Verbessern Plan Planen Ständige Verbesserung Check Überprüfen Do Ausführen Abbildung 33: PDCA-Zyklus Der PDCA-Zyklus basiert auf einem prozessorientiertem Managementansatz, der aus den folgenden Phasen besteht (vgl. [ISO , 2005]): Plan (Planen): Die Phase dient der Einführung der Prozesse und der damit verbundenen Ziele, die notwendig sind, um Ergebnisse entsprechend den Kundenanforderungen und den geschäftspolitischen Zielen zu liefern. Do (Ausführen): Innerhalb der zweiten Phase erfolgt die Durchführung (initial die Implementierung) der geplanten Prozesse. Check (Überprüfen): Die dritte Phase dient der Überwachung und Messung der Prozesse und Services gegenüber den geschäftspolitischen Zielen und den 102

113 einzelnen Prozess-/Service-Zielen und Anforderungen, sowie zur Berichterstattung der Ergebnisse. Act (Verbessern): Liegen Ergebnisse aus der Überprüfung vor, so sind diese zu analysieren und geeignete Maßnahmen zu ergreifen, um die Leistungsfähigkeit der Prozesse nachhaltig zu verbessern. Diese identifizierten Verbesserungen finden wiederum Eingang in Plan. Dadurch ist kontinuierliche Verbesserung sichergestellt. Prozess-Management ist eine fortgehende, nicht endende Managementaufgabe. Hierzu hat Deming bereits herausgestellt, dass es kein Optimum gibt und demzufolge immer Verbesserungen identifiziert werden können. Von besonderer Bedeutung ist beim PDCA-Zyklus, dass es ein System ist, welches nicht nur der Prozesseinführung dient, sondern als Managementsystem der kontinuierlichen Verbesserung und so mittel- und langfristig einen wesentlichen Beitrag zum Unternehmenserfolg liefert. Diese Schritte werden ständig wiederholt, um eine kontinuierliche Prozessverbesserung zu erreichen. Daher wird der PDCA-Zyklus auch als Regelzyklus bezeichnet. Die Kennzahlen für IT Service Management-Prozesse stellen eine äußerst wichtige Informationsbasis für die Phase Check dar. Ohne Kennzahlen kann eine Überprüfung der Ergebnisse und Ziele nicht erfolgen und ohne Überprüfung ist eine Verbesserung der Prozesse nicht möglich. Die Kennzahlen für IT Service Management-Prozesse sind für die stetige Prozess-Optimierung ein unerlässliches Werkzeug. Die im Folgenden beschriebene Vorgehensweise mag zum Teil theoretisch klingen oder auch als selbstverständlich angesehen werden, sie hat aber grundlegende Bedeutung für den Erfolg von IT Service Management- Prozessen. Es muss zum Selbstverständnis des Service Managers, Prozess Owners und Prozess Managers werden, dass die Kennzahlen ein unverzichtbares Werkzeug im Rahmen des Prozess-Managements sind. Ohne Kennzahlen ist letztendlich keine Prozessoptimierung und letztendliche Leistungssteigerung möglich. Es ist ein Irrglaube, Kennzahlen aus bestehenden Best Practices bedenkenlos übernehmen zu können. Es geht um die Sicherstellung der Ziele der Organisation und ihrer Kunden. Kennzahlen müssen dementsprechend ausgerichtet und abgebildet werden. 3.2 PDCA-Zyklus 103

114 3 IT Prozess-Management 3.3 Etablierung des Prozess-Managements Bestehende Strukturen in der IT orientieren sich an den eingesetzten Komponenten. Die Gewinnung von Kennzahlen für IT Service Management-Prozesse setzt die Etablierung einer entsprechenden Prozessstruktur voraus. Bevor die Prozessziele definiert und die daraus abgeleiteten Kennzahlen gewonnen werden können, sind die IT Service Management-Prozesse in der Organisation zu verankern. Dazu ist es nicht ausreichend, einzelne in den ITIL Best Practices dokumentierten Aktivitäten umzusetzen oder ausgewählte Control Objectives aus COBIT sicherzustellen. Vielmehr müssen die Prozesse mit einem Prozess-Management in der Organisation etabliert werden. Dazu sind die damit verbundenen Verantwortlichkeiten und Zuständigkeiten für die IT Service Management-Prozesse zu definieren. Dieser organisatorische Akt, der sich in der Praxis häufig als problematisch darstellt, ist für die Einführung der IT Service Management-Prozesse ein äußerst kritischer Erfolgsfaktor. In der Regel sind die bestehenden IT-Organisationen hierarchisch strukturiert, wobei sich deren Struktur stark an den eingesetzten Hardware-Systemen bzw. an Software/Applikationen orientiert. So gibt es Organisationsbereiche, die das LAN, die Datenbanken, die Applikationen oder die Sicherheitskomponenten planen, implementieren und betreuen. Diese Struktur ist historisch gewachsen und hat sich durch die stetig steigende Komplexität der eingesetzten IT-Komponenten ergeben. Der Einsatz der IT- Komponenten setzt entsprechendes Spezialwissen der IT-Mitarbeiter voraus. Zum wirkungsvollen Management dieser Spezialisten werden die IT- Mitarbeiter thematisch in der Organisationsstruktur zu entsprechenden Gruppen, Abteilungen und Bereichen zusammengefasst. Diese Struktur führt häufig dazu, dass die Mitarbeiter innerhalb der IT-Organisation auf den Betrieb Ihrer Systeme ausgerichtet sind und ihr Handeln darauf konzentrieren. Die Kunden- und Servicesicht ist noch nicht in allen IT- Organisation etabliert. Wie im vorhergehenden Kapitel bereits ausgeführt, werden unter dem IT Service ein oder mehrere IT-Systeme verstanden, die einen Geschäftsprozess unterstützen. In der Regel sind damit die Leistungen von mehreren Abteilungen verbunden. Für die IT Services muss es eine Gesamtverantwortung geben, die die Einhaltung der Service Level Agreements sicherstellt. Der Ansatz führt dazu, dass es organisationsübergreifende Verantwortungen geben muss. Analog wie IT Services organisationsübergreifend sichergestellt werden müssen, verhält es sich mit den IT Service Management-Prozessen. Auch diese Prozesse können nur dann wirkungsvoll sein, wenn die Prozesse und damit verbundenen Verantwortlichkeit nicht an Abteilungsgrenzen enden. 104

115 3.3 Etablierung des Prozess-Managements Mit dem fortschreitenden Out-Tasking wird das notwendige Spezialwissen teilweise durch externe Lieferanten beigestellt. Die Einscheidung für ein Out-Tasking wird einerseits getroffen, wenn das notwendige Wissen innerhalb der eigenen IT-Organisation nicht vorhanden ist. Andererseits werden Entscheidungen für ein Out-Tasking häufig aus finanziellen Gründen getroffen. Bei der Integration von externen Lieferanten muss deren Einbindung in die bestehenden IT-Prozesse sichergestellt werden. Diese Festlegung muss vor dem Vertragsschluss erfolgen. In diese Struktur gilt es die IT Service Management-Prozesse nachhaltig zu etablieren Der Charakter von IT-Prozessen Ein Prozess kann wie folgt definiert werden (vgl. Service Design, [OGC, 2007b]): Ein Prozess ist eine strukturierte Folge von Aktivitäten, die geplant werden, um ein bestimmtes Ziel zu erreichen. Ein Prozess benötigt ein oder mehrere definierte Inputs und transformiert diese Inputs zu definierten Outputs. Ein Prozess beinhaltet die notwendigen Rollen, die Verantwortlichkeiten, die Tools und die Management Controls, um den Output zu liefern. Ein Prozess definiert dazu die notwendigen Grundsätze (Policies), Standards, Richtlinien, Aktivitäten und Arbeitsanweisungen. Am Beispiel des Incident Managements soll diese Begriffsdefinition veranschaulicht werden. Die Zielsetzung des Incident Managements besteht darin, den normalen Service-Betrieb so schnell wie möglich wiederherzustellen und die nachteiligen Auswirkungen auf den Geschäftsbetrieb auf ein Minimum zu begrenzen (vgl. [OGC, 2005b]). Ein Input des Incident Managements ist die detaillierte Störungsbeschreibung. Um den Output behobene Störung und abgeschlossene Störungsvorgänge zu erreichen, sind im Prozess des Incident Managements definierte Aktivitäten durchzuführen. Dazu zählen unter anderem die Registrierung der Störung und deren Untersuchung und Diagnose. In einer bestehenden IT-Organisation werden einzelne Aktivitäten des Prozesses häufig in unterschiedlichen Organisationseinheiten, zum Teil auch in unterschiedlichen Organisationen durchgeführt. So wird die Störung im Service Desk registriert, während die notwendige Störbehebung durch den 2nd oder 3rd Level Support in einzelnen Fachgruppen mit Spezialwissen übernommen wird. Dies hat zur Konsequenz, dass die IT- Prozesse organisationsübergreifend durchgeführt werden. 105

116 3 IT Prozess-Management IT-Prozesse durchdringen die gesamte IT-Organisation, schließen gegebenenfalls externe Lieferanten ein und enden demzufolge nicht an bestehenden organisatorischen Grenzen. Die mögliche Bearbeitung eines Incidents könnte wie folgt abgewickelt werden (Abbildung 34): Organisation und EDV Incident Service Desk Daten und Systeme Netze und Kommunikation Client Systeme Serversysteme Datenbanken LAN WAN Externer Onsite Support Abbildung 34: Exemplarische Darstellung der Bearbeitung eines Incidents In dem abgebildeten Beispiel wird der Incident dem Service Desk gemeldet und dort registriert. Nach einer ersten Untersuchung leitet der Service Desk den Incident-Record zur weiteren Bearbeitung an die Gruppe LAN weiter. In dieser Gruppe wird festgestellt, dass das LAN keine Störung aufweist und der Incident-Record wird an die Gruppe Client Systeme weitergegeben. Dort wird festgestellt, dass der Desktop in einer Niederlassung ausgefallen ist und man beauftragt den zuständigen externen Onsite Support mit deren Behebung. Nach der erfolgten Behebung wird der Service Desk entsprechend informiert. Dieses Beispiel einer einfachen Bearbeitung im Incident Management verdeutlicht, dass die IT-Prozesse die gesamte IT-Ogranisation durchdringen und zum Teil externe Lieferanten sowie Kunden einbeziehen. 106

117 3.3 Etablierung des Prozess-Managements Die Aufgabe des Prozess-Managements ist es sicherzustellen, dass der Prozess die definierten Ziele erfüllt. Hierzu definiert ITIL die Prozesssteuerung wie folgt (vgl. Best Practice Service Design, [OGC, 2007b): Die Prozess-Steuerung ist die Aktivität, einen Prozess zu planen und zu regulieren, mit dem Ziel, den Prozess effektiv, effizient und in einer einheitlichen Art und Weise auszuführen. Die damit verbundene Verantwortung der effektiven und effizienten Prozessdurchführung liegt beim Prozess-Management des jeweiligen Prozesses. Auf die einzelnen Rollen im Prozess-Management wird an späterer Stelle in diesem Kapitel eingegangen. Mit der konsequenten Umsetzung der ITIL und COBIT Best Practices wird innerhalb der IT-Organisation aber nicht nur ein Prozess etabliert, sondern eine Vielzahl von Prozessen. Die ISO definiert hierzu, abgesehen von den übergeordneten Management-Prozessen, insgesamt 13 unerlässliche Prozesse. Das führt dazu, dass die bestehende hierarchische IT-Organisation querschnittlich von IT-Prozessen durchdrungen wird (Abbildung 35). Organisation und EDV Incident Management Problem Management Service Desk Daten und Systeme Netze und Kommunikation Change Management Release Management Service Level Management Capacity Management Security Management Client Systeme Serversysteme Datenbanken LAN WAN Externer Onsite Support Abbildung 35: IT-Prozesse und bestehende Aufbauorganisation Damit ergibt sich letztendlich eine Matrixorganisation mit den bekannten strukturellen Problemen. Die Mitarbeiter sind einerseits einer Linienorga- 107

118 3 IT Prozess-Management nisation zugehörig und unterstellt, andererseits haben sie Aktivitäten innerhalb von einem oder mehreren IT Service Management-Prozessen durchzuführen, wofür jeweils ein Prozess Owner bzw. Prozess Manager verantwortlich ist. Diese doppelte Zugehörigkeit zur Linienorganisation und zu den jeweiligen IT Service Management-Prozessen stellt nicht nur die Mitarbeiter der IT-Organisation in ein Spannungsfeld, sondern auch das IT-Management. Ein IT Service Management mit den erforderlichen IT-Prozessen kann nur dann erfolgreich etabliert werden, wenn die Verantwortlichkeiten zwischen Linienorganisation und Prozess-Management festgelegt werden. Die angestrebte Transparenz führt nicht nur zu Ängsten bei Mitarbeitern sondern auch bei der verantwortlichen Linienorganisation. Denn wer möchte schon transparent sein? Wenn eine IT-Organisation es nicht schafft diese Probleme zu lösen, zum Beispiel durch ein begleitendes Veränderungs-Management und die aktive Beteiligung der Betroffenen, so werden die IT Service Management-Prozesse nicht wirkungsvoll sein. Die notwendige und als Ziel gesetzte Transparenz hinsichtlich der Leistungsfähigkeit und des Optimierungspotenzials der Prozesse und der IT Services wird dann ggf. als Bedrohung empfunden und kann nicht erreicht werden. Fehlt die notwendige Unterstützung, so werden die ermittelten Kennzahlen unter Umständen ein fehlerhaftes Bild darstellen und letztendlich wenig zielführend sein. So wie ein Veränderungsmanagement und die Überzeugung notwendig sind, so muss aber andererseits auch sichergestellt werden, dass die festgelegten Prozesse und Aktivitäten auch einzuhalten sind. Wird festgestellt, dass diese Vorgaben nicht eingehalten werden, so müssen damit spürbar Konsequenzen verbunden sein. Auch die Durchsetzung dieser Konsequenzen gehört zur Managementverantwortung. Im Einzelfall kann es durchaus vorkommen, dass vom Prozess abweichend gehandelt werden musste. Dies wird bei der Implementierung neuer Prozesse durchaus vorkommen. Dann muss aber sichergestellt werden, dass die notwendige Abweichung kommuniziert wird und zum Input für eine Prozessanpassung wird (im Sinne des PDCA-Zyklus). Ein IT Service Management mit den erforderlichen IT-Prozessen verlangt das Commitment des gesamten Managements. Es liegt in der Verantwortung des gesamten Managements, zum Erfolg des IT Service Managements aktiv beizutragen. Dies erfolgt sowohl durch ein begleitendes Veränderungs-Management, als auch durch Konsequenzen bei der Nichteinhaltung von getroffenen Vorgaben. Damit das IT Service Management erfolgreich innerhalb einer hierarchischen Organisationsstruktur betrieben werden kann, sind die Verantwort- 108

119 3.3 Etablierung des Prozess-Managements lichkeiten eindeutig zu definieren. Diese Definition betrifft einerseits die Abgrenzung zwischen der Linien- und Prozessverantwortung. Andererseits sind auch für das IT Service Management die Verantwortlichkeiten festzulegen. Dazu sind die wahrzunehmenden Rollen im Prozess- Management zu spezifizieren Rollen im Prozess-Management Die hier verwendeten Begriffe sind in IT-Organisation zum Teil mit anderen Aufgaben und Verantwortlichkeiten hinterlegt. Es ist daher im Rahmen der Implementierung zu prüfen, ob für die folgenden Rollen bestehende Begriffsdefinitionen bzw. die hier dokumentierten Rollenbezeichnungen anzupassen sind. Analog zu den ITIL Best Practices stellen die folgenden Rollenschreibungen Empfehlungen dar, deren Umsetzung von der jeweiligen Situation abhängig ist. So wird eine kleine IT-Organisation nicht einen Prozess Manager und einen Prozess Owner etablieren, sondern diese Aufgaben zusammenführen. Die hier beschrieben Rollen entsprechen den ITIL Best Practices (vgl. [OGC, 2007b) bzw. der ISO (vgl. [ISO , 2005): Service Manager Obwohl es bereits seit vielen Jahren eine offizielle Ausbildung und eine international anerkannte Zertifizierung zum ITIL Service Manager (vgl. [KESS, 2007a]) gibt, war diese Rolle in der ITIL Version 2, abgesehen von der Publikation Business Perspective Volume 2, nicht explizit beschrieben. In einigen Textpassagen wurde zwar auf einen Service Manager hingewiesen, aber eine Rollenbeschreibung hierfür lag nicht vor. In der ITIL Version 3 ist auch die Rolle des Service Managers beschrieben (vgl. [OGC, 2007e]): Der Service Manager ist eine wichtige Rolle für die Entwicklung, Implementierung, Evaluation und das fortlaufende Management neuer und existierender Produkte und Services. Seine Verantwortung umfasst die Entwicklung der Geschäfts-Strategie, Markt- und Kunden-Analyse, Lieferanten-Management, Inventarisierung, Kosten Management und insbesondere das Auslieferungs- und Lebenszyklus-Management von Produkten und Services. Die ISO empfiehlt, dass ein Mitglied des oberen Managements ( senior level ) die Verantwortung für den Service Management-Plan und dessen Umsetzung übernehmen sollte (vgl. [ISO , 2005]). Innerhalb dieses Service Management-Plans wird die Zielsetzung und Ausgestaltung des IT Service Managements beschrieben. 109

120 3 IT Prozess-Management Daraus folgt, dass es eine den einzelnen Prozess Ownern und Prozess Managern vorgesetzte Instanz gibt und diese dem oberen Management angehört. Das IT Service Management und die damit verbundenen Prozesse dienen keinem Selbstzweck, sondern sind in die IT-Planung und -Strategie einzubinden. Letztendlich leiten sich die konkrete Ausrichtung der Prozesse und ihre Zielsetzung aus den Business-Anforderungen und der IT- Strategie ab. Dabei kann sich die konkrete Ausprägung in Abhängigkeit von den aktuellen Business-Anforderungen und der IT-Strategie durchaus ändern. So besteht zum Beispiel die Zielsetzung des Capacity Managements gemäß ITIL darin, dass... die aktuellen und zukünftigen geschäftlichen Anforderungen im Hinblick auf Kapazitäten und Performance auf wirtschaftliche Weise erfüllt werden.... Befindet sich eine Organisation in einer starken Wachstumsphase, so wird das Capacity Management auf die Bereitstellung der erforderlichen Kapazitäten fokussiert sein. Muss die Organisation dagegen primär Kosten einsparen, so gewinnt die Wirtschaftlichkeit der Bereitstellung in der Regel ein größeres Gewicht. Die grundsätzliche Zielsetzung an ein Capacity Management ändert sich zwar nicht, aber die konkrete Ausgestaltung der Ziele ist abhängig von den Geschäftsanforderungen. Daher benötigen die Prozess Owner und Prozess Manager entsprechende Vorgaben, die in die Prozessziele eingehen und letztendlich auch Auswirkungen auf das Kennzahlensystem haben. Diese Vorgaben werden vom oberen Management getroffen und liegen in der Verantwortung des Service Managers. Eine weitere Aufgabe des Service Managers besteht darin, eine Eskalationsebene für die Prozess Owner und Prozess Manager zu bieten, da die einzelnen IT Service Management-Prozesse durchaus konkurrierende Ziele verfolgen können. Der Service Manager kann mit einem Städteplaner verglichen werden, während die Prozess Owner und Prozess Manager die Architekten und die Bauaufsicht darstellen Prozess Owner Der Prozess Owner ist für die Zielerreichung des jeweiligen Prozesses verantwortlich. Der Prozess Owner hat demzufolge die Ergebnisverantwortung für den jeweiligen Prozess. Eine Möglichkeit, die Verantwortlichkeiten für Aktivitäten übersichtlich darzustellen, besteht mittels einer RACI-Matrix. Dabei leitet sich der Name aus den vier Verantwortlichkeiten Responsible, Accountable, Con- 110

121 3.3 Etablierung des Prozess-Managements sulted und Informed ab. Dabei wird Responsible als Verantwortung für die Durchführung verstanden. Accountable ist dagegen die Person, die die Gesamt- und letztendlich die Ergebnisverantwortung trägt. Bei der Darstellung in Form der RACI-Matrix werden in einer Matrix Rollen gegenüber Aktivitäten aufgetragen (Abbildung 36). Durch Eintragen der Buchstaben R, A, C und I werden die Aktivitäten den Rollen zugeordnet. Diese Form zur Darstellung der Prozessaktivitäten und Rollen (Funktionen innerhalb der Organisation) wird von ITIL und COBIT genutzt. Role Responisibility Change sponsor, e.g. business and IT leaders Change enabler, e.g. process owners, service owners Change agent, e.g. team leader instructing change Change target, e.g. individual performing the change Articulate a vision for the business and service change in their domain Recognize and handle resistance to change Initiate change, understand the levers for change and the obstacles Manage change and input to change plan A/R A/R C I A/R A A C A/R A/R C C A/R A/R C C Abbildung 36: Ausschnitt der RACI-Matrix zum Change Management (vgl. [OGC, 2007c]) Die Definition der zu erreichenden Ziele wird mit dem Service Manager abgestimmt und entsprechend dokumentiert. In der ITIL Version 3 wird die Rolle des Prozess Owners wie folgt definiert (vgl. [OGC, 2007b): Der Prozess Owner ist dafür verantwortlich, dass ein Prozess zweckmäßig ist. Die Verantwortung des Prozess Owners schließt die Unterstützung, das Design, das Change Management und die beständige Verbesserung des Prozesses und der damit verbunden Messsysteme ein. Die Definition von Kennzahlen setzt definierte Prozessziele voraus Auf Basis der definierten Ziele legt der Prozess Owner gemeinsam mit dem Prozess Manager die damit verbundenen Kennzahlen fest. Erst mithilfe dieser Kennzahlen kann gesichert festgestellt werden, ob der Prozess 111

122 3 IT Prozess-Management die definierten Ziele hinsichtlich der erwarteten Effektivität und Effizienz erreicht. Die Kennzahlen (KGI, KPI) sind top down zu entwickeln. Aus den Business- Anforderungen und der IT-Strategie ergeben sich die jeweiligen Prozessziele. Mittels der definierten Kennzahlen erfolgt dann das Management der Prozesse, um die geforderte Effektivität und Effizienz zu erreichen. Die Kennzahlen signalisieren dem Prozess Owner, ob die definierten Ziele erreicht werden. Es hat sich bewährt, dass der Prozess Owner dem IT-Management angehört. So ist einerseits die Abstimmung mit den Business-Anforderungen sowie mit der IT-Strategie sichergestellt. Anderseits erfährt der Prozess die notwendige Managementunterstützung. Es kann durchaus vorgekommen, dass der Prozess Manager innerhalb der Organisation auftretende Widerstände überwinden muss. Hier kann ihm ein Prozess Owner aus dem IT- Management die notwendige Unterstützung bieten. Außerdem wird damit ein wichtiges Signal für alle Mitarbeiter gegeben: IT Service Management wird von unserem Management aktiv gefördert. Dies setzt aber selbstverständlich voraus, dass das IT-Management die Prozesse aktiv vorlebt und sich selbst an diese Prozesse hält Prozess Manager Die Verantwortung des Prozess Managers besteht in der erfolgreichen Umsetzung des Prozesses auf Basis der definierten Ziele. Der Prozess Manager ist für die Durchführung des Prozesses verantwortlich. In der ITIL Version 3 wird die Rolle des Prozess Managers wie folgt definiert (vgl. [OGC, 2007b): Der Prozess Manager ist für das operationelle Management des Prozesses verantwortlich. Die Verantwortung des Prozess Managers umfasst die Planung und Koordinierung aller Aktivitäten, deren Monitoring und deren Berichterstattung. In größeren Organisationen kann es durchaus mehrere Prozess Manager für einen Prozess geben, wie zum Beispiel regionale Change Manager pro Niederlassung. In kleineren IT-Organisationen erfolgt keine Unterteilung zwischen Prozess Owner und Prozess Manager. Die Ergebnis- und Durchführungsverantwortung wird dann gemeinsam wahrgenommen. Im Rahmen der Durchführungsverantwortung gestaltet der Prozess Manager den Prozess und definiert die durchführenden Aktivitäten. Er stellt sicher, dass der Prozess mit den notwendigen Ressourcen unterstützt wird. Der Prozess Manager hat dazu die kritischen Erfolgsfaktoren (CSF: Critical 112

123 3.3 Etablierung des Prozess-Managements Success Factors) zu identifizieren und durch geeignete Maßnahmen abzusichern (= Plan im PDCA-Zyklus). Mögliche Schwachstellen im Prozess sind vom Prozess Manager zu analysieren und durch geeignete Verbesserungsmaßnahmen nachhaltig zu beseitigen (= Act im PDCA-Zyklus). Angesichts der Komplexität der Prozesse und der verschiedenen Beteiligten in unterschiedlichen Organisationseinheiten benötigt der Prozess Manager hierzu eine gesicherte Informationsbasis, er benötigt Prozesskennzahlen (= Check im PDCA-Zyklus). Die Prozess-Kennzahlen sind Indikatoren. Sie informieren über die Zielerreichung bzw. über das Verlassen eines Zielbereichs. Unter der weiteren Berücksichtigung von Trendinformationen kann so der Prozess Manager aktiv werden. Die Indikatoren zeigen an, dass etwas passiert. Ein Indikator kann zum Beispiel sein, dass die definierten Lösungszeiten für Incidents nicht eingehalten werden, oder dass die Implementierung von Changes zu Incidents führt. Ein Indikator zeigt aber nicht an, warum etwas passiert ist. Kennzahlen sind die Arbeitsinstrumente des Prozess Managers. Die Kennzahlen sind für den Prozess Manager ein äußerst wichtiges Management-Werkzeug. Sie signalisieren was im Prozess passiert und in Verbindung mit Trenddaten wie sich der Prozess entwickelt. Nur mit entsprechenden Kennzahlen kann der Prozess Manager seiner Verantwortung nachkommen. Um feststellen zu können, warum etwas passiert ist, muss der Prozess Manager einzelne Kennzahlen in Zusammenhang bringen. Zum Beispiel könnte geprüft werden, ob neue Services eingeführt wurden und damit erklärbar wird, warum die Lösungszeiten den vorgegeben Wert nicht mehr erreichen. Der Prozess Manager muss hierzu die Einflussfaktoren identifizieren, Zusammenhänge zuordnen und letztendlich die eigentlichen Ursachen analysieren (= Check im PDCA-Zyklus). Die IT Service Management-Prozesse sind gekennzeichnet durch wechselseitige Aktivitäten. Der Prozess Manager benötigt daher nicht nur das Know-how für seinen eigenen Prozess, sondern muss auch über Grundlagenwissen zu den anderen Prozessen verfügen. Ohne dieses Wissen kann der eigene Prozess nicht erfolgreich gestaltet und gesteuert werden. Hinzu kommt, dass Kennzahlen zum Teil aus Daten anderer Prozesse generiert werden. So ist eine wichtige Kennzahl im Change Management Anzahl von Störungen, die auf Änderungen zurückgeführt wurden. Die Generierung dieser Kennzahl benötigt demzufolge Informationen aus dem Incident Management. Hierzu muss der Prozess Manager um das beschriebene Grundlagenwissen zu allen IT Service Management-Prozessen verfügen. Andererseits muss er die Ermittlung bzw. Nutzung der benötigen Daten mit einem anderen Prozess Manager abstimmen. 113

124 3 IT Prozess-Management Der Prozess Manager benötigt Grundlagenwissen zu allen IT Service Management-Prozessen. Bei der Gestaltung des Prozesses und der Definition der Kennzahlen ist eine enge Zusammenarbeit mit den anderen Prozess Managern von großer Bedeutung Prozess-Mitarbeiter Die Prozess-Mitarbeiter sind für bestimmte Aktivitäten in einem Prozess verantwortlich und berichten dem Prozess Manager. Sie führen die Aktivitäten im Prozess durch, die ihrer fachlichen Qualifikation entsprechen. Neben der entsprechenden theoretischen Schulung benötigen die Mitarbeiter auch das Wissen um die konkrete Zielsetzung des Prozesses. Hierzu empfiehlt es sich, zunächst auch die Prozess-Mitarbeiter in den ITIL Grundlagen zu schulen und anschließend die Prozessschulungen durchzuführen. Mit der Einführung von Prozessen ändern sich häufig bestehende Abläufe und durchzuführende Aktivitäten. Kennzahlen unterstützen hierbei das notwendige Veränderungsmanagement. Anhand von Kennzahlen kann den Prozess-Mitarbeitern dargestellt werden, wie wirksam der Prozess ist und wie ihre Leistungen sowie die veränderten Arbeitsweisen zum erzielten Erfolg beitragen. Nach Möglichkeit sollten die Kennzahlen nicht nur dem Management zur Verfügung stehen. Auch die IT-Mitarbeiter sollten hierauf Zugriff haben. Kennzahlen sind informations- und/ oder mitbestimmungspflichtig Betriebs- und Personalrat Abschließend muss an dieser Stelle auf den Betriebs- bzw. Personalrat eingegangen werden. Die Kennzahlen zu den einzelnen Prozessen werden häufig aus operativen Systemen, wie zum Beispiel den Daten eines IT Service Management-Tools, generiert. Damit greifen die Kennzahlensysteme auf Daten zurück, die die Möglichkeit zur Leistungsbeurteilung von Mitarbeitern eröffnen. Innerhalb Deutschlands ist für die Erfassung und Auswertung derartiger Daten die Zustimmung des Betriebs- bzw. Personalrats erforderlich. Die geplanten Kennzahlen zur Beurteilung der IT Service Management-Prozesse sollten frühzeitig mit dem Betriebs- bzw. Personalrat abgestimmt werden. Insbesondere sollte dem Betriebs- bzw. Personalrat dargelegt werden, dass das System der Beurteilung von Prozessen dient und nicht der Beurteilung von Mitarbeitern. 114

125 3.4 Definition der Prozessziele und -Kennzahlen Definition der Prozessziele 3.4 Definition der Prozessziele und -Kennzahlen Die hier dargestellte Vorgehensweise der Zieldefinition und die daraus abgeleiteten Kennzahlen basieren auf erfolgreich durchgeführten ISO Projekten. Im Rahmen dieser Projekte wurden mit dem im Folgenden beschriebenen Konzept die ISO Anforderungen an das übergeordnete Managementsystem sichergestellt, und so die Basis für eine erfolgreiche Zertifizierung gelegt. Ungeachtet einer ISO Zertifizierung empfiehlt es sich jedoch generell, diese Vorgehensweise bei der Einführung von IT Service Management-Prozessen zu nutzen. Diese Vorgehensweise entspricht auch der ITIL Version 3 mit dem beschriebenen Service Lifecycle und der Service Strategy als Mittelpunkt bzw. Ausgangspunkt des Service Lifecycle. Die hier beschriebene Vorgehensweise stellt sicher, dass die IT Service Management-Prozesse den Geschäftsanforderungen entsprechen, in die IT-Strategie eingebunden sind und die definierten Ziele mit endlichen Ressourcen wirkungsvoll erreicht werden können. Die Kennzahlen und deren Zielwerte sind unmittelbar mit den Prozesszielen verbunden. Daher können die Kennzahlen und deren Zielwerte erst dann definiert werden, wenn die konkreten Prozessziele spezifiziert sind. Mithilfe von COBIT und ITIL kann dann geprüft werden, welche Best Practice Kennzahlen sich hierfür anbieten. In Projekten mussten darüber hinaus aufgrund der Prozessziele zum Teil Kennzahlen definiert werden, die in COBIT und ITIL nicht spezifiziert sind. Mögliche KPI, KGI aus COBIT und ITIL auszuwählen, ohne die Prozessziele zuvor definiert zu haben, ist nicht zielführend. Gegebenenfalls sind Kennzahlen zu spezifizieren, die in COBIT und ITIL nicht dokumentiert sind. Die Prozessziele und die damit verbundenen Kennzahlen sowie deren Zielwerte sind in dem bereits zuvor angesprochenen top down-ansatz zu definieren. Ein wichtiger Ausgangspunkt bei der Definition von Prozesszielen sind die Anforderungen des Kunden bzw. dessen Geschäftsprozesse. Die Anforderungen aus den Geschäftsprozessen beziehen sich in erster Linie auf die bereitzustellenden IT Services. In der Regel liegen die damit verbundenen (internen) IT Service Management-Prozesse der IT nicht im Blickpunkt des Kunden. Der Kunde benötigt die IT Services zur Durchführung seiner Geschäftsprozesse und die IT hat dies gemäß den getroffenen Vereinbarungen sicherzustellen. Wie diese Bereitstellung bestmöglich erfolgt, über- 115

126 3 IT Prozess-Management lässt der Kunde der IT-Organisation, in deren Verantwortung die entsprechende Umsetzung grundsätzlich liegen sollte. Die Anforderungen an die IT Services werden mittels SLAs spezifiziert (siehe Abbildung 37). Daraus abgeleitet werden die OLAs sowie die UCs verhandelt und vereinbart. Anhand dieser Vereinbarungen sind die jeweiligen Service Level sowie die Kapazitätsanforderungen zu messen, zu berichten und regelmäßigen Reviews zu unterziehen. Business Business-Anforderungen Messung IT-Services Service Level (Ziele) SLA (OLA/UC) Kapazitäten Abbildung 37: Definition der IT Services Werden Verbesserungsmaßnahmen identifiziert, sind diese gemäß ITIL und der ISO in einem Service Improvement Plan (SIP) zu dokumentieren. Betreffen diese Verbesserungsmaßnahmen die implementieren IT Service Management-Prozesse, so werden sie im Prozess Improvement Plan (PIP) des jeweiligen Prozesses dokumentiert (siehe Abbildung 38). In der ISO werden zwar Reviews in den Prozessen und deren Dokumentation gefordert, aber nicht näher spezifiziert, wo diese Dokumentation zu erfolgen hat. In der Projektpraxis hat sich herausgestellt, dass der SIP hierfür wenig geeignet ist, da hier eine Vermischung von Informationen erfolgt. Für die Dokumentation sind daher die PIPs zu definieren. Dieses Konzept wurde erstmalig erfolgreich bei der ISO Zertifizierung der badenit umgesetzt und wird im Folgenden vorgestellt. 116

127 3.4 Definition der Prozessziele und -Kennzahlen Business Business-Anforderungen Messung IT-Services Service Level (Ziele) SLA (OLA/UC) Kapazitäten Verbesserungspotenzial Service Improvement Plan (SIP) Prozess Improvement Pläne (PIP) Abbildung 38: Definition der IT Services Service Improvement Plan Bei Kunden-Anforderungen an neue IT Services und bei veränderten Anforderungen an bestehende IT Services (siehe Abbildung 39) ist zu prüfen, ob die etablierten IT Service Management-Prozesse diesen Anforderungen genügen oder unter Umständen die Prozessziele sowie die damit verbundenen Prozessaktivitäten anzupassen sind. Außer den Anforderungen an die IT Services gibt es weitere übergeordnete Kunden- und Geschäfts-Anforderungen an die IT-Organisation, die Auswirkungen auf die IT Service Management-Prozesse haben (siehe Abbildung 40). Zu den Geschäftsanforderungen des Business gehören zum Beispiel die Forderungen nach einem IT Qualitätsmanagement, nachgewiesen durch die ISO Zertifizierung. Als zweiter Block stehen die regulativen Anforderungen (Compliance Anforderungen) wie zum Beispiel SOX, Euro SOX, Basel II oder GXP für Unternehmen in der Pharma- Branche. Diese Anforderungen haben Auswirkungen auf die IT Service Management-Prozesse, deren Zielsetzung und letztendlich auf die damit verbundenen Kennzahlen. 117

128 3 IT Prozess-Management Business Business-Anforderungen Messung Service Level (Ziele) SLA (OLA/UC) IT-Services Neue oder veränderte IT-Services Kapazitäten Service Improvement Plan (SIP) Prozess Improvement Pläne (PIP) Abbildung 39: Definition der Prozessziele Neue Services Business Business-Anforderungen Messung Service Level (Ziele) SLA (OLA/UC) IT-Services Neue oder veränderte IT-Services Kunden- Anforderungen Geschäfts- Anforderungen Kapazitäten Verbesserungspotenzial Verbesserungspotenzial Service Improvement Plan (SIP) Prozess Improvement Pläne (PIP) Abbildung 40: Definition der Prozessziele Kundenanforderungen 118

129 3.4 Definition der Prozessziele und -Kennzahlen Auf Basis der geschäftspolitischen Ziele des Unternehmens, die größtenteils bereits in den zuvor genannten Anforderungen beschrieben sind, wird die IT-Strategie entwickelt (siehe Abbildung 41). Im Rahmen der Entwicklung und Weiterentwicklung der IT Service Management-Prozesse sind diese strategischen Ziele ebenfalls zu berücksichtigen. Business Business-Anforderungen Messung Service Level (Ziele) IT-Services Neue oder SLA veränderte (OLA/UC) IT-Services Kunden- Anforderungen Geschäfts- Anforderungen IT- Strategie Kapazitäten Verbesserungspotenzial Service Improvement Plan (SIP) Prozess Improvement Pläne (PIP) Abbildung 41: Definition der Prozessziele IT-Strategie Auch mögliche finanzpolitische Aspekte haben Auswirkungen auf die IT Service Management-Prozesse und deren Ziele. Dies wird in der ITIL Version dadurch zum Ausdruck gebracht, dass das Financial Management der Service Strategy zugeordnet ist. Die Geschäftsanforderungen an das Service Management können im Rahmen einer übergeordneten Balanced Scorecard und einer daraus abgeleiteten IT Balanced Scorecard vorgegeben werden. Diese Durchgängigkeit von der Balanced Scorecard zu den Zielen des Service Managements und den Prozesszielen hat zum Beispiel die badenit in Freiburg erfolgreich umgesetzt. Im Rahmen der ISO Zertifizierung wurde dieser Aspekt von den Prüfern besonders positiv hervorgehoben. Dem Kapitel 6 Lessons learned ist ein weiteres Beispiel für die Ableitung der Service Management-Prozess-Ziele aus der IT-Strategie und der BSC zu entnehmen. 119

130 3 IT Prozess-Management Eine weitere Quelle für die Definition der Prozessziele der IT Service Management-Prozesse, damit deren Kennzahlen und Sollwerte, sind die Ergebnisse der Prozess Improvement Pläne (PIPs). In diesen Plänen ist prozessbezogen der jeweils identifizierte Verbesserungsbedarf der IT Service Management-Prozesse dokumentiert (siehe Abbildung 42). Der Verbesserungsbedarf wird im Rahmen von Audits und Reviews sowie anhand der vorliegenden Prozess-Kennzahlen, deren Sollwerten und der nachfolgenden Analysen des Prozesses ermittelt. Business Business-Anforderungen Messung Service Level (Ziele) IT-Services Neue oder SLA veränderte (OLA/UC) IT-Services Kunden- Anforderungen Geschäfts- Anforderungen IT- Strategie Kapazitäten Verbesserungspotenzial Service Improvement Plan (SIP) Verbesserungspotenzial Prozess Improvement Pläne (PIP) IT Service Management- Prozesse Abbildung 42: Definition der Prozessziele Prozess Improvement Plan Diese Informationen sind der Input für die Planung und Implementierung des IT Service Managements (siehe Abbildung 43). Im Rahmen der Planung und Implementierung des IT Service Managements wird die Ausgestaltung des gesamten Systems durchgeführt. Dazu zählt auch die Festlegung der Ziele für die einzelnen Service Management-Prozesse. 120

131 3.4 Definition der Prozessziele und -Kennzahlen Diese übergeordnete Management-Aufgabe ist nicht als einmaliger Vorgang zu verstehen, sondern sie ist eine fortlaufende Aktivität und entspricht dem kontinuierlichen Verbesserungsprozess gemäß PDCA-Zyklus. Die Planung und Implementierung des IT Service Managements ist kein Projekt, sondern ein übergeordneter Management-Prozess. Business Business-Anforderungen Messung Service Level (Ziele) IT-Services Neue oder SLA veränderte (OLA/UC) IT-Services Kunden- Anforderungen Geschäfts- Anforderungen IT- Strategie Kapazitäten Verbesserungspotenzial Service Improvement Plan (SIP) Planung und Implementierung des IT Service Managements Verbesserungspotenzial Prozess Improvement Pläne (PIP) IT Service Management- Prozesse Abbildung 43: Definition der Prozessziele Planung und Implementierung Mit diesem übergeordneten Management-Prozess wird sichergestellt, dass die IT Service Management-Prozesse auf die Geschäftsziele und daraus abgeleitete IT-Strategie ausgerichtet sind. Durch die kontinuierliche Anpassung an eine sich ändernde Umgebung und durch die laufende Erfolgsüberprüfung wird die Nachhaltigkeit der implementierten Prozesse sichergestellt. Das Ergebnis der Planung und Implementierung des IT Service Managements sind die Zielvorgaben für die einzelnen IT Service Management- Prozesse. Diese Vorgaben sind ein Teil des dokumentierten Service Ma- 121

132 3 IT Prozess-Management nagement Plans (SMP). Während im Service Improvement Plan (SIP) die identifizierten Serviceverbesserungen definiert sind, enthält der Service Management Plan (SMP) die Dokumentation des aktuellen IT Service Management-Systems. Dieser SMP wird als Dokumentation von der ISO gefordert. Zusätzlich fließen die Ergebnisse aus Planung und Implementierung des IT Service Managements in die Prozess-Management Pläne (PMPs) ein (siehe Abbildung 44). Durch die PMPs werden auf Prozessebene die übergeordneten Managementziele für den jeweiligen Prozess konkretisiert. Der PMP kann als Prozessdokumentation mit allen notwendigen Informationen wie Prozessbeschreibung, Kennzahlen und deren Zielwerte, etc. angesehen werden. Business Business-Anforderungen Messung Service Level (Ziele) IT-Services Neue oder SLA veränderte (OLA/UC) IT-Services Kunden- Anforderungen Geschäfts- Anforderungen IT- Strategie Kapazitäten Verbesserungspotenzial Service Improvement Plan (SIP) Planung und Implementierung des IT Service Managements Verbesserungspotenzial Prozess Improvement Pläne (PIP) Anforderungen Anforderungen Service Management Plan (SMP) IT Service Management- Prozesse Prozess Management Pläne (PMP) Abbildung 44: Definition der Prozessziele Service Management Plan 122

133 3.4 Definition der Prozessziele und -Kennzahlen Der hier beschriebene Managementansatz mag zunächst komplex und administrativ erscheinen, aber er stellt letztendlich die wirksame Ausrichtung des IT Service Managements sicher und sorgt für einen zielgerichteten Einsatz der Ressourcen. Die Verantwortung für diesen übergeordneten Prozess liegt beim Top-Management der IT-Organisation in der Rolle des Service Managers. Der Service Manager führt diese Aufgaben durch und stellt das übergeordnete Management-System sicher. Ein Prozess-Management führt mittel- und langfristig zu Erfolgen. Gegebenenfalls sind Quick-Wins abhängig von der bestehenden Ist-Situation zu erzielen, sie stehen aber nicht im Fokus eines Prozess-Managements. Der hier beschriebene konzeptionelle Management-Ansatz erfüllt die Anforderungen der ISO Dieser Management-Ansatz stellt sicher, dass die konkrete Zielsetzung der einzelnen IT Service Management-Prozesse aus den Geschäftsanforderungen stringent abgeleitet wird. Im nächsten Kapitel wird dargestellt, wie die Kennzahlen und Sollwerte auf Basis der Zielsetzung definiert werden. Damit wird letztendlich sichergestellt, dass die Kennzahlen unmittelbar oder mittelbar mit den Geschäftsanforderungen der Kunden korrespondieren. Die ISO dokumentiert die Anforderungen an dieses Management- System und kann zum Nachweis der Konformität herangezogen werden (siehe Abbildung 45). Die konkrete Umsetzung ist Projektaufgabe. Es können zwar dezentral einzelne Service Management-Prozesse implementiert werden und einzelne beschriebene Aktivitäten umgesetzt werden, aber die Etablierung eines IT Service Managements verlangt unabdingbar das Management-Commitment und eine Integration in die bestehenden Management-Prozesse sowie in die IT-Strategie. 123

134 3 IT Prozess-Management Business Business-Anforderungen Messung Service Level (Ziele) IT-Services Neue oder SLA veränderte (OLA/UC) IT-Services Kunden- Anforderungen Geschäfts- Anforderungen IT- Strategie Kapazitäten Verbesserungspotenzial Service Improvement Plan (SIP) Planung und Implementierung des IT Service Managements Verbesserungspotenzial Prozess Improvement Pläne (PIP) Konformität Anforderungen Anforderungen ISO IT Service Management Service Management Plan (SMP) IT Service Management- Prozesse Prozess Management Pläne (PMP) Abbildung 45: Konformität des Managementsystems Die Prozessdokumentation stellt die Leitlinien dar Definition der Prozess-Kennzahlen Auf der Basis der definierten Ziele sind die Control Objectives zu spezifizieren, die Prozessaktivitäten zu definieren und die kritischen Erfolgsfaktoren zu ermitteln. Das Prozessdesign erfolgt letztendlich auf der Basis der zuvor festgelegten Prozessziele (siehe Abbildung 46). Der Umfang der zu erstellenden Prozessdokumentation ist abhängig von der jeweiligen Unternehmenskultur. Es ist ein Kompromiss zu finden zwischen der Dokumentation notwendiger Informationen und Vorgaben einerseits und einem ausreichenden Gestaltungsspielraum für die Mitarbeiter andererseits. Hier sollte nicht der Anspruch bestehen, dass der erste Entwurf alle Eventualitäten abdeckt und fehlerfrei ist. Erfahrungsgemäß ergibt sich im täglichen Betrieb ein Optimierungsbedarf. Diese Einstellung und Erwartungshaltung sollte auch gegenüber den Mitarbeitern kommuniziert werden. 124

135 3.4 Definition der Prozessziele und -Kennzahlen Die Mitarbeiter sollten aufgerufen werden, den notwendigen Verbesserungsbedarf zu identifizieren und an den Prozess Manager weiterzugeben. Es darf nicht an fehlerhaften Abläufen festgehalten werden. Allerdings sind notwendigen Abweichungen in die richtigen Bahnen zu lenken und Änderungen müssen Einzug in die Prozessdokumentation finden. Service Management Plan (SMP) Prozess Management Plan (PMP) IT Service Management- Prozesse Wird sichergestellt durch Aktivitäten Kritische Erfolgsfaktoren Control Objectives Abbildung 46: Prozess-Management Prozessdesign Zeitgleich mit dem Prozessdesign und vor der Implementierung sind die Kriterien festzulegen, die die Überprüfung des Prozesses sicherstellen. Zunächst geht es darum zu überprüfen, ob die definierten Prozessziele erreicht werden. Das heißt, es wird die Effektivität des Prozesses überprüft. Darüber hinaus gilt es im Rahmen der Prozessdurchführung festzustellen, ob und wie die definierten Prozessaktivitäten durchgeführt werden und ob die Control Objectives und die kritischen Erfolgsfaktoren sichergestellt werden. Diese Überprüfungen können mit Kennzahlen und den zugehörigen Sollwerten, Reviews und Audits durchgeführt werden. Dabei gehen die Ergebnisse aus den durchgeführten Reviews und Audits wiederum in Kennzahlen ein (siehe Abbildung 47). Mit diesen Überprüfungen wird die Wirksamkeit des Prozesses, betrachtet in den Dimensionen Effektivität und Effizienz, sichergestellt. Die Kennzahlen stehen in einem unmittelbaren Bezug zu den Prozesszielen. Die Kennzahlen und die damit verbundenen Sollwerte werden aus den Prozesszielen abgeleitet. 125

136 3 IT Prozess-Management Service Management Plan (SMP) Prozess Management Plan (PMP) IT Service Management- Prozesse Wird sichergestellt durch Aktivitäten Kritische Erfolgsfaktoren Control Objectives Überprüfen / Verbessern Kennzahlen (KPI, KGI) Reviews/ Audits Abbildung 47: Prozess-Management Überprüfung Bei der Ausgestaltung (Prozessdesign) der Prozesse und der Definition der Kennzahlen (KGI, KPI), sowie bei den durchzuführenden Audits und Reviews unterstützten die Best Practices von COBIT und ITIL (siehe Abbildung 48). Diesen Publikationen können entsprechende praxiserprobte Empfehlungen entnommen werden. Unter Umständen können aber zu den definierten Prozesszielen keine entsprechenden Kennzahlen aus COBIT und ITIL entnommen werden. In diesem Falle müssen die entsprechenden Kennzahlen und deren Zielwerte im Rahmen des Prozessdesigns definiert werden. COBIT und ITIL enthalten dokumentierte Best Practices für Kennzahlen. Es ist aber ein Irrglaube, diese Kennzahlen einfach übernehmen zu können. Vielmehr sind zunächst die Prozessziele zu definieren. Aus den Prozesszielen werden Kennzahlen und Sollwerte abgeleitet. Dabei können die Best Practices entsprechend unterstützen und herangezogen werden. 126

137 3.4 Definition der Prozessziele und -Kennzahlen Service Management Plan (SMP) Prozess Management Plan (PMP) IT Service Management- Prozesse Wird sichergestellt durch Aktivitäten Kritische Erfolgsfaktoren Control Objectives Überprüfen / Verbessern Kennzahlen (KPI, KGI) Reviews/ Audits Best Practice COBIT ITIL Abbildung 48: Prozess-Management Nutzung von COBIT und ITIL Sind die Kennzahlen und Zielwerte definiert, so empfiehlt es sich, als Qualitätscheck zu prüfen, ob von der Kennzahl eine unmittelbare oder mittelbare Verbindung zu einem Geschäftsziel besteht. Möchte die IT-Organisation die Konformität mit der ISO nachweisen, so können der ISO (vgl. [ISO , 2005]) die Anforderungen entnommen werden, die vom jeweiligen Prozess sichergestellt und nachgewiesen werden müssen (siehe Abbildung 49). 127

138 3 IT Prozess-Management Service Management Plan (SMP) Prozess Management Plan (PMP) IT Service Management- Prozesse Wird sichergestellt durch Aktivitäten Kritische Erfolgsfaktoren Control Objectives Überprüfen / Verbessern Kennzahlen (KPI, KGI) Reviews/ Audits Best Practice Konformität COBIT ITIL ISO Abbildung 49: Prozess-Management Konformität Die Kennzahlen und deren laufende Überprüfung stellen die Basis für die gegebenenfalls notwendigen Verbesserungen der Prozesse dar. Ohne ausreichende Messung kann letztendlich keine zielgerichtete Verbesserung erreicht werden. Die Ergebnisse dieser Verbesserungsphase finden Einzug in dem Prozess Improvement Plan PIP (siehe Abbildung 50). 128

139 3.4 Definition der Prozessziele und -Kennzahlen Service Management Plan (SMP) Prozess Management Plan (PMP) IT Service Management- Prozesse Wird sichergestellt durch Prozess Improvement Plan (PIP) Aktivitäten Kritische Erfolgsfaktoren Control Objectives Überprüfen / Verbessern Kennzahlen (KPI, KGI) Reviews/ Audits Best Practice Konformität COBIT ITIL ISO Abbildung 50: Prozess-Management Prozess Improvement Plan Der hier beschriebene Managementansatz entspricht der Methode, die in der ITIL Version 3 empfohlen wird und in Continual Service Improvement [OGC, 2007e] beschrieben ist. Aus der übergeordneten Vision werden die Ziele definiert und mittels Kennzahlen gemessen. Dies stellt die nachfolgende Abbildung 51 aus [OGC, 2007e] dar. 129

140 3 IT Prozess-Management Vision Mission Ziele Objectives CSFs KPIs Metriken Messungen Abbildung 51: Entwicklung von Kennzahlen Dokumentation der Prozess-Kennzahlen Für die Dokumentation empfiehlt es sich, die Kennzahl mit der entsprechenden Definition, der Messmethode und anderen relevanten Informationen zu dokumentieren. Dazu bietet sich die Dokumentation in Form eines Kennzahlen-Steckbriefes an. 130

141 3.4 Definition der Prozessziele und -Kennzahlen Bestandteil des Steckbriefs Kennzahl IT Service Management-Prozess Beschreibung Zielwert Beziehung zu anderen Prozessen Datenquelle Beschreibung Bezeichnung der Kennzahl Prozess, der diese Kennzahl nutzt Beschreibung der Kennzahl, ihrer Aussagekraft und des mit dieser Kennzahl zu überprüfenden Prozesszieles Zielwert der Kennzahl, der sich aus der Zieldefinition für den Prozess ergibt Prozesse, die diese Kennzahl beeinflussen Beschreibung der Quelle für die zugrunde liegenden Daten Formel Berechnungsmethode der Kennzahl Erhebungsfrequenz Festlegung, wann/wie oft die Kennzahl fortgeschrieben wird Auditfrequenz Festlegung, wann/wie oft die Kennzahl hinsichtlich ihres Nutzen und ihrer Verwendung überprüft wird Anmerkungen Zusatzinformationen Bei Bedarf können weitere Informationen wie zum Beispiel Empfänger der Kennzahl, Risiken, etc. aufgenommen werden. Im Rahmen der Prozessdokumentation ist zu prüfen, wie der Kennzahlen- Steckbrief zu dokumentieren ist. Es empfiehlt sich, die Beschreibung der Kennzahlen in den Service Management-Plan (SMP) aufzunehmen Reporting der Prozess-Kennzahlen An der Zieldefinition und der Ausrichtung der IT Service Management- Prozesse sind verschiedene Management-Ebenen beteiligt. In einem top down-ansatz erstreckt sich dieser Prozess vom Top-Management bis zum Prozess Manager. 131

142 3 IT Prozess-Management Kennzahlen müssen ebenengerecht sein. So unterschiedlich die beteiligten Managementebenen sind, so unterschiedlich ist auch deren Informationsbedarf hinsichtlich der etablierten IT Service Management-Prozesse und der erbrachten Services. Der Prozess Manager benötigt im Rahmen seiner Durchführungsverantwortung verschiedene Kennzahlen (KGI, KPI), die ihm detaillierte Informationen bezüglich der Erreichung der einzelnen Prozessziele und der planmäßigen Prozessdurchführung aufzeigen. Das Top-Management möchte dagegen auf einen Blick sehen, ob das IT Service Management erfolgreich ist, ohne selbst den Zusammenhang aus verschiedenen Kennzahlen herleiten zu müssen. Das Top-Management benötigt also eine Gesamtsicht auf die Prozesse und Services. Die Kennzahlen müssen ebenengerecht aufbereitet und präsentiert werden. Diese Anforderung des ebenengerechten Reportings lässt sich für die Rollen des Prozess Managers und zum Teil des Prozess Owners leicht umsetzen. Die für diese Rollen benötigten Kennzahlen sind die, die im Rahmen des Prozessdesigns zur Überprüfung des Prozesses definiert wurden. Die Kennzahlen hierzu sind als KPIs bzw. KGIs in COBIT und ITIL dokumentiert. Anders verhält es sich, wenn eine Gesamtbewertung knapp und präzise erfolgen muss. Dies ist beispielsweise immer der Fall, wenn der Service Manager eine Übersicht benötigt bzw. an das Top (IT-) Management berichtet. Nehmen wir an, die Fragestellung würde lauten: Hat der Prozess Change Management seine Zielsetzung erfüllt? Dann müssen die Prozess- Kennzahlen zu einer Kennzahl zusammengefasst werden. Hierfür sind die einzelnen Kennzahlen zu gewichten und zu aggregieren So ist es für die Beurteilung seitens des Service Managers zunächst wichtig, zu erkennen, ob alle Services und alle Prozesse die Zielsetzung erfüllen - ob sie im grünen Bereich sind. Am Beispiel des Change Managements könnte sich eine zusammengesetzte Kennzahl zum Prozess durch die Gewichtung der einzelnen Ziele und der damit verbundenen Kennzahlen wie folgt ergeben (siehe Abbildung 52): 132

143 3.4 Definition der Prozessziele und -Kennzahlen Anteil fehlerfreier Changes 60% Anteil termingerechter Changes 20% Effektivität Change Management 70% Anteil kostengerechter Changes 20% Zielerreichung Change Management Anteil zurückgewiesener Changes Anteil der Notfall-Changes 40% Effektivität Change Management 60% 30% Abbildung 52: Zusammengesetzte Prozess-Kennzahlen Es ist zu empfehlen, Gesamtzusammenhänge beispielsweise in Form einer Ampel darzustellen. Dabei ist es in den meisten Fällen so, dass in die Ampelbewertung auch qualitative Dinge einfließen. So könnte sich zum Beispiel eine Gesamtübersicht der Zielerreichung aller SLAs sich wie folgt (Abbildung 53) darstellen: Abbildung 53: Darstellung der SLAs mit dem Q-Board von Q to be Die operativen Systeme, wie zum Beispiel die Tool-Unterstützung für das Change Management, liefern die notwendigen Basis-Informationen, aus 133

144 3 IT Prozess-Management denen durch entsprechende Datenselektionen und Aggregation die Prozess-Kennzahlen gewonnen werden können. Durch weitere Aggregationen erhalten dann der Service Manager und das Mittlere sowie das Top Management die notwendigen Informationen. Dabei sind aber nicht nur Kennzahlen zu den IT Service Management- Prozessen zu kreieren, sondern auch die erfolgreiche Umsetzung der im Service Management Plan (SMP) und Service Improvement Plan (SIP) festgelegten Verbesserungsmaßnahmen zu belegen (siehe Abbildung 54). Top Management gewichtete Kennzahlen Prozess Management Prozess- Kennzahlen (KGI, KPI) ITSM-Tool(s). weitere operative Systeme Basisdaten aus den jeweiligen Prozessen Service Improvement Plan Service Management Plan Abbildung 54: Das IT Service Management Kennzahlensystem Generell empfiehlt es sich, auf allen Hierarchieebenen für das Reporting auf grafische Elemente zurückzugreifen und Kennzahlen in den Ampelfarben darzustellen, nach dem Motto Ein Bild sagt mehr als tausend Worte. Hierzu wird der dargestellte Wert in Abhängigkeit der Sollwerte entsprechend farbig dargestellt oder grafisch animiert. Dazu können zum Beispiel Ampelsymbole oder Tachoscheiben herangezogen werden. 134

145 3.4 Definition der Prozessziele und -Kennzahlen Werden zu den absoluten Werten noch die Sollwerte und ein Trend ausgewiesen, so können die Prozess-Kennzahlen kompakt und dennoch informativ dargestellt werden. Abbildung 55 und Abbildung 56 zeigen ein anonymisiertes Projektbeispiel zum Reporting von Prozess-Kennzahlen. Die erste Seite zeigt die Gesamtbetrachtung und den Trend des Prozesses, während auf der zweiten Seite die einzelnen Prozess-Kennzahlen, deren Sollwerte und Trends ausgewiesen werden. Incident Management Berichtsmonat: 04/2007 Prozent Monat/2007 Zielerreichung in Prozent Abbildung 55: Exemplarischer Prozess-Bericht Deckblatt zum Report 135

146 3 IT Prozess-Management Erstlösungsquote in % Erstlösung Soll 60% Ist 62% Monat/ Anzahl Major Incidents 6 Major Incident Lösungszeit Prio 1 Prio 2 Soll Ist Soll 2 Ist 1, , Lösungszeit in Std. Monat/ Monat/2007 Abbildung 56: Exemplarischer Prozess-Bericht Darstellung der Kennzahlen Die Hersteller von Tools haben den Bedarf für eine übersichtliche, abgestufte Darstellung erkannt und bieten hierzu so genannte Management- Cockpits an. Ein Beispiel gibt die folgende Abbildung

147 3.5 Von der Kennzahl zur Verbesserungsmaßnahme Abbildung 57: Darstellung des Management Cockpits von iet Solutions 3.5 Von der Kennzahl zur Verbesserungsmaßnahme Die definierten Kennzahlen mit ihren jeweiligen Zielwerten, beschrieben als KGI (Key Goal Indicator) oder KPI (Key Performance Indicator), sollen erkennbar machen, dass ein Zielwert bzw. Prozessziel nicht erreicht wird. In Verbindung mit Trenddaten soll aufgezeigt werden, dass die Erreichung eines Prozesszieles gefährdet ist. Dabei kann der Indikator lediglich etwas aufzeigen. Die eigentliche Ursache ist vom Prozess Manager festzustellen. So kann dem Prozess Manager zum Beispiel aufgezeigt werden, dass sich die Erstlösungsquote im Incident Management verschlechtert (siehe Abbildung 58). 137

148 3 IT Prozess-Management Abbildung 58: Beispiel für eine Trenddarstellung Der Prozess Manager hat durch detaillierte Auswertung festzustellen, warum sich die Erstlösungsquote verschlechtert. Hierzu muss der Prozess Manager analytisch tätig werden, indem er versucht, verschiedene Einflussfaktoren zu untersuchen, die einen möglichen Einfluss auf die Erstlösungsquote haben. Angenommen, ein neuer IT Service wurde eingeführt, könnte die Betrachtung der Erstlösungsquote in Abhängigkeit von dem durch die aufgetretene Störung betroffenen IT Service sein hilfreich sein (siehe Abbildung 59). Hierzu wird die vorherige Auswertung der Erstlösungsquote in Abhängigkeit vom betroffenen Service ausgewertet. In diesem Beispiel zeigt die Auswertung eine schlechter werdende Erstlösungsquote für die Services und Kfz-Dialog. 138

149 3.5 Von der Kennzahl zur Verbesserungsmaßnahme Abbildung 59: Beispiel 1 für eine Analyse möglicher Ursachen In einem weiteren Analyseschritt könnte der Prozess Manager dann zum Beispiel auswerten, ob sich hierzu die zugrunde liegenden Fehlerursachen verändert haben (siehe Abbildung 60). Der Prozess Manager benötigt für diese weitergehenden Analysen nicht nur Prozess-Know-how sondern auch umfangreiche Erfahrungen im täglichen Betrieb und das Wissen um mögliche Abhängigkeiten. Die möglichen Ursachen sind nicht immer offensichtlich, sondern erfordern analytisches Vorgehen Detektivarbeit. Dabei ist eine geeignete Toolunterstützung von großem Vorteil. Das eingesetzte Tool sollte über variable Drill-Down-Möglichkeiten verfügen, sodass Analysen und deren Richtung situativ durchgeführt werden können. 139

150 3 IT Prozess-Management Abbildung 60: Beispiel 2 für eine Analyse möglicher Ursachen 3.6 Kennzahlen müssen reifen So wie die IT Service Management-Prozesse sich entwickeln und reifen müssen, so müssen auch die Kennzahlen reifen. Werden noch keine Prozesse gemessen, so empfiehlt es sich zunächst, die wichtigsten Prozessziele mit Kennzahlen zu hinterlegen. Mit diesen Kennzahlen kann das Managementsystem aufgebaut werden und es können erste Erfahrungen gesammelt werden. Liegen noch keine gesicherten Informationen zu einem Prozess vor, so muss sich der Prozess Manager zunächst einen Eindruck über das zu bewältigende Volumen im Prozess verschaffen. Welche Inputs hat der Prozess zu bewältigen? Zum Beispiel: Wie viele Incidents sind zu bearbeiten oder wie viele Changes sind auszuführen? Werden diese Vorgänge für das Incident, Problem und Change Management in Kategorien und Prioritäten unterteilt, so liegen bereits erste wichtige Informationen vor. 140

151 3.7 Der Umgang mit Kennzahlen Die Informationen zum Umfang des Inputs sind auch für die späteren Auswertungen als Referenzgröße von großer Bedeutung. Mögliche Veränderungen in den ermittelten Kennzahlen lassen sich häufig auf einen veränderten Input zurückführen. Zunächst gilt es, das Volumen des Inputs (Durchsatz) zu messen. Die Größe ist auch für vergleichende Betrachtungen von großer Bedeutung. Eine weitere wichtige Betrachtung für den Prozess Manager ist die zeitliche Entwicklung. Trendinformationen können frühzeitig Handlungsbedarf aufzeigen und ermöglichen es, Maßnahmen zu ergreifen, bevor die Sollwerte unter- bzw. überschritten werden. Damit Trends dargestellt werden können, ist eine Stabilität im Kennzahlensystem notwendig. Sobald Kennzahlen vorliegen, sollten Änderungen der Berechnungsmethoden sorgsam geprüft werden. Die Berechnungsgrundlagen der Kennzahlen sollten nur nach sorgsamer Prüfung verändert werden. Ansonsten können keine verlässlichen Trends ausgewertet werden. Die Prozesse sind hinsichtlich ihrer Zielerreichung (Key Goal Indicator = Effektivität) und ihrer Leistungsfähigkeit (Key Performance Indicator = Effizienz) zu messen. Dabei steht die Zielerreichung, die Betrachtung des Outputs, im Vordergrund. Demzufolge gilt es, sich zunächst auf die Einführung dieser Kennzahlen zu konzentrieren. Im Anschluss können diese Kennzahlen um Kennzahlen für eine Betrachtung der Effizienz erweitert werden. Die Anzahl genutzter Kennzahlen sollte im eingeschwungenen Zustand pro Prozess bei maximal zwischen Kennzahlen liegen. 3.7 Der Umgang mit Kennzahlen Die Kennzahlen dienen primär als Management-Werkzeug für den Prozess Manager und den Prozess Owner. Diese können anhand der Kennzahlen erkennen, ob die Prozessziele erreicht werden und ob der Prozess wirkungsvoll durchgeführt wird. Darüber hinaus unterstützen die Kennzahlen den Prozess Manager bei der Identifizierung eines möglichen Verbesserungspotenzials, bei der Darstellung komplexer Sachverhalte und bei der Begründung möglicher Veränderungsmaßnahmen. Durch die Definition einer Kennzahl stellt das Prozess-Management die Bedeutung der damit verbundenen Aktivitäten heraus. 141

152 3 IT Prozess-Management Die Organisation wird demzufolge ihr Handeln auf die Erreichung des festgelegten Sollwerts für die Kennzahl ausrichten. Dieses Ziel wird jedoch auch dann angestrebt werden, wenn sich dies für das Unternehmen nachteilig auswirken sollte! Wird beispielsweise für den Service Desk eine maximale Bearbeitungszeit von 5 Minuten pro Telefonat als Zielwert vorgegeben, so werden die Mitarbeiter sich an dieser Kennzahl orientieren. Die Telefonate werden innerhalb dieser Zeit abgeschlossen, auch wenn eine mögliche Störung innerhalb der nächsten 30 Sekunden gelöst werden könnte. Das Verhalten der Mitarbeiter wird sich an den festgelegten Kennzahlen orientieren. Der Prozess Manager muss sich dieses Verhaltens bewusst sein. Eine Möglichkeit, dem zu begegnen besteht darin, mit einer anderen Kennzahl negativen Auswirkungen entgegen zu wirken. Viel wichtiger ist es aber, den Nutzen der Kennzahlen in der Organisation herauszustellen. Die Kennzahlen dürfen nicht als Bedrohung sondern müssen als Chance verstanden werden. Werden dem Top-Management einzelne Kennzahlen berichtet, so muss das Top-Management auch die Prozessziele der damit verbundenen IT Service Management-Prozesse kennen und verstehen. Ansonsten besteht die große Gefahr, dass aus den übermittelten Kennzahlen falsche Schlüsse gezogen werden. Was an dieser Stelle als Selbstverständlichkeit verstanden werden kann, hat in einigen Organisationen zu erheblichen Schwierigkeiten geführt. Die Aufgabe des Problem Managements besteht zum Beispiel darin, Probleme zu identifizieren. Steigt die Kennzahl der identifizierten Probleme, so ist dies ein Indikator für einen gut funktionierenden Problem Management-Prozess. Es wäre dagegen fatal, wenn das Management die wachsende Zahl identifizierter Probleme falsch interpretiert und dem Problem Management negativ anlastet. 142

153 4 IT Kennzahlensysteme 4.1 Management Summary Die IT eines Unternehmens lässt sich nur dann erfolgreich steuern, wenn verlässliches Material über Zahlen und Fakten verfügbar ist. Zum einen müssen diese Informationen die Situation der IT-Organisation realitätstreu widerspiegeln, zum anderen müssen Sie Anreize für die Veränderungen schaffen. Dies ist die Aufgabe von Kennzahlensystemen. In der IT gibt es wahrscheinlich so viele Kennzahlen wie in keinem anderen Bereich. Ein nur durchschnittlich ausgeprägtes Monitoring der IT-Systeme über System Management-Werkzeuge stellt mit Leichtigkeit schon Hunderte von Kennzahlen bereit und das regelmäßig, in vielen Fällen im Minutentakt. Wichtig ist es daher, zu hinterfragen, was eine einzelne Kennzahl bezüglich der Gesamtsituation aussagt. Im Allgemeinen benötigt man hierzu eine Kombination aus mehreren Einzelkennzahlen. Die Praxis zeigt, dass das Design, die Umsetzung und die Pflege von Kennzahlensystemen in der IT nicht zu unterschätzende Aufgaben darstellen. Durch Interessenkonflikte innerhalb von Unternehmen sowie die häufig asymmetrische Informationsverteilung zwischen den Beteiligten wird die benötigte Objektivität zur entscheidenden Herausforderung. Die Kunst liegt darin, ein IT-Kennzahlensystem zu konstruieren, das einen präzisen und zeitnahen Überblick liefert, das sich nicht manipulieren lässt und das möglichst geringe Kosten verursacht. Es gibt einige veröffentlichte IT-Kennzahlensysteme. Mögen diese auch noch so exzellent in ihrer Ausprägung, Tiefe und Methodik sein. Eins bleibt festzuhalten: Kein IT-Kennzahlensystem lässt sich Eins zu Eins von einer IT-Organisation auf eine zweite übertragen. Der Hauptgrund liegt darin, dass der Betrieb eines Kennzahlensystems immer auch einen strategischen Effekt erzielt. Dies ist zwangsläufig so unabhängig davon, ob es von Anfang an beabsichtigt war oder nicht. Die strategische Positionierung der IT hinsichtlich ihrer Außen- und Innenwirkung ist CIO-Sache. Kennzahlensysteme bilden hierfür eine entscheidende Basis, nicht nur als Steuerungs- sondern insbesondere als Kommunikationsinstrument. 143

154 4 IT Kennzahlensysteme 4.2 Ziele Für Unternehmen steht heute nicht mehr zur Diskussion, dass Effizienz und Effektivität ihrer Organisationseinheiten objektiv, präzise und zuverlässig ermittelt werden müssen. Dies gilt für IT-Organisationen im Besonderen. Das frühzeitige Erkennen von Problemen und Verbesserungspotenzialen ist eine wichtige Voraussetzung für den Erfolg der IT. An dieser Stelle setzen Kennzahlensysteme an. Sie ermöglichen einen Blick auf die Situation der IT-Organisation, ihre Teilbereiche und ihre Prozesse. Die Auswahl und Erfassung von geeigneten Kennzahlen stellt sich in der Praxis als überraschend schwierig heraus. Der Grund hierfür liegt darin, dass Kennzahlen, um effektiv zu sein, die folgenden Voraussetzungen erfüllen müssen: Eine Kennzahl muss objektiv erfassbar sein, um eine zuverlässige und unverzerrte Darstellung der Situation zu ermöglichen. Die verwendeten Begriffe zur Beschreibung der Kennzahl müssen eindeutig und für alle Beteiligten verständlich sein und von diesen akzeptiert werden. Der Aufwand zur Erfassung einer Kennzahl sollte gering sein, um eine möglichst häufige, schnelle und preiswerte Ermittlung zu ermöglichen. Auch sollte eine zeitnahe Erfassung möglich sein. Idealerweise wird die Kennzahl automatisch erfasst und gespeichert. Kennzahlen müssen das Entstehen von Fehlanreizen verhindern: Durch Kennzahlen ausgelöste positive Entwicklungen müssen begünstigt und negative sanktioniert werden. Die Kennzahlen sollten nicht manipulierbar sein. Kennzahlen, die in einem bestimmten Bereich oder Prozess erhoben werden, sollten effektiv von diesem Bereich oder Prozess kontrollierbar sein. Andernfalls liefern sie ein falsches Bild der tatsächlichen Leistung oder Kosten. Beispiel: Anwenderzufriedenheit Viele Unternehmen evaluieren die Anwenderzufriedenheit mit der IT über Fragebögen 1 oder CAPIs 2. Aber mit welcher Fragestellung lässt sich die Anwenderzufriedenheit ermitteln? 1 Diese werden auch User Quality Surveys genannt. 2 CAPI steht für Computer Assisted Personal Interview. 144

155 4.2 Ziele Eine direkte Frage nach der Zufriedenheit mit der IT führt zu wenig brauchbaren Resultaten, da Anwender häufig keinen Überblick über die Gesamtleistung der IT haben. Stattdessen rücken ungewollte Aspekte in den Vordergrund. Die Anwenderzufriedenheit ist durch die IT-Organisation selbst oft schwer zu beeinflussen, da sie von nicht-kontrollierbaren Dingen abhängen kann, wie mangelnder Lernbereitschaft bestimmter Anwender. Auch kann eine restriktive Sicherheitspolitik der IT die Anwenderzufriedenheit negativ beeinflussen, wie das Verbot der Internet-Nutzung oder privater . Obwohl solche Dinge dem Unternehmen als Ganzes nützen und von der IT gegebenenfalls professionell umgesetzt werden, ziehen Sie die Bewertung der IT nach unten. Hinzu kommt, dass der Anwender häufig eine andere Erwartung an den IT Service hat als seine Vorgesetzten, die Vereinbarungen in Form von SLAs mit dem IT Service Provider abgeschlossen haben. Dem Anwender sind zum Teil diese SLAs mit den Service Level Targets gar nicht bekannt. Auch wenn der IT Service Provider diese Anforderungen vollständig erfüllt, kann es so vorkommen, dass die Anwenderzufriedenheit nicht gegeben ist. Der Versuch, die Anwenderzufriedenheit indirekt zu messen, ist ebenfalls nicht einfach. Legt man beispielsweise die Anzahl der Kontaktaufnahmen mit dem Service Desk zugrunde, so gibt es mindestens zwei Interpretationsmöglichkeiten. Ein Service Desk, der wenig kontaktiert wird, kann eine hohe Anwenderzufriedenheit im Sinne Alles läuft reibungslos bedeuten, aber auch, dass die Anwender es aufgegeben haben, sich an die IT zu wenden, beispielsweise wegen Inkompetenz oder Arroganz des Service Personals. Das Beispiel zeigt, dass man zur Ermittlung der Anwenderzufriedenheit nicht mit einer Kennzahl auskommt. In einem Kennzahlensystem sollen sich sorgfältig ausgewählte Kennzahlen gegenseitig ergänzen, um ein möglichst ausgewogenes und präzises Gesamtbild zu liefern. Genauso wie einzelne Kennzahlen sollte ein gutes Kennzahlensystem Anforderungen erfüllen: Der Informationszugewinn, der aus einem Kennzahlensystem im Vergleich zu einzelnen Kennzahlen entsteht, hängt davon ab, wie sehr sich die Kennzahlen voneinander unterscheiden. Auch die Größe des Kennzahlensystems ist entscheidend. Zunächst führt jede zusätzliche Kennzahl zu einem Informationsgewinn, sofern sie optimal eingesetzt wird. Dieser wird aber mit wachsenden 145

156 4 IT Kennzahlensysteme Systemen immer geringer. Es kommt also darauf an, das Kennzahlensystem mit optimaler Größe auszulegen. 3 Beispiel: Anwenderzufriedenheit (Fortsetzung) Die beiden Kennzahlen Befragung und die Kontakthäufigkeit, die wir oben vorgeschlagen hatten, sind beide für sich genommen zur Bestimmung der Anwenderzufriedenheit mit der IT wenig geeignet. Sie sind entweder nicht präzise genug oder können negative Effekte bewirken. Durch die Kombination der beiden Kennzahlen erhält man aber ein präziseres Maß, das weniger fehler- und zufallsanfällig ist. Auch wird eine Manipulation der resultierenden Kennzahl deutlich schwieriger und aufwendiger. Durch weitere Kennzahlen ließe sich dieses Kennzahlensystem nun verbessern, bis der gewünschte Kompromiss aus Informationsgehalt und Kosten des Systems erreicht ist. Doch bei der Auswahl neuer Kennzahlen ist Vorsicht geboten. Zunächst liegt der Gedanke nahe, den Mitarbeitern weitere Fragen zu anderen Aspekten ihrer Zufriedenheit zu stellen. Während dies im Einzelfall nützlich sein kann, um Problembereiche zu identifizieren, liegt die Vermutung nahe, dass die Zufriedenheit mit einzelnen Aspekten stark mit der allgemeinen Zufriedenheit korreliert und somit bereits zum Teil im System enthalten ist. In diesem Fall steht dem zusätzlichen Aufwand kaum ein Informationsgewinn gegenüber. Als Erfolg versprechend könnte sich hingegen die Analyse des Anwenderverhaltens erweisen. Falls sich beispielsweise deren Produktivität im Umgang mit ihrer IT-Umgebung messen ließe, so könnte dies auf deren Zufriedenheit schließen lassen. Auch eine Aufschlüsselung der Kontakthäufigkeit mit dem Service Desk nach Ursache (Incident, Service Request, Request for Change usw.) könnte sich als wertvoll erweisen. 3 Wegen des Verhältnisses von Grenzkosten und Grenznutzen. 146

157 4.3 Überblick 4.3 Überblick In den letzten 30 Jahren sind einige Vorschläge für IT-Kennzahlensysteme entwickelt und veröffentlicht worden. Diese sind zum Teil generisch und zum Teil im Hinblick auf konkrete Unternehmen konzipiert. Im Folgenden stellen wir eine Auswahl von Kennzahlensystemen kurz vor. Wir erheben dabei keinen Anspruch auf Vollständigkeit, sondern verfolgen vielmehr das Ziel, dem Leser eine grobe Vorstellung über den Aufbau von Kennzahlensystemen zu geben. Jedes Kennzahlensystem folgt einer eigenen Philosophie und ist für spezifische Anwendungsszenarien besonders geeignet. Die Qualität und Eignung der vorgestellten Systeme hängt somit immer vom geplanten Einsatz ab, sodass eine allgemeine Bewertung von Kennzahlensystemen weder objektiv möglich noch in diesem Text beabsichtigt ist. Grob unterscheiden kann man zwischen praxisorientierten, konkreten Systemen, und eher als generisch zu verstehenden Systemen. Während erstere in der Regel aktualisiert und auf die bestehende IT-Infrastruktur eines Unternehmens abgestimmt werden müssen, erfordern letztere das Entwickeln eigener, geeigneter Kennzahlen. Da sich kaum eines dieser Kennzahlensysteme direkt und ohne Anpassungen einsetzen lässt, ist es wichtig, vorab einige Kriterien zu nennen, anhand derer sich der Aufwand einer Implementierung abschätzen lässt: Stimmt die Zielsetzung des Kennzahlensystems mit den Anforderungen überein? Werden alle IT-Bereiche ausreichend abgedeckt? Werden die wesentlichen Fragen hinreichend beantwortet? Stimmt die Gewichtung der Kennzahlen mit der Relevanz überein? Wie konkret ist das Kennzahlensystem? Lassen sich die genannten Kennzahlen einfach erheben? Müssen Kennzahlen noch weiter ausformuliert werden? Wie aufwendig ist die Implementierung des Systems? Werden die verwendeten Kennzahlen bereits erhoben? Welcher Aufwand würde die Erhebung der nötigen Kennzahlen verursachen? Wie häufig wäre eine Erhebung möglich? Im Folgenden machen wir eine kleine Reise durch die Welt der Kennzahlensysteme. Unsere Stopps sind aber nur kurz. Für längere Aufenthalte empfehlen wir einen Blick in die Originalarbeiten oder das sehr empfehlenswerte Buch von Martin Kütz [Kütz, 2007]. 147

158 4 IT Kennzahlensysteme SVD 1980 Herkunft Schweizerische Vereinigung für Datenverarbeitung Quelle EDV-Kennzahlen (1980), Bern/Stuttgart Idee SVD 1980 ist ein kompaktes, relativ allgemein gehaltenes Kennzahlensystem, das 34 nach Adressaten gruppierte Kennzahlen enthält. Struktur Gruppierung nach Adressat und Art der Kennzahl. Insgesamt 34 Kennzahlen. Kennzahlen Management Anwender IT-Entwicklung IT-Betrieb Kosten Leistungen Nutzen Sonstige Beispiele IT-Produktivitätsindex (Management / Nutzen) Nutzenpunkte (Anwender / Nutzen) Anzahl IT-Mitarbeiter (IT-Entwicklung / Sonstige) Mean Time to Repair (MTTR) (IT-Betrieb / Leistung) Fazit Einige Kennzahlen müssen für den konkreten Einsatz in der Praxis spezifiziert werden, z. B. was Nutzenpunkte im Einzelnen sind. 148

159 4.3 Überblick Diebold 1984 Herkunft Diebold Deutschland GmbH Quelle Idee Struktur Diebold Kennzahlensystem (1984), 3. Auflage, Frankfurt Dieses von der Unternehmensberatung Diebold entwickelte Kennzahlensystem stellt eine hierarchische Struktur dar, in die konkrete Kennzahlen eingearbeitet werden können. Hierarchische Strukturierung mit insgesamt 19 Untergruppen 1 Spitzenkennzahl 2 Kennzahlenbereiche (A, B) Kennzahlenunterbereiche (AA, AB,...) Kennzahlengruppen (AAA, AAB,...) Kennzahlenuntergruppen (AAAA, AAAB,...) Beispiele Anteil IT-Kosten bezogen auf Umsatz (Spitzenkennzahl) Wirkung des Einsatzes der IT im Hinblick auf die Unternehmensleistung (A)... bezogen auf das Gesamtunternehmen (AA)... je Hauptfunktionsbereich (AB) Fazit Diebold stellt ein abstraktes Kennzahlensystem dar, das für eine praktische Nutzung stark konkretisiert und angepasst werden muss. Es stellt sich auch die Frage, wie sich (durchaus wichtige) Aspekte wie Innovationsverhalten und Zukunftsorientierung praktisch und objektiv messen lassen. Die hierarchische Struktur bietet Vorteile dadurch, dass eine an den jeweiligen Adressaten angepasste Informationstiefe erreicht werden kann. Zu klären ist dabei allerdings, auf welche Art und Weise die Kennzahlen einer Gruppe zur jeweils höheren Hierarchiestufe zusammengerechnet werden können. 149

160 4 IT Kennzahlensysteme Kargl 1996 Herkunft Herbert Kargl Quelle Controlling im DV-Bereich (1996), München Idee Das von Kargl entwickelte Kennzahlensystem bietet eine große Fülle an einfach zu implementierenden Kennzahlen. Struktur 5 Koordinationsfelder mit insgesamt 163 Kennzahlen Strategische IT-Planung (34) Planung / Durchführung von IT-Projekten (30) Wirtschaftlichkeit (24) Anwendungsbetrieb und IT-Infrastruktur (52) Verrechnung von Kosten und Leistungen (23) Beispiele Betriebskosten der Anwendungen (Strategische Planung) Projektfertigstellungsgrad (Plan / Durchführung) Projektkostenstruktur (Wirtschaftlichkeit) Risikofelder und Gefahrenpotenzial (Infrastruktur) Zusammensetzung der Budgets (Verrechnung) Fazit Die Strukturierung des Kennzahlensystems ist stimmig und erfasst sowohl wirtschaftliche als auch strategische Ziele. Die Kennzahlen sind größtenteils relativ konkret formuliert, sodass sie sich gut praktisch nutzen und einfach abwandeln lassen. Zudem sind einige Kennzahlen enthalten, die nützliche Hintergrundinformationen liefern, beispielsweise über die Struktur der Leistungserstellung. 150

161 4.3 Überblick Van der Zee 1996 Herkunft Han van der Zee Quelle In: Search of the Value of Information Technology (1996), Dissertation, Katholische Universität Brabant Idee Das von van der Zee entwickelte IT-Kennzahlensystem versucht die Idee der Balanced Scorecard auf den Bereich der IT zu übertragen. Ferner werden für jede Perspektive konkrete Ziele formuliert. Struktur Aufteilung in 5 Management-Bereiche und jeweils 4 Perspektiven mit insgesamt 200 Kennzahlen: Kennzahlen Interne Persp. Kundenperspekt. Innovationspersp. Finanzpersp. Leistungsmgmt Entwicklungsm Infrastrukturm Kundenmgmt Anwendersupport Beispiele Fazit Leistungsmanagement, interne Perspektive Ziel: Ein guter Arbeitgeber sein. Mitarbeiterzufriedenheit Fluktuationsrate Wettbewerbsfähigkeit der Gehälter... Der einseitige Fokus auf die Kosten- und Finanzperspektive kann zu kurzsichtigem Handeln verleiten. Die Kunden-, Innovations- und Prozessperspektiven sollen helfen, langfristig relevante Werte zu erfassen. Die Kennzahlen selbst sind zum großen Teil konkret formuliert. Der enorme Umfang des Systems erfordert allerdings eine sorgfältige Auswahl. 151

162 4 IT Kennzahlensysteme 4.4 Bewertung Die betrachteten Kennzahlensysteme zeigen, dass es verschiedene, gleichermaßen schlüssige und sinnvolle Ansätze gibt, die scheinbar schwer messbare Leistung der IT zu erfassen. Zunächst stellt sich die Frage nach der grundsätzlichen Struktur eines Kennzahlensystems. In dieser sollten alle Kernbereiche der IT wieder zu finden sein. Auch sollte die Abgrenzung mit der tatsächlichen Aufteilung von Aufgaben und Kompetenzen in etwa übereinstimmen. Matrizenförmige Strukturen erlauben das gleichzeitige Gliedern der Kennzahlen nach dem Bereich und einem zweiten Kriterium. Eine (zusätzliche) hierarchische Strukturierung der Kennzahlen ist möglich und dann sinnvoll, wenn das System ohne Probleme von mehreren unterschiedlich stark involvierten Managementstufen benutzt werden soll. Das Hinzufügen von Zielen oder die Unterteilung nach Prozessen verleiht dem Kennzahlensystem schließlich eine eigene Philosophie, was sowohl bei der Erstellung des Systems, als auch bei der Auswertung der späteren Resultate sinnvoll ist. Was die Anwendbarkeit der vorgestellten Systeme betrifft, so erfordert jedes die Anpassung an die konkrete IT-Organisation. Während dies bei relativ konkreten Systemen wie van der Zee 1996 einfach durch die geschickte Auswahl aus einem Kennzahlenpool erfolgen kann 4, dienen abstrakte Klassifizierungssysteme wie Diebold 1984 eher als Basis für das Zusammenstellen und Strukturieren eines eigenen Systems. Stellt man sich die spannende Frage Welches IT-Kennzahlensystem soll man so, wie es ist, in der Praxis einsetzen?, so lautet die enttäuschende Antwort: Keines 5. In der Praxis zeigt sich: Der Überdeckungsgrad der Kennzahlensysteme ist eher gering, jedes Kennzahlensystem liefert neue Aspekte. Die Anforderung, dass Prozessmodelle des IT Service Managements zu berücksichtigen sind, liefert nicht weniger, sondern mehr Kennzahlen. Kein Kennzahlensystem ist ohne Modifikation in der Praxis einsetzbar: Zu viele Kennzahlen werden genannt. 4 Dies gilt im Übrigen auch für COBIT (vgl. Kapitel 3.3). 5 Vielleicht etwas hoffnungsvoller, versöhnlicher (und diplomatischer): Keines ohne Modifikation. 152

163 Kennzahlen werden genannt, die aber im konkreten Unternehmen nicht reported / gemessen werden können oder sollen. Kennzahlen werden zwar genannt, aber nicht definiert. Es wird kaum Bezug zur IT-Strategie genommen. Der strategische Aspekt von Kennzahlensystemen bleibt unberücksichtigt. IT-Kennzahlensysteme sagen, was man messen könnte, aber nicht, was man messen sollte! Sie sind damit Guidelines nicht mehr und nicht weniger! IT-Kennzahlensysteme sind nicht Selbstzweck, sondern haben immer eine strategische Ausrichtung. Sie sind immer unternehmensspezifisch. Einsatzbereiche für IT-Kennzahlensysteme können beispielsweise sein: Steuerung des IT-Bereichs oder Darstellung des IT-Bereichs (z. B. um der Geschäftsführung zu zeigen, wie der IT-Bereich im Unternehmen dasteht: Lagebericht der IT ). Hieraus lässt sich ein wichtiger Aspekt ableiten: IT-Kennzahlensysteme haben immer einen bestimmten Adressatenkreis: Top Management, CIO, Prozess Owner oder Kunden. 4.5 Konsequenzen 4.5 Konsequenzen Anmerkung: Dies ist das kürzeste und wichtigste Kapitel in unserem Buch. Beantworten Sie die folgenden Fragen: Wer sind die Adressaten des IT-Kennzahlensystems? Welche Ziele verfolgen Sie mit der Einführung des IT-Kennzahlensystems in Bezug auf die Adressaten? Welche IT Service Management-Prozesse sollen gemessen werden? Wie sollte das Kennzahlensystem strukturiert sein? Welche Kennzahlen können bzw. können nicht gemessen werden? Welchen Aufwand darf das Kennzahlensystem verursachen? Entwickeln Sie Ihr eigenes IT-Kennzahlensystem! 153

164 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen 5.1 Management Summary In diesem Kapitel gehen wir darauf ein, wie ein praxistaugliches IT- Kennzahlensystem entwickelt werden kann. Es kommt uns darauf an, zu zeigen, welche IT-Kennzahlen sich in unseren Praxisprojekten als nützlich und sinnvoll erwiesen haben. In unseren Projekten haben wir die Erfahrung gemacht, dass das Hauptproblem bei der Entwicklung eines IT-Kennzahlensystems darin besteht, die Komplexität des Systems zu reduzieren. Daher widmen wir uns diesem Problem gleich am Anfang des Kapitels und zeigen auf, wie man Kennzahlen in Cluster unterteilen kann, damit ein Mehr-Ebenen- Kennzahlen-System ohne Überfrachtung und Überforderung der Führungsebene entsteht. Insbesondere sind Kennzahlen hinsichtlich ihres Einsatzes und der strategischen Bedeutung zu verdichten. Dies sollte den entsprechenden IT- Mitarbeitern übertragen werden. Dabei ist wichtig, dass eine Aggregation der Daten stattfindet und nicht eine Datenreduktion. Eine Lösung bieten hier Controls on Demand, die dann herangezogen werden, wenn sie benötigt werden. Für die Aufbewahrung ist der jeweilige IT-Mitarbeiter verantwortlich. Die IT-Leitung erhält nur die aggregierten Zahlen zur Steuerung und Kontrolle, kann aber die Detaildaten jederzeit anfordern. 5.2 Klassifikationsschema für IT-Kennzahlen In IT-Organisationen gibt es im Allgemeinen sehr viele Kennzahlen. In einem durchschnittlichen mittelständischen Unternehmen (Größe der IT- Organisation 10 Mitarbeiter) haben wir bei der Ist-Analyse mit Leichtigkeit 500 Kennzahlen ermittelt, die alle erhoben und an die IT-Leitung reported wurden. Es drängt sich nun der Verdacht auf, diese seien nicht alle notwendig und man könne auf einen Großteil verzichten. Dem ist nicht so, denn 95 % dieser Kennzahlen sind sinnvoll und wichtig. Allerdings nicht so wichtig, dass sie monatlich an den CIO reported werden müssen, geschweige denn an die Geschäftsführung. 155

165 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Die Frage Erheben wir die richtigen Kennzahlen? sollte man etwas detaillieren und erweitern: Erheben wir die richtigen Kennzahlen zum richtigen Zeitpunkt für die richtige Person? Was richtig oder nicht richtig ist, lässt sich aus den Zielen und der Strategie ableiten! Interessanterweise erhält man hierdurch ein Klassifikationsschema für Kennzahlen, das sich pragmatisch in der Praxis anwenden lässt und die Komplexität des Systems reduziert. In der folgenden Abbildung 61 ist dieses Modell zur Klassifikation von IT- Kennzahlen dargestellt. Top Management Geschäftsführung Balanced Scorecard (KSFs) Kennzahlen einer IT- Organisation IT-Management CIO KPIs CSIs IT-Controls Controls on Demand IT - Kunden SLAs Abbildung 61: Schema zur Klassifikation von IT-Kennzahlen Hierzu die 3 Kernideen des Modells: Im Wesentlichen lassen sich die Kennzahlen einer IT-Organisationseinheit in drei größere Gruppen einteilen, die sich an den Adressaten der Kennzahlen orientieren: Top Management, IT-Management und IT-Kunden. Die meisten Kennzahlen in der Praxis einige hundert fallen im Umfeld des CIOs an. Ein Teil die IT-Controls ist zur Steuerung der IT notwendig. Der größte Teil wird nur in bestimmten Situationen benötigt. Diese Kennzahlen sollten als Kennzahlen auf Abruf (Controls on Demand) vorgehalten werden. 156

166 5.2 Klassifikationsschema für IT-Kennzahlen Es gibt viele Alternativen, Kennzahlen darzustellen. Entscheidend für den Erfolg eines Kennzahlensystems ist gerade die Fähigkeit, Strategien zu kommunizieren. Wir halten daher mindestens für das Reporting an die Geschäftsführung die Balanced Scorecard für unabdingbar. Lassen Sie uns auf die wesentlichen Kernideen des Klassifikationsschemas genauer eingehen Key Success Factors Über die Rolle der IT in Unternehmen ist viel diskutiert und geschrieben worden. Wir sind der Meinung, dass die IT einen wesentlichen Produktionsfaktor für Unternehmen darstellt. Sie ist wettbewerbsbestimmend, da sie nicht nur die Systeme am Laufen hält, sondern gleichzeitig eine bedeutende Innovationskraft für Unternehmen darstellt. Wodurch soll heute Wachstum entstehen, wenn nicht durch Innovation? Nach unserer Ansicht hat die IT heute 2 Aufgaben zu erfüllen: Run the Business: Die IT ist der Motor für die Geschäftsprozesse. Sie hat die Aufgabe, die Kosten im Griff zu halten, marktgerecht zu agieren, zu standardisieren, Skaleneffekte auszunutzen und das Risiko zu minimieren. Grow and Transform the Business: Die IT ist ein wesentlicher Teil der Entwicklungsabteilung für Geschäftsprozesse. Sie verändert und optimiert die Kernprozesse von Unternehmen, legt die Basis für neue Märkte und ist eine strategische Waffe im Wettbewerb. Die IT ist damit nicht Selbstzweck, sondern sie trägt messbar zum Business Value des Gesamtunternehmens bei. Eine wesentliche Aufgabe des CIO besteht darin, den IT-Erfolg dem Top Management und IT-Kunden darzustellen. Vielen Unternehmen bereitet diese Sicht Schwierigkeiten und daher implementieren sie nur unzureichende Möglichkeiten zur Kommunikation. Dies ist schade, denn dadurch verpufft einerseits viel Innovationskraft und andererseits bauen sich leicht Konfliktsituationen auf, die für das Unternehmen und die IT schädlich sein können. Sehr zu empfehlen ist ein Management Report zur Lage der IT im Unternehmen. Wir haben diese Art des Reportings in vielen Unternehmen verschiedener Größen und Branchen erfolgreich eingeführt. In den meisten Fällen wird dieser Report mit Interesse von der Geschäftsführung entgegengenommen. 157

167 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Der IT Management Report richtet sich an das Top Management. Der Report sollte jährlich erscheinen. Er beschreibt und bewertet die IT im Hinblick auf ihre Leistungsfähigkeit. Wichtig dabei sind die folgenden Dinge: Der Management Report muss auf einer mehrdimensionalen Bewertung der IT basieren. Er muss die Entwicklungstendenzen darstellen. Kennzahlenverläufe sind für die letzten 3 bzw. 5 Jahre anzugeben. Die Bewertung (und die Kennzahlen) müssen für das Top Management verständlich sein. Der Management Report darf Marketingaspekte beinhalten und verfolgen. Er ist eine Selbstdarstellung und dient dem Erreichen strategischer Ziele. Er muss einen Überblick über die durchgeführten Projekte enthalten. Dabei ist herauszustellen, inwiefern die Projekte zum Business Value beigetragen haben. 1 Aus dem Management Report müssen die Ziele für das nächste Jahr abgeleitet werden. Insgesamt muss der Business Value der IT erkennbar sein. In unseren Projekten verwenden wir als Instrument zum Reporting an das Top Management in den meisten Fällen die Balanced Scorecard. Sie ist nicht nur für Management Meetings hervorragend geeignet sondern auch zum Aufbau von Management Reports. Die Frage, die sich hier stellt ist, welche Zahlen und Ergebnisse interessieren das Top Management? Dies sind sicherlich nicht die technischen Details der IT, die man ja reichlich reporten könnte. Es geht im Grunde darum, mit Fakten aufzuzeigen, wie erfolgreich die IT ist. Diese Kennzahlen nennen wir Key Success Faktoren (KSF). Sie setzen sich im Allgemeinen aus anderen Kennzahlen zusammen und sind damit selbst mehrdimensional. Es bietet sich an, die Dimensionen einer Balanced Scorecard als Key Success Faktoren zu nehmen (vgl. Abbildung 62). Die Kennzahlen können Key Performance Indikatoren 2 oder Customer Satisfaction Indices aus der Ebene des IT-Managements sein, die durch Aggregation entstehen. Im Folgenden geben wir einen Ausschnitt aus einem solchen Kennzahlensystem an: 1 ROI im Sinne Return on IT. 2 KPIs im Sinne einer betriebswirtschaftlichen Begriffsbestimmung (vgl. den Exkurs zum Begriff KPI in Kapitel ) 158

168 5.2 Klassifikationsschema für IT-Kennzahlen KSF: Finanzperspektive IT-Kosten nach Umsatz IT-Kosten je Anwender KSF: Potenzialperspektive Aus- und Weiterbildungstage Mitarbeiterzufriedenheit KSF: Kundenperspektive Verfügbarkeit der Systeme Kundenzufriedenheit IT Management Report 2006 Finanzperspektive... Kundenperspektive Mitarbeiterperspektive Abbildung 62: Key Success Faktoren im IT Management Report Die auszuwählenden Key Success Faktoren sind nach unserer Erfahrung für IT-Organisationen unterschiedlich. Wir haben die Perspektiven einer Balanced Scorecard bisher nie eins zu eins von einem Unternehmen auf das andere übertragen können. Das liegt unter anderem daran, dass sich die Key Success Faktoren aus der IT-Strategie ableiten (vgl. Abbildung 63). Meistens benutzen wir zwischen 5 7 Perspektiven und damit auch 5 7 Key Success Faktoren, die die IT insgesamt darstellen. Nicht zu viel und nicht zu wenig gerade geeignet, um die Lage der IT dem Top Management transparent zu machen. Jeder Key Success Faktor sollte mit einem kurzen Text versehen werden, der den Verlauf der Kennzahlen interpretiert und sich auf die aktuelle 159

169 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Situation des Unternehmens bezieht. Expandiert das Unternehmen beispielsweise in andere Länder, so kann dies der Grund für erhöhte IT- Aufwände sein. Hat man in den letzten Jahren die IT-Plattformen konsolidiert, so kann dies in den Folgejahren ein Grund für sinkende Investitionen sein. IT- Strategie Key Success Factor Key Success Factor KPI KPI KPI KPI KPI KPI KPI CSI CSI CSI KPI CSI CSI Key Success Factor Kennzahlensystem Abbildung 63: Key Success Faktoren zur Gruppierung von KPIs und CSIs Hilfreich ist es auch, für Kennzahlen Benchmarks anzugeben, falls diese verfügbar sind. Dies ist in einigen Branchen der Fall. Oft gibt es auch allgemeine Benchmarks, die dem Management zeigen, ob die eigene IT noch im grünen Bereich liegt. Ein Beispiel ist die Kennzahl IT-Kosten pro Umsatz, die zwischen 2 und 3 % liegen sollte. Dies ist aber von Branche zu Branche verschieden und sollte auf die aktuelle Situation des Unternehmens bezogen werden Key Performance und Customer Satisfaction Alle IT Service Management-Ansätze sehen IT-Organisationen als IT Service Provider, die Leistungen für ihre Kunden erbringen. Der Kunde ist in diesem Zusammenhang derjenige, der für Leistungen bezahlt. Kunden werden von Anwendern unterschieden, die lediglich die IT-Infrastruktur nutzen. 160

170 5.2 Klassifikationsschema für IT-Kennzahlen In IT-Kennzahlensystemen sollte die Kundenfokussierung Berücksichtigung finden. Es ist daher nicht nur zu messen und zu bewerten, welche Leistungen die IT-Organisation an ihre Kunden ausliefert sondern auch, wie der Kunde diese Leistungen empfindet. Im Marketing und nicht nur da findet man hierzu den Begriff Customer Satisfaction Index (CSI), der angibt, wie der Kunde einen entsprechenden Service empfindet. Es wird sozusagen die gefühlte Qualität bewertet. Die CSIs sind von den üblichen Key Performance Indikatoren (KPI) zu unterscheiden, die die Leistungsfähigkeit von Prozessen aus eigener Sicht bewerten. In [Zeithaml et al., 1988] werden die Lücken zwischen Kunden- und Providersicht sehr treffend beschrieben. Die nachfolgende Abbildung 64 zeigt zum einen, wie kompliziert die Wahrnehmungsprozesse sind, und zum anderen, dass es viele Schnittstellen gibt, an denen die Kunden- und Providersicht unterschiedlich sein kann. Customer Satisfaction Index Customer Satisfaction Index Abbildung 64: Beispiele für Lücken zwischen Kunden- und Providersicht Wir haben in der Abbildung 64 drei Punkte herausgegriffen, an denen man CSIs messen kann: Zwischen Leistungserwartung und Servicewahrnehmung kann es ein Gap geben. Dies ist in der Praxis oft der Fall, wenn IT- Marketingaspekte zu kurz kommen. Zwischen Leistungserwartung des Kunden und der durch den Provider wahrgenommenen Kundenerwartung kann ebenfalls eine Lü- 161

171 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen cke klaffen. Das ist in der Praxis der Fall, wenn das Service Level Management keine Engagement Funktion hinsichtlich der Kunden wahrnimmt. Sind die Leistungsspezifikationen schwach ausgeprägt, so ist dies ebenfalls ein Nährboden für Wahrnehmungsstörungen. Wir haben diesen Fall in der Praxis oft gesehen, wenn SLAs nicht hinreichend genau formuliert waren und zu große Interpretationsspielräume zuließen. In [OGC, 2007e] werden 16 Gaps identifiziert, die sich im Service Lifecycle in allen möglichen Phasen Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement wiederfinden. Das Service Management hat dafür Sorge zu tragen, dass diese Lücken geschlossen werden und muss gegebenenfalls ein entsprechendes Service Improvement Program (SIP) initiieren. Die untere Abbildung 65 ist angelehnt an Continual Service Improvement [OGC, 2007e] und stellt diese Gaps dar. Interessant ist, dass sie beim Kunden, beim Provider und auch zwischen Kunde und Provider auftreten können. Gap 5 beschreibt beispielsweise ein Kommunikationsproblem bzw. eine falsche Erwartungshaltung, die auf Seiten des Kunden besteht. Für IT-Kennzahlensysteme bedeutet dies, dass CSIs auf der Ebene des IT- Managements gemessen und reported werden müssen. Sie sind zur Steuerung der IT genau so wichtig wie die KPIs. Die Messung der CSIs sollte an all den Stellen erfolgen, wo Kundenkontakte wahrgenommen werden. Der wichtigste Sensor liegt hier sicherlich beim CIO selbst, der wahrnehmen muss, wie die IT im Unternehmen da steht. Andere Quellen sind natürlich das Service Level Management, aber auch der Service Desk sowie das Projekt Management. 162

172 Kommunikation zum Kunden 5.2 Klassifikationsschema für IT-Kennzahlen Externe u. interne Kommunikation, GAP 1 Einflüsse und Treiber GAP 3 GAP 5 Was wollen wir? Was brauchen wir? Was bekommen wir? Erwarteter Service Was bekamen wir? Erhaltener Service Erfahrung GAP 2 Vergangenheit GAP 16 GAP 4 GAP 15 GAP 14 GAP 9 GAP 6 GAP 8 GAP 7 Service Operation Service Transition Service Design Service Strategy GAP 13 GAP 12 GAP 11 GAP 10 Abbildung 65: Gaps nach OGC (aus [OGC, 2007e]) Exkurs: Zum Begriff Key Performance Indicator (KPI) Es sei an dieser Stelle angemerkt, dass der Begriff Key Performance Indicator (KPI) in vielen Zusammenhängen verwendet wird. Betriebswirtschaft / Management (vgl. [Wikipedia, 2007]): Key Performance Indicators (KPI) are financial and non-financial metrics used to quantify objectives to reflect strategic performance of an organization. KPIs are used in Business Intelligence to assess the present state of the business and to prescribe a course of action. KPIs are typically tied to an organization's strategy (as exemplified through techniques such as the Balanced Scorecard). The KPIs differ depending on the nature of the organization and the organization's strategy. COBIT (vgl. [COBIT, 2005]): Hier werden die wesentlichen Leistungsindikatoren als Key Goal Indicators (Effektivität) bezeichnet, während KPIs lediglich die Effizienz beschreiben. 163

173 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen ITIL definiert KPIs als (vgl. [OGC, 2007c]): A Metric that is used to help manage a Process, IT Service or Activity. Many Metrics may be measured, but only the most important of these are defined as KPIs and used to actively manage and report on the Process, IT Service or Activity. KPIs should be selected to ensure that Efficiency, Effectiveness, and Cost Effectiveness are all managed. Auf der IT- Management- Ebene sind KPIs und CSIs zu reporten. Wenn wir in unserem Klassifikationsschema in diesem Abschnitt von KPIs reden, verstehen wir darunter KPIs im Sinne der betriebswirtschaftlichen Definition. Diese Begriffsbestimmung ist allgemeiner, hat sich auch im IT- Controlling durchgesetzt und kann auch im Zusammenhang mit nicht- COBIT-basierten Frameworks eingesetzt werden. KPIs sind eben auch wesentlich für die Umsetzung der IT-Strategie ja, entstehen geradezu aus dieser und müssen losgelöst von Frameworks für jedes Unternehmen individuell zusammengestellt werden. KPIs müssen die Prozessperformance widerspiegeln. Leistungsgrößen sind besser als Aufwandsgrößen. Prozesse darstellen und möglichst Kundenbezug haben. Steuerungsinstrumente des Process Owners und Prozess Managers sein. mit den Customer Satisfaction Indicators CSIs verknüpft werden können. Beispiele für KPIs sind die Erstlösungsrate im Service Desk und IT- Projekte in time und in budget. Beispiele für CSIs sind die empfundene Kompetenz der Service Desk Mitarbeiter und die Kundenzufriedenheit mit der IT IT-Controls und Controls on Demand Durch die Vielzahl eingesetzter Monitoring Tools stehen in IT- Organisationen zeitnah immense Datenmengen zur Verfügung, die prinzipiell als Kennzahlen nutzbar sind. Es macht auf keiner Ebene des Kennzahlensystems weder auf der Geschäftsführungs- noch auf der IT Management Ebene Sinn, eine unüberschaubare Menge von Kennzahlen in ein monatliches Reporting einzubeziehen. Wir unterscheiden daher IT-Controls und Controls on Demand. IT-Controls sind Kennzahlen, die kontinuierlich reported werden. Controls on Demand sind Kennzahlen, die nur in speziellen Situationen aussagekräftig sind. 164

174 Beispiele für IT-Controls sind: 5.2 Klassifikationsschema für IT-Kennzahlen Personalaufwand monatlich Abschreibungen auf Sachanlagen Kapazitätsplan Fehlzeiten Anzahl von Systemstillständen 3 Auswertung der Service-Aufträge Erstlösungsrate (Incident Management) 4 Anteil fehlerhafter Changes (Change Management) 5 Wie die IT-Controls strukturiert werden, hängt vom Typ und von der Größe der IT-Organisation ab. Es bieten sich verschiedene Werkzeuge an, unter anderem die Balanced Scorecard. Im Gegensatz zum Fall des Reportings an die Geschäftsleitungsebene haben wir hier in unseren Projekten eine stärkere Ähnlichkeit der Kennzahlensysteme untereinander erkennen können. Die Idee, Cockpits einzusetzen, die diese Kennzahlen automatisch aus den operativen Systemen generieren, setzt sich immer mehr durch. Die Steuerung der IT über ein Cockpit kann vor allen Dingen zeitnah erfolgen und bedarf nicht der aufwendigen Sammlung und Auswertung von Daten zu einem bestimmten Zeitpunkt. Controls on Demand werden auf Anforderung reported. Sie müssen zwar generell zur Verfügung stehen, werden aber nur situationsbedingt eingesetzt, da sie von Ereignissen (oder Projekten) getriggert werden: Nach einem Angriff muss reported werden, wer auf welche Server zugegriffen hat. Nach Ausfall des Web-Servers muss die Trafic-Situation reported werden. Beispiele für Controls on Demand sind: Betrieb der IT-Infrastruktur Auslastung Datenbanken Verfügbarkeit spezieller Server Web-Server-Statistik Virenbefall-Statistik 3 Dies ist eine Standard-Kennzahl für das Prozessmanagement, die wir im folgenden Kapitel behandeln. 4 Dito. 5 Dito. 165

175 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Anwendungen Datensicherungsprotokolle Anzahl Datensätze in SAP BW ITIL Prozesse (Prozess Owner Kennzahlen) Größe und Kapazität der DSL (Release Management) Dokumentationsqualität der CIs (Configuration Management) Das Beispiel zeigt, dass wir den Bereich der Controls on Demand absolut inhaltlich ausrichten. Es gibt keine Meta-Ebene, die sich beispielsweise an der IT-Strategie orientiert. Bei Controls on Demand geht es bei der Klassifizierung in Gruppen nur um eins: Die betreffenden Statistiken zu den Kennzahlen müssen im Ernstfall schnell gefunden werden können. 5.3 Prozess-Kennzahlen Im Folgenden beschreiben wir ausgewählte Prozess-Kennzahlen, die sich in unseren Projekten und auf der Basis unserer Managementerfahrungen bewährt haben. Sie basieren zum Teil auf ITIL und COBIT, beinhalten aber darüber hinausgehende Betrachtungen. Die Struktur der dargestellten Kennzahlen bildet die in der ITIL Version 3 beschriebenen Prozesse und Managementaufgaben. Zusätzlich wurde der Service Desk als Anforderung an die Aufbauorganisation aufgenommen. Bedingt durch die zusammenfassende Darstellung aus den verschiedenen Best Practices, ist vor der Nutzung der ausgewiesenen Kennzahlen zu prüfen, ob sie in Verbindung mit den spezifizierten Prozesszielen der IT-Organisation stehen. Zu den ausgewiesenen Kennzahlen wird deren jeweilige Definition, Messung und Relevanz spezifiziert. Bei der Messung von Kennzahlen ist zu beachten, dass hierfür keine Standards existieren. So ist zum Beispiel die Kennzahl Erstlösungsquote weit verbreitet, aber deren Messung weicht zwischen den einzelnen IT-Organisationen voneinander ab. Daher muss bei einem Vergleich von Kennzahlen zwischen Organisationen immer deren spezifische Messung in die Betrachtung einbezogen werden. Im Rahmen von Benchmarks soll eine gemeinsame Vergleichsbasis sichergestellt werden. Die im Folgenden angegebenen Messwerte stammen aus unserer Projekterfahrung. Sie können von Fall zu Fall von den implementierten Methoden in IT-Organisation abweichen. 166

176 5.3 Prozess-Kennzahlen Wie bereits im Kapitel Prozess-Management ausgeführt, stehen die Ziele Ihrer IT-Prozesse im Vordergrund. Daher sind auch die hier aufgeführten Prozesse hinsichtlich deren Relevanz kritisch zu prüfen. Damit die aufgeführten Kennzahlen die notwendigen Informationen liefern können, müssen sie jeweils als Trend, in Bezug zum Sollwert und in Relation zu anderen Kennzahlen dargestellt werden. So ist zum Beispiel die Information einer schlechter werdenden Erstlösungsquote erst dann hilfreich, wenn gleichzeitig die Anzahl der eingehenden Störungsmeldungen dargestellt wird. Kennzahlen sind als Trend und Relation darzustellen. Durch die Darstellung von Trends für die im Anschluss beschriebenen Kennzahlen steigt der Informationsgehalt. Bei der Trenddarstellung sind die Sollwerte als Bezugslinien auszuweisen. Die Kennzahlen sind nach dem Motto Keep It Simple Stupid (KISS) - oder In der Kürze liegt die Würze - zu definieren. Einerseits sollten die Kennzahlen möglichst einfach verständlich zu sein. Andererseits gilt es auch den Aufwand zu betrachten, der zur Generierung einer Kennzahl notwendig ist. Hier muss jeweils der Aufwand zur Generierung mit der Steuerungsrelevanz der Kennzahl und des möglichen Verbesserungspotenzials bewertet werden. Um Zusatzaufwendungen zu vermeiden, sollten die Kennzahlen möglichst ohne zusätzlichen Erfassungsaufwand aus den operativen IT-Systemen gewonnen werden. Speziell die Kennzahlen für die Prozesse Incident Management, Request Fulfilment, Problem Management, Access Management, Service Asset and Configuration Management, Change Management und Release and Deployment Management generieren sich weitestgehend aus dem eingesetzten IT Service Management-Tool. Kennzahlen werden zum Teil durch die Verknüpfungen von Daten aus verschiedenen Prozessen gewonnen. Dies erfordert eine hohe Integrität der zugrunde liegenden Datenbasis über verschiedene Prozesse hinweg. Kennzahlen sind möglichst aus operativen Systemen zu generieren. Auch aus der Betrachtung der Kennzahlengenerierung sollte das eingesetzte Tool nach Möglichkeit von einem Hersteller stammen. Es muss sichergestellt werden, dass die automatisch generierten Kennzahlen fehlerfrei sind. Zum Teil werden Daten aus einem anderen Prozess zur Generierung von Kennzahlen herangezogen. Zum Beispiel lautet eine Kennzahl zum Change Management Anteil fehlerhafter Changes. Um diese Kennzahl zu ermitteln, müssen Daten aus dem Incident Management ermittelt werden. Bei zukünftigen Änderungen in Prozessen und der eingesetzten Toolumgebung ist sicherzustellen, dass diese Änderungen keine Auswirkungen auf die daraus generierten Kennzahlen haben. 167

177 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Änderungen im Tool sind Changes und als solche zu behandeln Änderungen im IT Service Management-Tool sind auf mögliche Auswirkungen hinsichtlich der Kennzahlengenerierung zu bewerten. Daher sollten auch Änderungen am IT Service Management-Tool über das Change Management gesteuert werden. Die Tool-Unterstützung in den einzelnen IT-Organisationen ist sehr vielfältig. Zum Teil existiert zumindest für einen Teil der Prozesse des Service Design (früher Service Delivery) und Service Transition (früher Service Support) und Service Operations (früher Service Support) ein einheitliches Tool mit einer zentralen gemeinsamen Datenbank. Bei anderen IT-Organisationen werden die Service Management-Prozesse von unterschiedlichen Tools und Datenbaken unterstützt. Daher wird in den folgenden Kapiteln der Prozessname als Synonym für das Tool bzw. den View in der Datenbank genannt. Die IT Service Management-Prozesse und die Generierung von Kennzahlen bedingen eine adäquate Tool-Unterstützung. Die Kennzahlen werden zum Teil prozessübergreifend gewonnen. Es empfiehlt sich, die eingesetzten Produkte von einer geringen Anzahl von Herstellern zu beziehen. Datenqualität im Prozess kritisch bewerten und ggf. eine andere Messung wählen Eine wichtige Datenbasis für die Messung von Kennzahlen stellt der Prozess des Incident Managements mit den dokumentierten Incident Records dar. So kann zum Beispiel die Effektivität des Change Managements, das heißt die fehlerfreie Implementierung von Changes, an der Anzahl von Incidents aufgrund des implementierten Changes gemessen werden. Dies setzt voraus, dass die Incident Records die notwendige Datenqualität aufweisen. Dazu müssen die Mitarbeiter über ein ausreichendes Know-how, aber insbesondere über ausreichende Zeit und Motivation (Einsicht) für die korrekte Erfassung des Incident Records verfügen. Ist diese Datenqualität nicht gegeben, leidet der Informationsgehalt von Kennzahlen in anderen IT Service Management-Prozessen. Kann hier keine ausreichende Datenqualität sichergestellt werden, so muss über eine alternative Messmethode nachgedacht werden. Zum Beispiel, in dem Probleme anstatt der Incidents ausgewertet werden. Kennzeichnend für das IT Service Management sind Prozesse mit wechselseitigen Aktivitäten und Schnittstellen. Daher werden häufig Daten aus anderen Prozessen zur Generierung von Kennzahlen genutzt. Eine schlechte Datenqualität, wie zum Beispiel von Incident Records, hat Auswirkung auf die Aussagekraft von Kennzahlen in anderen Prozessen. 168

178 5.3 Prozess-Kennzahlen Service Strategy Financial Management Der Prozess und die Funktionen des Financial Management sind verantwortlich für das Management der Budgetierung, des Accounting und des Charging beim IT Service Provider. Name der Kennzahl Definition Relevanz Messwert Bemerkung Kundenzufriedenheit Financial Management Ergebnis der Kundenzufriedenheit mit dem Financial Management für IT Services. Die Kundenzufriedenheit zeigt, wie das Kostenmodell und die Preise empfunden werden. Abfrage in der Kundenzufriedenheitsumfrage Hier sollten die Fragen auf bestimmte Aspekte, wie Verständlichkeit des Kostenmodells oder Fairer Service-Preis detailliert werden. Name der Kennzahl Definition Relevanz Messwert Budgetplanung Übereinstimmung des geplanten Budgets mit den tatsächlichen Ausgaben. Eine gute Budgetplanung reduziert die finanziellen Risiken. Gegenüberstellung der Plan-Kosten zu den tatsächlichen Kosten. Diese sind in der Regel im ERP-System hinterlegt. Name der Kennzahl Definition Relevanz Messwert Ermittlung Service-Kosten Ermittlung der vollständigen Kosten für den IT Service Mittels des IT Service werden die Geschäftsprozesse sichergestellt. Hierzu werden servicebezogene IT-Kosten bzw. Preise benötigt. Auswertung der Kosten im Service Katalog. 169

179 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl Definition Relevanz Messwert Bemerkung Bemängelte Leistungsverrechnung Anteil der verrechneten Leistungen, die vom Kunden hinterfragt bzw. reklamiert werden. Die Leistungsverrechnung muss für den Kunden nachvollziehbar und widerspruchsfrei sein. Auswertung der durchgeführten und dokumentierten Reviews. Voraussetzung für die Messung ist, dass die Reviews auf diesen Aspekt eingehen. Name der Kennzahl Definition Relevanz Messwert Anteil kritischer Services mit BIA Anteil der geschäftskritischen Services, für die eine Business Impact Analyse (BIA) vorliegt. Mithilfe der BIA können die Auswirkungen von Serviceausfällen auf die Geschäftsprozesse bewertet werden und sind Basis für Forderungen an die sicherzustellende Qualität des Service Managements. Identifizierung kritischer Services aus dem Service Katalog und Überprüfung auf vorhandene BIA. Name der Kennzahl Definition Relevanz Messwert Bemerkung IT-Kosten am Umsatz Anteil der IT-Kosten am Umsatz des Unternehmens. Dies ist die klassische Kennzahl zur Bewertung der IT aus Top Management Sicht. Die Messwerte sind nach Branche verschieden. Ein Benchmark ist das Intervall 1,5 bis 3,00 %. Die Kennzahl beschreibt, wie effizient die IT arbeitet (Kostenaspekt). 170

180 5.3 Prozess-Kennzahlen Service Portfolio Management Dieser Prozess ist für das Management des Service Portfolios verantwortlich. Er berücksichtigt die Services in Bezug auf den für das Business gelieferten Wert. Name der Kennzahl Definition Relevanz Messwert Anzahl Services im Portfolio Anzahl der definierten Services im Portfolio Ist einerseits als Referenzwert notwendig, andererseits zeigt die Kennzahl den Umfang des Servicespektrums auf. Auswertung der Services im Service Portfolios Name der Kennzahl Definition Relevanz Messwert Anteil gelieferter Services Anteil der im Service Portfolio definierten Services, die von Kunden genutzt werden. Diese Kennzahl zeigt die Nachfrage der angebotenen Services auf. Auswertung der Services im Service Katalog und im Service Portfolio. Name der Kennzahl Definition Messwert Anteil Relationen IT Services zu Geschäftsprozessen Anteil der abgebildeten Relationen zu den übergeordneten Geschäftsprozessen. Die IT Services dienen der Unterstützung der Geschäftsprozesse. Vorfälle und Maßnahmen innerhalb der IT können so direkt einem Geschäftsprozess zugeordnet werden. Auswertung des Service Portfolios. Name der Kennzahl Definition Relevanz Messwert Anteil Veränderungen im Service Portfolio Anteil der im Service Portfolio vorgenommenen Veränderungen an den enthaltenen Services. Die Kennzahl ist ein Kennzeichen für die Dynamik der geplanten und angebotenen Services. Auswertung des Service Portfolios. 171

181 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl Definition Relevanz Messwert Bemerkung Status der Services im Service Portfolio Status der Services im Service Portfolio Die Kennzahl zeigt den Anteil der produktiven Services in Relation zu den in Entwicklung/ Überführung sowie den in Aussonderung befindlichen Services. Auswertung des Service Portfolios und Gruppierung anhand des Status. Die Services können den folgenden Status annehmen Service Katalog, Service Pipeline (Service noch nicht produktiv) und Retired Services Demand Management Das Demand Management hat die Kundenanforderungen an die IT Services aufzunehmen und zu beeinflussen, sodass die notwendigen Kapazitäten bereitgestellt werden können, die diesen Forderungen entsprechen. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl der Kundenneuprojekte Anzahl der vom Kunden gewünschten Neuprojekte in einer speziellen Applikationsdomain, einem Applikationsbereich etc. Festlegung der Priorität in der Umsetzung von Applikationsprojekten. Festlegung der IT Ressourcenauslastung mit dem Kunden. Anzahl der IT Projektanmeldungen pro Applikationsbereich und Zeitraum Transparenz zwischen Kunde und IT bzgl. der IT Ressourcenauslastung. Name der Kennzahl Definition Relevanz Anzahl kurzfristiger Kapazitätsanpassungen Anzahl kurzfristiger Anpassungen der bereitzustellenden Kapazitäten Kurzfristige Anpassungen der Kapazitäten führen zu Zusatzkosten. Entweder entstehen ungenutzt Überkapazitäten oder Zusatzkapazitäten sind kurzfristig daher in der Regel teuer zu beschaffen. Häufig auftretende Anpassungen 172

182 5.3 Prozess-Kennzahlen Messwert sind ein Indiz für Probleme beim Demand Management. Ergebnisse aus dem Review des Capacity Managements Service Design Service Catalogue Management Das Service Catalogue Management soll sicherstellen, dass ein Servicekatalog entwickelt und gewartet wird, der genaue Information über alle aktuellen und geplanten operationellen Services enthält. Name der Kennzahl Definition Relevanz Messwert Bemerkung Service aus dem Service Katalog Anzahl und Anteil der im Betrieb befindlichen Services, die im Service Katalog beschrieben sind. Der Service Katalog soll alle im Betrieb befindlichen Services enthalten. Diese Kennzahl zeigt die Qualität und Aktualität des Service Katalogs auf. Vergleich der SLAs mit dem Service Katalog. Bei der Messung wird vorausgesetzt, dass für alle im Betrieb befindlichen Services SLAs existieren. Name der Kennzahl Definition Relevanz Messwert Bemerkung Inhaltliche Abweichungen zum Service Katalog Anteil der inhaltlichen Abweichungen der im Betrieb befindlichen Services gegenüber den Spezifikationen im Service Katalog. Der Service Katalog dient auch der Standardisierung von Services. Weichen die tatsächlichen Services von den Beschreibungen im Service Katalog ab, so wird diese Standardisierung nicht erreicht. Vergleich der SLAs mit dem Service Katalog. Bei der Messung wird vorausgesetzt, dass für alle im Betrieb befindlichen Services SLAs existieren. 173

183 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Service Level Management Der Prozess Service Level Management (SLM) ist für das Verhandeln von Service Level Agreements verantwortlich und hat sicherzustellen, dass diese SLAs eingehalten werden. Das SLM hat sicherzustellen, dass alle IT Service Management-Prozesse, Operational Level Agreements (OLAs) and Underpinning Contracts (UCs) den vereinbarten Service Level Zielen (Service Level Targets) entsprechen. Das SLM führt hierzu ein Monitoring und Reporting der Service Level sowie regelmäßige Reviews mit den Kunden durch. Name der Kennzahl Definition Relevanz Messwert Bemerkung Kundenzufriedenheit Service Level Management Ergebnis der Kundenzufriedenheit mit dem Service Level Management. Die Kundenzufriedenheit mit dem Service Level Management ist mehr als die (messtechnische) Einhaltung der SLAs. Dazu gehört unter anderem auch die Flexibilität des IT Service Providers. Abfrage in der Kundenzufriedenheitsumfrage. Zusätzlich kann dieser Aspekt auch innerhalb einer Anwenderzufriedenheitsumfrage abgefragt werden. Name der Kennzahl Definition Relevanz Messwert Bemerkung Einhaltung der SLAs Anteil der SLAs, deren Vereinbarungen eingehalten werden. Die Einhaltung von SLAs stellt die vereinbarte IT-Unterstützung der Geschäftsprozesse sicher. Im externen Kunden-Lieferanten-Verhältnis sind mit der Einhaltung Preis-Regelungen verbunden. Hier sollte auf ein professionelles SLM-Tool zurückgegriffen werden, mit dessen Hilfe die einzelnen SLAs gemessen und die Ergebnisse berichtet werden können. Hierzu muss definiert werden, wann ein SLA als eingehalten zählt. Zum Beispiel, wenn alle 174

184 einzelnen Service Level eines SLAs eingehalten werden. 5.3 Prozess-Kennzahlen Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl der SLA-Reviews Anteil der durchgeführten SLA-Reviews. Die Reviews unterstützten eine bessere Zusammenarbeit zwischen Kunde und IT Service Provider. Im Rahmen von Reviews werden u. a. notwendige Service-Verbesserungen diskutiert. Auswertung der dokumentierten Reviews. Die Anzahl der Reviews können auch im SLA vereinbart werden. Name der Kennzahl Definition Relevanz Messwert Bemerkung Kundenerlöspriorität im Unternehmen Welche Erlöse werden mit welchem Kunden, welchem Fachbereich, welcher Unternehmenseinheit getätigt. Fokussierung auf die wichtigsten Kunden der IT. Erlös-Summe aller SLAs für einen bestimmten Kunden. Eine für die IT relevante Kennzahl, um im Sinne der ABC Technik festzulegen, wie intensiv ein Kunde betreut wird. Kunden mit hohen IT Erlösen werden bevorzugt betreut. Diese Kennzahl ist auch im Sinne des Gesamtunternehmens von hoher Bedeutung, da sie auf die Unternehmensbereiche mit hohen IT Erlösen fokussiert. Name der Kennzahl Definition Relevanz Messwert Anteil SLA Verletzungen durch UCs Anteil der SLA-Verletzungen, die aufgrund nicht eingehaltener UCs entstanden sind. Können SLAs nicht eingehalten werden, weil der Lieferant seine Zusagen nicht einhält, so müssen entsprechende Folgeaktivitäten eingeleitet werden. Hier sollte auf ein professionelles SLM-Tool 175

185 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen zurückgegriffen werden, mit dessen Hilfe die einzelnen SLAs und UCs gemessen und die Ergebnisse berichtet werden können. Name der Kennzahl Definition Relevanz Messwert Anteil SLA Verletzungen durch OLAs Anteil der SLA-Verletzungen, die aufgrund nicht eingehaltener OLAs entstanden sind. Können SLAs nicht eingehalten werden, weil interne Einheiten ihre Zusagen nicht einhalten, so müssen entsprechende Folgeaktivitäten eingeleitet werden. Hier sollte auf ein professionelles SLM-Tool zurückgegriffen werden, mit dessen Hilfe die einzelnen SLAs und OLAs gemessen und die Ergebnisse berichtet werden können. Name der Kennzahl Definition Relevanz Messwert Anzahl ausstehender Maßnahmen im SIP Anzahl der im Service Improvement Plan (SIP) enthaltenen Maßnahmen, die nicht wie geplant umgesetzt wurden. Der SIP enthält notwendige Verbesserungsmaßnahmen für die IT Services. Diese Kennzahl zeigt, ob die identifizierten Maßnahmen planmäßig umgesetzt wurden. Auswertung der offenen Maßnahmen im SIP, deren Umsetzungstermin überschritten ist. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl Maßnahmen im SIP Anzahl der im Service Improvement Plan (SIP) enthaltenen Maßnahmen. Der SIP enthält notwendige Verbesserungsmaßnahmen für IT Services. Diese Kennzahl zeigt den Umfang der noch offenen Maßnahmen bzw. der umgesetzten Maßnahmen. Auswertung der offenen Maßnahmen im SIP. Die Maßnahmen sollten im Plan mit einem Status versehen werden. Dadurch können offene 176

186 Maßnahmen, in der Umsetzung befindliche oder bereits umgesetzte Maßnahmen dargestellt werden. 5.3 Prozess-Kennzahlen Capacity Management Das Capacity Management stellt sicher, dass die bereitgestellten Kapazitäten für die IT Services und die IT Infrastruktur gemäß den vereinbarten Service Level Zielen kostengünstig und rechtzeitig bereitgestellt werden. Das Capacity Management berücksichtigt alle geforderten Ressourcen zur Bereitstellung des IT Service und plant auf Basis der kurz-, mittel- und langfristigen Geschäftsanforderungen. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl SLA-Verletzungen aufgrund fehlender Kapazitäten Anzahl der Verletzungen von SLAs aufgrund der nicht sichergestellten Kapazitäten. Werden die vereinbarten Kapazitäten nicht bereitgestellt, so führt dies in der Regel zu Geschäftsausfällen. Die Ist-Kapazitäten werden in der Regel aus dem System-Management oder mit Robotern (Antwortzeiten) ermittelt und den Soll-Werten gegenübergestellt. Die SLA-Verletzungen sind pro SLA auszuweisen. Name der Kennzahl Definition Relevanz Messwert Lastspitzen und Gesamtauslastungsrate Darstellung der Lastspitzen und Gesamtauslastung pro SLA. Zielsetzung des Capacity Managements ist die Einhaltung der Service Level, aber auch der Wirtschaftlichkeit. Daher sollte sich die Auslastung - in Abhängigkeit der IT-Strategie - dem Soll-Wert annähern. Lastspitzen können ggf. Zusatzbedarf oder die Notwendigkeit von Verlagerungen aufzeigen Die Auslastungen werden in der Regel aus dem System-Management oder zum Beispiel mit Robotern (Antwortzeiten) ermittelt. 177

187 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl Definition Relevanz Messwert Prozentsatz unzureichender Antwortzeiten Prozentsatz der Antwortzeiten, die dem SLA nicht entsprechen. Schlechte Antwortzeiten führen dazu, dass der Service als nicht verfügbar angesehen und nicht mehr genutzt wird. Geschäftsausfälle und Kundenunzufriedenheit sind die Folge. Die Antwortzeiten werden in der Regel aus dem System-Management oder zum Beispiel mit Robotern ermittelt. Name der Kennzahl Definition Relevanz Messwert Bemerkung Qualität des Capacity Plans Übereinstimmung der im Capacity Plan dokumentierten Veränderungen gegenüber den tatsächlichen Veränderungen. Eine gute Planung ist wichtig für das Financial Management. Eine gute Planung verhindert kurzfristige und in der Regel teurere Beschaffungsmaßnahmen. Gegenüberstellung der Planungsdaten gegenüber den Daten des Configuration Management Systems. Es können auch Emergency Changes aus dem Capacity Managements ermittelt werden. Diese sind ein Indiz für einen kurzfristigen Handlungsbedarf. Name der Kennzahl Definition Relevanz Messwert Anzahl und Anteil überwachter Systeme Anzahl und Anteil der zentralen Systeme, die mittels eines Monitoring überwacht werden. Das Monitoring ist Voraussetzung für eine gute Planung und Überwachung der eingesetzten Systeme. Die Anzahl ist dem System Management zu entnehmen, ggf. auch dem Configuration Management. Die Anzahl der zentralen Systeme kann dem Configuration Management System entnommen werden. 178

188 5.3 Prozess-Kennzahlen Name der Kennzahl Definition Relevanz Messwert Bemerkung Kosteneinsparung durch das Capacity Management pro Bereich oder Technologie Einsparungssumme in Euro, die durch optimaleren Einsatz von Technik (z. B. Verdichtung von Applikationen durch Virtualisierung) eingespart werden kann. Capacity wird in immer mehr Unternehmen nicht nur in der Prognose von Kapazitätswachstum gesehen, sondern auch zur effektiveren Nutzung der Ressourcen Kosteneinsparung durch optimalere Nutzung der Technologien in Euro; z. B. im Bereich der Security wurden Euro Invest eingespart, indem Lizenzen aus dem Abbau von Clients im Bereich xyz wiederverwendet wurden. Vermeidung von Invest durch Technologieoptimierungen sichert die Möglichkeit, in innovative IT Bereiche zu investieren Name der Kennzahl Capacity Management pro Technologie zum Beispiel Anzahl der Mails In and Out pro Tag Definition Vergleich der eingehenden zu den ausgehenden Mails. Je nach Unternehmen ist diese Kennzahl unterschiedlich, liegt aber in der Regel bei ca. 1 zu 2 (ausgehend zu eingehend). Sollte der eingehende Wert stark ansteigen ist dies z. B. der Hinweis auf SPAM oder Mail-Attacken, dem unbedingt entgegen zu treten ist, um die Ressourcen weiterhin optimal zu nutzen. Relevanz Erkennen von Ressourcenverschwendungen Hinweis auf die Einführung neuer Technologien um einen Kostenanstieg dauerhaft zu vermeiden. Messwert Vergleich über mehrere Tage, Wochen, Monate der Anzahl der eingehenden zu den ausgehenden Mails. 179

189 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Availability Management Der Prozess ist verantwortlich für die Definition, Analyse, Planung, Messung und Verbesserung aller Aspekte der Verfügbarkeit für IT Services. Das Availability Management ist dafür verantwortlich, dass die gesamte IT Infrastruktur, Prozesse, Tools, Rollen usw. den vereinbarten Service Level Zielen bezüglich der Verfügbarkeit entsprechen. Name der Kennzahl Definition Relevanz Messwert Verfügbarkeit des Service und Komponenten Verfügbarkeit der Services und der Komponenten innerhalb des vereinbarten Zeitraums. Die Verfügbarkeit ist als wichtigster Service Level anzusehen. Deren Kenntnis ist ein wichtiger Input für das Service Level Management. Die Definition der Messung ist abhängig von der geforderten Qualität und den damit verbundenen Kosten. Von der Auswertung von Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel über Mess- PCs. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl SLA-Verletzungen aufgrund fehlender Verfügbarkeit Anzahl der Verletzungen von SLAs aufgrund der nicht sichergestellten Verfügbarkeit. Wird die vereinbarte Verfügbarkeit nicht sichergestellt, so führt dies in der Regel zu Geschäftsausfällen. Auswertung der gemessenen Verfügbarkeit gegenüber dem Soll-Wert. Die SLA-Verletzungen sind pro SLA auszuweisen. Name der Kennzahl Definition Relevanz Nicht-Verfügbarkeit innerhalb kritischer Geschäftszeiten Nicht-Verfügbarkeit innerhalb kritischer Geschäftszeiten für einen IT Service. Wurden mit dem Kunden kritische Geschäfts- 180

190 5.3 Prozess-Kennzahlen Messwert zeiten vereinbart, so ist die Verfügbarkeit innerhalb dieser Zeit besonders herauszustellen. Die Definition der Messung ist abhängig von der geforderten Qualität und den damit verbundenen Kosten. Von der Auswertung von Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel über Mess- PCs. Name der Kennzahl Definition Relevanz Messwert Kosten der Nicht-Verfügbarkeit Kosten für das Business, wenn die vereinbarte Verfügbarkeit nicht erreicht wird. Wird die Verfügbarkeit nicht erreicht, so führt dies in der Regel zu Geschäftsausfällen oder zumindest Zusatzkosten. 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 Definition Relevanz Messwert Bemerkung Mittlere Ausfallzeit pro Service Mittlere Ausfallzeit pro IT Service, gemessen vom Ausfall des Service bis zum Zeitpunkt, zu dem der Service wieder vom Kunden (Anwender) genutzt werden kann. Während die Verfügbarkeit ein statisches Maß ist, bestimmt die mittlere Ausfallzeit die jeweilige Dauer. Maximale Dauer kann zusammen mit der Verfügbarkeit als Service Level vereinbart werden. Die Definition der Messung ist abhängig von der geforderten Qualität und den damit verbundenen Kosten. Von der Auswertung von Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel über Mess- PCs. Zum Teil wird diese Zeit als MTTR - Mean Time to Restore - bezeichnet. Häufiger wird die Ab- 181

191 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen kürzung für Mean Time to Restore verwendet. Es ist daher stets zu prüfen, ob die Zeitspanne die Recovery-Zeit einschließt. Eine Drill-Down Funktion sollte eine detaillierte Analyse der einzelnen Zeitstrecke ermöglichen. Name der Kennzahl Definition Relevanz Messwert Häufigkeit von Ausfällen pro Service Anzahl der Unterbrechungen des vereinbarten Service. Die Kennzahl dient als Indiz für die Zuverlässigkeit des IT Service. Die Definition der Messung ist abhängig von der geforderten Qualität und den damit verbundenen Kosten. Von der Auswertung von Incidents ist abzuraten. Bei hohen Anforderungen erfolgt die Messung in der Regel über Mess- PCs. Name der Kennzahl Definition Relevanz Messwert Bemerkung Qualität des Availability Plans Übereinstimmung der im Availability Plan dokumentierten Veränderungen gegenüber den tatsächlichen Veränderungen. Eine gute Planung ist wichtig für das Financial Management. Eine gute Planung verhindert kurzfristige und in der Regel teurere Beschaffungsmaßnahmen. Gegenüberstellung der Planungsdaten gegenüber den Daten des Configuration Management Systems. Es können auch Emergency Changes aus dem Availability Managements ermittelt werden. Diese sind ein Indiz für einen kurzfristigen Handlungsbedarf IT Service Continuity Management Der Prozess IT Service Continuity Management (ITSCM) ist verantwortlich für das Management der Risiken, die schwere Auswirkungen auf den IT Service haben. Das ITSCM stellt durch eine Risikoreduzierung auf eine 182

192 akzeptable Ebene und die Planung des Recovery von IT Services sicher, dass der IT Service Provider immer die minimal vereinbarten Service Level Ziele bereitstellen kann. Das ITSCM sollte zur Unterstützung des Business Continuity Managements entworfen werden. 5.3 Prozess-Kennzahlen Name der Kennzahl Definition Relevanz Messwert Bemerkung Anteil SLAs mit ITSC-Anforderungen Anteil der SLAs, die Anforderungen an die IT Service Continuity enthalten. Die ITSCM Pläne sind an die Geschäftsanforderungen und den jeweiligen Service-Anforderungen auszurichten. Innerhalb von SLAs sind diese zu dokumentieren. Überprüfung der vorhandenen SLAs. Hier wird davon ausgegangen, dass für sämtliche Services SLAs existieren. Alternativ ist zu prüfen, ob die ITSC-Pläne mit den IT Services korrespondieren. Name der Kennzahl Definition Relevanz Messwert Anzahl und Anteil erfolgreicher ITSCM Audits Anzahl und Anteil der erfolgreich durchgeführten ITSCM Überprüfungen. Es muss sichergestellt werden, dass die ITSCM Pläne im Notfall auch funktionieren. Daher sind sie regelmäßig zu überprüfen. Auswertung der durchgeführten Reviews und Audits. Bemerkung Ergänzend sollte das Datum des letzten Audits / Reviews ausgewiesen werden. Name der Kennzahl Definition Relevanz Messwert Anzahl und Anteil erfolgreicher ITSCM Tests Anzahl und Anteil der erfolgreich durchgeführten ITSCM Tests. Es muss sichergestellt werden, dass die ITSCM Pläne im Notfall auch funktionieren. Daher sind sie regelmäßig zu testen. Auswertung der durchgeführten Testprotokolle. 183

193 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Bemerkung Die Tests sollten zumindest einmal jährlich zusammen mit den Geschäftsbereichen (Business Continuity Management) erfolgen. Name der Kennzahl Definition Relevanz Messwert Schulungsstunden und Maßnahmen ITSCM Anzahl der durchgeführten Schulungsstunden und Schulungsmaßnahmen für das ITSCM. Schulung der Mitarbeiter stellt sicher, dass die Mitarbeiter mit den Maßnahmen vertraut sind und die Notwendigkeit einsehen. Auswertung der durchgeführten Schulungsmaßnahmen. Name der Kennzahl Definition Relevanz Messwert Zeitdauer für Aktualisierung der ITSC-Pläne Zeitdauer für Aktualisierung der ITSC-Pläne aufgrund eines identifizierten Änderungsbedarfs. Änderungen können sich aufgrund geänderter Kundenanforderungen oder durchgeführter Changes ergeben. Dann ist sicherzustellen, dass die notwendigen Änderungen zeitnah umgesetzt werden. ITSC-Pläne sind CIs. Im Rahmen der Versionsverfolgung kann aus dem Configuration Management System die Zeitspanne ermittelt werden Information Security Management Der Prozess Information Security Management stellt die Vertraulichkeit, Integrität und Verfügbarkeit von den Vermögenswerten (Assets) einer Organisation, deren Information, Daten und IT Services sicher. Das Information Security Management ist normalerweise ein Teil des organisatorischen Ansatzes zum Security Management, das einen breiteren Scope gegenüber dem IT Service Provider hat und die Handhabung von Schriftstücken, Gebäudezugängen, Telefonanrufe usw. für die gesamte Organisation beinhaltet. 184

194 5.3 Prozess-Kennzahlen Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl und Auswirkungen Security Incidents Anzahl und Auswirkungen der festgestellten Security Incidents. Aufgabe des Security Managements ist die Analyse mögliche Bedrohungen und deren präventive Reduktion. Diese Kennzahl zeigt die Qualität der Prävention auf und ist Indikator für mögliche Verbesserungen. Auswertung der Incident Records mit der Kategorie Security und der Codierung Auswirkung (Impact). Voraussetzung ist, dass die Security Incidents entsprechend erkannt und dokumentiert werden. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anteil SLAs mit Sicherheits-Klauseln Anteil des SLAs, die Klauseln zu den Sicherheits-Anforderungen enthalten. Die notwendigen Sicherheitsmaßnahmen sind auf die Geschäftsanforderungen abzustimmen. Innerhalb werden die Anforderungen mit dem Kunden vereinbart und dokumentiert. Auswertung der SLAs. Werden Leistungen an Dritte vergeben, so sind die UCs entsprechend zu verfolgen. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl festgestellter Sicherheitsverletzungen Anzahl der festgestellten Nicht-Konformität der IT Service Management-Prozesse und Systeme mit den definierten Sicherheitsanforderungen (Security Policy und Prozess). Die Kennzahl zeigt die zunehmende Akzeptanz und Wahrnehmung von Sicherheitsbelangen. Auswertung durchgeführter Audits und Revisionen. Festgestellte Verletzungen von Compliance- Anforderungen sind besonders herauszustellen. 185

195 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl vergeblicher Login-Versuche Anzahl der festgestellten vergeblichen Login- Versuche. Eine hohe Anzahl vergeblicher Login-Versuche zeigt mögliche illegale Versuche der Informationsbeschaffung auf. Auswertung der Protokolldatei entsprechender Identifizierungssysteme. Hierzu sind auffällige User-IDs zur Prävention herzustellen. Name der Kennzahl Definition Relevanz Messwert Anzahl Verbesserungsvorschläge zur Security Anzahl der eingereichten Verbesserungsvorschläge und Verbesserungsmaßnahmen im Bereich des Security Managements. Die Kennzahl zeigt die zunehmende Akzeptanz und Wahrnehmung von Sicherheitsbelangen. Auswertung der Service und Prozess Improvement Pläne (SIP und PIP). Name der Kennzahl Definition Relevanz Messwert Aufwand für Security pro Jahr und pro Bereich. Höhe der Investition pro Security-Bereich und Jahr z. B. in Virenschutz, Firewalls etc. und damit z. B. in äußere und innere Sicherheit. Abstimmung, Umsetzung und Monitoring der Investitionen in die Security eines Unternehmens Investitionen pro Jahr aufgeteilt in interne und externe Security oder z. B. Virenschutz, Firewalls, Sniffer etc Supplier Management Der Prozess Supplier Management ist dafür verantwortlich, sicherzustellen, dass alle Verträge mit Lieferanten die Geschäftsanforderungen unterstützen und dass alle Lieferanten ihren vertraglichen Verpflichtungen nachkommen. 186

196 5.3 Prozess-Kennzahlen Name der Kennzahl Definition Relevanz Messwert Anteil eingehaltener UCs Anteil der Lieferanten, die die im Underpinning Contract (UC) vereinbarten Anforderungen erfüllen. Die Enthaltung der SLAs ist abhängig von der Einhaltung der UCs. Halten die Lieferanten die Vereinbarungen nicht ein, so hat dies einen unmittelbaren Einfluss auf die Unterstützung der Geschäftsprozesse. Wird dem Tool für das Monitoring der Service Level entnommen. Name der Kennzahl Definition Relevanz Messwert Anzahl Kundenbeschwerden zum Service Anzahl der Kundenbeschwerden, die auf Nichteinhaltung von UCs zurückzuführen sein. Die Nichteinhaltung von UCs führt in der Regel zu Service Level-Verletzungen und zu Kundenunzufriedenheit. Über ein Monitoring sind nicht sämtliche Aspekte zu messen. Auswertung von Reviews. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl der Streitfälle mit Lieferanten Anzahl der formellen Streitfälle mit den beauftragten Lieferanten. Formelle Streitfälle mit Lieferanten sind ein Indiz für nicht eindeutige Vereinbarungen innerhalb der UCs. Die Streitfälle sind vom Supplier Manager in einem System zu speichern. Bei Bedarf kann hier im Rahmen einer Drill- Down Funktion noch nach dem Anlass unterschieden werden, wie zum Beispiel bemängelte Rechnungen oder Verletzungen von Compliance-Anforderungen. Name der Kennzahl Definition Anzahl der Reviews mit Lieferanten Anzahl der mit Lieferanten zum Service und 187

197 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Relevanz Messwert UC durchgeführten Reviews. Reviews dienen der besseren Abstimmung mit dem Lieferanten und führen zu einer Steigerung der Service-Qualität. Die Anzahl der durchgeführten Reviews sind vom Supplier Manager in einem System zu speichern. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl von Lieferanten, die faktisch der IT- Steuerung unterliegen. Anzahl der Lieferanten, die einem Supplierund Vertrags-Manager zugeordnet sind. Die Supplier sind hinsichtlich der vereinbarten Leistungen und vertraglichen Aspekte durch verantwortliche Manager zu steuern. Die UCs sind zusammen mit den zugeordneten Managern im SLM-Tool gespeichert. Die zugeordnete Anzahl kann diesem System entnommen werden. Ergänzend kann zur Anzahl auch der Anteil der zugeordneten Lieferanten dargestellt werden. Name der Kennzahl Definition Relevanz Messwert Bemerkung Zufriedenheit mit dem Lieferanten Zufriedenheit in der Zusammenarbeit und Kommunikation mit dem Lieferanten. Eine gute Kommunikation und Zusammenarbeit zeigt sich auch außerhalb der festgelegten Service Level. Zufriedenheitsbefragung der innerhalb der IT mit dem Lieferanten zusammenarbeitenden Bereiche. Es kann auch der Lieferant zur Zufriedenheit befragt werden. 188

198 5.3 Prozess-Kennzahlen Service Transition Transition Planning and Support Der Prozess Transition Planning und Support ist verantwortlich für die Planung der gesamten Service Transition Prozesse und Koordination der erforderlichen Ressourcen. Diese Prozesse sind Change Management, Service Asset and Configuration Management, Release and Deployment Management, Service Validation and Testing, Evaluation und Knowledge Management. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anteil eingehaltener Release-Vereinbarungen Anteil der Releases, die die zuvor vereinbarten Kriterien hinsichtlich Kosten, Qualität, Umfang und Terminplanung einhalten. Für den Kunden ist nicht nur die Einhaltung der Qualität und die geplanten Termine für Releases von Relevanz, sondern auch, dass der implementierte Inhalt der Planung und Vereinbarung entspricht. Die Auswirkung der Einhaltung der Kostenplanung ist abhängig von der Leistungsverrechnung. Hierzu sind in den Release-Records die Planungsinformationen hinsichtlich Kosten, Termine und geplante Inhalte (Changes) zu speichern und mit dem Auslieferungsumfang, Termin und ermittelten Kosten zu vergleichen. Die Qualität wird über ggf. auftretende Incidents gemessen. In dieser Kennzahl werden mehrere Aspekte gemeinsam betrachtet. Dazu ist ggf. eine Gewichtung dieser Aspekte notwendig. Es ist auch möglich, aus den einzelnen Aspekten (Kosten, Termine, etc.) einzelne Kennzahlen zu definieren. Name der Kennzahl Definition Kundenzufriedenheit Service Transition Pläne Ergebnis der Kundenzufriedenheit bezüglich der Service Transition Pläne. 189

199 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Relevanz Messwert Bemerkung Abweichungen des geplanten Release haben Auswirkungen auf die Kunden- (und Anwender) -zufriedenheit. Abfrage in der Kundenzufriedenheitsumfrage Hier ist zusätzlich auch eine Abfrage der Anwender möglich. Name der Kennzahl Definition Relevanz Messwert Zufriedenheit Service Team Zufriedenheit in den Projekt- und Service- Teams mit den in der Phase Service Transition definierten Verfahren. Die korrekte Nutzung der beschrieben Verfahren hängt von der Praktikabilität und von Akzeptanz innerhalb der Service Teams und der beteiligten Projekt-Teams ab. Hierzu sind interne Feedbacks einzuholen und auszuwerten. 190

200 5.3 Prozess-Kennzahlen Change Management Der Prozess Change Management ist für das Controlling des gesamten Lifecycle aller Changes verantwortlich. Das primäre Ziel des Change Managements besteht darin, die Durchführung vorteilhafter Changes zu ermöglichen, mit minimalen Störungen der IT Services. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl Changes Die Kennzahl stellt die Anzahl der bearbeiteten Changes im Betrachtungszeitraum dar. Betrachtet werden alle RFCs, die vom Change Management bearbeitet wurden, das heißt auch zurückgewiesene RFCs. Die Kennzahl ist wichtig als Referenzwert. Darüber hinaus zeigt die Anzahl der Changes die Flexibilität der IT-Organisation, auf Kundenanforderungen schnell zu reagieren. Aus der Change-DB werden sämtliche RFCs im Betrachtungszeitraum ermittelt. Die Darstellung der Gesamtzahl allein ist wenig informativ. Daher ist eine Aufschlüsselung in IT Services, betroffene CIs (Infrastruktur, Applikation, etc.) notwendig. Eine weitere Aufschlüsselung besteht in der Darstellung der Prioritäten, wobei die Emergency Changes besonders herausgehoben werden sollten. Weiterhin sollte eine Aufgliederung darstellen, ob es sich um Kunden- oder IT-getriebene Changes handelt. Name der Kennzahl Definition Relevanz Anteil fehlerfreier Changes Darstellung des Verhältnisses fehlerfreier Changes das heißt Implementierung des Changes ohne anschließende Incidents im Betrieb in Bezug zur Anzahl der Changes Diese Kennzahl ist die wichtigste Kennzahl für die Effektivität des Change Managements. Ein hoher Anteil nicht fehlerfreier Changes ist ein 191

201 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Messwert Bemerkung Indiz für eine unzureichende Auswirkungsanalyse der RFCs. Fehlerhafte Changes führen zu Geschäftsausfällen, dadurch sinkt die Kundenzufriedenheit. Weiterhin führen fehlerhafte Changes innerhalb der IT zu Zusatzaufwendungen, das heißt die IT-Kosten steigen. Im Idealfall werden im Betrachtungszeitraum die implementierten Changes aus der Change- DB ermittelt und geprüft, ob hierfür Incident Records existieren (im Incident Record ist die Nummer des Changes als Grund für den Incident vermerkt). Für die Aussagekraft dieser Kennzahl sind die Datenqualität und das Know-how im Incident Management entscheidend. Wird ein fehlerhafter Change nicht als Grund der Störung erkannt und eingetragen, so hat dies erheblichen Einfluss auf die Qualität dieser Kennzahl. Hier wäre dann zu überlegen, ob alternativ die Probleme aufgrund von Changes auszuwerten sind, da im Problem Management von einer besseren Datenqualität auszugehen ist. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anteil termingerechter Changes Darstellung des Verhältnisses termingerechter Changes - das heißt Implementierung bis zum vereinbarten Termin - in Bezug zur Anzahl der Changes Diese Kennzahl ist eine Kennzahl für die Effektivität des Change Managements. Ein hoher Anteil nicht termingerechter Changes ist ein Indiz für eine unzureichende Planung. Werden die zugesagten Termine nicht eingehalten, sinkt die Kundenzufriedenheit und unter Umständen entstehen Auswirkungen auf das Business. In der Change-DB werden die Datenfelder der geplante Implementierung mit der tatsächlichen Implementierung verglichen. Bei Bedarf können weitere Aspekte hinsichtlich der Qualität der Terminplanung verfolgt wer- 192

202 den, wie zum Beispiel den Beginn der geplanten Tests, etc. 5.3 Prozess-Kennzahlen Name der Kennzahl Definition Relevanz Messwert Anteil kostengerechter Changes Darstellung des Verhältnisses kostengerechter Changes - das heißt Changes, die die vereinbarten Kosten nicht überschreiten - in Bezug zur Anzahl der Changes Die Relevanz dieser Kennzahl ist abhängig von der Leistungsverrechnung. Werden die Kosten für Changes vom Kunden getragen, so haben Mehrkosten Auswirkungen auf die Kundenzufriedenheit. Muss die IT für die Kosten aufkommen, so führen Changes mit höheren Durchführungskosten zu einer nicht eingeplanten Kostensteigerung innerhalb der IT. Die Kennzahl zeigt die Qualität der Planung und Analyse von Changes hinsichtlich der Aufwendungen auf. Zum Change sind die damit verbundenen Aufwendungen (Personal, Material) zu erfassen. Aus der Change-DB werden diese Aufwendungen ermittelt und den geplanten Kosten gegenübergestellt. Name der Kennzahl Definition Relevanz Messwert Anteil erfolgreicher Back-Out-Planungen Die Kennzahl stellt die Anzahl der erfolgreichen Back-Out-Maßnahmen im Verhältnis zu den durchgeführten Back-Out-Maßnahmen dar. Nicht alle Changes können störungsfrei implementiert werden. Dann ist es wichtig, dass die Möglichkeit besteht, in den gesicherten Ausgangszustand zurückzukehren. Hierzu ist im Change Management eine Back-Out-Planung notwendig. Diese Kennzahl misst die Qualität dieser Planung. Aus der Change-DB werden die Changes ermittelt, die zurückgenommen werden mussten und die Changes, deren Back-Out-Plan erfolgreich 193

203 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Bemerkung war. Existieren hierfür keine Datenfelder, so können zur Generierung auch die Ergebnisse aus dem Review herangezogen werden. Name der Kennzahl Definition Relevanz Messwert Anzahl offener RFCs Die Kennzahl zeigt an, wie viele RFCs noch nicht bearbeitet wurden. Eine hohe Anzahl offener RFCs zeigt einen Bearbeitungsstau im Prozess an. Als Folge wird die Akzeptanz für das Change Management sinken, unter Umständen das Change Management umgangen und sinnvolle RFCs nicht mehr eingereicht. Ermittelt werden aus der Change-DB die Anzahl der RFCs für die Aktivität Asses and evaluate the Change noch nicht durchgeführt wurde. Name der Kennzahl Definition Relevanz Messwert Anzahl nicht genehmigter Changes Diese Kennzahl identifiziert die festgestellten Changes, die unter Umgehung des Change Managements durchgeführt wurden. Die Anzahl deutet auf einen nicht wirksamen Change Management-Prozess hin. Häufig ist er zu administrativ, sodass der Prozess umgangen wird. Insbesondere für Unternehmen, die Compliance-Anforderungen wie SOX erfüllen müssen, ist diese Kennzahl von besonderer Bedeutung. Es werden die Ergebnisse des Verification and Audit im Prozess Service Asset und Configuration Management ausgewertet. Name der Kennzahl Definition Anteil zurückgewiesener RFCs Die Kennzahl zeigt an, wie viele der eingereichten RFCs vom Change Management zurückgewiesen wurden. 194

204 5.3 Prozess-Kennzahlen Relevanz Messwert RFCs können zurückgewiesen werden, wenn sie zum Beispiel unvollständig sind. Ein hoher Anteil zurückgewiesener RFCs führt zu einem ineffizienten Prozess. Ermittelt werden aus der Change-DB, die Anzahl der RFCs, die den Status zurückgewiesen aufweisen Service Asset and Configuration Management Dieser Prozess gliedert sich in die Sub-Prozesse Asset Management und Configuration Management. Das Asset Management ist für die Verfolgung und das Reporting der Werte und Ownership sämtlicher finanzieller Assets während des gesamten Lebenszyklus verantwortlich. Das Configuration Management ist für die Pflege der Information über Configuration Items (CIs) und deren Beziehungen verantwortlich, die für die Bereitstellung der IT Services benötigt werden. Diese Informationen sind über den gesamten Lebenszyklus der CIs zu verwalten. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl der CIs Anzahl der Service Assets und der Configuration Items (CIs). Die Anzahl der CIs dient für weitere Betrachtungen als Referenzwert. Ermittlung der CIs aus dem Configuration Management System (CMS) Hierfür sollte eine Drill-Down Funktion existieren, um die CIs aufgliedern zu können (zum Beispiel CIs, die zu einem IT Service gehören, Applikationen, etc.) Name der Kennzahl Definition Relevanz Anzahl abweichender CIs Anzahl der festgestellten Abweichungen an CIs zwischen dem CMS und dem tatsächlichen Bestand. Die Informationen des CMS dienen unterschiedlichen Prozessen und Aktivitäten als Planungsgrundlage. Fehlerhafte Informationen haben eine negative Auswirkung auf die Qualität des 195

205 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Messwert Bemerkung IT Service. In Verbindung mit Compliance-Anforderungen, wie zum Beispiel SOX oder Versicherungsbestimmungen, können geschäftliche Schäden bzw. Kosten entstehen. CI-Abweichungen zwischen Soll- und Ist-Bestand sind im CMS beim betroffenen CI zu dokumentieren. Ausgewertet werden die Ergebnisse dieser Audits. Eine Gruppierung der CIs nach IT Services oder relevante Compliance-Anforderungen ist zweckmäßig. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anteil nicht genutzter Lizenzen Anteil der erworbenen und nicht genutzten Software-Lizenzen. Nicht genutzte Software-Lizenzen führen zu unnötigen Kosten für die IT und die IT Services. Abgleich zwischen den erworbenen und in Nutzung befindlichen Software-Lizenzen. Hierzu müssen die CIs mit einem entsprechenden Status in Nutzung und Codierung für Software ausgewiesen werden. Diese Kennzahl kann auch genutzt werden, um eine Unterlizenzierung darzustellen. Name der Kennzahl Definition Relevanz Messwert Bemerkung Zunahme an und Wert der CIs Zunahme der CIs und finanzieller Wert der CIs. Zeigt das Wachstum innerhalb der IT auf. Auswertung des Configuration Management Systems. Hierfür sollte eine Drill-Down Funktion existieren, um die CIs aufgliedern zu können (IT- Zuordnung zum Service oder CI-Typen, wie Applikationen etc.). 196

206 5.3 Prozess-Kennzahlen Name der Kennzahl Definition Relevanz Messwert Bemerkung Auswirkungen fehlerhafter CIs Anzahl der fehlerhaften Changes, deren Ursachen auf fehlerhafte CIs und CI-Informationen zurückzuführen sind. Das CMS liefert eine wichtige Informationsbasis für die Analyse der Auswirkungen von Changes. Fehlerhafte Informationen können zu Ausfällen von IT Services und für das Business führen, wenn hierdurch Changes fehlerhaft sind. Zur Generierung dieser Kennzahl sind die Ergebnisse der Reviews im Change Management auszuwerten. In der Literatur wird als Kennzahl auch Incidents oder Probleme aufgrund fehlerhafter CIs beschrieben. Hier ist kritisch zu prüfen, ob eine eindeutige und verlässliche Unterscheidung im operativen Betrieb möglich ist. Name der Kennzahl Definition Relevanz Messwert Zeitspanne Korrektur fehlerhafter CIs Zeitspanne zwischen der Feststellung eines fehlerhaften CIs und dessen Korrektur. Diese Zeitspanne ist ein Indiz für die Effizienz des Configuration Managements. Hierzu sind die Audits zum jeweiligen CI auszuwerten. Mittels Codierung sind festgestellte Abweichungen und deren Korrektur zu dokumentieren Release and Deployment Management Der Prozess ist verantwortlich für das Release und Deployment Management. Dabei ist das Release Management für die Planung, Terminplanung und Steuerung der Überführung von Releases in die Test- und Live-Umgebung verantwortlich Das primäre Ziel des Release Managements besteht im Schutz der Live-Umgebung und der Herausgabe der richtigen Komponenten. Das Deployment Management ist verantwortlich für die Überführung von neuer oder geänderter Hardware, Software, Dokumentation, Prozesse usw. in die Live-Umgebung. 197

207 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl durchgeführter Releases Anzahl der durchgeführten Releases pro IT Service. Die Anzahl der CIs dient für weitere Betrachtungen als Referenzwert. Ermittlung der durchgeführten Releases aus der Release-DB. Hierfür sollte eine Drill-Down Funktion existieren, um die Releases aufgliedern zu können (zum Beispiel in Major Release, Minor Release und Emergency fix Release). Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl Incidents aufgrund von Releases Anzahl der Incidents, die aufgrund durchgeführter Releases auftreten. Treten nach einem Release Incidents auf, so führt dies zu Geschäftsbeeinträchtigungen und einer Kundenunzufriedenheit. Außerdem treten mit der notwendigen Behebung Zusatzkosten für die IT-Organisation auf. Auswertung der Incidents im Betrachtungszeitraum, die auf einen Release referenzieren. Hier sollte eine Drill-Down Funktion auf betroffene IT Services bestehen. Kann das Incident Management die notwendigen Informationen und Datenqualität nicht sicherstellen, so sind statt der Incidents die Problems auszuwerten. Name der Kennzahl Definition Relevanz Messwert Kundenzufriedenheit durchgeführter Releases Kundenzufriedenheit mit der Durchführung von Releases. Die Kennzahl ist ein Maß für die subjektive Einschätzung des Kunden. Abfrage in der Kundenzufriedenheitsumfrage 198

208 5.3 Prozess-Kennzahlen Name der Kennzahl Definition Relevanz Messwert Bemerkung Fehlerhafte CMS Anzahl der durch das Release Management verursachten Abweichungen zwischen dem CMS und dem Ist-Bestand. Mittels Releases durchgeführte Veränderungen sind im CMS zu dokumentieren. Diese Kennzahl dient der Messung, ob die notwendigen Daten dem Configuration Management zur Verfügung gestellt werden. Auswertung der CIs hinsichtlich festgestellter Abweichung und der Ursache Release Management Hierzu sind nicht nur festgestellte Abweichungen im Audit zum CI zu dokumentieren, sondern auch der Verursacher. Name der Kennzahl Definition Relevanz Messwert Vollständigkeit DML Anzahl der fehlenden Medien im Bestand der Definitive Media Library (DML). Sobald eine neue Software produktiv gesetzt wird, sind die Medien in die DML aufzunehmen und das CMS zu aktualisieren. Ermittlung auf Basis durchgeführter Verifikationen und Audits Evaluation Der Prozess ist verantwortlich für die Beurteilung neuer oder geänderter IT Services, um sicherzustellen, dass die Risiken gemanagt werden und hilft so bei der Festlegung, ob der Change fortgesetzt wird. Der Prozess wird ebenfalls genutzt, um zu beurteilen, ob die tatsächlichen Ergebnisse den angestrebten Ergebnissen entsprechen oder zum Vergleich einer Alternative mit einer anderen. Name der Kennzahl Definition Anzahl Abweichungen in der Service Performance Anzahl der festgestellten Abweichungen zwischen der bereitgestellten und der benötigten Service Performance. 199

209 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Relevanz Messwert Zur Unterstützung der Geschäftsprozesse muss der Service die benötigte Performance sicherstellen. Eine unzureichende Performance kann zu Geschäftsausfällen führen. Auswertung der Testergebnisse. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl Incidents zum Service Anzahl der zum Service gemeldeten Incidents Eine höhere Anzahl führt zur Einschränkung des Geschäftsbetriebs und Kundenunzufriedenheit. Auswertung der Incident Records, die zu einem Service erfasst sind. Zusätzlich sind die Termine für durchgeführte Deployments darzustellen. Hierzu muss eine Zuordnung des Incident Records zum Service möglich sein. Eine Drill-Down Funktion sollte die dazugehörigen Kategorien der Incidents aufzeigen. Name der Kennzahl Definition Relevanz Messwert Durchlaufzeit Auswertung Durchlaufzeit, um die Auswertung der Tests durchzuführen. Eine geringe Durchlaufzeit bzw. deren Reduzierung ist ein Zeichen für die verbesserte Effizienz. Auswertung der im Textbericht protokollierten Zeiten Knowledge Management Der Prozess ist dafür verantwortlich das Wissen und die Informationen innerhalb einer Organisation zu sammeln, zu analysieren, zu speichern und gemeinsam zu nutzen. Der Hauptzweck des Knowledge Managements ist es, durch das Reduzieren der Notwendigkeit das Wissen wieder zu entdecken, die Effizienz zu verbessern. 200

210 5.3 Prozess-Kennzahlen Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl Incident fehlendes Anwender-Wissen Anzahl der Incidents mit der Kategorisierung fehlendes Anwender-Wissen. Das fehlende Anwender-Wissen führt nicht nur zu Geschäftsausfällen, sondern auch zu Zusatzressourcen und Kosten innerhalb der IT- Organisation. Auswertung der Incident Records mit der Kategorie fehlendes Anwender-Wissen. Hierzu können auch die damit verbunden Bearbeitungszeiten und resultierenden Kosten dargestellt werden. Name der Kennzahl Definition Relevanz Messwert Durchschnittliche Diagnosezeit Durchschnittliche Diagnose- und Behebungszeit für die Lösung von Fehlern. Eine schnelle Diagnose- und Behebungszeit ist ein Indiz für ein gutes Service Knowledge Management System (SKMS). Auswertung der Diagnosezeiten der Incident Records. Name der Kennzahl Definition Relevanz Messwert Bemerkung Zugriffe SKMS Anzahl der Zugriffe auf das SKMS. Die Nutzung des SKMS führt in der Regel nicht nur zu schnelleren Lösungen, sondern sichert auch ein konsistentes Vorgehen. Auswertung der Zugriffe aus dem SKMS. In Verbindung mit der Anzahl der Incidents kann festgestellt werden, in wie vielen Fällen (Anteil in Prozent) nach einer Lösung im SKMS gesucht wurde. Name der Kennzahl Definition Nutzungsgrad SKMS Nutzungsgrad des SKMS zur Behebung von Incidents. 201

211 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Relevanz Messwert Bemerkung Die Nutzung des SKMS führt in der Regel nicht nur zu schnelleren Lösungen, sondern sichert auch ein konsistentes Vorgehen. Auswertung der Incident Records, die mit Known Errors oder Workarounds verknüpft sind. In Verbindung mit den Zugriffen auf das SKMS kann festgestellt werden, in wie vielen Fällen eine Lösung in dem SKMS gefunden werden konnte. Name der Kennzahl Definition Relevanz Messwert Anwenderzufriedenheit SKMS Anwenderzufriedenheit mit den zur Verfügung gestellten Informationen, wie zum Beispiel Newsletter, Einweisungen, Web-Informationen, etc. Gute Informationen des Anwenders führen zu einer besseren Nutzung des Service und reduzieren Support-Kosten. Erhebung und Auswertung im Rahmen einer Anwenderzufriedenheitsbefragung Service Operation Event Management Der Prozess ist verantwortlich für das Management von Events während des gesamten Lifecycle. Das Event Management ist eine der Hauptaktivitäten von IT Operation. Bisher wurden in ITIL und der ISO 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 Definition Relevanz Anzahl der Events Anzahl der Events im Betrachtungszeitraum. Die Anzahl der Events dient für weitere Betrachtungen als Referenzwert. Sie kann zusam- 202

212 5.3 Prozess-Kennzahlen Messwert Bemerkung men mit einer Trend-Darstellung auch als Indiz für die Qualität des Events Managements genutzt werden. Ermittlung der Records aus der Event-DB. Hierfür sollte eine Drill-Down Funktion existieren, um die betroffenen Cis (Applikationen, Plattformen, etc.) darstellen zu können. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anteil der Events Prozentualer Anteil und Anzahl der Events pro Art (Incident, Problem, Change) im Betrachtungszeitraum. Die Anzahl der Events dient für weitere Betrachtungen als Referenzwert. Sie kann zusammen mit einer Trend-Darstellung auch als Indiz für die Qualität des Events Managements genutzt werden. Eine steigende Anzahl zeigt, dass die Ereignisse besser erkannt werden, bevor sie sich zum Beispiel als Störung beim Anwender äußern. Ermittlung der Records aus der Event-DB. Hierfür sollte ein Drill-Down möglich sein um die betroffenen Cis (Applikationen, Plattformen, etc.) darstellen zu können. Name der Kennzahl Definition Relevanz Messwert Events zu Incidents (Problems) Prozentualer Anteil der per Events erkannten Incidents (Problems) zu den von Anwendern gemeldeten Incidents (Problems). Ein hoher Anteil der Events zeigt, dass die Ereignisse vom System erkannt werden, bevor sie sich zum Beispiel als Störung beim Anwender äußern. Dies führt zu einer höheren Verfügbarkeit und größeren Kundenzufriedenheit. Ermittlung der Records aus der Event-DB und Incident-DB bzw. Problem-DB. 203

213 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl Definition Relevanz Messwert Events pro Signifikanz Anzahl und Anteil der Events pro Signifikanz. Zielsetzung für das Event Management ist die Erkennung von signifikanten Incidents oder Problemen. Diese Kennzahl zeigt an, ob dieses Ziel erreicht wird. Ermittlung der Records aus der Event-DB und Incident-DB bzw. Problem-DB. Name der Kennzahl Definition Relevanz Messwert Events mit Verfügbarkeits-Belangen Anzahl und Anteil der Events mit möglichen Belangen für die Verfügbarkeit. Die Verfügbarkeit ist einer der wichtigsten Service Level. Eine Nicht-Verfügbarkeit wirkt sich unmittelbar auf die Geschäftsprozesse aus. Diese Kennzahl zeigt an, wie gut diese Incidents / Probleme erkannt werden. Ermittlung der Records aus der Event-DB und Incident-DB bzw. Problem-DB Incident Management Der Prozess ist verantwortlich für das Management der Incidents während des Lifecycle. Das primäre Ziel ist es, den IT Service für den Anwender so schnell wie möglich wieder herzustellen. Mit der Herausgabe von ITIL Version 3 werden Service Requests in einem gesonderten Prozess behandelt. Daher ist hier keine Filterung der erfassten Vorgänge notwendig. Innerhalb von ITIL Version 2 und der ISO werden im Incident Management Störungen und Service Requests behandelt. Für Auswertungszwecke ist hier eine Eingrenzung der erfassten Vorgänge auf Störungen notwendig. Name der Kennzahl Definition Relevanz Anzahl der Incidents Anzahl der Incidents im Betrachtungszeitraum. Die Anzahl der Incidents dient für weitere Betrachtungen als Referenzwert. Sie kann zusammen mit einer Trend-Darstellung auch als Indiz für die Qualität des Problem Managements genutzt werden. Eine steigende Anzahl wirkt 204

214 5.3 Prozess-Kennzahlen Messwert Bemerkung sich darüber hinaus auf die Kundenzufriedenheit aus. Bei einer steigenden Anzahl führt deren Behebung zu steigenden Prozess- und IT- Kosten. Ermittlung der Incident Records aus der Incident-DB. Die Gesamtanzahl ist allein wenig aussagekräftig. Die Anzahl der Incidents ist aufzugliedern in die betroffenen IT Services und pro Priorität darzustellen. Hier ist eine Drill-Down Funktion zur weiteren Analyse unbedingt notwendig. Name der Kennzahl Definition Relevanz Messwert Anzahl und Anteil der Major Incidents Anzahl und Anteil der Major Incidents im Betrachtungszeitraum. Major Incident führen i. d. R. zu größeren Ausfällen des IT Service und so der relevanten Geschäftsprozesse. Ermittlung der Incident Records anhand der Codierung aus der Incident-DB. Name der Kennzahl Definition Relevanz Messwert Erstlösungsquote Die Erstlösungsquote definiert, wie viel Prozent der eingehenden Incidents im Erstkontakt zwischen den Anwendern und dem Service Desk gelöst werden konnten. Eine gute Erstlösungsquote steigert die Anwenderzufriedenheit und reduziert die Ausfallzeit für das Business. Zusätzlich trägt eine gute Erstlösungsquote dazu bei, dass der 2nd Level Support entlastet wird. In der Regel führt dies auch zu einer Reduzierung der Kosten für die Behebung von Incidents. Ausgewertet werden alle Incidents, die mittels Telefon beim Service Desk eingegangen sind. Als Erstlösungsquote wird der Prozentwert dieser Incidents dargestellt, bei denen die Mitar- 205

215 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Bemerkung beiter im Service Desk den Incident direkt lösen konnten und der Incident nicht weitergeleitet wurde. Die Erstlösungsquote kann auch als Service Level in SLAs vereinbart werden. Dann ist die Erstlösungsquote in Bezug auf den jeweiligen IT Service darzustellen. Diese Kennzahl kann auch für die Bewertung des Service Desk herangezogen werden. Name der Kennzahl Definition Relevanz Messwert Bemerkung Durchschnittliche Reaktionszeit Die Reaktionszeit bestimmt die Dauer zwischen der Weiterleitung vom Service Desk und der Aufnahme der Tätigkeit in der zugewiesenen Support-Einheit. Hohe Reaktionszeiten können auf eine zu hohe Arbeitslast für die betroffene Support-Einheit hinweisen. Aus den Incident Records wird die Zeitdauer zwischen der Weiterleitung vom Service Desk und der Beginn der Bearbeitung in der zugewiesenen Support-Einheit ermittelt. Hier ist zu definieren, was unter Reaktion bzw. Reaktionszeit zu verstehen ist. Man könnte den Begriff Reaktion z. B. als Kontaktaufnahme mit dem Anwender definieren. Name der Kennzahl Definition Relevanz Einhaltung Reaktionszeit Anteil der Incidents, die in Abhängigkeit der Priorität innerhalb der vereinbarten Reaktionszeit bearbeitet wurden. Die Bedeutung ist abhängig von den vereinbarten Service Level. Ist die Reaktionszeit als Service Level vereinbart, so ist deren Einhaltung wichtig für die Kundenzufriedenheit. Innerhalb der IT ist die Reaktionszeit ein wichtiges Maß für die Bearbeitung von weitergeleiteten Störungen. Hohe Reaktionszeiten können auf eine zu hohe Arbeitslast für die betroffene 206

216 5.3 Prozess-Kennzahlen Messwert Bemerkung Support-Einheit hinweisen. Mit der Festlegung der Priorität zu einem Incident wird die vereinbarte Reaktionszeit ermittelt. Die Kennzahl wird durch Auswertung der Incident Records und dem Vergleich zwischen der geplanten Reaktionszeit und der tatsächlichen Reaktionszeit ermittelt. 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 Definition Relevanz Messwert Bemerkung Lösungszeit Die Lösungszeit ist die Dauer zwischen der Aufnahme des Incidents und dessen Abschluss. Die durchschnittlichen Lösungszeiten in Abhängigkeit von IT Service und Priorität (SLA) müssen den vereinbarten Service Level entsprechen. Mit der Zuweisung der Priorität liegt für den Incident Record die vereinbarte Lösungszeit vor. Anhand der dokumentierten Lösungszeit wird die tatsächliche Lösungszeit ermittelt. Siehe auch Einhaltung Lösungszeit. Name der Kennzahl Definition Relevanz Messwert Bemerkung Einhaltung Lösungszeit Anteil der Incidents, die in Abhängigkeit der Priorität innerhalb der vereinbarten Lösungszeit behoben wurden. Die Einhaltung der Lösungszeiten ist eine wichtige Kennzahl für die Effektivität des Prozesses. Durch deren Einhaltung wird die Anwenderund Kundenzufriedenheit beeinflusst. Mit der Zuweisung der Priorität liegt für den Incident Record die vereinbarte Lösungszeit vor. Anhand der dokumentierten Lösungszeit wird ermittelt, in welchem Maß (Prozent) diese Zeit eingehalten wurde. Die Lösungszeit kann auch als Service Level in 207

217 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen SLAs, OLAs oder UCs vereinbart werden. Dann ist die Lösungszeit in Bezug auf den jeweiligen IT Service zu berechnen. Entscheidend für die Lösung ist, dass der Anwender wieder arbeiten kann. Es ist mit dem Kunden festzulegen, wann ein Incident als abgeschlossen gewertet werden kann. Name der Kennzahl Definition Relevanz Messwert Anteil Remote-Lösungen Anteil der bearbeiteten Störungen, die Remote - das heißt ohne Vor-Ort-Service - gelöst werden konnten. Der Vor-Ort-Service ist gegenüber einer Remote Lösung mit mehr Aufwand (Arbeitszeit und Kosten) verbunden. Hinzu kommt, dass die Lösungszeiten dadurch höher sind. Diese Kennzahl ist ein Indikator für die Effizienz des Prozesses. Ausgewertet wird der Anteil der Incidents, bei denen keine Vor-Ort Support-Einheit in die Behebung eingebunden waren. Name der Kennzahl Definition Relevanz Messwert Bemerkung Kosten Incidents Die Kennzahl weist die Kosten für die Aufnahme und Behebung von Incidents aus. Eine Reduzierung der Kosten ist ein Nachweis für eine Steigerung der Effizienz. Die durchgeführten Aktivitäten sind hinsichtlich ihrer Aufwendungen (Material, Arbeitszeit, etc.) zu dokumentieren. Ausgewertet werden die damit verbunden Kosten. Die Aufwendungen sind häufig abhängig von den betroffenen IT Services, CIs und Kategorie. Eine Drill-Down-Funktion ist hierfür notwendig. Name der Kennzahl Definition Anteil fehlerhaft zugewiesener Incidents Die Kennzahl weist die Kosten für die Auf- 208

218 5.3 Prozess-Kennzahlen Relevanz Messwert Bemerkung nahme und Behebung von Incidents aus. Werden Incidents einer fehlerhaften Support- Gruppe zugewiesen, so entstehen zusätzliche Bearbeitungskosten (Effizienz) und die Bearbeitungszeit verlängert sich (Effektivität). Hierzu muss im Incident Record bei einer Weiterleitung deren Grund eingepflegt werden. Diese Kennzahl kann auch als Kennzahl für den Service Desk herangezogen werden. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anteil fehlerhafter Incident Kategorien Die Kennzahl weist den Anteil der bei der Aufnahme eines Incidents fehlerhaft zugewiesener Kategorien aus. Die Kategorisierung unterstützt die Suche von Known Errors, Workarounds sowie die Weiterleitung von Incidents. Fehlerhafte Kategorien wirken sich negativ auf die Effizienz und Effektivität aus. Hierzu wird im Incident Record geprüft, ob beim Abschluss gegenüber der Eröffnung eine andere Kategorie zugewiesen wurde. Diese Kennzahl kann auch als Kennzahl für den Service Desk herangezogen werden. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anteil wiedereröffneter Incidents Die Kennzahl weißt den Anteil der Incidents aus, bei denen die aufgetretene Störung wieder auftritt. Die Kennzahl zeigt an, ob Incidents fehlerhaft als gelöst abgeschlossen wurden. Hierzu muss im Incident Record eine Reopen Aktivität dokumentiert werden. Die Anzahl der Incidents mit dieser Aktivität wird ausgewertet. Häufig werden Incidents nicht wiedereröffnet, sondern als neue Incidents aufgenommen. 209

219 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Request Fulfilment Der Prozess ist für das Management des Lifecycle sämtlicher Service Requests verantwortlich. Bisher wurden in ITIL und der ISO die Service Requests im Incident Management aufgenommen. Daher werden die Service Requests bei vielen IT-Organisationen in der Incident-DB gespeichert. Statt der im Folgenden beschriebenen Request-DB sind in diesen Fällen die Service Requests aus der Incident-DB anhand einer Codierung zu ermitteln. Name der Kennzahl Definition Relevanz Messwert Anzahl Service Requests Anzahl der Service Requests im Betrachtungszeitraum. Die Anzahl der Service Requests dient für weitere Betrachtungen als Referenzwert. Ermittlung der Service Requests Records aus der Request-DB. Name der Kennzahl Definition Relevanz Messwert Bearbeitungszeit Service Requests Darstellung der mittleren Bearbeitungszeit "Service Requests" und Art der "Service Requests" (z. B. Passwort-Reset, Umzug etc.). Die Kennzahl zeigt die Zeitdauer für den Workflow und ist Basis für die Berechnung möglicher Service Level. Ermittlung der Service Requests Records aus der Request-DB. Name der Kennzahl Definition Relevanz Einhaltung der Service Request-Zeiten Anteil der Service Requests, die in Abhängigkeit von der Art innerhalb der vereinbarten Bearbeitungszeit abgeschlossen wurden. Die Einhaltung der vereinbarten Service Request-Zeiten ist eine wichtige Kennzahl für die Effektivität des Prozesses. Durch deren Einhaltung wird die Anwender- und Kundenzufriedenheit beeinflusst. 210

220 5.3 Prozess-Kennzahlen Messwert Bemerkung Dem Service Request muss ein Workflow mit einer geplanten Bearbeitungszeit hinterlegt sein. Auf dieser Basis kann die Einhaltung überwacht werden. Diese Kennzahl kann als Service Level in Service-Berichte einfließen. Bei einem Aufbruch in die einzelnen Aktivitäten und der Planwerte können die Werte auch für die Bewertung von OLAs und UCs herangezogen werden. Name der Kennzahl Definition Relevanz Messwert Service Request-Kosten Kosten für die Durchführung für die verschiedenen Arten von Service Requests (zum Beispiel Passwort-Reset, Umzug, etc.). Die Kosten werden für die Kalkulation des Service benötigt. Darüber hinaus zeigt die Kennzahl als Trenddarstellung die Effizienz auf. Zur Ermittlung müssen zu den einzelnen Aktivitäten die benötigten Arbeitsstunden erfasst werden. Name der Kennzahl Definition Relevanz Messwert Bemerkung Kundenzufriedenheit Service Request Grad der Kundenzufriedenheit mit der Durchführung von Service Requests. Die Kennzahl zeigt die Ausrichtung des Prozesses auf die Geschäftsanforderungen auf. Abfrage in der Kundenzufriedenheitsumfrage Hier ist zusätzlich auch eine Befragung der Anwender möglich. 211

221 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Problem Management Der Prozess ist für das Management des Lifecycle sämtlicher Probleme verantwortlich. Das primäre Ziel des Problem Managements besteht in der Verhinderung von Incidents und der Reduzierung der Auswirkung von Incidents, die nicht verhindert werden können. Die Relevanz von Problemen hinsichtlich der SLAs ist kritisch zu prüfen und zu hinterfragen. Wenn der Kunden nicht die Terminologie von ITIL nutzt, so ist häufig mit Problemen eigentlich Incidents mit deren Service Level gemeint. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl der Probleme Anzahl der Probleme im Betrachtungszeitraum. Die Anzahl der Probleme dient für weitere Betrachtungen als Referenzwert. Ermittlung der Problem-Records aus der Problem-DB. Die Gesamtanzahl ist wenig aussagekräftig. Hier sollte eine Drill-Down Funktion auf betroffene IT Services, CIs, etc. möglich sein. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl offener Probleme Anzahl der Probleme, die noch nicht gelöst wurden. Die Kennzahl zeigt, wie viele Probleme zurzeit vom Problem Management zu bearbeiten sind bzw. die mittels eines Change zu implementieren sind. Auswertung der Probleme, die noch nicht abgeschlossen sind Die Gesamtzahl ist wenig aussagekräftig. Hier sollte die Gesamtzahl aufgebrochen werden in Problemursache unbekannt, Known Error, RFC gestellt 212

222 5.3 Prozess-Kennzahlen Name der Kennzahl Definition Relevanz Messwert Bemerkung Durchschnittliche Problem-Lösungszeit Durchschnittliche Zeitdauer für die Lösung von Problemen im Betrachtungszeitraum. Eine lange Lösungsdauer kann dazu führen, dass innerhalb dieser Zeit weiterhin Incidents auftreten und so zu Aufwendungen (Kosten) im Support führen. Außerdem wird die Kundenzufriedenheit beeinträchtigt, wenn Incidents weiterhin auftreten oder nur unzureichende Workarounds existieren. Ermittlung der durchschnittlichen Zeitdauer zwischen der Eröffnung eines Problems und dessen Abschluss, das heißt, bis ein Change erfolgreich durchgeführt wurde. Zeitdauer über alle Services, CIs ist wenig aussagekräftig. Hier sollte ein Drill-Down auf betroffene IT Services, CIs, etc. möglich sein. Name der Kennzahl Definition Relevanz Messwert RFCs aufgrund von Problemen Anzahl der vom Problem Management initiierten RFCs. Eine hohe Anzahl vom Problem Management eingereichter RFCs kann ein Indiz für die Effektivität des Problem Managements sein. Auswertung der RFCs im Betrachtungszeitraum mit einer Verknüpfung zu Problemen. Name der Kennzahl Definition Relevanz Messwert Nutzungsgrad Known Errors Anteil der Incidents, die mithilfe der Known Errors gelöst wurden. 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. Auswertung der Incidents hinsichtlich einer Verknüpfung mit Known Errors. 213

223 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Access Management Der Prozess ist dafür verantwortlich, es den Anwendern zu ermöglichen, IT Services, Daten oder andere Assets zu benutzen. Das Access Management hilft, die Vertraulichkeit, Integrität und Verfügbarkeit von Assets dadurch zu schützen, dass nur autorisierte Anwender in der Lage sind, auf die Assets zuzugreifen oder diese zu modifizieren. Das Access Management wird teilweise als Rechteverwaltung oder Identity Management bezeichnet. Bisher wurden in ITIL und der ISO die Service Requests im Incident Management aufgenommen. Daher werden die Service Requests bei vielen IT-Organisationen innerhalb der Incident-DB gespeichert. Statt der im Folgenden beschriebenen Access-DB sind in diesen Fällen die Service Requests mit dem Typ Zugriffsrechte aus der Incident-DB anhand einer Codierung zu ermitteln. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl der Zugriffs-Anforderungen Anzahl der Anforderungen auf Zugriffsberechtigungen im Betrachtungszeitraum. Die Anzahl der Anforderungen dient für weitere Betrachtungen als Referenzwert. Ermittlung der Access-Records aus der Access- DB. Die Gesamtanzahl ist wenig aussagekräftig. Hier sollte eine Drill-Down Funktion auf betroffene IT Services, Abteilungen, etc. möglich sein. Name der Kennzahl Definition Relevanz Messwert Incidents aufgrund fehlerhafter Zugriffsrechte Anzahl der Incidents aufgrund fehlerhaft vergebener Zugriffsrechte. Die Anzahl der auftretenden Incidents ist ein Maß für die Effektivität des Prozesses. Ermittlung der Incident-Records mit Kategorie Zugriffsrechte Name der Kennzahl Definition Anzahl Bearbeitungsinstanzen Anzahl Bearbeitungsinstanzen für die Generierung der Zugriffsrechte. 214

224 5.3 Prozess-Kennzahlen Relevanz Messwert Die Anzahl der Bearbeitungsinstanzen ist ein Maß für die Effizienz des Prozesses. Ermittlung der Access-Records aus der Access- DB und der beteiligten Bearbeiter von der Aufnahme bis zum Abschluss. Name der Kennzahl Definition Relevanz Messwert Bemerkung Kosten für Zugriffsberechtigungen Kosten für die Generierungen der Zugriffsberechtigungen. Die Kosten für die Generierungen der Zugriffsberechtigungen sind ein Maß für die Effizienz des Prozesses und sind unter anderem bei der Kalkulation der SLAs zu berücksichtigen. Ermittlung der Arbeitsstunden pro Access-Records aus der Access-DB. Die Gesamtkosten sind wenig aussagekräftig. Hier ist eine Unterscheidung zwischen den IT Services notwendig Service Desk Der Service Desk dient als Single Point of Contact (SPOC) zwischen dem IT Service Provider und den Anwendern. Ein typischer Service Desk verwaltet die Incident und Service Requests und wickelt auch die Kommunikation mit den Anwendern ab. Der Service Desk beschreibt die funktionalen Anforderungen an eine Organisation und ist kein Service Management-Prozess. Der Service Desk ist in verschiedene Prozesse eingebunden, mit dem Schwerpunkt in den Prozessen Incident Management und Request Fulfilment. In diesem Kapitel werden die Kennzahlen ausgewiesen, die nicht zu den bereits ausgewiesenen Prozess-Kennzahlen, wie zum Beispiel der Erstlösungsquote, gehören. Name der Kennzahl Definition Relevanz Anzahl Lost-Calls Anzahl der Lost-Calls (verlorene Anrufe) im Betrachtungszeitraum. Die Lost-Calls definieren die Anrufer, die aufgrund eines zu langen Wartezeitraums den Anruf beenden, ohne mit einem Mitarbeiter des Service Desk gesprochen zu haben. Diese Kenn- 215

225 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Messwert Bemerkung zahl ist ein wichtiges Maß für die Anwenderund Kundenzufriedenheit. Die Lost-Calls sind der Telefonanlage (ACD) zu entnehmen. Diese Kennzahl kann Bestandteil eines SLAs sein. Name der Kennzahl Definition Relevanz Messwert Bemerkung Dauer Telefonannahme Durchschnittliche Dauer, bis ein Telefonanruf entgegengenommen wird. Die durchschnittliche Dauer, bis ein Telefonanruf entgegengenommen wird, ist ein wichtiges Maß für die Anwender- und Kundenzufriedenheit. Die durchschnittliche Dauer, bis ein Telefonanruf entgegengenommen wird, ist der Telefonanlage (ACD) zu entnehmen. Diese Kennzahl kann Bestandteil eines SLAs sein. Name der Kennzahl Definition Relevanz Messwert Bemerkung Gesprächsdauer Durchschnittliche Dauer pro Gespräch (Telefonkontakt) mit dem Anwender. Das Ziel des Service Desk besteht in der Erreichbarkeit durch den Anwender. Zu lange Gespräche gefährden die Erreichbarkeit für andere Anwender. Daher kann eine maximale Gesprächsdauer festgelegt werden. Diese Kennzahl zeigt, ob diese Vorgabe erreicht wird. Die durchschnittliche Dauer, bis ein Telefonanruf entgegengenommen wird, ist der Telefonanlage (ACD) zu entnehmen. Diese Kennzahl kann Bestandteil eines OLAs sein. 216

226 5.3 Prozess-Kennzahlen Continual Service Improvement The 7 Step Improvement Process Für das Continual Service Improvement (CSI) ist das Konzept der Messung von grundlegender Bedeutung. Das CSI beschreibt hierzu den 7 Step Improvement Prozess. Ausgehend von Definition was sie wollen werden durchzuführende Aktivitäten bis zur Implementierung korrigierende Aktionen beschrieben. Name der Kennzahl Definition Relevanz Messwert Anzahl Eingaben in SIP Anzahl der identifizierten Maßnahmen zur Verbesserung der Services, als Eingabe in den Service Improvement Plan (SIP). Identifizierte Verbesserungsmaßnahmen für die Services sind im SIP zu dokumentieren. Auswertung des SIP. Name der Kennzahl Definition Relevanz Messwert Anzahl Eingaben in PIP Anzahl der identifizierten Maßnahmen zur Verbesserung der Prozesse, als Eingabe in den Prozess Improvement Plan (PIP). Identifizierte Verbesserungsmaßnahmen für die Prozesse sind im PIP zu dokumentieren. Auswertung des PIP. Name der Kennzahl Definition Relevanz Messwert Bemerkung Anzahl identifizierter Probleme Anzahl der im proaktiven Problem Management identifizierten Probleme. Ein proaktives Problem Management steigert die Service-Qualität und reduziert die Aufwendungen für reaktive Maßnahmen. Auswertung der Problem-DB. In der ITIL Version 3 gehört das proaktive Problem Management nicht mehr zu den Aktivitäten des Problem Managements im Service Operation. 217

227 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Service Reporting Der Prozess ist für die Erstellung und Lieferung von Berichten über Leistung und Trends gegenüber den Service Level verantwortlich. Das Service Reporting sollte das Format, den Inhalt und die Häufigkeit von Berichten mit den Kunden vereinbaren. Name der Kennzahl Definition Relevanz Messwert Kundenzufriedenheit Service Reporting Ergebnis der Kundenzufriedenheit mit dem Service Reporting. Das Service Reporting und die enthaltenen sowie dargestellten Informationen müssen den Geschäfts- bzw. Kundenanforderungen entsprechen. Abfrage in der Kundenzufriedenheitsumfrage Name der Kennzahl Definition Relevanz Messwert Termintreue für Service Reports Einhaltung der vereinbarten Erstellungstermine für die Service Reports. Service Reports stellen intern und extern eine wichtige Informationsquelle dar. Im externen Verhältnis sind die Berichtstermine zum Teil Bestandteil des SLAs. Daher sind die Berichte termingerecht zu veröffentlichen. Auswertung der Erstellungsdaten im Vergleich zu den definierten Terminen. Name der Kennzahl Definition Relevanz Messwert Anzahl fehlerhafter Service Reports Anzahl der Service Reports, in denen fehlerhafte oder inkonsistente Informationen enthalten sind. Fehlerhafte Service Reports führen zur Kundenunzufriedenheit. Auswertung von Prozess Reviews. 218

228 Service Measurement Aufgabe des Service Measurement ist die Messung der IT Services. Hierzu betont ITIL, dass es nicht mehr genügt, die Leistung einer einzelnen Komponente, wie einen Server oder eine Applikation zu messen und zu berichten. Die IT muss in der Lage sein, end-to-end Service zu messen und zu berichten. Hierzu gibt es mit der Verfügbarkeit, Zuverlässigkeit und Performance drei Grundmessungen, von denen die meisten Organisationen Gebrauch machen. 5.3 Prozess-Kennzahlen Name der Kennzahl Definition Relevanz Messwert Bemerkung Anteil SLAs mit end to end Messung Anteil der SLAs, deren Service Level und die Erreichung der Service Level Ziele auf Basis einer end to end Messung gemessen werden. Eine end to end Messung stellt die Sicht des Business auf den Service dar und ermöglicht eine Bewertung, in welchem Maße die Kunden den vereinbarten Service nutzen konnten. Bewertung der implementierten Messverfahren. Hierbei sind die damit verbundenen Kosten zu bewerten. Unter Umständen kann aus Kostengründen diese Messung lediglich für geschäftskritische Services angewandt werden Return on Investment (ROI) for CSI Im Rahmen des Return on Investments (ROI) für das Continual Service Improvement (CSI) sind die Kosten für die Durchführung dieser Phase des Service Lifecycle zu ermitteln und zu bewerten, welche geschäftlichen Vorteile durch das Continual Service Improvement erzielt werden. Name der Kennzahl Definition Relevanz Messwert Kosten für das Continual Service Improvement Kosten für die Durchführung des Continual Service Improvement Hier werden die Kosten für das CSI dargestellt. Im Vergleich mit den Kennzahlen erzielte Einsparungen (IT / Business) und Mehrwert Business kann so der ROI bewertet werden. Vorrangig Betrachtung der Prozesskosten und Kosten für Tools 219

229 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl Definition Relevanz Messwert Erzielte Einsparungen (IT / Business) Erzielte Einsparungen für die IT und / oder das Business Primär geht es um die Einsparungen für das Business; aber auch Einsparungen innerhalb der IT kommen dem Business zugute. Informationen aus dem Financial Management Name der Kennzahl Definition Relevanz Messwert Mehrwert Business Mehrwert der durchführten Verbesserungsmaßnahme für das Business Wenn das Business einen Mehrwert hat, liegt die Rechtfertigung von Investitionen vor Bewertung durch das Business The Business Questions for CSI Das Business muss in die Entscheidungsfindung im CSI eingebunden werden, um zu beurteilen, welche Verbesserungsmaßnahmen sinnvoll sind und dem Business den größten Nutzen bringen. Name der Kennzahl Kundenzufriedenheit Verbesserungsmaßnahmen Definition Ergebnis der Kundenzufriedenheit mit den identifizierten und umgesetzten Verbesserungsmaßnahmen. Relevanz Die Kennzahl identifiziert die Einbeziehung des Business in das Continual Service Improvement. Messwert Abfrage in der Kundenzufriedenheitsumfrage Service Level Management Die Kennzahlen zum Service Level Management sind zusammengefasst im Kapitel (Prozess Service Level Management innerhalb von Service Design) beschrieben. Speziell die Service Improvement Programme (SIP) und die damit verbundenen Kennzahlen betreffen die Maßnahmen innerhalb des Continual Service Improvements. 220

230 6 Lessons learned: Empfehlungen und Ratschläge 6.1 Management Summary Wir haben viele ITIL-Projekte durchgeführt, geleitet oder wenigstens begleitet. Die Einführung von ITIL in Unternehmen ist oft kein einfaches Projekt. Im Folgenden stellen wir unsere Erfahrungen dar und versuchen herauszustellen, was man tun sollte und woran man scheitern kann. Insbesondere möchten wir die Notwendigkeit vorbereitender Überlegungen und Maßnahmen verdeutlichen, mit denen eine erfolgreiche Adaption der ITIL Best Practices in IT-Organisationen abgesichert werden kann. Die wesentlichen Kernaussagen und Empfehlungen sind: Die Nutzung der ITIL Best Practices für die Implementierung und Verbesserung des IT Service setzt voraus, dass Sie die unternehmensspezifischen IT Service Management-Prozesse definieren und designen. Hierzu kann ITIL einen wichtigen Beitrag leisten, darf dabei aber nicht zum Selbstzweck werden. Ziel ist es nicht, ITIL zu implementieren, sondern ITIL als Medium zu nutzen, um die IT Service Management-Prozesse zu etablieren und stetig zu verbessern. Faktisch etabliert die Einführung von durchgängigen IT Service Management-Prozessen eine Matrixorganisation. Zu der bestehenden Linienorganisation existieren dann bereichsübergreifende IT Service Management-Prozesse mit entsprechenden Verantwortlichkeiten und Zielvorgaben unter Einbeziehung möglicher Supplier oder Lieferanten. Sie müssen sicherstellen, dass die organisatorische Verankerung dieser Prozesse erfolgt und die Akzeptanz der Prozesse und Prozessverantwortlichkeiten in allen Hierarchieebenen erreicht wird. Die damit verbundenen Implementierungsaufgaben dürfen nicht unterschätzt werden. Ohne ein geeignetes Veränderungsmanagement werden die an das Projekt bzw. an die späteren Prozesse gerichteten Erwartungen nicht erfüllt. Ein fehlendes Veränderungsmanagement wird Zeitverschiebungen und Zusatzaufwendungen hervorrufen. Im schlimmsten Fall kann es zum Scheitern des gesamten Vorhabens führen. 221

231 6 Lessons learned: Empfehlungen und Ratschläge 6.2 ITIL-Einführung Berücksichtigung bestehender Prozesse Analyse der bestehenden Prozesse Auf den ersten Blick mag es kurios erscheinen, aber jede auch Ihre IT- Organisation betreibt bereits IT Service Management-Prozesse. Zielsetzung und Aktivitäten dieser Prozesse entsprechen aber in der Regel nur zum Teil den ITIL Best Practices. Sie sollten daher zunächst Ihre bestehenden Prozesse analysieren und mit den ITIL Best Practices vergleichen. Damit stehen Sie aber in der Praxis vor dem Dilemma, etwas bewerten zu müssen, was Sie und Ihre Mitarbeiter ggf. noch nicht ausreichend kennen. Eine Lösungsmöglichkeit für Sie und die im Vorhaben involvierten Mitarbeiter besteht darin, sich kurzfristig ITIL-Know-how anzueignen. Hilfreich ist hier der Erwerb eines Foundation Certificate in IT Service Management und/oder das Studium der ITIL-Fachliteratur. Alternativ können Sie auf einen erfahrenen, zertifizierten Berater zurückgreifen. Berater bieten i. d. R. zusätzlich den Vorteil, nicht nur über das theoretische Grundwissen, sondern auch über Erfahrungen in vergleichbaren Projekten zu verfügen. Besonders wichtig bei diesem Ansatz: Sie müssen sicherstellen, dass der Berater nicht selbstständig allein die Maßnahmen durchführt. Die wesentliche Aufgabe des Beraters besteht vielmehr darin, Sie zu begleiten. Sie benötigen einen Coach, der den Wissenstransfer sicherstellt. Fungiert Ihr Berater nicht als Coach, so kann sowohl die Implementierungsanalyse, als auch die spätere Erweiterung und/oder Umsetzung schwierig werden. Ohne Akzeptanz des Beraters als Coach in Ihrer Organisation verlieren Sie Zeit und nutzen Ressourcen nicht optimal. Die Motivation zur Etablierung der Prozesse wird sinken. Auf der Basis von ITIL sollten Sie analysieren und vergleichen, welche der dort beschriebenen IT Service Management-Prozesse und Aktivitäten bereits (zumindest vermeintlich) in Ihrer IT-Organisation etabliert sind. Dabei ist zunächst eine generische Betrachtung der Prozesse ausreichend. Als Hilfestellung hierbei bietet sich eine tabellarische Darstellung an: Tragen Sie als Zeilen (-überschriften) die IT Service Management-Prozesse ein, wie zum Beispiel Incident Management, Change Management, Service Level Management. Auf der vertikalen Achse erfolgt eine Einstufung der bestehenden Situation hinsichtlich Konzeption, Prozesse, Verfahren, Methoden und Nutzungsgrad. Diese ITIL-Prozesslandkarte ist eine erste, einfache Darstellung des bestehenden Reifegrades. 222

232 6.2 ITIL-Einführung Die ITIL-Prozesslandkarte soll aus der IT-Organisation heraus entwickelt werden, ggf. unter Beteiligung eines Coaches. Dadurch lernen Sie und Ihre Mitarbeiter die ITIL Best Practices erheblich besser kennen. Für die Einstufung der Prozesse ist ausreichendes internes oder externes Know-how von großer Wichtigkeit. Speziell im Bereich des Incident und Problem Managements bedarf es einer entsprechenden Erfahrung, um eine Abgrenzung der Prozessaktivitäten vornehmen zu können. Sie müssen bei der Ist-Aufnahme unterstreichen, dass die Zielsetzung in der neutralen Aufnahme der bestehenden Prozesse besteht. Nur so ist eine echte Standortbestimmung möglich. Bei der Ist-Aufnahme ggf. festgestellte Fehler sowie Abweichungen von bestehenden Richtlinien, festgelegten Abläufen oder Standards dürfen keine negativen Auswirkungen auf die betroffenen Personen haben. Sie benötigen eine objektive Feststellung der Ist- Situation und keine geschönte Darstellung. Eröffnen Sie Ihren Mitarbeitern die Chance zur Offenheit und verzichten Sie auf Rügen für Fehlverhalten. Geben Sie ihren Mitarbeitern die notwendige Sicherheit für eine ungeschönte Darstellung der Ist-Situation. Liegt die ITIL-Prozesslandkarte vor, so sollten Sie spätestens jetzt eine Abstimmung mit einem externen Berater anstreben. Nur zusammen mit einem externen Berater können Sie die bestehende Situation wirklich bewerten und mit anderen IT-Organisationen vergleichen. Die Nutzung der ITIL Best Practices zur Optimierung der IT Service Management-Prozesse kann von verschiedenen Gruppen initiiert werden. Der Kreis der Betroffenen kann grob wie folgt gruppiert werden: Top-Management, mittleres Management, Mitarbeiter, Kunde / Markt Speziell wenn die Implementierung vom Top-Management ausgeht, werden häufig externe Berater frühzeitig mit den Durchführungsleistungen beauftragt. Die Gefahr bei diesem Szenario liegt in den auftretenden Akzeptanzproblemen: Das mittlere Management und die Mitarbeiter können das Gefühl entwickeln, die externen Berater und damit ITIL würden ihnen von oben übergestülpt. Folge hiervon sind die mangelnde Akzeptanz der geplanten Maßnahmen und die damit verbundene Verzögerung bei der Umsetzung. Konsequenz hieraus: Der eigenen Organisation muss die Chance gegeben werden, sich weiterzuentwickeln und ITIL zu adaptieren. Initiierung der geplanten Maßnahmen 223

233 6 Lessons learned: Empfehlungen und Ratschläge Stellen Sie sicher, dass für das Management und die Mitarbeiter im Vorfeld eine Chance besteht, sich mit den ITIL Best Practices auseinander zu setzen. Damit können Sie einer Abwehrhaltung innerhalb Ihrer IT-Organisation erfolgreich begegnen. Geht die Initiierung von der Mitarbeiterschaft aus, so muss zunächst das mittlere Management von den Vorteilen der ITIL Best Practices überzeugt werden: Die Nutzung von ITIL verlangt immer die Unterstützung des Managements. Aufgabe des mittleren Managements ist es, das Top-Management für die Implementierung der IT Service Management-Prozesse auf Basis von ITIL zu gewinnen. Dazu müssen Sie die Vorteile für Ihre Organisation deutlich herausstellen. Fehlt es hierzu an Kennzahlen, da noch keine messbaren Prozesse existieren, sollten Sie auf möglichst prägnante Ereignisse in der Vergangenheit verweisen, beispielsweise einen fehlgeschlagenen Change mit großen Auswirkungen auf die IT-Organisation und auf die Geschäftsprozesse Ihres Kunden. Nutzen Sie solche Beispiele und stellen Sie heraus, welche Vorteile Ihnen ein IT Service Management nach ITIL hierbei geboten hätte. Sie können auch den Weg über Konferenzen nutzen wie zum Beispiel das ITIL Forum und von den Erfahrungen anderer IT- Organisationen profitieren bzw. auf deren positive Erfahrungen verweisen. Als Grund für die Einführung von ITIL werden häufig die damit erreichbare höhere Servicequalität und die bessere Ausrichtung auf die Geschäftsprozesse angeführt. Sie können das Top-Management von ITIL aber nur dann überzeugen, wenn es Ihnen gelingt, die erkannten Defizite und deren Auswirkungen mit finanziellen Beträgen zu hinterlegen. Von Vorteil ist es, finanzielle Vorteile für die IT-Organisation aufzeigen zu können. Noch überzeugender ist die (glaubhafte) Aussicht auf finanzielle Vorteile für das Kerngeschäft. Stellen Sie gegenüber dem Top-Management heraus, dass sich die mit der Einführung von ITIL verbundenen Investitionen amortisieren. Ganz gleichgültig, ob die Nutzung der ITIL Best Practices vom Management oder aus dem Mitarbeiterkreis initiiert wurde: Es muss sichergestellt werden, dass das gesamte Management hinter dem geplanten Vorhaben steht und die damit verbundenen Veränderungen aktiv unterstützt. Nutzen Sie die Kundenanforderungen, um die Notwendigkeit der geplanten Maßnahmen in Ihrer Organisation herauszustellen. Nach dem Motto: Wir implementieren IT Service Management, nicht weil es uns Spaß macht, sondern weil es ein im Markt anerkannter Standard für die optimale Zusammenarbeit zwischen IT und Kunde ist. 224

234 Eine besondere Rolle bei der geplanten Implementierung fällt Ihren Kunden bzw. dem Markt zu. Häufig verlangen Ihre Kunden in Angebotsaufforderungen oder bei Ausschreibungen, dass die anbietende IT- Organisation (IT Service Provider) ITIL-konforme Prozesse bzw. eine ISO (vormals BS 15000) Zertifizierung nachweist. Diese Situation stellt eine große Chance für Ihr geplantes Projekt dar: Mit diesem Außendruck kann die Notwendigkeit einer ITIL Implementierung in der IT-Organisation leichter vermittelt werden. Das Implementierungsprojekt wird unter diesen Voraussetzungen in der Regel mit einem höheren Nachdruck verfolgt werden. Nutzen Sie die Kundenanforderungen, um die Notwendigkeit der geplanten Maßnahmen in Ihrer Organisation herauszustellen. Nach dem Motto: Wir implementieren IT Service Management, nicht weil es uns Spaß macht, sondern weil es vom Markt verlangt wird. Hat sich Ihre Organisation entschieden, die IT Service Management-Prozesse zu etablieren, so müssen Sie Ihren Mitarbeitern die damit verbundenen Ziele vermitteln. Mit der Einführung von Prozessen soll eine Messbarkeit des IT Service Managements und eine Identifizierung von Schwachstellen sichergestellt werden. Die damit verbundene Transparenz ruft aber unter Umständen bei den Betroffenen Ängste hervor. Eine aus dem Kreis der Mitarbeiter häufig geäußerte Sorge ist: Heute muss ich meine Tätigkeiten und mein Wissen transparent dokumentieren und morgen wird mit dem dokumentierten Wissen meine Leistung outgesourced. Versuchen Sie diesen Ängsten mit Gegenbeispielen aus anderen IT- Organisationen zu begegnen. Erklären Sie Ihren Mitarbeitern, dass Outsourcing in der Regel keinen Sinn macht, wenn die Prozesse in der IT-Organisation gut funktionieren, transparente Services und Leistungen erbracht und die gesetzten Ziele erreicht werden. Stellen Sie den mit IT Service Management angestrebten Nachweis der eigenen Leistungsfähigkeit als möglichen Schutz vor Outsourcing heraus. Informieren Sie Ihre Mitarbeiter frühzeitig über die geplanten Maßnahmen und die damit verfolgten Ziele. Motivieren Sie die Mitarbeiter und begegnen Sie den Ängsten Ihrer Mitarbeiter. 6.2 ITIL-Einführung Für eine erfolgreiche Etablierung der geplanten IT Service Management- Prozesse ist die Akzeptanz seitens Ihrer Mitarbeiter eine unabdingbare Voraussetzung. Wertschätzung des Bestehenden 225

235 6 Lessons learned: Empfehlungen und Ratschläge Bei der Analyse der ITIL-Prozesslandkarte werden Sie wahrscheinlich feststellen, dass die bestehenden Prozesse die Anforderungen der ITIL Best Practices nicht vollständig erfüllen. Beispiel: Es existiert bereits ein Change Management, aber dieses Change Management bietet gegenüber ITIL Verbesserungspotenzial. Trotzdem hat dieser Prozess bisher Erfolge gezeigt, und Ihre Mitarbeiter haben sich in diesem bestehenden Prozess engagiert. Sie sollten die bisher bestehenden Abläufe und Leistungen nicht gering schätzen, sondern als Basis für eine Verbesserung würdigen. Zeigen Sie Ihre Wertschätzung für die bestehenden Abläufe und für die damit erzielten Erfolge. Stellen Sie ITIL als Chance für eine Verbesserung dar. Nutzen Sie die bestehenden Prozesse und zeigen Sie die positiven Möglichkeiten der ITIL Best Practices auf, um diese Prozesse weiter zu verbessern. Ihre Mitarbeiter sollten ITIL als Angebot verstehen, auf das darin dokumentierte Wissen zurückzugreifen. Dafür muss ITIL als Chance gesehen werden, nicht als Damoklesschwert, das Bestehendes entwertet. Ihre Mitarbeiter und Manager sollen ITIL als Chance verstehen, von anderen zu lernen und sich dadurch weiterzuentwickeln. Ihr Ziel muss es sein, ein Verständnis von ITIL als Chance für eine ganzheitliche Betrachtung der IT in Ihrer Organisation zu verankern. Selbst erarbeiten statt fertig kaufen Prozess-Einführungen Sie müssen mit Widerständen bei der Implementierung der geplanten Prozesse rechnen. Sehr hilfreich ist es hier, wenn die IT Service Management-Prozesse aus Ihrer IT-Organisation heraus, von Ihren Mitarbeitern entwickelt werden. Ihre Mitarbeiter können dabei Ihre praktischen Erfahrungen einbringen und so sicherstellen, dass die geplanten Prozesse auf die Geschäftsprozesse Ihres Kunden ausgerichtet sind sowie den Anforderungen der IT-Organisation entsprechen. Ihre IT Service Management-Prozesse auf Basis von ITIL können Sie nicht extern einkaufen, sondern sie müssen unbedingt von Ihren Mitarbeitern erarbeitet werden. Externe Berater können und sollten Ihnen hierbei helfen. Der Berater soll Ihre Mitarbeiter ansprechen können und als Coach tätig sein. Dazu muss der Berater nicht nur über die erforderlichen ITIL (und ISO 20000) Zertifizierungen verfügen, sondern auch Erfahrungen aus vergleichbaren Projekten und vergleichbaren Organisationen mitbringen. Nicht zuletzt ist 226

236 6.2 ITIL-Einführung die Sozialkompetenz des Beraters dabei ein weiterer wichtiger Erfolgsfaktor: Die Chemie muss stimmen. Das beauftragte Unternehmen muss sicherstellen können, dass es über eine ausreichende Anzahl von Beratern verfügt um ggf. mehrere gleichzeitig anstehende Projektaktivitäten in Ihrer IT-Organisation qualitativ zu unterstützen. Der Berater muss in der Lage sein, mit ggf. anderen im Ihrem Hause tätigen Beratern zusammenarbeiten zu können. Hierbei kann es sich unter Umständen um Berater handeln, die im Rahmen des IT Governance tätig sind oder den Veränderungsprozess einer Organisation unterstützen. Beauftragen Sie keine Zertifizierungsorganisation mit der Beratung: Ist eine spätere Zertifizierung der IT Service Management-Prozesse geplant, muss Unabhängigkeit zwischen Berater und Zertifizierer gewährleistet sein. Zertifizierungsorganisationen konzentrieren sich außerdem häufig auf die formalen Anforderungen des Standards, während ein Berater praxisorientiert vorgehen wird. Der Betriebsrat sollte von Ihnen bzw. vom Top-Management frühzeitig über die geplanten Maßnahmen informiert werden. Mit der Einführung von Prozessen auf Basis der ITIL Best Practices ist das Ziel verbunden, die Wirksamkeit der Prozesse zu messen und ggf. den Bedarf an notwendigen Optimierungsmaßnahmen zu identifizieren. In vielen Fällen führt dies dazu, dass die Prozess-Aktivitäten der Mitarbeiter erfasst und aggregiert werden. Zum Beispiel wird die Kennzahl Einhaltung der Lösungszeiten in Abhängigkeiten der SLAs oder Dauer der Liegezeiten aus den dokumentierten Maßnahmen in Tickets gewonnen. Nach deutschem Recht ist der Betriebsrat zumindest über diese Maßnahmen zu informieren; in Teilbereichen wird möglicherweise die Zustimmung des Betriebsrates erforderlich sein. Einbeziehung des Betriebsrats Informieren und beteiligen Sie den Betriebsrat frühzeitig. Unterstreichen Sie, dass Prozesse ausgewertet werden sollen und nicht die Leistung einzelner Mitarbeiter. Machen Sie klar, dass die geplanten Maßnahmen der internen Optimierung und damit auch dem Schutz von Arbeitsplätzen dienen. Zur Information und Abstimmung mit dem Betriebsrat hat sich folgendes Vorgehen bewährt: Das Top-Management hat den Betriebsrat frühzeitig über die Ziele der geplanten Prozesseinführung und das Erreichen von Meilensteinen informiert. Es wurde mit dem Betriebsrat vereinbart, dass die Prozesse gemessen werden und keine Auswertung auf Mitarbeiterebene erfolgt. 227

237 6 Lessons learned: Empfehlungen und Ratschläge Qualität vor Geschwindig keit In Abhängigkeit der Größe Ihrer IT-Organisation ist zu entscheiden, ob die Prozess Manager eine Full-time Tätigkeit übernehmen. In vielen Unternehmen ist dies der Fall. Dann sollte der Betriebsrat bei der Ausschreibung und Besetzung der Positionen der Prozess Manager beteiligt werden. Eine detaillierte Absprache der geplanten und erhobenen Kennzahlen mit dem Betriebsrat liegt in der Verantwortung der eingesetzten Prozess Manager. Vielfach bedeutet die Einführung der IT Service Management-Prozesse auf Basis der ITIL Best Practices eine veränderte Betrachtungsweise in der IT- Organisation: Weg von der Systemorientierung, hin zu einer Service- und Prozessorientierung. Das bedeutet auch und gerade eine Veränderung in der Denkweise und im Verhalten der Mitarbeiter in Ihrer IT-Organisation. Wie bei allen Veränderungsmaßnahmen wird hierzu eine ausreichende Zeit benötigt. Die Mitarbeiter müssen die Veränderungen adaptieren und verinnerlichen. Eine Veränderung über Nacht ist nicht zu erzwingen. Ebenso ist es nicht ratsam, zu große Veränderungen auf einmal durchzuführen. Sie sollten unbedingt stufenweise vorgehen. Dies gilt sowohl für die Gesamtheit aller IT Service Management-Prozesse, als auch innerhalb der einzelnen Prozesse. Es ist wenig ratsam, sämtliche IT Service Management-Prozesse gleichzeitig zu implementieren. In der Regel beginnt man mit der Implementierung des Service Level Managements, gefolgt von Incident, Configuration, Change und Problem Management. Die konkrete Reihenfolge der Einführung hängt aber von Ihrer Ist-Situation und den Anforderungen an Ihre IT-Organisation ab, also von Ihrer Pain. Ebenso sollte der Reifegrad, die Qualität der einzelnen Prozesse schrittweise gesteigert werden. Die Veränderungen müssen von den Mitarbeitern und der gesamten IT-Organisation verkraftet werden. Planen Sie daher Projektpausen ein, in denen sich die Mitarbeiter und die IT-Organisation zunächst mit den durchgeführten Veränderungen vertraut machen können und Sicherheit zurückgewinnen. Die Implementierung von IT Service Management-Prozessen bedingt eine Veränderung der IT-Organisation und der Mitarbeiter. Stellen Sie eine schrittweise Veränderung mit entsprechenden Projektpausen sicher. 228

238 6.2 ITIL-Einführung Die Organisation gewinnen Innerhalb Ihrer IT-Organisation existieren verschiedene Interessengruppen. Sie müssen die Motivation der einzelnen Interessengruppen identifizieren und sie anschließend auf Basis der identifizierten Motivationsgründe für ITIL gewinnen. Eine wichtige Motivation zur Nutzung von ITIL besteht in der bereits beschriebenen Chance, die IT-Organisation und sich persönlich weiterzuentwickeln. Das Qualitätsmanagement können Sie leicht für die ITIL Best Practices gewinnen, wobei unter Qualitätsmanagement hier nicht eine Abteilung, sondern der Gedanke der Qualitätsverbesserung zu verstehen ist. Ein wichtiges Kriterium für Qualität ist Nachhaltigkeit. ITIL stellt eine höhere Nachhaltigkeit in der IT sicher. So werden beispielsweise mit dem Incident Management nicht nur akute Störungen behoben, sondern darüber hinaus wird mit dem Problem Management eine nachhaltige Untersuchung etabliert, die zu einer Qualitätsverbesserung in der IT führt. Mitarbeiter mit einem starken Kundenfokus gewinnen Sie für ITIL, indem Sie die Serviceorientierung und die Ausrichtung der IT Service Management-Prozesse auf die Geschäftsprozesse des Kunden herausstellen. Die Motivation des Top-Managements wird wahrscheinlich primär durch die Qualitätsverbesserung geprägt sein. Durch Hinweise auf Kostenbetrachtungen und einen häufig gegebenen Wachstums- oder Konsolidierungsdruck können Sie weitere Motivation für die ITIL Best Practices generieren. Das mittlere Management gewinnen Sie für ITIL mit den zu erwartenden Verbesserungen in der abteilungsübergreifenden Zusammenarbeit oder der Mess- und Nachweisbarkeit von Qualitätsverbesserung gegenüber dem Top-Management. Den Mitarbeitern bietet ITIL u. a. eine stärkere Absicherung der durchgeführten Aktivitäten durch klare Rollen- und Prozessdefinitionen. Die jeweilige Motivation für IT Service Management wird auch von der Größe der IT-Organisation beeinflusst. In kleineren IT-Organisationen steht häufig allein die Kundenorientierung im Mittelpunkt. Kommunikationsprobleme innerhalb der IT-Organisation und die Vernetzung der einzelnen IT-Organisationen spielen hier kaum eine Rolle. Mit wachsender Größe der IT-Organisation nehmen diese Probleme aber exponentiell zu und ITIL wird als Chance erkannt, diese Probleme zu lösen. Zur Identifizierung der verschiedenen Motivationsgründe ist es hilfreich, über einen externen Berater mit entsprechenden Erfahrungen zu verfügen. 229

239 6 Lessons learned: Empfehlungen und Ratschläge Der Gewinn für die Organisation Die Rollen gemäß der ITIL Best Practices Verdeutlichen Sie den durch IT Service Management erzielbaren Gewinn für die IT-Organisation, indem Sie die Sicht des Kunden einnehmen: Die IT wird in der Regel vom Kunden nur dann (negativ) wahrgenommen, wenn zugesagte Vereinbarungen nicht eingehalten werden oder größere IT-Störungen auftreten. Durch ein regelmäßiges, kundenorientiertes Reporting können Sie dieses Erscheinungsbild zum Positiven verändern. Reporten Sie Ihren Kunden aber nicht nur die einzelnen Bestandteile der SLAs, sondern stellen Sie ihnen aussagekräftige Qualitätsinformationen aus den IT Service Management-Prozessen zur Verfügung. So wird im Hause des IT Rechenzentrums dem Kunden unter anderem berichtet, welche Probleme identifiziert wurden und welche Maßnahmen ergriffen werden, um die identifizierten Probleme zu beheben. Für interne IT-Organisationen ist es ideal, über erreichte Kosteneinsparungen berichten zu können. Im beschriebenen Unternehmen konnte zum Beispiel mit Hilfe des Prozesses Capacity Management dargestellt werden, welche Kosteneinsparungen durch die Konsolidierung der IT Infrastruktur erzielt wurden Rollenbeschreibungen Innerhalb der ITIL Best Practices bis Version 2 finden Sie Rollenbeschreibungen zu den einzelnen Prozess Managern der IT Service Management- Prozesse. Schauen Sie sich hierzu [OGC, 2005b], [OGC, 2006b] und [OGC, 2006a] an: OGC Best Practice for Service Support, OGC Best Practice for Service Delivery und Best Practice für Security Management. Generelle Rollenbeschreibungen für den Prozess Manager und den Prozess Owner sind der Originalliteratur zur ITIL Version 2 nicht zu entnehmen. Hier liefert aber entsprechende Sekundärliteratur Empfehlungen (vgl. [OGC, 2005a]). Die ITIL Version 3 greift diesen leichten Mangel aus Version 2 auf und gibt Handlungsempfehlungen für die Etablierung der organisatorischen Rollen Prozess Owner und Prozess Manager. Diese generischen Rollenbeschreibungen sind im Rahmen der Umsetzung entsprechend der jeweiligen Organisation zu operationalisieren. Diesen Empfehlungen gemäß ist der Prozessinhaber (Prozess Owner) für die Prozessergebnisse verantwortlich, während der Prozess Manager für die Durchführung und die Einrichtung des Prozesses verantwortlich ist. Der Prozess Owner dient dem Prozess Manager primär als Coach. 230

240 6.2 ITIL-Einführung Innerhalb des Unternehmens wurden für die Rollen der Prozess Owner und Prozess Managern abweichende Verantwortlichkeiten festgelegt. Der Prozess Manager hat die Verantwortung für das Funktionieren seines Prozesses und steuert die notwendigen Optimierungen. Der Prozess Manager muss demzufolge mit den notwendigen Weisungsrechten innerhalb seines Prozesses ausgestattet sein. Die Prozess-Ziele werden nicht nur primär vom Prozess Owner vorgegeben, sondern auch durch ihn aus der IT-Strategie und der Balanced Scorecard abgeleitet. Aus diesen Anforderungen heraus definiert der Prozess Manager die notwendigen Prozess-Ziele und die damit verbundenen Kennzahlen. Es muss sichergestellt werden, dass die Prozess Manager ein Grundverständnis aller IT Service Management-Prozesse haben. Dadurch wird einerseits erreicht, dass der eigene Prozess hinsichtlich seiner Schnittstellen, Abhängigkeiten und Verzahnungen besser gemanagt werden kann. Andererseits motivieren diese Kenntnisse und die damit verbundenen Aufstiegsmöglichkeiten den Prozess Manager zum Lernen. In der ITIL-Literatur bis Version 2 wird die Rolle des Service Managers nur stellenweise angesprochen, aber nicht übergreifend beschrieben. Trotzdem kommt dieser Rolle in der praktischen Umsetzung der ITIL Best Practices eine sehr wichtige Aufgabe zu. Die ITIL Version 3 präzisiert diese wichtige Rolle wie folgt: Einzelne Prozess-Ziele können partiell miteinander konkurrieren, Umsetzungsmaßnahmen aus unterschiedlichen Prozessen sind zu priorisieren und es können Abstimmungsprobleme zwischen Prozessorganisation und hierarchischer Organisationsstruktur auftreten. In diesen Fällen ist der Service Manager die Eskalationsinstanz für die Prozess Manager. Die Rolle des Prozess Managers Die Rolle des Service Managers Letztendlich liegt die Gesamtverantwortung für das Service Management in der Rolle des Service Managers (vgl. Continual Service Improvement, [OGC, 2007e] Seine Verantwortung umfasst die Entwicklung der Geschäfts-Strategie, Marktund Kunden-Analyse, Lieferanten-Management, Inventarisierung, Kosten Management und insbesondere das Auslieferungs- und Lebenszyklus-Management von Produkten und Services. Für die Einführung der IT Service Management-Prozesse und der identifizierten Optimierungsmaßnahmen ist der Service Manager richtungsweisend, er erstellt den Bebauungsplan. 231

241 6 Lessons learned: Empfehlungen und Ratschläge Die Rolle des Service Managers muss mit einem erfahrenen Manager besetzt werden. Die Rolle des Top- Managements Aufgabe des Top-Managements ist es, den zu etablierenden IT Service Management-Prozessen den Rücken zu stärken und ihre Ziele nach außen zu vertreten. Das Top-Management ist der Sponsor der IT Service Management-Prozesse. Mit der Implementierung der neuen IT Service Management-Prozesse kann vorübergehend eine Phase der Instabilität entstehen. Mit den bisherigen Abläufen waren die Mitarbeiter vertraut, mit den neu implementierten Prozessen sind sie es noch nicht. Erworbene Kompetenzen, gehen unter Umständen verloren, es beginnt eine unsichere Lernphase ( Tal der Tränen ). Hier muss das Top-Management unterstützend einwirken und die Sicherheit geben, dass Anfangsfehler toleriert werden. Das Top-Management muss Anfangsfehler tolerieren und so dazu beitragen, dass kein Rückfall in alte Zustände eintritt. Die Rolle des mittleren Managements Das mittlere Management setzt einerseits die Vorgaben des Top-Managements im täglichen Betrieb aktiv um. Andererseits muss es die Prozess Manager unterstützen und ihnen den erforderlichen Freiraum verschaffen. Die Einführung von durchgängigen Prozessen mit dezidierter Prozessverantwortung führt häufig zu Widerständen im mittleren Management. Diese Widerstände sind mit der Angst vor der geplanten Transparenz und einem möglichen Machtverlust verbunden. Manchmal kann diesen Widerständen erfolgreich entgegen gewirkt werden, wenn die Rollen der Prozess Owner mit Personen aus dem mittleren Management besetzt werden. Dem mittleren Management kommt eine wichtige Rolle in der Unterstützung des Wandels zu. Die Rolle der Mitarbeiter Mit der Einführung von IT Service Management-Prozessen kann sich die Rolle von Mitarbeitern im IT Service aus deren Sicht verkomplizieren. Waren sie vorher ausschließlich einem Vorgesetzten verantwortlich (und dort der Ergebniserbringung), wird Ihre Tätigkeit nun in verschiedenen Prozessen überwacht und die Weisungen unterschiedlicher Prozess Manager steuern auf Qualitätsebene die operative Arbeit der Mitarbeiter. Stellen Sie sicher, dass Ihre Mitarbeiter sich in dieser Situation nicht verloren vorkommen. Die Hierarchie, insbesondere das mittlere Management, muss die Prozesse aktiv unterstützen, um damit die Ziele der ITIL Einführung nachhaltig zu unterstützten. 232

242 6.3 Kontinuierlicher Verbesserungsprozess Die Prozess Manager geben den Mitarbeitern Leitplanken (Prozessleitlinien) vor, innerhalb derer sie sich sicher bewegen können. Durch diese Konzentration auf klare Prozesse geben sie ihren Mitarbeitern ein Gefühl der Sicherheit. Transparente Ziele und veröffentlichte Kennzahlen als Erfolgsnachweis der eigenen Arbeit steigern die Zufriedenheit der Mitarbeiter im Unternehmen. Beziehen Sie Ihre Mitarbeiter und deren Know-how bei der Entwicklung der neuen IT Service Management-Prozesse mit ein und gewinnen Sie dadurch weitere Akzeptanz. Damit die ITIL Best Practices erfolgreich zur Gestaltung und Implementierung Ihrer IT Service Management-Prozesse genutzt werden können, müssen Sie einen Veränderungsprozess in Ihrer IT-Organisation initiieren. Ohne flankierende Maßnahmen führt das Einführen von ITIL zu Akzeptanzproblemen und scheitert nicht selten. Die ITIL Best Practices sind eine Methode, aber nicht das Ziel. Sie nutzen lediglich die Best Practice-Erfahrungen, um von Ihnen bei der Definition Ihrer IT Service Management-Prozesse zu profitieren. Die angepassten IT Service Management-Prozesse müssen innerhalb Ihrer IT- Organisation gelebt werden. Dazu müssen Ihre Mitarbeiter die Prozesse verstehen, mitgestalten und insbesondere die Erfolge erfahren. 6.3 Kontinuierlicher Verbesserungsprozess Eine wichtige Komponente der ITIL Best Practices ist das im konzeptionalen Ansatz enthaltene Qualitätsmanagement. Hierzu verweisen die ITIL Best Practices auf verschiedene Methoden wie zum Beispiel auf Six Sigma oder auf den Deming-Zyklus (vgl. [OGC, 2005b]), dargestellt in Abbildung 66. Von wesentlicher Bedeutung für die Qualität der IT Services und der Prozesse ist, dass Sie eine fortlaufende Überprüfung, ein Monitoring sämtlicher implementierten IT Service Management-Prozesse durchführen. Auf die dazu notwendige Ermittlung von Kennzahlen wird im nächsten Kapitel eingegangen. In der Publikation Best Practice für Service Support vgl. [OGC, 2005b]) heißt es hierzu: Dieser Ansatz bedingt, dass ein Unternehmen nach definierten Prozessen agiert, seine Aktivitäten in Bezug auf die Zielerreichung misst, sowie die aus den Prozessdurchläufen folgenden Outputs im Hinblick auf mögliche Prozessverbesserungen überprüft. 233

243 6 Lessons learned: Empfehlungen und Ratschläge Abbildung 66: Deming (oder PDCA) Zyklus Die Norm ISO 20000, der (einzige) internationale Standard für das IT Service Management, konkretisiert diesen Ansatz der ITIL Best Practices weiter. So fordert die ISO einen übergeordneten Prozess Planung und Implementierung. Dieser Prozess stellt unter anderem die Etablierung eines übergreifenden kontinuierlichen Verbesserungsprozesses für das IT Service Management sicher. Darüber hinaus sind gemäß der ISO in den einzelnen IT Service Management-Prozessen notwendige Verbesserungsmaßnahmen zu identifizieren und aufzuzeigen. Mit der Messung und dem Review der IT Services und der IT Service Management-Prozesse erhalten Sie hierzu die notwendigen Voraussetzungen. Eine Kurzbeschreibung zur ISO finden Sie im Download-Bereich der KESS DV-Beratung (vgl. [KESS, 2006b]). Darüber hinausgehende Informationen können Sie den im Quellenverzeichnis aufgeführten Publikationen zu ISO entnehmen. Ein professionelles IT Service Management bedingt unabdingbar die stetige Messung der Prozesse und die Identifikation von möglichen Verbesserungsmaßnahmen (KVP: Kontinuierlicher Verbesserungs-Prozess) KVP der bestehenden Prozesse Ausgangspunkt ist die oben beschriebene Analyse der bereits innerhalb der IT-Organisation bestehenden IT Service Management-Prozesse. Prozess Manager von bereits bestehenden IT Service Management-Prozessen befinden sich dabei in einer vermeintlich komfortablen Ausgangsposition: Während andere Prozesse noch zu definieren und zu entwickeln sind, bestehen deren Prozesse bereits. 234

244 6.3 Kontinuierlicher Verbesserungsprozess In diesem Zusammenhang mag es zunächst paradox erscheinen, aber speziell die Prozess Manager von bestehenden Prozessen benötigen die intensivste Unterstützung durch eine externe Begleitung. Sie müssen die IT Service Management-Prozesse, die am weitesten entwickelt sind (mit der höchsten Prozessreife), besonders eng begleiten. Ansonsten besteht die große Gefahr, dass sich der betroffene Prozess Manager aufgrund der durchgeführten Ist-Aufnahme (ITIL-Prozesslandkarte) in seiner bestehenden Handlungsweise bestätigt fühlt und keine notwendigen Handlungsmaßnahmen für seinen Prozess identifiziert. Auch bei guten (Einzel-) Ergebnissen der durchgeführten Ist-Aufnahme (Prozessreife) muss aber zumindest davon ausgegangen werden, dass die Vernetzung der IT Service Management-Prozesse noch nicht ausreichend gegeben ist. Das heißt, es besteht immer ein Handlungsbedarf, den Prozess mit den anderen IT Service Management-Prozessen zu vernetzen. Die (externe) Begleitung des Prozess Managers soll sicherstellen, dass die erforderliche Vernetzung erkannt und aktiv betrieben wird. Die Rolle des externen Begleiters ist es, als Coach den Prozess Manager einzufangen. Durch die Forcierung der Vernetzung vermeiden Sie eine isolierte Optimierung einzelner IT Service Management-Prozesse, die ansonsten den anderen Prozessen davoneilen würden. Die isolierte Optimierung einzelner Prozesse kann zu Mehraufwendungen führen, wenn später die notwendigen Schnittstellen und unter Umständen damit verbundene Aktivitäten angepasst werden müssen. Es ist für Ihre IT-Organisation von großem Vorteil, wenn eine gleichmäßige vertikale Entfaltung der geplanten IT Service Management-Prozesse betrieben wird. Diese Forderung bedeutet nicht, dass Sie alle IT Service Management-Prozesse gleichzeitig einführen sollen. Es ist vielmehr pro Projekt- bzw. Implementierungsphase eine synchrone Entwicklung der einzelnen Prozesse sicherzustellen. Dem Prozess Manager mit dem bereits am weitesten entwickelten Prozess kommt hierbei eine besondere Rolle zu. Er muss auf die anderen Prozess Manager zugehen, die Vernetzung der einzelnen Prozesse aktiv vorantreiben und sicherstellen. Planen Sie zum Beispiel die Etablierung des Incident, Problem und Change Managements und ist der Prozess des Incident Managements am weitesten fortgeschritten, so muss der Prozess Manager des Incident Managements die führende Rolle bei der erforderlichen Vernetzung der drei Prozesse einnehmen. 235

245 6 Lessons learned: Empfehlungen und Ratschläge Bei den bestehenden Prozessen zeichnet sich der KVP dadurch aus, dass die Prozesse gleichmäßig (vertikal) entwickelt werden und keine Prozesse die Entwicklung isoliert vorantreiben. Nicht zu früh beginnen KVP der neuen Prozesse Mit dem Start des kontinuierlichen Verbesserungsprozesses darf bei neuen Prozessen nicht zu früh begonnen werden. Stellen Sie zunächst sicher, dass der Prozess bereits komplett eingeführt ist. Am Bild einer Treppe verdeutlicht: Sie sollten die Stufen stetig, mit ruhigen Schritten emporsteigen. Nehmen Sie nicht mehrere Stufen auf einmal, überspringen Sie keine Stufen. Um das Ziel sicher zu erreichen, sollten Sie auf jeder Stufe erst einmal verharren und Kraft tanken, um dann erholt die nächste Stufe zu erklimmen. Ihre Organisation muss die Prozesse angenommen haben und damit verbundene (Ver-) Änderungen müssen verkraftet sein. Die Einführung von IT Service Management-Prozessen auf Basis der ITIL Best Practices ist eine Maßnahme der Organisationsentwicklung und bedarf eines Veränderungs-Managements. Der Soziologe Kurt Lewin gilt als Wegbereiter der Organisationsentwicklung. Aufbauend auf seiner Grundannahme, dass sich eine Organisation ändert, wenn sich ihre Akteure ändern, entwickelte er sein Phasenmodell (vgl. Abbildung 67) zum Veränderungs-Management (vgl. [Lewin, 1958]). Neue Welt Alte Welt Einfrieren Auftauen Bewegen Abbildung 67: 3-Phasen-Modell nach Lewin 236

246 6.3 Kontinuierlicher Verbesserungsprozess Im Ausgangszustand befindet sich eine Organisation im Gleichgewicht. Die bestehenden Abläufe und Prozesse werden in Frage gestellt. Hierzu kann auf die ITIL Best Practices und die damit in anderen IT-Organisationen erzielten Erfolge verwiesen werden. Die bestehende IT-Organisation wird aufgetaut. Ist das Auftauen der IT-Organisation (und der Mitarbeiter) erreicht, werden in der Phase der Bewegung neue Prozesse implementiert und die Mitarbeiter in deren Handhabung ausgebildet und eingewiesen. Es ist dann von großer Bedeutung, dass dieser Zustand zunächst eingefroren wird. Mit den alten Abläufen waren Ihre Mitarbeiter vertraut. Die Implementierung der neuen IT Service Management-Prozesse führt zu einer Instabilität. Die Mitarbeiter sind mit in den neuen Prozessabläufen und den damit verbundenen Abläufen noch nicht vertraut. Sie fühlen sich unsicher. Ihre Aufgabe besteht jetzt darin, den Mitarbeitern die notwendige Sicherheit zu vermitteln. Das heißt, Sie müssen den Mitarbeitern die Chance geben, sich mit den neuen Prozessen auseinander zu setzen und deren Handhabung im täglichen Betrieb einzuüben. Die Mitarbeiter Ihrer IT-Organisation müssen die Veränderungen bewältigen. Geben Sie ihrer Organisation die Chance, sich mit neuen Abläufen vertraut zu machen und planen Sie Phasen des Einfrierens ein. Erst wenn die Mitarbeiter mit den neuen Prozessaktivitäten vertraut sind, sollten Sie eine weitere Verbesserung und Erweiterung des Prozesses angehen. Zusätzlich ist die Phase des Einfrierens für die Motivation Ihrer IT- Organisation von großer Bedeutung. Die Einführung von IT Service Management-Prozessen auf Basis der ITIL Best Practices führt zu veränderten Abläufen und ggf. zu anderen Aktivitäten, die die Mitarbeiter durchzuführen haben. Von nachhaltigem Erfolg sind diese Maßnahmen nur dann, wenn Sie akzeptiert werden. Akzeptiert werden die Maßnahmen in der Regel, wenn Sie den Erfolg wenn möglich für den Einzelnen nachweisen. Haben Sie zum Beispiel ein Configuration Management eingeführt, so sollten Sie die Erfolge des Prozesses für Ihre IT-Organisation und Ihre Mitarbeiter erfahrbar machen. Die Mitarbeiter sollen erleben, welche Vorteile dieser Prozess in der täglichen Arbeit bietet. Damit stellen Sie die Motivation der Mitarbeiter für weitere Veränderungsmaßnahmen sicher. 237

247 6 Lessons learned: Empfehlungen und Ratschläge Das Service Improvement Programm Beginnen Sie zu früh mit den nächsten Verbesserungsmaßnahmen, so nehmen Sie ihrer IT-Organisation und Ihren Mitarbeiter die Chance, die bisher erzielten Vorteile zu erleben. Innerhalb der ITIL Best Practices wird lediglich im Rahmen des Service Level Management-Prozesses auf ein Service Improvement Programm (SIP) eingegangen. Die ISO IT Service Management ist hier konsequenter. Dort wird zu den jeweiligen Prozess-Reviews gefordert, dass ein erkanntes Verbesserungspotenzial zu Prozessen oder Services der Input für das SIP ist. Durch die Dokumentation im SIP stellen Sie die Nachhaltigkeit der Umsetzung von identifizierten Verbesserungsmaßnahmen sicher. Häufig wird innerhalb der IT-Organisation die Feststellung getroffen Darum müsste man sich einmal kümmern. Dann jedoch diktiert wieder das Tagesgeschäft das Geschehen. Bis zum nächsten akuten Auftreten eines Problems gerät die identifizierte Schwachstelle samt Optimierungsbedarf wieder in Vergessenheit. Ein Service Improvement Programm und die Möglichkeit, dass jeder Mitarbeiter hierzu einen Input liefern kann, hilft Ihnen nachhaltig, die Qualität der Prozesse und des IT Service zu verbessern. Ihre Mitarbeiter haben mit dem Service Improvement Programm die Chance sich einzubringen und zu erleben, wie sie persönlich zum Erfolg der IT-Organisation beitragen. ITIL Einführung erfordert ein Release Damit entsteht letztendlich eine Kombination aus formellen Reviews zur Service- und Prozessoptimierung und einem betrieblichen Vorschlagswesen. In Ihrer Organisation existiert damit ein Verbesserungsprozess, der Input für neue und eingeführte IT Service Management-Prozesse aus der IT-Organisation (Reviews) und von den Mitarbeitern bezieht. Aufgabe des Prozess Managers ist die Bewertung des Inputs für den Service Improvement Plan und die Erstellung einer Umsetzungsplanung. Die Einführung und der Ausbau der IT Service Management-Prozesse sollten in Stufen und mit Stabilisierungsphasen (Projektpausen) erfolgen. Dazu muss der Prozess Manager die zuvor geplanten Projektphasen sowie den Input aus dem SIP bewerten, die mit den Maßnahmen verbundenen Vorteile identifizieren und die Umsetzung planen. Diese Tätigkeit ist mit dem IT Service Management-Prozess des Release Management vergleichbar. Es ist nicht zweckmäßig eine Reihe von Änderungen jeweils einzeln und nacheinander zu implementieren. Sie sollten vielmehr die Einzelmaßnahmen bündeln und als Aufgabenpaket (Release) durchführen. 238

248 6.3 Kontinuierlicher Verbesserungsprozess Bündeln Sie die einzelnen Verbesserungs- und Erweiterungsmaßnahmen zu einem Aufgabenpaket (Release). Dem Prozess Owner kommt hierbei als Coach eine qualitätssichernde Aufgabe zu. Zum Beispiel hat der Prozess Owner beim Prozess Manager kritisch zu hinterfragen, ob die nächste Umsetzungsmaßnahme sowohl inhaltlich als auch vom Zeitpunkt her die IT-Organisation nicht überfrachtet. Sobald diese Abstimmung erfolgt ist, muss der Prozess Manager die geplanten Verbesserungen und Erweiterungen in der IT-Organisation gegenüber dem Management und den Mitarbeitern kommunizieren. Kommunizieren Sie als Prozess Manager Ihre geplanten Maßnahmen (SIP für Ihre IT Service Management-Prozesse) in der IT-Organisation. Die Initiierung zur Entfaltung weiterer IT Service Management-Prozesse muss vom IT-Management erfolgen. Haben Sie zum Beispiel bereits Incident, Problem, Configuration und Change Management implementiert, so muss eine Erweiterung um das Release Management vom IT-Management initiiert werden. Die Verantwortung für die Prozessentfaltung die Erweiterung der bestehenden IT Service Management-Prozesse liegt beim Service Manager und dem prozessverantwortlichen Prozess Manager. Diese stimmen die mit der Prozesseinführung verbundenen Maßnahmen mit dem Prozess Owner ab. Die Verantwortung für die Prozessentfaltung die Erweiterung der bestehenden IT Service Management-Prozesse liegt beim Service Manager. Dieser stimmt zunächst die damit verbundenen Maßnahmen mit dem Prozess Owner ab. Sobald der Prozess Manager für den neuen IT Service Management-Prozess etabliert ist, stimmen sich dann der Prozess Owner und der Prozess Manager ab. Es ist hilfreich, wenn die Prozess Owner für alle IT Service Management- Prozesse zu Beginn benannt werden, auch wenn die Prozesse noch nicht implementiert wurden. Die Prozess Manager können mit der Entscheidung des Managements über die Einführung eines Prozesses benannt werden. Wichtig ist, nicht nur die implementierten Prozesse hinsichtlich ihrer Zielerreichung zu messen, sondern auch die Einführung von Prozessen zu messen und zu überwachen. Der Entfaltungsprozess 239

249 6 Lessons learned: Empfehlungen und Ratschläge Der Service Manager hat hierzu ein prozessorientiertes Führungssystem aufgebaut, in dem pro Prozess die folgenden Stufen vom Service Manager gemessen und berichtet werden: 1. Stufe Prozess verstanden 2. Stufe Prozessnutzung initiert 3. Stufe Prozess implementiert 4. Stufe Prozess wird kontinuierlich verbessert (KVP) Damit die Implementierung der Prozesse vom Management besser verfolgt werden kann, könnten die obigen Stufen der IT Service Management- Prozesse mit einem Ampelsystem dargestellt werden. Für die Gestaltung des Ampelsystems empfiehlt es sich, auf der vertikalen Achse die unternehmenswichtigen Prozesse (z. B. Incident, Problem, Change aufzuführen (etc.) und auf der horizontalen Achse die involvierten Gruppen, Abteilungen, Hauptabteilungen etc. darzustellen. Die Matrix kann dann anschließend in der Stufigkeit 1 4 befüllt werden. Wir haben sehr gute Erfahrung mit einer einfachen Einstufung der Skala 1 4 gemacht: Stufe 1: die Mitarbeiter sind geschult, die Mitarbeiter haben die richtigen Informationen über die Umsetzung der Prozesse; Stufe 2: die Mitarbeiter leben die Prozesse in den ersten Anfängen, nutzen die neuen Tools, Portale etc.; Stufe 3: die Prozesse werden vollumfänglich genutzt (es kommen Vorschläge zur Verbesserung), die Prozesstools werden ausgereizt; Stufe 4: die Organisation denkt darüber nach, Erweiterungen und Verbesserungen umfänglich einzuführen. Mit diesem Ampelsystem verfügt der Service Manager und damit das gesamte Management über ein gutes Führungssystem zur Überwachung der geplanten Maßnahmen und der erzielten Prozessreife. Sie benötigen nicht nur ein System zur Messung der Effizienz und Effektivität der Prozesse, sondern auch ein Messsystem für die Prozessimplementierung. Mit einem Ampelsystem können Sie die Einhaltung der Prozesse und deren Wirksamkeit in der Linie überprüfen. 240

250 6.3 Kontinuierlicher Verbesserungsprozess Wettbewerb der Prozesseinführung Für die Einführung der IT Service Management-Prozesse werden so genannte Quick-Wins benötigt. In unserer schnelllebigen Zeit akzeptiert kein Management mehr Projekte, deren erste Erfolge nach 9 Monaten eintreten. Daher müssen die Prozess Manager bei der Prozesseinführung die Quick- Wins identifizieren und darstellen. Damit kann nicht nur gegenüber dem Management ein erster ROI demonstriert werden, sondern Sie können auch die Anerkennung des Prozesses in der IT-Organisation erleichtern. Selbst mit der besten Einführungsplanung und einem optimalen Veränderungs- Management werden Sie nicht alle Mitarbeiter von den geplanten Maßnahmen überzeugen können. Mit den Quick-Wins können Sie erste Erfolge nachweisen, die die Richtigkeit des Vorhabens demonstrieren. Die Einführung wird anschließend durch eine größere Akzeptanz beschleunigt. Die ITIL Einführung benötigt eine durchgängige Kommunikationsplattform. Hier berichten die Prozess Manager dem Service Manager und dem Prozess Owner über die bereits erzielten Erfolge. Diese Erfolge können aus einer Verbesserung der Prozessreife und der damit verbundenen Änderung der Ampelfarbe bestehen, wie zum Beispiel der erreichten Dokumentation eines Prozesses. Ein Erfolg kann aber beispielsweise auch darin bestehen, dass Probleme erfolgreich behoben wurden und dadurch die Anzahl der Störungen gesenkt werden konnte. Mit der Zeit lernen die Prozess Manager, wie sie der Organisation die Wirksamkeit ihrer Prozesse darstellen können. Zum Beispiel kann der Prozess Manager Configuration Management dem Produktionsleiter demonstrieren, wie mithilfe des Configuration Managements sehr viel schneller wichtige Informationen abgerufen werden können. Dadurch, dass die Prozess Manager erste Erfolge aufzeigen, entsteht innerhalb der IT-Organisation ein Wettbewerb der Prozesseinführung. Andere Prozess Manager haben ein Interesse daran, ebenfalls Erfolge aufzuzeigen. Es entsteht eine Sogwirkung. Durch die gemeinsame Kommunikationsplattform ist die notwendige Transparenz gegeben. Zusammen mit dem kontinuierlichen Verbesserungsprozess und der damit verbundenen Planung entsteht so auch ein internes Benchmarking. 241

251 6 Lessons learned: Empfehlungen und Ratschläge Reifegradanalyse der Prozesse im laufenden Betrieb Die oben angegebenen Maßnahmen zur Bestimmung des Reifegrads dürfen nicht zu einer Behinderung des Betriebs innerhalb Ihrer IT-Organisation führen. Eine Überprüfung der IT Service Management-Prozesse, die zu früh durchgeführt wird oder zu lange dauert, führt zu einer Verunsicherung der Mitarbeiter. Wird eine Überprüfung zu früh durchgeführt, so fühlen sich Ihre Mitarbeiter in eine Position der Rechtfertigung gedrängt. Es entsteht eine Vorwurfshaltung, bis hin zu Neid und Missgunst. Es geht dann nicht mehr um die Identifizierung von Verbesserungspotenzial, sondern es werden Schuldige gesucht. Eine zu frühe bzw. zu lange Analyse hinterlässt i. d. R. verbrannte Erde. Eine Analyse der bestehenden Prozesse hat schnell und kurzfristig zu erfolgen. Sie sollten besser mit einer gewissen Ungenauigkeit leben, als mehr Genauigkeit zu fordern und damit Ihre IT-Organisation zu belasten und zu verunsichern. Speziell die Überprüfung durch eine externe Organisation vor der Einführungsphase kann zu diesen Problemen führen. In der Regel werden große Defizite zu den ITIL Best Practices identifiziert und die Mitarbeiter verbinden dies mit einer Disqualifikation ihrer Leistungen und ihres Know-how. Der Berater muss daher unbedingt als Coach auftreten. Erfahrene Berater sind in der Lage sich durch eine kurze Bestandsaufnahme einen Eindruck zu verschaffen, der für eine Planung der notwendigen Maßnahmen völlig ausreichend ist, ohne die Mitarbeiter zu verunsichern. Dies soll keinesfalls heißen, dass Sie Ihre Prozesse nicht extern überprüfen und zertifizieren lassen sollten. Achten Sie lediglich darauf, dass die Ü- berprüfung erst dann erfolgt, wenn eine reelle Chance besteht, dass die Anforderungen erfüllt werden können. Mit einer externen Zertifizierung können Sie Ihre Mitarbeiter weiter motivieren und in Ihrer IT-Organisation den Erfolg der vollzogenen Veränderungsmaßnahmen nachweisen. Die Zertifizierung nach der ISO belegt, dass auch eine externe, neutrale Organisation den Erfolg Ihrer IT Service Management-Prozesse anerkennt. Achten Sie darauf, dass der externe Berater nicht nur Unterschiede und "Nicht 100% ITIL konform" feststellt, sondern in der Lage ist, Ihren Mitarbeitern Wertschätzung zu geben und das bisher Erreichte positiv unterstreichen zu können. Die Abstimmung des IT Service Management auf die Business-Strategie sollte frühestmöglich erfolgen. Klären Sie zunächst innerhalb der IT- Organisation, welche IT Services, welche Service Level und welche Messungen realistisch zugesichert werden können. Sie vermeiden dadurch 242

252 eine falsche Erwartungshaltung bei Ihrem Kunden. Holen Sie dann unbedingt Ihren Kunden ab, erläutern Sie ihm die jetzige Situation, gehen Sie ggf. auf die Kostensituation ein und binden Sie ihn in die weitere Entwicklung ein. Think big, start small getreu diesem Motto sollte die Entwicklung von Kennzahlen erfolgen. Starten Sie zunächst die Messung Ihrer IT Service Management-Prozesse mit wenigen charakteristischen Kennzahlen und entwickeln Sie die Kennzahlen im Rahmen des KVP weiter. Verhindern Sie, dass die Prozesse nach einer gewissen Zeit einschlafen. Die Zielsetzung für das IT Service Management und die dazu gehörigen Prozesse muss aus der IT-Organisation heraus entwickelt werden. Sie ergibt sich aus der Umsetzung der IT-Strategie und der Strategie Ihres Kunden. Beachten Sie stets, dass die ITIL Best Practices nur eine Methode sind. Definieren Sie keine isolierten ITIL Ziele. Ihre Mitarbeiter müssen die IT Service Management-Prozesse verstehen, dafür benötigen sie theoretische und praktische Schulungen. Wichtig ist die Hinführung der Mitarbeiter von der ITIL-Theorie zu den für sie relevanten Prozessen in Ihrer IT-Organisation. Das Management sollte regelmäßig z. B. Kongresse als Informationsquelle nutzen, um Ihre IT-Organisation mit anderen Unternehmen vergleichen zu können und um weiteres Optimierungspotenzial zu identifizieren. 6.4 Kennzahlen 6.4 Kennzahlen Die IT Service Management-Prozesse auf der Basis der ITIL Best Practices sind fortlaufend kritisch hinsichtlich ihrer Zielerreichung und ihrer Ausrichtung auf die Geschäftsprozesse Ihres Unternehmens zu überprüfen. In diesem Kapitel stellen wir Ihnen vor, wie Sie Ihre IT Service Management-Prozesse bezüglich der Zielerreichung und der Ausrichtung auf die Geschäftsprozesse überprüfen können. Anschließend gehen wir darauf ein, wie Sie die IT Service Management-Prozesse auf Ihre IT-Strategie und Ihre Geschäftsanforderungen ausrichten können. Zum Schluss dieses Kapitels erläutern wir, warum auch nach der Einführung der Prozesse ein Transition Management weiterhin notwendig bleibt. 243

253 6 Lessons learned: Empfehlungen und Ratschläge IT-Prozesse am Tagesgeschäft ausrichten Die ITIL Best Practices und die ISO sehen Reviews zu den Prozessen und den IT Services vor und betonen die Sicherstellung der Messbarkeit von IT Service Management-Prozessen und IT Services. Dadurch soll gewährleistet werden, dass die IT Service Management-Prozesse die jeweils definierten Ziele erfüllen. Die Publikation Best Practice für Service Support hierzu (vgl. [OGC, 2005b]): Um ermitteln zu können, ob Ihre Aktivitäten einen optimalen Beitrag der vom Prozess verfolgten geschäftlichen Zielsetzung leisten, sollten Sie regelmäßig ihre Effektivität messen. Die Durchführung von Messungen ermöglicht Ihnen, das tatsächlich Erreichte mit dem Geplanten zu vergleichen sowie eine eventuell erforderliche Verbesserung zu erwägen bzw. einzuleiten. Angesichts der Komplexität und der großen Zahl von durchgeführten Aktivitäten innerhalb einer IT-Organisation kann in der Praxis nur über Kennzahlen verfolgt werden, ob die IT Service Management-Prozesse die definierten Ziele erreichen bzw. welche Entwicklungen sich in den IT Service Management-Prozessen abzeichnen. Die Prozesssteuerung von IT Service Management-Prozessen ist ohne Kennzahlen unmöglich. Sie benötigen Kennzahlen für jeden einzelnen IT Service Management-Prozess. Die Kennzahlen werden dabei zum Teil aus den operativen Systemen gewonnen, wie zum Beispiel aus den in einem Tool für das Incident Management dokumentierten Aktivitäten. Die gespeicherten Informationen werden dabei zu aussagekräftigen Kennzahlen verdichtet, mit denen die Effektivität und Effizienz der jeweiligen IT Service Management-Prozesse gemessen werden kann. Wenn Sie zum ersten Mal Ihre IT Service Management-Prozesse messen, also erste Kennzahlen gewinnen, können die Ergebnisse für das Management sehr ernüchternd sein. Einzelwerte können sogar erschreckend sein. Sehen Sie diesen ersten Eindruck als Chance für das Management. Sie können die Prozesse messen und haben dadurch die Basis für ein erfolgreiches Management der Prozesse geschaffen. Ein Nutznießer der Kennzahlen ist Ihr IT-Management, z. B. Gruppenoder Abteilungsleiter. Anhand weniger signifikanter Kennzahlen kann sich das IT-Management einen Überblick über die aktuelle Situation verschaffen. 244

254 Folgende Kennzahlen können von Interesse sein: Incidents pro Monat und Gruppe Probleme pro Monat und Gruppe Changes pro Monat und Gruppe Die Anzahl der Changes zeigt die Änderungsdynamik im Unternehmen auf und dient außerdem als Indikator für die Arbeitsbelastung der Mitarbeiter. Ein sprunghaftes Ansteigen von Incidents kann auf eine Flächenstörung hinweisen. Das Management sollte jeweils die Gründe hinterfragen und ggf. die notwendigen organisatorischen Maßnahmen veranlassen. Stellen Sie in Ihrer IT-Organisation heraus, dass die Ermittlung und Auswertung von Kennzahlen für das Management der IT Service Management-Prozesse unbedingt notwendig sind. Betonen Sie, dass die Kennzahlen nicht zur Messung und Beurteilung Ihrer Mitarbeiter dienen und auch nicht dazu genutzt werden. 6.4 Kennzahlen Wenn Sie noch über keine Messwerte zu einem Prozess verfügen, sollten Sie sich zunächst auf die wichtigsten Kennzahlen konzentrieren. Denken Sie bei der Definition der Kennzahlen an die 80/20-Regel (Pareto-Regel): Der Aufwand und das Ergebnis stehen oft in einem nicht-linearen Verhältnis. 80 % der Arbeit lässt sich mit 20 % Aufwand erledigen. Die restlichen 20% erfordern dagegen 80 % Aufwand. Wenige, der IT-Organisation nutzbringende, Kennzahlen Bei der 80/20-Regel geht es nicht nur um den Aufwand zur Definition der Kennzahl, sondern insbesondere um den Aufwand der Datengenerierung. Ihre IT-Organisation muss zunächst Erfahrungen mit dem Management von und mit Kennzahlen gewinnen. Daher sollten Sie anfangs mit einfachen Kennzahlen beginnen. Komplexere Kennzahlen z. B. wie viele Incidents werden auf Probleme referenziert? sollten erst in einer zweiten oder dritten Stufe des kontinuierlichen Verbesserungsprozesses (KVP) angewandt werden. Für das Incident Management ist es zunächst ausreichend, wenn Sie feststellen, wie viele Incidents überhaupt gemeldet und bearbeitet werden. Die Verfolgung des Trends der Incidents und die Identifizierung signifikanter Abweichungen sind für erste Analysen ausreichend. Mit den ersten Kennzahlen erhalten Sie eine Art Fieberthermometer für Ihre IT Service Management-Prozesse. Auch bei der Definition von Kennzahlen bewahrheitet sich die Erkenntnis Weniger ist oft mehr. Wenn noch keine Messwerte vorliegen, sollten Sie sich zunächst auf wenige signifikante Kennzahlen konzentrieren. 245

255 6 Lessons learned: Empfehlungen und Ratschläge Schrittweise Erweiterung der Kennzahlen Die Anforderungen hinsichtlich der Messbarkeit von Prozessen werden von Prozess Managern oft überinterpretiert. Der Konzeptphase folgt dann häufig ein Erschrecken über den Umfang der definierten Kennzahlen und als (vermeintliche) Lösung der Ruf nach einer Tool-Unterstützung. Werden die definierten Kennzahlen schließlich mit Daten hinterlegt, wird oft klar, dass lediglich 10% der Kennzahlen nutzbringend sind. Dieses Vorgehen rührt z. T. auch aus einer unkritischen Nutzung von Publikationen. In den ITIL Best Practices finden Sie zwar beispielhaft einige Kennzahlen. Aber Sie sollten die dargestellten Kennzahlen nicht komplett und ungeprüft übernehmen. Um Ihre Kennzahlen zu definieren, müssen Sie sich fragen, welche Kennzahlen sich aus Ihrer IT-Strategie ableiten und welche Kennzahlen von Ihrer Linienorganisation benötigt werden. Das heißt, welche Kennzahlen unterstützen Ihr Tagesgeschäft? Eine große Hilfestellung bei der Definition von Kennzahlen für die Linienorganisation kann der Prozess Owner geben. Aufgrund der Anforderungen und seinen Erfahrungen aus dem Tagesgeschäft ist der Prozess Owner der ideale Partner, um die notwendigen Kennzahlen zu diskutieren und zu definieren. Interessante Kennzahlen für den Beginn eines Kennzahlenmonitorings können sein: Anzahl der ausgefertigten und abgeschlossenen SLAs mit Ihren Kunden in Bezug auf den Servicelevelprozess Anzahl der Notfall / BCM Übungen pro Jahr in Bezug auf das IT Service Continuity Management Anzahl der vorhandenen Assets pro Gruppe (Windows, Unix, Host etc.) in Bezug auf das Configuration Management. Anzahl der Ausfälle > 120 min pro Applikation und Monat in Bezug auf das Availability Management Verwendete Kennzahlen müssen für das Management prägnant und beeinflussbar sein. Kann ein Linien-Manager die Kennzahlen nicht sinnvoll nutzen, so findet ITIL beim Management keine Anerkennung! Im Rahmen der schrittweisen Weiterentwicklung Ihrer IT Service Management-Prozesse können Sie ggf. auf einzelne Kennzahlen verzichten oder Kennzahlen ergänzen. Haben Sie zum Beispiel im Incident Management mit der Kennzahl Anzahl Incidents insgesamt begonnen, so können Sie dann die Incidents auf einzelne Kunden, IT Services oder IT-Systeme gruppieren. 246

256 Im Rahmen dieser schrittweisen Erweiterung können Sie dann auch auf Best Practices wie ITIL oder COBIT zurückgreifen. Prüfen Sie die dort dokumentierten Kennzahlen auf sinnvolle Nutzung in Ihrer IT-Organisation, und übernehmen Sie sie nur bei einer positiven Bewertung. Wollen Sie eine Revision Ihrer IT Service Management-Prozesse auf der Basis von COBIT sicherzustellen, so sollten Sie die Umsetzung dieser Anforderung als Stufe Ihres KVP planen und nicht zu Beginn des Prozesses integrieren. Im weiteren Reifegrad der ITIL Einführung können folgende Kennzahlen signifikanter werden: Anzahl der Changes mit Auswirkungen auf die Availability, somit die Referenz von Changes zu Incidents. Anzahl der Incidents die auf ein Problem referenzieren, somit die Übersicht darüber, wie viele Maßnahmen im Problem Management aktuell betrachtet werden. Anzahl der Service Level Agreements in verschiedenen monetären Volumen (z. B. < Euro; < Euro) und damit eine Gruppierung nach A,B,C Kunden. 6.4 Kennzahlen ITIL abgestimmt auf die Business- und IT-Strategie Charakteristisch für IT Service Management-Prozesse auf der Basis der ITIL Best Practices ist ihre Ausrichtung auf die Geschäftsprozesse Ihres (internen oder externen) Kunden. Hierzu heißt es in Best Practice für Service Support (vgl. [OGC, 2005b]): ITIL richtet den Fokus auf die Bereitstellung qualitativ hochwertiger Services und unterstreicht insbesondere die Bedeutung von Kundenbeziehungen. Dies bedeutet, dass die IT-Organisation bereitstellen sollte, was immer mit dem Kunden vereinbart wurde, was wiederum eine enge Beziehung zwischen der IT-Organisation und deren Kunden und Partnern voraussetzt. Planen Sie die Einführung von kundennahen IT Service Management- Prozessen (z. B. Service Level Management oder Financial Management for IT Services), sollten Sie vorab die Erwartungshaltung des Kunden in Erfahrung bringen. Sie müssen die Erwartungshaltung Ihres Kunden verstehen, um auf dieser Basis die Machbarkeit innerhalb der IT-Organisation zu prüfen und mit den möglichen Anforderungen abzugleichen. Im Idealfall sollten Sie in der Lage sein, sämtliche Kundenanforderungen an einen IT Service dort zu messen, wo der Kunde bzw. Anwender den IT Den Kunden rechtzeitig einbinden. 247

257 6 Lessons learned: Empfehlungen und Ratschläge Service wahrnimmt. Dies ist in der Regel der Arbeitsplatz, und dieser Ansatz führt damit zu einer end-to-end Messung des IT Service. Diese end-to-end Messungen können jedoch zurzeit in vielen Unternehmen noch nicht durchgeführt werden, da die notwendigen Werkzeuge fehlen. Die Implementierung dieser Werkzeuge ist in der Regel in Abhängigkeit von den betrachteten IT Services und der genutzten IT-Infrastruktur mit nicht unerheblichen Investitionen verbunden. Eine kunden- bzw. serviceorientierte Messung und ein entsprechendes Reporting, die Realisierung einer end-to-end Messung, sollte zumindest mittel- bis langfristig Ihr Ziel sein. Da dieses Ziel häufig nicht kurzfristig erreichbar ist, sollten Sie gemeinsam mit dem Kunden machbare Lösungen definieren. Prüfen Sie zunächst, was zurzeit an Messungen und damit an verbindlichen Vereinbarungen überhaupt technisch darstellbar ist, statt im Vorfeld die Anforderungen des Kunden unstrukturiert einzufordern. Erst dann sollten Sie konkrete Vereinbarungen mit dem Kunden treffen. Der Prozess Manager sollte dies gemeinsam mit dem für den Kunden verantwortlichen Personenkreis durchführen. Je nach IT-Organisation kann dies mit dem Relationship Management, dem Key-Account-Manager oder dem Kunden- Service Manager erfolgen. Oft wird diese Vorprüfung möglicher Service Level gemeinsam mit dem Kundenservicemanager und dem Relationship- Manager, der den Kunden strategisch verantwortet, vorgenommen. Die innerhalb Ihrer IT-Organisation bestehenden Möglichkeiten zur Definition von Service Level und deren Messung sollten Sie dann gemeinsam Ihrem Kunden erläutern. Es besteht ansonsten die Gefahr, dass der Kunde einige von Ihnen nicht umsetzbare Anforderungen definiert, was in der Folge zu (vermeidbarer) Unzufriedenheit und Enttäuschung bei Ihrem Kunden führen würde. Gehen Sie daher mit einem ersten Vorschlag was zurzeit technisch machbar ist auf den Kunden zu. Ist dieser Vorschlag dem Kunden nicht ausreichend, so seien Sie offen für die Anforderungen Ihres Kunden. Zeigen Sie dem Kunden aber auch die damit für ihn ggf. verbundenen finanziellen Auswirkungen auf. In unserem Beispiel konnte durch die so erfolgte Abstimmung zwischen notwendigen Anforderungen aus Kundensicht und der technischen Machbarkeit innerhalb der IT-Organisation ein sinnvoller Kompromiss gefunden werden. Bei diesem Abstimmungsprozess muss der Prozess Manager selbstverständlich über die notwendige Verantwortung und Kompetenz für seinen Prozess verfügen. Er benötigt aber auch die Unterstützung des gesamten Managements, wie zum Beispiel des Key-Account-Managements. 248

258 6.4 Kennzahlen Sie sollten die IT Service Management-Prozesse schrittweise einführen. Dies betrifft sowohl die Anzahl der einzuführenden Prozesse, als auch den stufenweisen Ausbau (KVP). Dieses schrittweise Vorgehen bedingt eine Priorisierung der Einführung durch das Management. Ein Aspekt ist dabei der so genannte Pain-Faktor. Gibt es innerhalb Ihrer IT-Organisation in bestimmten Bereichen besonderen Handlungsdruck, so empfiehlt sich eine Priorisierung derjenigen IT Service Management-Prozesse, die hier Abhilfe schaffen können. Stellen Sie zum Beispiel fest, dass durchgeführte Änderungen häufig zu Betriebsstörungen geführt haben, so sollte der Change Management-Prozess priorisiert eingeführt werden. Ein weiterer wichtiger Aspekt für die Priorisierung von IT Service Management-Prozessen ist das Wissen um die Geschäftsstrategie Ihres Kunden. Sie müssen diese Strategie verstehen, um zu entscheiden, wie Sie ihre Prozessentfaltung vorantreiben, wie Sie die stufenweise Einführung und den Ausbau der IT Service Management-Prozesse planen. Befindet sich Ihr Unternehmen bzw. Ihr Kunde in einer Wachstumsphase, so würde sich die Priorisierung der Planungsprozesse (Service Delivery) und des Release Managements empfehlen. Denn damit stellen Sie sicher, dass die notwendigen Kapazitäten rechtzeitig bereitgestellt werden können und die Geschäftsprozesse nicht durch fehlende IT-Kapazitäten in Mitleidenschaft gezogen werden. Betreibt Ihr Unternehmen dagegen eine Kostendämpfungsstrategie, so bietet sich eine Konzentration auf das Problem und Change Management an. Durch das Problem Management identifizieren Sie die Ursachen von Störungen und können die Qualität der IT Services steigern. Die Anzahl von Störungen und Geschäftsausfällen wird abnehmen und Sie leisten einen Beitrag zur Kosteneinsparung. Betrachten Sie die Gründe für IT- Störungen, so werden Sie unter Umständen feststellen, dass die Ursachen häufig in fehlerhaften Änderungen (Changes) liegen. Durch einen Change Management-Prozess steigern Sie nicht nur die Qualität, sondern reduzieren Aufwände für Folge-Maßnahmen und tragen so mit dem Change Management zu einer weiteren Kosteneinsparung bei. Die Strategie des Kunden verstehen So wie die Geschäftsstrategie Ihres Kunden in die IT-Strategie einfließt, so beeinflusst die Geschäftsstrategie auch die Einführungsplanung Ihrer IT Service Management-Prozesse. Auch wenn Sie über erste Kennziffern verfügen, sollten Sie ihrem Kunden keine technischen Kennziffern berichten. 249

259 6 Lessons learned: Empfehlungen und Ratschläge Das Reporting der Kennzahlen muss kundenorientiert erfolgen Grundsätzlich besteht Ihre Verantwortung darin, Ihrem Kunden die vereinbarten Service Level zu berichten. Manchmal bewährt sich die Maxime, dieses Reporting in einer Sprache und Darstellung vorzunehmen, die der Kunde versteht, also in der Sprache des Kunden, nicht in der Sprache des Technikers. Statt zum Beispiel dem Kunden über die Anzahl von Incidents zu berichten, wird dargestellt, was für Folgen die wichtigsten Störungen hatten, welche Konsequenzen zum Beispiel ein Ausfall einzelner Standorte hatte und welche Verbesserungsmaßnahmen innerhalb der IT ergriffen wurden, um diese Ausfälle in Zukunft zu vermeiden. Speziell die Darstellung eingeleiteter Verbesserungsmaßnahmen ist für den Kunden von großer Bedeutung. Der Kunde ist zwar auch an der Historie interessiert, aber viel wichtiger ist ihm, dass die IT Verbesserungsmaßnahmen ergreift und die Ausfälle in Zukunft vermieden werden können. Als signifikanter Report reicht aus, dem Kunden einmal im Monat eine kleinere Powerpoint-Präsentation zur Verfügung zu stellen, die vor allem auf die Availability- und Performancekennzahlen eingeht also das, was der Kunde direkt über die IT wahrnimmt. Zum Beispiel könnte der Report folgende Informationen enthalten: Im Monat März hatten wir am eine Störung in der Anwendung (xyz). Diese Störung wurde hervorgerufen durch einen Netzwerk-Change, der im Wechsel einer technischen Komponente zu einem Ausfall von 6.00 Uhr 7.30 Uhr führte. Um dies zukünftig zu vermeiden, haben wir unseren Servicepartner angewiesen, eine weitere redundante Komponente im Falle eines Hardwarewechsels vor Ort verfügbar zu haben, um damit schneller eine Reparatur zu ermöglichen. Berichte zu den geleisteten IT Services und den Kennzahlen aus den IT Service Management-Prozessen müssen aus der Sicht und in der Sprache des Kunden erfolgen ITIL Refresh oder wie geht es weiter? Nachdem Sie auf Basis der ITIL Best Practices Ihre IT Service Management-Prozesse gestaltet und eingeführt haben, bedarf es eines regelmäßigen Refresh. Dieser Refresh betrifft alle Beteiligten Ihrer IT-Organisation mit unterschiedlichen Ausprägungen und Inhalten. In diesem Abschnitt stellen wir die wichtigsten Aspekte gruppiert nach den beteiligten Bereichen vor. 250

260 6.4 Kennzahlen Falls Sie eine Zertifizierung Ihrer IT Service Management-Prozesse durchführen, wird von der Zertifizierungsorganisation auch geprüft, ob eine Aus- und Weiterbildungsplanung existiert und mögliche Defizite werden aufgezeigt. Das Top-Management, der Service Manager, die Prozess Owner und die Prozess Manager sollen beobachten, wie sich die Umsetzung der ITIL Best Practices im Unternehmen weiterentwickelt. Hierbei ist auch relevant, wie sich vergleichbare andere IT-Organisationen weiter entwickeln und wie sich diese Weiterentwicklung in Bezug auf Ihre Organisation darstellt. Die dokumentierten ITIL Best Practices unterliegen zwar einer stetigen Weiterentwicklung, aber diese geht erst mit einem Zeitverzug in die offiziellen Publikationen ein. Auf Kongressen, wie dem ITIL Forum oder dem Jahreskongress der itsmf Deutschland e.v., wird aktuell über Erfahrungen mit der Umsetzung der ITIL Best Practices und über in Unternehmen vollzogene Ausgestaltungen und Erweiterungen berichtet. Auf diesen Kongressen können Sie nicht nur aufnehmen, wo Ihre IT- Organisation in Bezug auf andere IT-Organisationen steht. Sie können Ideen aufnehmen und prüfen, ob diese Ideen auch für Ihre IT-Organisation eine Innovation darstellen und einen Mehrwert generieren können. Insbesondere für den Service Manager, den Prozess Owner und den Prozess Manager stellt dieser Informationsprozess eine wichtige Aufgabe dar. Das Management hat die Weiterentwicklung zur Aufgabe Es ist sehr wichtig, dass Sie sich mit den erreichten Maßnahmen nicht zufrieden geben. Sie müssen die Weiterentwicklung von ITIL und von anderen IT- Organisationen beobachten, andere Ansätze prüfen und mehrwertschaffende- Konzepte adaptieren. In der Ebene der Mitarbeiter ist es von großer Bedeutung, dass neue Mitarbeiter über ITIL Know-how verfügen bzw. entsprechend geschult werden. Diese Schulung sollte in drei Teilen erfolgen: Die Mitarbeiter benötigen zunächst einen Gesamtüberblick über die Ziele des IT Service Managements sowie aller Prozesse. Ansonsten werden die Mitarbeiter den Nutzen von ITIL nicht verstehen. Es empfiehlt sich diese Schulungen extern wahrnehmen zu lassen. Gegebenenfalls könnte dies auch von einem Service Manager mit entsprechender Schulungserfahrung übernommen werden. Sind die theoretischen Aspekte bekannt, so sollten die Prozess Manager die Mitarbeiter in denjenigen Prozessen schulen, in denen diese eingebunden sind. Hierbei wird insbesondere geschult, wie die jeweiligen Prozesse innerhalb der jeweiligen Organisation des Unternehmens ihre Anwendung finden (von der Theorie zur Praxis). Mitarbeiter müssen geschult werden 251

261 6 Lessons learned: Empfehlungen und Ratschläge Sind die IT Service Management-Prozesse auf Basis der ITIL Best Practices eingeführt, so ist unbedingt darauf zu achten, dass es regelmäßige Nachschulungen für die geschulten Mitarbeiter gibt (Wissen erhalten und erweitern) und neue Mitarbeiter ebenfalls die Stufen des aufgesetzten ITIL Schulungsprozesses durchlaufen. Ein erfolgreiches IT Service Management bedingt, dass Ihre Mitarbeiter die Prozesse kennen und verstehen. Sie müssen sicherstellen, dass dieses Verständnis auch bei neuen Mitarbeitern ausreichend gegeben ist. Der Prozess Manager sorgt dafür, dass Prozesse gelebt werden Sie werden wahrscheinlich feststellen müssen, dass die Prozesse nach der Implementierung und längerem Betrieb auf Mitarbeiter-Ebene einschlafen. Der bei der Einführung vorhandene Elan geht im Laufe der Zeit verloren. Die Aktivitäten erstarren in Routine. Dem Prozess Manager kommt hier eine weitere wichtige Aufgabe zu. Der Prozess Manager muss Maßnahmen entwickeln, die ein Einschleifen der Prozesse verhindern. Hierzu können bestimmte Prozesse, wie das Change Management, angepasst werden. Der Prozess Manager muss einen Prozess aktiv halten und das Einschlafen verhindern. Besondere Aufmerksamkeit benötigen bereits länger eingeführte Prozesse. Zerschlagen Sie nicht unnötig erfolgreiche Prozesse. Drücken Sie vielmehr ihre Wertschätzung aus und motivieren Sie ihre Mitarbeiter, diese Prozesse in Richtung der ITIL Best Practices weiter zu entwickeln. Nutzen Sie so die vorhandene Erfahrung. Stellen Sie sicher, dass die Prozesse innerhalb der Phasen gleichmäßig entwickelt werden (vertikale gleichmäßige Entfaltung) und dass sie vernetzt werden. Vermeiden Sie ein unkontrolliertes Davoneilen einzelner Prozesse. Diese Entwicklungen zu kontrollieren und zu steuern ist Aufgabe des Service Managers. Zeigen Sie die Erfolge der eingeführten Prozesse unbedingt auf. Lassen Sie Ihre Mitarbeiter die erzielten Verbesserungen im täglichen Betrieb spüren. Damit erhalten und steigern Sie die Motivation. Um dies möglich zu machen, sollten Sie Ruhe- und Stabilitätsphasen in der Entwicklung der Prozesse einplanen. Ansonsten können in einem permanenten Veränderungsprozess die Erfolge nicht mehr spürbar gemacht werden. Darüber hinaus fördert das Aufzeigen von Erfolgen in einem Prozess den Wettbewerb unter den Prozess Managern. Der Service Manager benötigt ein System zur Messung und Verfolgung der Prozess-Fortschritte. Im Beispiel hat sich hierzu ein Ampelsystem be- 252

262 6.4 Kennzahlen währt. Damit werden auch für die Prozess Manager die erzielten Erfolge sichtbar. Die IT Service Management-Prozesse haben eine eindeutige Ausrichtung auf die Geschäftsprozesse Ihres Kunden und müssen daher Bestandteil Ihrer IT-Strategie sein. Diese Anforderung bedeutet nicht nur, dass die IT Service Management- Prozesse aufgrund Ihrer IT-Strategie eingeführt werden, sondern auch, dass sich deren Ziele stets aus der IT-Strategie ableiten. Logische Konsequenz hieraus ist, dass sich auch die Kennzahlen und deren Soll-Werte aus der IT-Strategie ergeben. Um alle Bereiche auf die IT-Strategie auszurichten, sollten sie anfänglich eine einfache Balanced Scorecard (BSC) nutzen. Dazu werden aus den übergeordneten strategischen Betrachtungen konkrete Maßnahmen und Leistungen in den IT Service Management-Prozessen identifiziert und mit entsprechenden Kennzahlen hinterlegt. Die Ziele und Zielwerte (Soll-Werte) der IT Service Management-Prozesse leiten sich aus der IT-Strategie ab. Durch die Verknüpfung der Balanced Scorecard mit den Kennzahlen der jeweiligen IT Service Management- Prozesse etablieren Sie ein durchgängiges Controlling-System. Die Balanced Scorecard ermöglicht die Ausrichtung auf die IT- Strategie Vermeiden Sie den Aufbau eines zweiten, isolierten Kennzahlensystems für Ihre IT Service Management-Prozesse. Service Manager, Prozess Manager und Prozess Owner In den vorhergehenden Kapiteln wurde bereits auf die Rolle des Service Managers, des Prozess Managers und des Prozess Owners eingegangen. An dieser Stelle sei angemerkt, dass die Aufgabenzuordnungen zu den Rollen des Prozess Owners und des Prozess Managers von den Rollenbeschreibungen in der Literatur abweichen können. Oft können Prozess Owner und Prozess Manager organisatorisch über Kreuz besetzt werden dass heißt, der Prozess Owner kommt aus einem anderen Bereich als der Prozess Manager und so kann die Vernetzung innerhalb der IT-Organisation gestärkt werden. Bestehende Abteilungsgrenzen können erfolgreich überbrückt werden. Voraussetzung hierfür ist die Stärkung der Rolle des Prozess Managers, ansonsten dominiert der Prozess Owner allein aufgrund der hierarchischen Stellung den Prozess Manager. 253

263 6 Lessons learned: Empfehlungen und Ratschläge Service Manager In den ITIL Best Practices finden sich zwar an einigen Stellen Hinweise zum Service Manager, aber eine durchgängige Beschreibung dieser Rolle ist in ITIL nicht zu finden. Dabei ist diese Rolle für ein IT Service Management von existenzieller Bedeutung und damit auch die organisatorische Verankerung dieser Rolle. Die IT Service Management-Prozesse sollen sicherstellen, dass die IT Services auf die Geschäftsprozesse des Kunden ausgerichtet sind und deren Anforderungen optimal unterstützen. Daher bieten sich zwei Bereiche an, denen die Rolle des Service Manager organisatorisch zugeordnet werden kann. Zunächst wäre die Kundenschnittstelle der IT-Organisation zu nennen. Damit wird sichergestellt, dass die geforderte Ausrichtung der IT Service Management-Prozesse auf die Kundenanforderungen gewährleistet ist. Alternativ bietet sich eine Stabstelle zur IT-Geschäftsführung an. Hierfür sprechen die dann kurzen Wege zur Geschäftsführung und die enge Verknüpfung mit der IT-Strategie. Sie müssen für Ihre IT-Organisation entscheiden, welche Zuordnung für Ihren Bereich zweckmäßig ist. Der Service Manager muss unbedingt über eine langjährige Erfahrung im Bereich des IT Service Managements und mit dem Management von IT- Organisationen verfügen. Häufig ist der Service Manager im Bereich der Kundenschnittstelle angesiedelt und stimmt seine Planungen und Maßnahmen mit dem Board der Prozess Owner ab. Prozess Manager Der Prozess Manager sollte aus der Linienfunktion besetzt werden, in der wesentliche Prozessaktivitäten durchgeführt werden. Der Prozess Manager sollte weiterhin in der Linienorganisation angesiedelt bleiben und nicht herausgelöst werden, da ansonsten der Tagesbezug verloren geht. So ist zum Beispiel der Change Manager des Rechenzentrums innerhalb der Produktion angesiedelt. So ist sichergestellt, dass der Change Manager unmittelbar erfährt, wie erfolgreich die Implementierungen von Changes sind bzw. welche Auswirkungen auftreten. Damit ergibt sich auch die Anforderung, dass der Prozess Manager aus dem Bereich besetzt werden sollte, der über die meisten Erfahrungen mit dem jeweiligen Prozess verfügt. 254

264 Prozess Owner Innerhalb des RZs hat es sich als vorteilhaft erwiesen, die Rolle des Prozess Owners rotieren zu lassen. Durch die wechselnden Prozess Owner wird der Blickwinkel des Prozess Managers im Laufe der Zeit erweitert. Wenn möglich, wird die Rolle des Prozess Owners aus dem Bereich besetzt, der die größten Auswirkungen des Prozesses erfährt. So kommt zum Beispiel der Prozess Owner für das Change Management nicht aus der Produktion, sondern aus dem Kunden-Management, da dort die Auswirkungen der Changes unmittelbar zu spüren sind. Die Prozess Owner werden aus einer Hierarchieebene besetzt, die gegenüber der IT-Organisation weisungsbefugt ist. Innerhalb des Rechenzentrums unseres Beispiels sind die Prozess Owner Bereichs- und Abteilungsleiter, die direkt der Geschäftsführung berichten. IT im Wandel und wie unterstützt ITIL Ein ständiger Abgleich Ihrer IT Service Management-Prozesse mit der Business- und der IT-Strategie ist unumgänglich. Sie müssen diese Strategien nicht nur während der Einführung berücksichtigen, sondern auch während der gesamten Prozessphase. Wurden die IT Service Management-Prozesse beispielsweise während einer Wachstumsphase eingeführt, dürfte die spezifische Ausrichtung des Capacity Managements darin bestehen, zukünftige Erweiterungen der IT- Infrastruktur rechtzeitig einzuplanen, um das Wachstum der Organisation zu unterstützen. In einer Schrumpfungsphase wird das Hauptaugenmerk des Prozess Managers Capacity Management dagegen auf einer möglichst großen Auslastung bestehender Systeme bzw. auf der Reduzierung bestehender Systeme liegen, um so die notwendige Kostenreduzierung sicherzustellen. Die grundsätzlichen Ziele der IT Service Management-Prozesse bleiben bestehen, aber die konkrete Ausgestaltung und die Schwerpunkte sind stets aus der Business- und IT-Strategie abzuleiten. Die in den ITIL Best Practices dokumentierten Aktivitäten sind Empfehlungen, die Sie in Ihre IT-Organisation sinnvoll übertragen müssen. Damit sind diese Aktivitäten aber nicht für alle Zukunft festgeschrieben. Mit einer veränderten Business- und IT-Strategie können sich die Schwerpunkte und damit die Aktivitäten innerhalb der IT Service Management- Prozesse ändern. Ihre IT Service Management-Prozesse unterliegen damit einem stetigen Wandel. Beispiel: Hat ein Change Manager eine Vorlaufzeit von fünf Tagen für den RFC festgelegt, so muss dieser Ansatz unter Umständen modifiziert wer- 6.4 Kennzahlen 255

265 6 Lessons learned: Empfehlungen und Ratschläge den, wenn sich die Organisation in einer sehr starken Wachstumsphase befindet. Logische Konsequenz ist, dass die Business- und IT-Strategie einen Input für den kontinuierlichen Verbesserungsprozess der IT Service Management-Prozesse sind. Der Prozess Owner ist die Person, die diesen Input sicherstellt. Der Prozess Owner erfährt aufgrund seiner hierarchischen Stellung frühzeitig von Veränderungen in der Business- oder IT-Strategie. Er muss als Coach unter Einbeziehung des Service Managers den Prozess Manager auf die veränderten Rahmenbedingungen aufmerksam machen. Aufgabe des Prozess Managers ist es dann, notwendige Maßnahmen abzuleiten, sie mit dem Prozess Owner und dem Service Manager abzustimmen und schließlich im Prozess umzusetzen. Für die organisatorische Einbindung der IT Service Management-Prozesse ist die Besetzung des Prozess Managers von großer Bedeutung. Der Prozess Manager sollte aus der Linien-Organisation stammen und auch dort verbleiben. Als Bereich ist die Organisationseinheit zu wählen, in der die wesentlichen Aktivitäten des Prozesses stattfinden. Das Überkreuzen von Prozess Manager und Prozess Owner hat sich sehr bewährt. Dadurch konnte unter anderem eine bessere Vernetzung in der IT-Organisation erzielt werden. Ein wichtiger Nebeneffekt ist, dass der Prozess nicht durch Bereichsdenken geprägt wird. Diese Gefahr besteht, wenn Prozess Owner und Prozess Manager aus dem gleichen Bereich kommen. Die Rotation der Prozess Owner erweitert den Horizont der Prozess Manager. Sehr oft kommt dem Prozess Owner die Rolle eines Coaches zu. 256

266 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 Firmenportrait Nycomed ist ein internationales pharmazeutisches Unternehmen, das Arzneimittel für Krankenhäuser, Fachärzte und Allgemeinmediziner anbietet. Darüber hinaus versorgt das Unternehmen Patienten in ausgewählten Märkten mit OTC-Medikamenten. Nycomed arbeitet in einer Reihe von Therapiegebieten wie Kardiologie, Gastroenterologie, Osteoporose, Atemwegserkrankungen, Schmerztherapie und Gewebemanagement. Neue Produkte entstehen sowohl in der eigenen Forschung als auch in der Zusammenarbeit mit externen Partnern. Nycomed ist in etwa 50 Märkten weltweit präsent und engagiert sich in ganz Europa sowie in wachstumsstarken Märkten wie Lateinamerika, Russland/GUS und der asiatisch-pazifischen Region. Der im Privatbesitz befindliche Konzern verzeichnete 2006 einen Jahresumsatz von ca. 3,4 Milliarden sowie ein bereinigtes EBITDA von 933,4 Millionen. Weitere Informationen finden Sie unter Ausgangslage Die IT der ALTANA Pharma hatte sich 2004 das Ziel gesetzt, sich vom IT Service Provider zum innovativen Business Enabler zu wandeln. Um dieses Ziel zu unterstützen und die angebotenen Services und Lösungen an den sich ändernden Geschäftsanforderungen und der globalen IT-Strategie des Unternehmens auszurichten, wurde das Betriebsmodell der IT an IS Lite von Gartner ausgerichtet. 257