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

Transkript

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

2 Ralf Buchsein Frank Victor Holger Günther Volker Machmeier IT-Management mit ITIL V3 Strategien, Kennzahlen, Umsetzung 2., aktualisierte und erweiterte Auflage Mit 93 Abbildungen PRAXIS

3 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über < abrufbar. Das in diesem Werk enthaltene Programm-Material ist mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Der Autor übernimmt infolgedessen keine Verantwortung und wird keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programm-Materials oder Teilen davon entsteht. Höchste inhaltliche und technische Qualität unserer Produkte ist unser Ziel. Bei der Produktion und Auslieferung unserer Bücher wollen wir die Umwelt schonen: Dieses Buch ist auf säurefreiem und chlorfrei gebleichtem Papier gedruckt. Die Einschweißfolie besteht aus Polyäthylen und damit aus organischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffe freisetzen. 1. Auflage , aktualisierte und erweiterte Auflage 2008 Alle Rechte vorbehalten Vieweg+Teubner GWV Fachverlage GmbH, Wiesbaden 2008 Lektorat: Sybille Thelen Andrea Broßler Vieweg+Teubner ist Teil der Fachverlagsgruppe Springer Science+Business Media. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Druck und buchbinderische Verarbeitung: Wilhelm & Adam, Heusenstamm Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier. Printed in Germany ISBN

4 Vorwort zur 1. Auflage ITIL als Basis für eine neue Sicht auf die IT hat sich in den letzten Jahren in deutschen Unternehmen rasant verbreitet, und das mit anhaltendem Erfolg. Der Grund liegt darin, dass ITIL in der Version 2 gut verständlich ist und so die Grundideen des IT Service Managements leicht transportierbar sind. Seit Juni 2007 ist nun ITIL in der Version 3 am Markt verfügbar. Es scheint so, als sehe nun vieles anders aus als in Version 2, da das Gesamtwerk völlig neu strukturiert worden ist und neue Inhalte hinzugekommen sind. Wir haben für Sie die ersten Erfahrungen gemacht und sind überzeugt, dass die ITIL Version 3 keineswegs komplizierter ist als ITIL Version 2, dafür aber in wesentlichen Aspekten genauer und im Gesamtbild viel integrativer. Unser Buch gibt Antworten auf zwei Fragen, die in der Praxis für den Erfolg einer modernen IT entscheidend sind: Welche Kennzahlen und Kennzahlensysteme sollte man in der IT einsetzen? Welche Strategien sind zur Umsetzung und Steuerung von IT Service Management-Prozessen geeignet? Sie werden sich vielleicht fragen, wieso wir gerade diese beiden Themen in einem Buch behandeln. Die Antwort ist: Das sind die Themen, die aktuell in der Praxis relevant sind und Hunderte von Unternehmen nicht nur in Deutschland beschäftigen. Das Erstaunliche ist, dass die beiden Themen eng zusammenhängen und sich gegenseitig beeinflussen. Das Erfreuliche ist, dass mit ITIL V3, COBIT 4 und ISO 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

5 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

6 Vorwort zur 2. Auflage Im September 2007 ist unser Buch IT-Management mit ITIL V3 in der ersten Auflage erschienen. Seitdem hat sich viel getan. Die itsmf Deutschland e.v. hat mittlerweile das deutsche Glossar zu ITIL V3 herausgegeben und wir haben im letzten halben Jahr viele hilfreiche Diskussionen mit unserer werten Leserschaft geführt, deren Anmerkungen aufgegriffen und umgesetzt. Die vorliegende zweite Auflage unseres Buches ist eine gründliche Überarbeitung der ersten. Wir haben die deutschen Fachbegriffe auf die des offiziellen ITIL V3-Glossars angepasst, und wir sind dem Wunsch vieler Leserinnen und Leser nachgekommen, die Inhalte zu ITIL V3 neu zu strukturieren und zu vertiefen. Die Zielsetzung ist dabei gleich geblieben: ITIL V3 steht im Mittelpunkt. Darum ranken sich eine Reihe von praxisrelevanten Themen, wie IT-Management-Strategien, Kennzahlensysteme, Zertifizierungen, Balanced Scorecards und Reporting. ITIL V3 wird in einem Detaillierungslevel dargestellt, so dass die Kernideen und die Einordnung in die Gesamtzusammenhänge deutlich werden. Das Buch wendet sich damit an Praktiker und IT-Entscheider und ist weniger als Lehrbuch zu ITIL V3 gedacht. Es geht um Grundlagen, Ideen, IT- Management, Umsetzung und Erfahrungen aus der Praxis für die Praxis. An dieser Stelle möchten wir uns auch im Namen des Vieweg+Teubner Verlages ganz herzlich bei Ihnen, den Leserinnen und Lesern der ersten Auflage, für die guten Hinweise bedanken, die wir hoffentlich geeignet umgesetzt haben. Mai 2008 Ralf Buchsein, Frank Victor, Holger Günther und Volker Machmeier VII

7 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 Prozesse und 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 IX

8 Inhaltsverzeichnis Metriken für IT Service Management-Prozesse COBIT Metriken für IT Service Management-Prozesse 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 X

9 Inhaltsverzeichnis 4.3 Überblick SVD 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 XI

10 Inhaltsverzeichnis IT-Prozesse am Tagesgeschäft ausrichten ITIL abgestimmt auf Business- und IT-Strategie 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 Glossar Sachwortverzeichnis XII

11 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

12 1 Einführung und Überblick top down- Verfahren zur Entwicklung von IT- Kennzahlensystemen. 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. 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

13 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

14 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

15 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

16 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

17 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

18 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 und Service Delivery hierzu insgesamt zehn erforderliche IT-Prozesse dokumentiert. Zusätzlich ist der Prozess Security Management in einem eigenen Dokument beschrieben. Gemäß ITIL ist ein Prozess eine zusammenhängende Folge von Aktivitäten mit dem Ziel, einen gegebenen Input in einen definierten Output zu transformieren. Der Output eines Prozesses muss aus der geschäftlichen Zielsetzung abgeleitet werden und kann Input für einen anderen Prozess darstellen. So nimmt zum Beispiel der Prozess des Capacity Managements in enger Zusammenarbeit mit dem Service Level Management (SLM) die Kundenanforderungen an einen IT Service auf. Insofern ist das SLM der Anfang des ITIL-Prozessmodells und steht in enger Verbindung mit dem Kunden. Die Anforderungen bezüglich der Verfügbarkeit sind der Input für das Availability Management zur Planung und Überprüfung der IT-Verfügbar- 8

19 2.3 Die Struktur gemäß ITIL Version 2 keit. Jeder IT Service Management-Prozess hat eine charakteristische Zielrichtung und trägt im Zusammenwirken mit den anderen IT Service Management-Prozessen dazu bei, dass dem Kunden die notwendigen IT Services zur wirkungsvollen Unterstützung seiner Geschäftsprozesse geliefert werden. Die ITIL Best Practices beinhalten Prozessbeschreibungen mit wechselseitigen Aktivitäten. Service Level Management Continuity Management Service Delivery Financial Management 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 folgendermaßen definiert: Prozessteuerung: Der Prozess der Planung und Regelung; mit dem Ziel, einen Prozess in einer effektiven und effizienten Weise durchzuführen. 9

20 2 IT Service Management Hierzu sind in einem generischen Prozessmodell die wichtigsten Aufgaben beschrieben (siehe Abbildung 3, aus Best Practice Einführung in ITIL, [OGC, 2005a]). 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 Process Owner gibt die Prozessziele vor und kann anhand der KPIs die Erreichung der Ziele feststellen. Auf Basis der vom Process Owner vorgegebenen Prozessziele gilt es, die notwendigen Aktivitäten und Subprozesse der jeweiligen IT Service Management-Prozesse zu designen und zu implementieren. Angesichts der Komplexität der Prozessdurchführung in IT-Organisationen muss eine formelle Überprüfung der Zielerreichung sichergestellt werden. Dazu dienen die definierten Qualitätsparameter und Leistungsindikatoren (Key Performance Indicators, KPIs). Zielsetzung von ITIL war die Beschreibung von (weitgehend) organisationsneutralen Best Practices. Daher werden zur Durchführung von Prozessaktivitäten Rollen definiert, die mit den erforderlichen Ressourcen zu unterstützen sind. Die Leistungsindikatoren (KPIs) dienen auch zum Management der eingesetzten Ressourcen. Ohne Qualitätsparameter und Leistungsindikatoren (KPIs) ist ein wirksames Prozess-Management unmöglich. 10

21 2.4 Die Struktur gemäß ITIL Version 3 Um ein wirksames Prozess-Management zu erreichen, muss kontinuierlich überprüft werden, ob die definierten Prozessziele wirkungsvoll erreicht werden (Effektivität) und mit welchem Aufwand dieses Ergebnis erzielt wird (Effizienz). ITIL und insbesondere die ISO 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 Die in diesem Buch wiedergegebenen Definitionen stammen aus dem ITIL V3 Glossar des Arbeitskreises Publikation, ITIL Version 3 Translation Projekt des itsmf Deutschland e. V. Dieses Glossar bildet die Basis für die Übersetzung der Originalliteratur. Mit der Publikation von ITIL Version 3 richten sich die ITIL Best Practices noch stärker auf die Business-Anforderungen aus. Speziell mit der zentralen Publikation Service Strategy wird ein wichtiger Beitrag zur IT Go- 11

22 2 IT Service Management vernance geliefert. Im Rahmen der IT Governance soll sichergestellt werden, dass die IT-Organisation mit etablierten Strukturen und Prozessen die Unternehmensziele und -Strategie unterstützt. Wesentlicher Teil der IT Governance ist eine erfolgreiche Ausrichtung der IT an den Geschäftszielen des Unternehmens (Stichwort Business-IT Alignment ). Mit der Version 3 gehen die ITIL Best Practices einen Schritt weiter. Die Zielsetzung von ITIL mit der Version 3 besteht in der Business Integration. Mithilfe der ITIL Best Practice soll nicht nur eine bessere Ausrichtung der IT-Organisation an den Geschäftsprozessen und Anforderungen des Kunden ermöglicht werden, sondern es wird mit der ITIL V3 eine IT- / Business Integration angestrebt. In den meisten Organisationen ist inzwischen die Abwicklung eines Geschäftsprozesses ohne entsprechende IT-Unterstützung nicht mehr denkbar. In einigen Fällen findet die Durchführung eines Geschäftsprozesses inzwischen nur durch elektronische Systeme und ohne manuelle Bearbeitungsschritte statt. Als Beispiele hierfür können Web-Shops oder das Online Banking herangezogen werden. Die Qualität, Funktionalität und Leistungsfähigkeit dieser IT-Unterstützung prägt maßgeblich das Erscheinungsbild der gesamten Organisation nach außen zum Kunden. Gleichzeitig gehört die auf den Geschäftsprozess ausgerichtete IT-Unterstützung zu den strategischen Fähigkeiten und Ressourcen einer Organisation. Damit wird die notwendige und auf die jeweilige Organisation ausgerichtete IT- Unterstützung zum elementaren Bestandteil des Geschäftserfolges. Diese Unterstützung eines Geschäftsprozesses wird in den ITIL Best Practices als Service bezeichnet. Den Service definiert ITIL (Version 3) als: Service: Eine Möglichkeit, einen Mehrwert für Kunden zu erbringen, indem das Erreichen der von den Kunden angestrebten Ergebnisse erleichtert oder gefördert wird. Dabei müssen die Kunden selbst keine Verantwortung für bestimmte Kosten und Risiken tragen. In dieser neuen Definition des Service werden die Erbringung eines Mehrwertes für den Kunden und die angestrebten Ergebnisse herausgestellt. Damit unterstreicht die ITIL Version 3 die beabsichtigte Business Integration. Es wird nicht nur ein Service bereitgestellt, sondern er muss auch die angestrebten Ergebnisse erzielen und einen Mehrwert für das Business erbringen. ITIL Version 3 spricht hier von einer ergebnisbasierten Definition des IT Service: Was ist das Ergebnis bzw. der Mehrwert des IT Service für den Geschäftsprozess?. 12

23 2.4 Die Struktur gemäß ITIL Version 3 Damit verbunden ist auch die Erweiterung der Definition für den IT Service (aus Service Strategy, [OGC, 2007a]). Hier wird der allgemeine Begriff des Service auf den Bereich der IT konkretisiert: IT Service: Ein Service, der für einen oder mehrere Kunden von einem IT Service Provider bereitgestellt wird. Ein IT Service basiert auf dem Einsatz der Informationstechnologie und unterstützt die Business-Prozesse des Kunden. Ein IT Service besteht aus einer Kombination von Personen, Prozessen und Technologie und sollte in einem Service Level Agreement definiert werden. Sinngemäß lässt sich der IT Service also wie folgt definieren: IT Services werden von einem IT Service Provider für einen oder mehrere Kunden bereitgestellt. IT Services nutzen die Informationstechnologie und unterstützen die Business Prozesse der Kunden. IT Services definieren sich aus Personen, Prozessen und Technologien. IT Services sind in Service Level Agreements zu definieren. IT Services erbringen einen Mehrwert für Kunden. Ein IT Service ist demzufolge mehr als die Bereitstellung einer Technologie. Der IT Service Provider muss zur Bereitstellung des IT Service nicht nur die geeignete Technik, sondern auch über entsprechend qualifiziertes Personal und auf den IT Service ausgerichtete Prozesse verfügen. Innerhalb der Publikation Service Strategy werden diese Grundlagen und der Bezug eines IT Service zu den Geschäftsprozessen des Business deutlich herausgestellt. Letztendlich stellen die IT Services die Geschäftsprozesse des Business sicher bzw. stellen den IT Service aus Sicht des Kunden dar (Abbildung 4, auf Basis Service Strategy, [OGC, 2007a]). Die Abbildung zeigt die Ausrichtung der IT Services auf das Business und die Business Prozesse. Der IT Service Provider verfügt über spezielle Ressourcen und Fähigkeiten. ITIL V3 bezeichnet diese Ressourcen und Fähigkeiten als Service Assets, die im nachfolgenden Kapitel Service Strategy näher betrachtet werden. Mithilfe dieser Ressourcen und Fähigkeiten wird dem Business der notwendige IT Service bereitgestellt, der in die Business Prozesse integriert ist. Teilweise ist, wie zum Beispiel für Web- Shops, der IT Service mit dem Business Prozess gleichzusetzen (rechter mittlerer Teil der Abbildung). Letztendlich dienen die Business Prozesse dazu, dem Kunden der Organisation einen Service oder ein Produkt zu liefern. Hier wird die Leistungsfähigkeit der Organisation für den Kunden als Ganzes erlebbar. 13

24 2 IT Service Management Business Services (Produkte, Waren) Business Service Business Service Business Prozesse IT Services IT Service IT Service IT Service IT Service Ressourcen und Fähigkeiten Internet Abbildung 4: Die Ausrichtung der IT Services auf das Business IT Services bestehen in der Regel aus verschiedenen technischen Systemen, Applikationen und Teilleistungen mit unterschiedlichen Verantwortungen und Zuständigkeiten. Da dies in der Vergangenheit zu Kompetenzproblemen geführt hat, wird in ITIL Version 3 auch die Rolle des Service Owners spezifiziert (vgl. [OGC, 2007e]): Service Owner (Serviceverantwortlicher): Eine Rolle, die für die Bereitstellung eines bestimmten IT Service verantwortlich ist. Demzufolge ist der Service Owner verantwortlich für einen spezifischen IT Service, unabhängig davon, wo innerhalb der Organisation die zugrunde liegenden Ressourcen und Fähigkeiten, wie zum Beispiel technologischen Komponenten oder Applikationen angesiedelt sind. In vielen IT-Organisationen hat sich diese Rolle bereits etabliert, wenn auch zum Teil unter ei- 14

25 2.4 Die Struktur gemäß ITIL Version 3 nem anderen Namen. Häufig wird diese Rolle als Service Manager bezeichnet. Da innerhalb der ITIL Best Practice mit der Version 3 auch die Rolle des Service Managers beschrieben wird, gilt es, innerhalb der jeweiligen IT-Organisation eindeutige Bezeichnungen und Rollendefinitionen zu finden. In der Vergangenheit führte die Bezeichnung IT Infrastructure Library zu Missverständnissen. So wurde der Begriff Infrastructure fälschlicherweise dahingehend interpretiert, dass die ITIL Best Practice lediglich auf den Bereich der Infrastruktur der IT-Organisationen anzuwenden sei und zum Beispiel die Applikationen nicht im Betrachtungsbereich von ITIL liegen. Mit der neuen Version ist ITIL nicht mehr die Abkürzung für IT Infrastructure Library, sondern ITIL ist nun ein Synonym für Service Management. Hierzu definiert die ITIL Version 3 den Begriff ITIL wie folgt: ITIL: Ein Satz an Best Practice-Leitlinien für das IT Service Management. Inhaber von ITIL ist das OGC. ITIL umfasst eine Reihe von Publikationen, die Leitlinien zur Bereitstellung von qualitätsbasierten IT Services sowie zu den Prozessen und Einrichtungen bieten, die zur Unterstützung dieser Services erforderlich sind. Mit der Herausgabe der ITIL Version 3 hat sich auch der Fokus des Service Managements erweitert. Während in der früheren Version von ITIL das Service Management noch als das zur Erfüllung der Kundenanforderungen erforderliche Management definiert wurde, lautet die Definition jetzt wie folgt (vgl. Service Strategy, [OGC, 2007a]): Service Management: Das Service Management ist die Gesamtheit der spezialisierten organisatorischen Fähigkeiten, die zur Generierung eines Mehrwerts für Kunden in Form von Services verfügbar sind. In der ITIL Version 3 sind nicht nur Prozesse für das Service Management beschrieben, sondern der gesamte Service Lifecycle. Angefangen von: der Strategie (Service Strategy), über das Design (Service Design), die Überführung in den Betrieb (Service Transition) und der operationelle Betrieb (Service Operation). Diese Phasen und damit verbundenen Aktivitäten unterliegen einem kontinuierlichen Verbesserungsprozess (Continual Service Improvement). 15

26 2 IT Service Management Hierzu werden nicht nur Service Management-Prozesse beschrieben, sondern zum Beispiel auch die strategische Ausrichtung der IT, bewährte Methoden oder notwendige Aufgaben wie das Risiko Management. ITIL mit der Version 3 ist mehr als eine Sammlung von Prozessen. ITIL Version 3 ist ein ganzheitlicher integrierter Ansatz von Best Practices für das Service Management ITIL und der Service Lifecycle Innerhalb der Informationstechnologie haben sich traditionell die Phasen Plan (Planung), Build (Entwicklung, Erstellung) und Run (Betrieb, Produktion) etabliert: Die Phase Plan beinhaltet dabei in der Regel den ganzheitlichen Blick auf die Informationstechnologie und die Ausrichtung an den Anforderungen des Unternehmens. Innerhalb von Build werden darauf aufbauend die notwendigen IT-Systeme konzipiert, entwickelt und beschafft. Innerhalb von Run werden die Systeme betrieben und die Leistungen für die Kunden zur Verfügung gestellt. Diese bewährte Struktur hat die ITIL V3 konzeptionell aufgegriffen und mit einem umfassenden kontinuierlichen Verbesserungsprozess als Service Lifecycle beschrieben. Ausgehend von der strategischen Ausrichtung und Definition des IT Service (Service Strategy) werden die IT Services entwickelt (Service Design) und in die Produktion bzw. in den Betrieb überführt (Service Transition). Anschließend werden die IT Services betrieben und den Geschäftsprozessen zur Verfügung gestellt (Service Operation). Diese Phasen werden umschlossen von einem kontinuierlichen Verbesserungsprozess (Continual Service Improvement), der über alle Phasen des Service Lifecycle mögliche Verbesserungen identifiziert. Die Beschreibung dieses Service Lifecycle mit den Best Practices für jede einzelne Phase wird als ITIL Core bezeichnet. Der ITIL Core besteht aus den fünf Publikationen: Service Strategy (vgl. [OGC, 2007a]) Service Design (vgl. [OGC, 2007b]) Service Transition (vgl. [OGC, 2007c]) Service Operation (vgl. [OGC, 2007d]) Continual Service Improvement (vgl. [OGC, 2007e]) Diese fünf Core-Publikationen bilden die Phasen eines iterativen und mehrdimensionalen Lifecycle für die Services. Lernen und Reifen der Organisationen sollen ermöglicht werden. Ziele sind: Struktur, Stabilität und Stärke auf der Basis dauerhafter Prinzipien, Methoden und Werkzeuge. 16

27 2.4 Die Struktur gemäß ITIL Version 3 Dies soll dem Schutz von Investitionen dienen. Was hier angestrebt wird, ist ein Kreislauf aus Messen, Lernen und Verbesserung. Abbildung 5 verdeutlicht das Zusammenspiel dieser 5 Phasen. Continual Service Improvement Service Transition Service Design Service Strategy Service Operation Abbildung 5: Die 5 Phasen des Service Lifecycle nach ITIL V3. Diese Phasen haben nicht nur spezielle Zielsetzungen und Aufgaben innerhalb des Service Lifecycle, sondern auch definierte Übergänge zwischen den einzelnen Phasen. Die folgende Abbildung 6 veranschaulicht die Hauptaktivitäten der einzelnen Phasen sowie ihre Übergänge bzw. Schnittstellen (vereinfachte Darstellung aus The Official Introduction to Service Lifecycle ([OGC, 2007e]). In dieser Abbildung finden sich die einzelnen Phasen des Service Lifecycle als Ebenen wieder. Die dargestellten Aktivitäten bzw. Aufgabenstellungen pro Phase werden in den nachfolgenden Kapiteln erläutert. An dieser Stelle werden die Übergänge zwischen den einzelnen Phasen beschrieben. 17

28 2 IT Service Management Service Level Package Service Design Early Life Support Service Operation Entwicklung Angebote Service Portfolio Management Entwicklung Angebote Service Portfolio Management Verifizieren Release & Deployment Management Monitoring & Aktionen Event Management Analyse Improvement Service Strategie Strategie Generierung Definition des Marktes Demand Management Service Design Package Supplier Management Verhandeln/ Vereinbaren Service Level Management Service Tranistion Change Management Risiken optimieren Service Asset Configuration Management Service Performance Reports Request Fulfilment Lösen & Wiederherstellen Incident Management CSI Service Measurement Definition Metriken Service Reporting Abbildung 6: Integrierter Ablauf der Lifecycle Elemente 18

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

30 2 IT Service Management IT Services zu ermöglichen. Da damit die gesicherte Überführung von Changes in die Betriebsumgebung verbunden ist, findet sich dieser Prozess innerhalb von Service Transition wieder. Aber Changes finden auch in anderen Phasen statt. Wird zum Beispiel innerhalb von Service Strategy entschieden, einen neuen Service zu entwickeln, so handelt es sich dabei auch um einen Change. Daraus folgt, dass einzelne Prozesse auch phasenübergreifend ihre Anwendung finden. In der ITIL V3 werden die IT Service Management-Prozesse innerhalb einer Phase des Service Lifecycle beschrieben und dokumentiert. Diese Prozesse finden aber zum Teil phasenübergreifend ihre Anwendung. Abbildung 7 veranschaulicht die Prozesse der einzelnen Phasen und ihren Wirkungsbereich (vereinfachte Darstellung aus The Official Introduction to Service Lifecycle ([OGC, 2007e]). Dieser ITIL Core soll von der OGC sukzessive um weitere Komponenten ergänzt werden und in ihrer Summe die gesamte ITIL Library ausmachen: Der ITIL Core als Leitfaden für alle Organisationen, die Dienstleistungen anbieten. Die ITIL Complementary Guidance als ergänzender Leitfaden für industrielle Bereiche, Organisationstypen, Betriebsmodelle und technologische Architekturen. Die ITIL Web Support Services mit Zusatzprodukten, Prozessmodellen, Templates und Studien. Ergänzt werden diese offiziellen Publikationen der OGC um eine allgemeine Einführung The Official Introduction to Service Lifecycle ([OGC, 2007e]) Service Strategy Im Zentrum des dargestellten Service Lifecycle steht die Phase Service Strategy (vgl. [OGC, 2007a]). Hier werden die strategischen Entscheidungen getroffen. Es geht um das Design, die Entwicklung und Implementierung des Service Managements nicht nur im organisatorischen, sondern vielmehr im strategischen Sinne. Service Management Richtlinien (Policies), Anleitungen und Prozesse über den gesamten ITIL Service-Lebenszyklus hinweg werden hier entwickelt und unterstützt. Service Strategy bildet im Kern des Kreislaufs das zentrale strategische Fundament für die Phasen Service Design, Service Transition, Service Operation und den alles umfassenden permanenten Verbesserungskreislaufs des Continual Service Improvement. 20

31 2.4 Die Struktur gemäß ITIL Version 3 Service Lifecycle Governance Prozesse Operational Service Lifecycle Prozessezb Service Strategy Service Portfolio Management Strategie Generierung Abbildung 7: Continual Service Service Service Service Improvement Design Transition Operation IT Financial Management Demand Management Service Service Catalogue Management Measurement Service Level Management Service Availability Management Reporting Capacity Management Service IT Service Continuity Management Improvement IT Security Management Supplier Management Transition Planning Change Management Service Asset and Configuration Management Release and Deployment Management Service Validation and Testing Evaluation Knowledge Management Event Management Incident Management Request Fulfilment Problem Management Access Management Common Service Operation Activities Service Lifecycle und Prozesse Ausgangspunkt der Phase Service Strategy sind die Identifizierung, Auswahl und Priorisierung von Geschäftschancen und Marktplätzen. Betrachtungen und Analysen der Marktentwicklung und die Definition von Zielen und Erwartungen führen zur Formulierung von Serviceleistungen gegenüber Kunden und Marktplätzen. Marktplätze sind nicht nur für IT Service Provider zu definieren, die ihre Leistungen auf dem Markt anbieten, sondern auch für interne IT-Bereiche. Hierzu gilt es, auch die Frage zu 21

32 2 IT Service Management beantworten: Wie können wir uns von der Konkurrenz bzw. externen Dienstleistern abheben?. Innerhalb der Service Strategy gilt es, auf Basis dieser Fragestellung geeignete Servicestrukturen zu entwickeln, die eigenen Stärken zu erkennen und kritisch zu prüfen, welche externen Leistungen einbezogen werden sollten. Heute kann keine IT-Organisation mehr alle Ressourcen und Fähigkeiten mit eigenen Ressourcen produzieren. Es gilt demzufolge, durch die Konzentration auf die Alleinstellungsmerkmale und die Einbeziehung geeigneter Lieferanten (Supplier) zweckmäßige Servicestrukturen zu konzipieren. Mit Unterstützung des IT Financial Managements werden ein Serviceportfolio definiert und die Entwicklung eines Servicekatalogs vorbereitet. Hierzu werden vom IT Financial Management Kostenmodelle entwickelt sowie Return on Investment und Return on Value-Berechnungen angestellt. Unter Berücksichtigung der Aktivitäten im IT Financial Management kann die zuvor auf Seite 18 dargestellte Abbildung 6: Integrierter Ablauf der Lifecycle Elemente aus dem Kapitel ITIL und der Service Lifecycle nun wie folgt detailliert werden (Auszug aus der Darstellung in The Official Introduction to Service Lifecycle ([OGC, 2007e]): Gelegenheiten und Grenzen Kostenmodelle Return on Investment Return on Value Service Strategie Strategie Generierung IT Financial Management Definition des Marktes Demand Management Entwicklung Angebote Service Portfolio Management Service Level Package Service Design Abbildung 8: Elemente Service Strategy Mit der ITIL V3 nimmt das Serviceportfolio eine wichtige Funktion im Service Management ein. Innerhalb der Service Strategy wird definiert, welche IT Services zur Unterstützung der Geschäftsprozesse zu liefern bzw. zu entwickeln sind. Diese IT Services werden im Serviceportfolio dokumentiert. Dagegen enthält der bereits aus ITIL V2 bekannte Servicekatalog lediglich die IT Services, die sich in der Nutzung bzw. im Übergang in die Betriebsumgebung befinden. 22

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

34 2 IT Service Management Service Lifecycle Service Status: Requirements Defined Analyzed Approved Chartered Designed Developed Built Test Released Operational Retired Servicepipeline Servicekatalog Serviceportfolio Außerkraftgesetzte Services Abbildung 9: Serviceportfolio und die einzelnen Stati Die Definition des Serviceportfolios und dessen Integration in die aktuellen und zukünftigen Geschäftsprozesse ist eine der wichtigsten Aufgaben von Service Strategy. Auch Themen wie Organisationsentwicklung sowie Kosten- und Risikobetrachtungen im Hinblick auf das Serviceportfolio werden angegangen. Neben dem Faktor operationelle Effizienz geht es entscheidend um ganzheitliche, nachhaltige und effektvolle Entscheidungen und Leistungen und deren Entwicklung. Strategische Reviews helfen, Fähigkeiten zu verbessern, und tragen zum weiteren Ausbau von Geschäftsstrategien und -chancen bei. Das Fazit in einem kurzen Satz wäre wohl, die Service Strategy folgendermaßen zu formulieren: Erst das WAS, dann das WIE! Im gesamten Service Lifecycle wird eines sehr deutlich: die Ausrichtung der IT Services an den Anforderungen und am wirklichen Bedarf des Kunden und seines Geschäftes. Dieses Ziel wird stringent verfolgt. IT Services werden auf die Business-Services fokussiert, damit deren Leistungen zur direkten Unterstützung der Geschäftsziele dienen. Business Service Management liefert hierfür ein Modell mit den entsprechenden Metriken (vgl. Abbildung 10). 24

35 2.4 Die Struktur gemäß ITIL Version 3 Geschäftsprozess Nutzt den IT Service Nimmt Leistungen in Anspruch Integration in Geschäftsprozess ermöglicht Wertbeitrag IT Service Provider IT Service Fähigkeiten und Ressourcen IT-Infrastruktur Personen Configuration Items Organisation Anwendungen Andere Elemente Geld IT Service Prozesse Abbildung 10: Verbindung zwischen IT Service und Business-Service Business Service Management: Ein Ansatz zur Verwaltung von IT Services, bei dem die unterstützten Business- Prozesse und der Geschäftswert berücksichtigt werden. Dieser Begriff bezeichnet darüber hinaus die Verwaltung von Business-Services, die für Business-Kunden bereitgestellt werden. Die mit der ITIL V3 verbundene Integration der IT Services in die Geschäftsprozesse des Kunden hat zu den bereits vorgestellten neuen Definitionen des Begriffs Service bzw. IT Service geführt. In diesen Definitionen wird zum Ausdruck gebracht, dass der IT Service einen Mehrwert für den Kunden erbringt. Die Service Level Agreements (SLAs) stellen hierzu einen wichtigen Beitrag dar; wobei sicherzustellen ist, dass diese SLAs einen IT Service aus Sicht des Geschäftsprozesses beschreiben und nicht die Bereitstellung eines technischen Systems wie den Betrieb eines SAP-Systems im Rechenzentrum. Aber damit wird der Mehrwert für den Geschäftsprozess und den Kunden noch nicht dokumentiert, und die Gefahr besteht, dass die IT weiterhin als Kostenfaktor gesehen und ihre Bedeutung für den Geschäftsbetrieb nicht ausreichend herausgestellt wird. Mit ITIL V3 soll der für den Kunden generierte Mehrwert betrachtet werden. Hierzu werden mit der Warranty (Gewährleistung) und Utility (Nutzen) zwei Dimensionen beschrieben. 25

36 2 IT Service Management Service Utility: Die Funktionalität eines IT Service aus der Perspektive des Kunden. Der Business-Wert eines IT Service setzt sich aus dem Service Utility ( was der Service tut) und der Service Warranty ( wie gut der Service das ausführt) zusammen. Service Warranty: Die Zusicherung, dass ein IT Service den vereinbarten Anforderungen gerecht wird. Dabei kann es sich sowohl um eine formale Vereinbarung wie ein Service Level Agreement oder einen Vertrag, als auch um eine Marketingbotschaft oder ein bestimmtes Markenimage handeln. Der Business-Wert eines IT Service setzt sich aus dem Service Utility ( was der Service tut) und der Service Warranty ( wie gut der Service das ausführt) zusammen. Die Service Utility hilft dem Kunden in der Steigerung der Produktivität seiner Geschäftsprozesse, während die Service Warranty die notwendigen Voraussetzungen wie zum Beispiel Verfügbarkeit und Kapazität für den Betrieb spezifiziert. Der hier beschriebene Zusammenhang lässt sich wie folgt darstellen (Abbildung 11, aus [OGC, 2007a]): Zweckmäßig? Anforderungen erfüllt? Unterstützt Leistung? Verschiebt Grenzen? Verfügbar? Kontinuität? Kapazität? Sicherheit? Utility Zwecke erfüllt? ODER W/F Warranty UND betriebsfähig? W/F Wertschaffend? W/F UND W/F = wahr / falsch Abbildung 11: Die Wertebetrachtung eines IT Service Wurde das Service Management bisher als taktische oder operative Aufgabe angesehen, so stellt das Service Management jetzt einen geschlossenen Regelkreis dar, wobei die Phase Service Strategy die Basis bildet (siehe Abbildung 12, aus Service Strategy, [OGC, 2007a]). 26

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

38 2 IT Service Management Service Strategy Service Level Package Service Design Package Supplier Management Verhandeln/ Vereinbaren Service Level Management Design Lösung Das Design der Messsysteme und Metriken der IT Services, der Architekturen, ihrer verbundenen Komponenten und der Prozesse selbst. ITIL spricht hier von einem ereignisgesteuerten Ansatz, in dem für jeden der genannten Aspekte die gewünschten und geplanten Ergebnisse definiert werden, so dass der gelieferte IT Service den Erwartungen der Kunden und Benutzer entspricht. Ausgehend von den strategischen Zielen, die in der Phase Service Strategy definiert wurden, findet hier die Transformation zu einem Portfolio von IT Services statt. Wichtigstes Ergebnis dieser Stufe ist das Design einer effektiven und effizienten Service-Lösung. Die sich ständig verändernden Anforderungen des Business und der IT erfordern eine ständige Interaktion mit allen anderen Bereichen und Prozessen. Abbildung 13 verdeutlicht dies. Beim Design werden diese Bereiche und Prozesse in den Service Design-Aktivitäten berücksichtigt, um alle Service- Lösungen mit existierenden Lösungen konsistent und kompatibel zu gestalten. Servicekatalog Management Design ausgewogener Zuverlässigkeit Anforderungen Messsysteme Architektur Compliance Service Design Availability Capacity Security Continuity Service Transition Abbildung 13: Service Design Aufgaben und Einbindung Dies beinhaltet auch Änderungen und Verbesserungen, die notwendig werden, um sowohl den Wert der IT Services für den Kunden über den Lebenszyklus der IT Services hinweg zu erhalten, als auch die Kontinuität der IT Services, das Erreichen der Service-Qualität (Service Level-Ziele) und die Konformität zu Standards und Regeln. 28

39 2.4 Die Struktur gemäß ITIL Version 3 Die Aufgaben des Service Design und die Einbindung in den Service Lifecycle stellen sich wie in Abbildung 13 dar (Auszug aus der Darstellung in The Official Introduction to Service Lifecycle ([OGC, 2007e]). Bevor ein neuer IT Service oder eine Änderung an einem bestehenden IT Service entwickelt wird, sind die damit verbundenen Kundenanforderungen aufzunehmen und zu analysieren. Eine damit verbundene Aufgabe ist die Analyse der bestehenden Fähigkeiten innerhalb der eigenen Organisation. Der Begriff der Fähigkeiten ist hier im Kontext zur Begriffsdefinition gemäß ITIL V3 zu verstehen: Fähigkeit (Capability): Die Fähigkeit einer Organisation, einer Person, eines Prozesses, einer Anwendung, eines Configuration Item oder eines IT Service zur Durchführung einer Aktivität. Fähigkeiten gehören zu den nicht greifbaren Assets einer Organisation. Gibt es zwischen bestehenden Fähigkeiten und den notwendigen Fähigkeiten für den neuen bzw. zu ändernden IT Service Diskrepanzen, so sind geeignete Maßnahmen zu konzipieren. Dabei ist es nicht unbedingt erforderlich, die notwendigen Fähigkeiten innerhalb der eigenen IT-Organisation aufzubauen. Die zusätzlichen Fähigkeiten können auch extern bezogen werden. Innerhalb von Service Design werden hierzu Delivery Model Options zur Integration von externen Lieferanten und Partnern beschrieben. Serviceportfolio Beschreibung Wertbeitrag Geschäftspläne (Business Cases) Prioritäten Risiken Angebote und Einheiten Kosten und Preisgestaltung Servicekatalog(e) Services Unterstützte Produkte Richtlinien (Policies) Bestellung und erforderliche Prozesse Unterstützte Liefer- und Zahlungsbedingungen Eingangspunkt und Eskalationen Preisgestaltung und Verrechnung Abbildung 14: Vom Serviceportfolio zum Servicekatalog 29

40 2 IT Service Management Das Serviceportfolio ist eine zentrale Informationsquelle innerhalb des Service Lifecycle. Dem Serviceportfolio können sämtliche IT Services und deren jeweiliger Status entnommen werden. Zusätzlich können weitere Details zum IT Service, dessen Schnittstellen und die Abhängigkeiten zu anderen IT Services hinterlegt werden. Eine Teilmenge des Serviceportfolios ist der Servicekatalog mit den Informationen zu sämtlichen in der Nutzung und der Überführung in die Betriebsumgebung befindlichen IT Services. Abbildung 14 beschreibt die Inhalte des Serviceportfolios und des Servicekatalogs (aus [KESS, 2007d]). Verbunden mit der Integration des IT Service in den Geschäftsprozess des Kunden entsteht die Notwendigkeit, diesen IT Service innerhalb der IT- Organisation zu strukturieren. Besteht der IT Service zum Beispiel in der Form eines Personalverwaltungssystems, so könnte dieser IT Service in den Betrieb eines Servers, eines LAN, einer Datenbank usw. verfeinert strukturiert werden. Zur besseren Abgrenzung bezeichnet ITIL V3 diesen IT Service als Business-Service: Business-Service: Ein IT Service, der einen Business-Prozess direkt unterstützt, im Gegensatz zu einem Infrastrukturservice, der intern vom IT Service Provider eingesetzt wird und der in der Regel nicht vom Business wahrgenommen wird. Der Begriff Business-Service bezeichnet darüber hinaus einen Service, der von einem Geschäftsbereich für Business-Kunden erbracht wird. Dazu gehören beispielsweise die Bereitstellung von Finanzdienstleistungen für Kunden einer Bank oder die Lieferung von Waren an Kunden eines Einzelhandelsgeschäfts. Die erfolgreiche Bereitstellung von Business-Services hängt häufig von einem oder mehreren IT Services ab. Es ist eine wesentliche Aufgabe innerhalb des Service Design, diese Business-Services so zu gestalten, dass sie die sich ändernden Anforderungen der Kunden und deren Geschäftsprozesse erfüllen. Hierzu sind die notwendigen unterstützenden IT Services zu bestimmen und auszugestalten. Der Prozess des Servicekatalog Managements hat zum Ziel, dass ein Servicekatalog erstellt und gepflegt wird, der diese Informationen über alle operationellen IT Services enthält, die für den operativen Betrieb vorbereitet werden. Hierzu werden zwei unterschiedliche Sichten zur Verfügung gestellt. Für den Kunden werden die Business-Services präsentiert, während innerhalb der IT die damit verbundenen (internen) IT Services in Verbindung gebracht werden (aus [OGC, 2007b]): 30

41 2.4 Die Struktur gemäß ITIL Version 3 Business Prozess 1 Business Prozess 2 Business Prozess 3 Business Servicekatalog Service A Service B Service C Service D Service E Technischer Servicekatalog Support Services Hardware Software Applikationen Daten Abbildung 15: Die Inhalte und Sichten des Servicekatalogs Liegt das Service Design vor, so ist es die Aufgabe des Service Level Managements, die entsprechenden Service Level Agreements (SLA) mit dem Kunden zu verhandeln, zu vereinbaren und sicherzustellen, dass die vereinbarten Service Level-Ziele eingehalten werden. Dazu zählt unter anderem die Sicherstellung der Zuverlässigkeits- und Compliance-Anforderungen. Dieser SLA wird mit dem Kunden auf der Ebene des Business-Service abgeschlossen werden (obere Ebene der Abbildung 15). Zur Absicherung des SLAs stellt das Service Level Management sicher, dass alle IT Service Management-Prozesse, Operational Level Agreements (OLAs) und Underpinning Contracts (UCs) für die vereinbarten Service Level-Ziele angemessen sind. Die Operational Level Agreements werden innerhalb der eigenen Organisation mit den beteiligten Einheiten, wie zum Beispiel Abteilungen abgeschlossen. Werden externe IT Services integriert, sind hierfür so genannte Underpinning Contracts zu verhandeln und zu vereinbaren. Dies erfolgt in Zusammenarbeit zwischen dem Service Level Management und Supplier Management. Sämtliche Prozesse des Service Design und deren Zielsetzung können dem Abschnitt Service Design entnommen werden. 31

42 2 IT Service Management Ist der IT Service vollständig entwickelt, ist die Phase Service Transition verantwortlich für die Überführung des IT Service in den operativen Betrieb Service Transition Die Phase Service Transition (vgl. [OGC, 2007c]) umfasst das Management und die Koordination von Prozessen, Systemen und Funktionen, um ein Release zu paketieren, zu bauen, zu testen, auszuliefern und in die Produktion zu übernehmen und die durch Kunden und Stakeholder spezifizierten Anforderungen umzusetzen. Hierzu werden die Anforderungen aus den Phasen Service Strategy und Service Design für ein effektives Service Operation realisiert. Hier findet das Management komplexer Changes bei den Services und Service Management-Prozessen und die Verhinderung unerwünschter Konsequenzen statt: Risiken sollen kontrollierbar bleiben; gleichzeitig der Versuch, Raum zu lassen für Innovation. Die Aufgaben der Phase Service Transition sind Abbildung 16 zu entnehmen (Darstellung aus The Official Introduction to Service Lifecycle ([OGC, 2007f]): Service Design Package Service Design Qualitätssicherung Service Abnahme Konformität Utility und Warranty Entscheidung Fähigkeiten Planung & Support Validierung & Testen Evaluierung Knowledge Service Transition Change Management Optimierung Riskien Service Asset & Configuration Management Verifizieren Release & Deployment Management Early Life Support Service Operation Abbildung 16: Service Transition-Prozesse Innerhalb von Service Transition haben die Prozesse Change Management, Service Asset und Configuration Management und Release und Deployment Management eine besondere Bedeutung. Sämtliche Prozesse 32

43 2.4 Die Struktur gemäß ITIL Version 3 von Service Transition können dem Abschnitt Service Transition entnommen werden. Jegliche Veränderung eines stabilen laufenden Systems ist mit Risiken verbunden. Das Change Management hat zum Ziel, die notwendigen Changes mit minimaler Unterbrechung der IT Services zu implementieren. Hierzu sind die einzelnen Changes zu bewerten, zu planen und so die damit verbundenen Risiken zu reduzieren. Die Verantwortung für die Autorisierung und Umsetzung von Changes liegt in der Rolle des Change Managers. Diese Bewertung kann bei umfassenden Changes nicht von einer Person allein mit einer ausreichenden Sicherheit durchgeführt werden. Daher hat sich die Unterstützung des Change Managers durch das so genannte Change Advisory Board (CAB) bewährt: Change Advisory Board (CAB) Eine Gruppe von Personen, die den Change Manager bei der Bewertung, Festlegung von Prioritäten und zeitlichen Planung in Bezug auf Changes beraten. Dieses Gremium setzt sich in der Regel aus Vertretern aller Bereiche des IT Service Providers, dem Business und den Drittparteien wie z. B Suppliern zusammen. Damit mögliche Auswirkungen von Changes beurteilt werden können, benötigt das Change Management Informationen zu den betroffenen IT Services und den damit in Verbindung stehenden Komponenten. Die Pflege dieser Informationen zu den Komponenten liegt in der Verantwortung des Configuration und Service Asset Managements. In ITIL werden diese Komponenten als Configuration Items (CIs) bezeichnet: Configuration Item (CI): Alle Komponenten, die verwaltet werden müssen, um einen IT Service bereitstellen zu können. Informationen zu den einzelnen CIs werden in einem Configuration Record innerhalb des Configuration Management Systems erfasst und über den gesamten Lebenszyklus hinweg vom Configuration Management verwaltet. CIs unterstehen der Steuerung und Kontrolle des Change Management. CIs umfassen vor allem IT Services, Hardware, Software, Gebäude, Personen und formale Dokumentationen, beispielsweise zum Prozess und SLAs. Configuration Items sind mehr als Hard- und Software Die Definition stellt deutlich heraus, dass die Configuration Items nicht nur technische Komponenten wie Hardware, Software und Applikationen umfassen. Im Mittelpunkt der Definition steht, dass ein IT Service bereitzustellen ist. Daher werden auch Informationen wie beispielsweise zu SLAs benötigt und als CIs hinterlegt. Aber auch Applikationen sind CIs. 33

44 2 IT Service Management Änderungen an Applikationen werden über das Change Management gesteuert. In der ITIL V2 wurde die Configuration Management Database (CMDB) noch als eine Datenbank beschrieben, die die relevanten Details zu jedem CI sowie Details der wichtigsten Beziehungen zwischen CIs enthält. Der Begriff eine Datenbank wurde vielfach mit einer physischen Datenbank assoziiert, in der sämtliche Informationen zu hinterlegen waren. Diese Forderung war in der Praxis nicht zweckmäßig umzusetzen und aus Sicht der Autoren auch nicht die Intention von ITIL V2. In der Version 3 gibt es zwar noch den Begriff der CMDB, aber das Gesamtsystem zur Verwaltung der Informationen ist nunmehr das Configuration Management System (CMS): Configuration Management System: Ein Satz an Hilfsmitteln und Datenbanken, der für die Verwaltung der Configuration-Daten eines IT Service Providers verwendet wird. Das CMS enthält darüber hinaus Informationen zu Incidents, Problemen, Known Errors, Changes und Releases und kann auch Daten zu Mitarbeitern, Suppliern, Standorten, Geschäftsbereichen, Kunden und Anwendern beinhalten. Das CMS umfasst Hilfsmittel zum Sammeln, Speichern, Verwalten, Aktualisieren und Präsentieren von Daten zu allen Configuration Items und deren Beziehungen. Das CMS untersteht der Zuständigkeit des Configuration Management und wird von allen IT Service Management-Prozessen eingesetzt. Die folgende Abbildung 17 (Auszug aus [OGC, 2007c]) verdeutlicht die möglichen Daten- und Informationsquellen sowie Tools für ein Configuration Management System: Projekt Dokumentation Strukturiert Projekt Software Daten- und Informations- Quellen und Tools Definitive Media Library Definitive Document Library 1 Definitive Multimedia Library 1 Physikalische CMDBs CMDB1 CMDB2 Plattform Configuration Tools wie Datenbank Netzwerk, Mainframe, Verteilte Desktop Software Configuration Management Enterprise Applikationen Access Management Human Ressourcen Supply Chain Management Customer Relationship Management Discovery, Asset Management und Audit Tools Abbildung 17: Daten und Informationsquellen für ein CMS 34

45 2.4 Die Struktur gemäß ITIL Version 3 Innerhalb des Release und Deployment Managements werden die Releases in den IT-Betrieb übergeleitet. Hierbei ist sicherzustellen, dass das Release effektiv in einen Einsatzbereich bzw. eine Zielumgebung ausgebracht (deployed) werden kann und die damit verbundenen Geschäftsanforderungen erfüllt werden. Die in Service Transition beschriebenen Prozesse lassen sich in die zwei Gruppen aufteilen: Prozesse, die den gesamten Service Lifecycle unterstützen Prozesse innerhalb des Service Transition Die Gruppe Prozesse, die den Service Lifecycle unterstützen enthält einerseits wichtige Prozesse innerhalb von Service Transition, aber diese Prozesse unterstützen darüber hinaus alle Service Lifecycle-Phasen (siehe Abbildung 7). Diese Prozesse sind: Service Asset und Configuration Management Knowledge Management Change Management Dagegen sind die folgenden Prozesse auf die Phase Service Transition fokussiert: Transition Planning and Support Release and Deployment Management Service Testing and Validation Evaluation Mit der Aufgabe, Informationen zu den Configuration Items zur Verfügung zu stellen, ist es offensichtlich, dass das Service Asset und Configuration Management über alle Phasen des Service Lifecycle seine Anwendung findet. Denn diese Informationen können das Serviceportfolio innerhalb von Service Strategy betreffen, Informationen für das Service Design enthalten, die Auswirkungsanalyse von Changes innerhalb Service Transition unterstützen, bei Service Operation einen Known Error für das Incident Management liefern und für die Phase Continual Service Improvement notwendige Daten zu einem SLA bereitstellen. Der Prozess Knowledge Management ist mit der Version 3 erstmalig in den ITIL Best Practices dokumentiert. Seine Zielsetzung besteht in der Bereitstellung von Wissen und der damit verbundenen Effizienzsteigerung. Innerhalb der IT-Organisation fällt eine Unmenge von Daten an, die es gilt, für sämtliche Phasen des Service Lifecycle verfügbar zu machen. Hierzu sind aus den Daten Informationen und Wissen zu generieren, das dann für das Management als Entscheidungsgrundlage genutzt werden kann. Dieses notwendige Wissen soll im Knowledge Management durch 35

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

47 2.4 Die Struktur gemäß ITIL Version 3 Kommunikation, Entscheidungen und Aktionen Kommunikation, Eskalationen für RFCs, Risiken, Erteilung Change Autorisierung Beispiele für betroffene Configuration-Ebene Business Executive Board Hohe Kosten/Risiken Change erfordert Entscheidung von Executive IT Management Board Change wirkt sich auf mehrere Services oder organisatorische Abteilungen aus CAB oder ECAB Change wirkt sich nur lokal oder auf Service-Gruppe aus Lokale Autorisierung Standard Change Abbildung 19: Autorisierungsebenen für Changes Sobald die Changes bzw. das Release in den operativen Betrieb übergeleitet sind, wird der neue oder geänderte IT Service innerhalb einer bestimmten Zeitspanne unterstützt und dann an Service Operation übergeben ( Early Life Support ) Service Operation In dieser Phase geht es um das Management des Service-Betriebs (Service Operation). Sie enthält Anleitungen für effektive und effiziente Lieferung und Support der IT Services, um den gewünschten Wert für die Kunden und den Service Provider sicherzustellen. Die strategischen Ziele werden in dieser letzten Stufe letztendlich durch Service Operation realisiert, was seine kritische Bedeutung erkennen lässt. Die Anforderungen an neue oder zu verändernde IT Services werden innerhalb von Service Strategy auf Basis der Kunden- und Marktanforderungen getroffen. Innerhalb von Service Design und Service Transition werden die IT Services entwickelt und in den Betrieb übergeleitet. Aber innerhalb von Service Operation wird der IT Service dem Kunden zur Verfügung gestellt und in dessen Geschäftsprozesse integriert. Hier wird der IT Service nutzbar und liefert den erwarteten Mehrwert. So kann Service Operation mit einer Produktionsstätte verglichen werden, in der der IT Service ausgeliefert wird. Siehe hierzu die Darstellung der Phasen des Hier wird der IT Service für den Kunden erleb- und nutzbar 37

48 2 IT Service Management Service Lifecycle und die Schnittstellen zum Kunden ([Basis der Abbildung 20 in Continual Service Improvement [OGC, 2007e]): Business (Geschäftsanforderungen) / Kunden Service Strategy Anforderungen IT Services Service Portfolio Service Design Service Katalog Service Transition Service Operation Operationelle Services Continual Service Improvement Improvement Pläne u. Aktionen Abbildung 20: Service Operation im Service Lifecycle Auch in dieser Phase des Service Lifecycle steht nach wie vor im Vordergrund, die IT Services am Bedarf des Business auszurichten. Hierzu müssen Aktivitäten und Prozesse so koordiniert und ausgeführt werden, dass die vereinbarten Service Level-Ziele eingehalten werden. Angestrebt wird ein stabiler Service-Betrieb, um Änderungen an Design, Skalierung und Inhalt der Services und die Einhaltung der Service Level- Ziele zu erlauben. Inhalte der Betrachtungen zu Service Operation sind u.a.: die Grundkonflikte in Service Operation die Prozesse innerhalb von Service Operation die Schnittstellen zu den anderen Phasen des Service Lifecycle die Funktionen innerhalb von Service Operation Service Operation beschreibt mit den vier Grundkonflikten: interne IT-Sicht versus der externen Sicht, 38

49 Stabilität versus Fähigkeit, auf Änderungswünsche einzugehen, Servicequalität versus Servicekosten und reaktive versus proaktive Organisation 2.4 Die Struktur gemäß ITIL Version 3 die Herausforderungen für den IT-Betrieb. Zwischen den konkurrierenden Anforderungen wie Stabilität und der Fähigkeit, auf Änderungswünsche des Kunden einzugehen, gilt es, für die eigene IT-Organisation eine angemessene Balance zu finden. Steht zum Beispiel die Stabilität zu sehr im Vordergrund, so werden die Änderungswünsche des Kunden nicht rechtzeitig umgesetzt, und die IT-Unterstützung für die Geschäftsprozesse wird als unzureichend angesehen. Werden aber alle Änderungswünsche sehr schnell umgesetzt, so besteht die Gefahr eines instabilen IT-Betriebs. Innerhalb von Service Operation kann hinsichtlich der geeigneten Ausprägung kein Patentrezept geliefert werden, sondern es werden für die jeweilige Betrachtung mögliche Risiken beschrieben und Best Practices beschrieben, wie sich die Balance erzielen lässt. Auch für die Phase Service Operation werden Best Practices notwendiger Prozesse beschrieben. Die Anzahl der Prozesse wird gegenüber der ITIL V2 erweitert. Das Zusammenwirken der Service Operation Prozesse ist in der Abbildung 21 aus [OGC, 2007f] dargestellt. Service Transition Early Life Support Request Lösen/Wiederherstellen Incident Monitoring/Aktionen Event Fulfilment Management Management Service Performance Reports Stabilität Qualität Monitor Control Kreislauf Performance Qualität zu Kosten Feedback Service Operation Operationeller Change Problem Technologie Access Continual Service Improvement Abbildung 21: Service Operation-Prozesse Mit der Version 3 beschreibt ITIL erstmalig das Event Management als Service Management-Prozess. Dieser Prozess ist aber in vielen IT-Organisationen seit Jahren etabliert (= Best Practice). Die Aufgabenstellung besteht in dem Hinterlegen von Alarmen in IT-Systemen, die auf bestimmte Ereignisse reagieren. Ein Alarm könnte zum Beispiel generiert werden, wenn 39

50 2 IT Service Management die freie Kapazität eines Speicherbereichs einen Grenzwert erreicht. Dadurch kann in Service Operation schneller reagiert werden, und die Servicequalität wird verbessert. Können zu einzelnen Events automatisierte Aktionen hinterlegt werden, so trägt das Event Management zu einer Verringerung der Aufwendungen in Service Operation bei. ITIL stellt bei der Beschreibung heraus, dass ein Event einen Incident, ein Problem oder einen Change generieren kann. In den meisten Fällen wird ein Event zu einem Incident Record führen. Das Ziel des Incident Management mit der Wiederherstellung des normalen Service-Betriebs ist gegenüber der Version 2 unverändert geblieben. Der normale Service-Betrieb ist hier als Einhaltung der Vorgaben aus den SLAs zu verstehen. Da es im Rahmen der Umsetzung der ITIL Best Practice noch Abgrenzungsschwierigkeiten zwischen Incident und Problem gibt, wird in der Version 3 deutlich herausgestellt, dass ein Incident immer ein Incident bleibt. Ein Incident kann ein zusätzliches Problem hervorrufen, wandelt aber niemals seinen Status oder seine Eigenschaft in ein Problem. An Service Operation werden von den Anwendern aber nicht nur Incidents herangetragen, sondern auch so genannte Service Requests. Service Request Eine Anfrage eines Anwenders nach Informationen, Beratung, einem Standard- Change oder nach Zugriff auf einen IT Service. Dabei könnte es sich beispielsweise um das Zurücksetzen eines Passworts oder die Bereitstellung standardmäßiger IT Services für einen neuen Anwender handeln. Service Requests werden in der Regel von einem Service Desk bearbeitet und erfordern üblicherweise nicht die Einreichung eines RfC. Mit dem Request Fulfilment wird ein Prozess beschrieben, in dem diese Service Requests bearbeitet werden. Dieser Prozess wurde in den früheren Versionen von ITIL zwar nicht beschrieben, aber in vielen IT-Organisationen existiert dieser Prozess bereits und wird zum Teil als Anforderungs- Management bezeichnet. Während das Incident Management den IT Service schnellstmöglich wiederherstellen soll, hat das Problem Management die zugrunde liegende Ursache zu identifizieren und Bekannte Fehler (Known Error) zu dokumentieren, so dass das Incident Management auf dieses Wissen zurückgreifen und auftretende Störungen schneller beheben kann. Gegenüber der ITIL Version 2 wurde das proaktive Problem Management in die Phase des Continual Service Improvement verlagert. 40

51 2.4 Die Struktur gemäß ITIL Version 3 Die folgende Abbildung 22 zeigt den Zusammenhang zwischen Event, Incident und Problem Management sowie dem Request Fulfilment (aus [KESS, 2007c]): Event Management Event Incident Incident Management Service Request Request Fulfilment Change Record Workaround Known Error Record Known Error Datenbank Problem Management Abbildung 22: Prozesse aus Service Operation Mit dem Access Management wird ein zusätzlicher Prozess beschrieben, der für die Zulassung der Nutzung von IT Services verantwortlich ist; insbesondere im Rahmen der stetig steigenden Compliance Anforderungen eine sehr wichtige Aufgabenstellung innerhalb von Service Operation. Neben diesen innerhalb von Service Operation etablierten Prozessen werden die Prozessaktivitäten beschrieben, die in den anderen Phasen des Service Lifecycle beheimatet sind, beispielhaft wird auf Aktivitäten von Service Operation im Rahmen des Change Management eingegangen. Für die Organisation des Service Operation beschreibt ITIL als Organisationseinheiten so genannte Funktionen, innerhalb derer bestimmte Aktivitäten durchzuführen sind. Die folgende Abbildung 23 stellt diese Funktionen dar (aus [OGC, 2007d]): 41

52 2 IT Service Management Service Desk Technical Management IT Operations Management Application Management Operations Control Facility Management Abbildung 23: Service Operation-Funktionen Der Service Desk ist der Single Point of Contact (SPOC) für die Kommunikation zwischen Service Provider und Anwendern. Ein Service Desk bearbeitet in der Regel Incidents und Service Requests und ist für die Kommunikation mit den Anwendern zuständig. Das Technical Management ist verantwortlich für die Bereitstellung von technischem Fachwissen zur Unterstützung von IT Services und für das Management der IT- Infrastruktur. Das IT Operations Management führt die täglichen Aktivitäten durch, die zur Verwaltung von IT Services und Unterstützung der IT-Infrastruktur erforderlich sind, wie zum Beispiel Backup und Restore. Das Application Management ist für die Verwaltung von Anwendungen während ihres gesamten Lebenszyklus verantwortlich Continual Service Improvement ITIL fordert IT Service Provider nicht nur dazu auf, konsistente und wiederholbare Prozessaktivitäten anzustreben, um Service-Qualität zu demonstrieren, sondern geht darüber hinaus und fordert als Teil der angestrebten Service-Qualität einen Prozess permanenten Strebens nach Verbesserungen. Primärer Zweck des Continual Service Improvement (CSI) (vgl. [OGC, 2007e]) ist die kontinuierliche Anpassung der IT Services an die sich ständig verändernden Anforderungen aus den Geschäftsprozessen. Ziel ist es, sowohl Prozess-Effektivität und -Effizienz als auch Kosten-Effektivität zu verbessern. Insofern geht es um die Aufrechterhaltung und Verbesserung des Business Value für den Kunden im Hinblick auf Design, Überleitung (Transi- 42

53 2.4 Die Struktur gemäß ITIL Version 3 tion) und Betrieb (Operation) der IT Services. Aber auch die Service Strategy erfährt aus dem Continual Service Improvement ein Feedback. Siehe hierzu die übergreifende Aufgabenstellung des Continual Service Improvement auf Basis der Darstellung in Continual Service Improvement, [OGC, 2007e] (siehe Abbildung 24). Continual Service Improvement Messung Bewertung/Feedback Messung Bewertung/Feedback Service Transition Service Design Service Strategy Service Operation Messung Bewertung/Feedback Abbildung 24: Continual Service Improvement Sharon Taylor, Chief Architect des Refresh Programms zur ITIL V3, verglich den Service Lifecycle mit einem Rad, wobei das Rad vom Continual Service Improvement umgeben wird, den gesamten Service Lifecycle durchdringt und für die Fortbewegung steht und einen Beharrungszustand innerhalb der IT-Organisation verhindert. Für eine optimale Unterstützung der Geschäftsprozesse müssen die IT Services und die IT Service Management-Prozesse nach klar definierten Zielen und mit relevanten Messsystemen implementiert, verwaltet und unterstützt werden. Hierfür ist es außerordentlich kritisch und wichtig zu verstehen, was gemessen und warum es gemessen werden muss und Erfolgsfaktoren sorgfältig zu definieren. ITIL führt zu Messung und Management aus: 43

54 2 IT Service Management Sie können nichts managen, was Sie nicht kontrollieren können. Sie können nichts kontrollieren, was Sie nicht messen können. Sie können nichts messen, was Sie nicht steuern können. Grundvoraussetzung für ein wirksames IT Service Management sind definierte Ziele. Nur wer in der Lage ist, die Ziele für einen Prozess oder einen IT Service eindeutig zu formulieren, kann den Prozess oder den IT Service messen und so feststellen, ob die Ziele erreicht wurden oder ob ein Verbesserungsbedarf besteht. Die grundsätzliche Aufgabenstellung des Continual Service Improvement ist der folgenden Abbildung 25 zu entnehmen (Darstellung aus The Official Introduction to Service Lifecycle ([OGC, 2007f]): Service Performance Reports Service Operation Baseline & Metriken Daten-Analyse Korrektive Aktionen Continual Service Improvement Service Messung Definition Metriken 7 Step Improvement Service Reporting Analyse Verbessern Service Improvement Plan Abbildung 25: Service Transition-Prozesse Das wesentliche Element von Continual Service Improvement ist die Messung von IT Services, Prozessen und Service Assets. Der Hauptgrund für Messungen besteht darin, die gesetzten Ziele erreichen zu können. Durch Messungen werden mögliche Abweichungen frühzeitig erkannt, und das Management ist in der Lage, frühzeitig gegensteuern zu können. Andererseits kann eine Übererfüllung vermieden und so die Effizienz sichergestellt werden. Darüber hinaus können Messungen auch den Erfolg durchgeführter Maßnahmen bestätigen und so für das Reporting gegenüber dem Kunden oder innerhalb des Service Providers genutzt werden. Ein wichtiger Ausgangspunkt, um einen Verbesserungsbedarf herauszustellen und den Erfolg einer durchgeführten Verbesserung zu bestätigen, besteht in der Etablierung einer definierten Ausgangsbasis (Baseline). 44

55 2.4 Die Struktur gemäß ITIL Version 3 Baseline: Ein Benchmark, der als Referenzpunkt verwendet wird. Beispiel: Mit einer ITSM-Baseline als Ausgangspunkt können die Folgen eines Serviceverbesserungsplans gemessen werden. Mit einer Performance Baseline können Änderungen in der Performance während der Lebensdauer eines IT Service gemessen werden. Der 7-Step Improvement-Prozess ist der primäre Prozess innerhalb des Continual Service Improvement (Einzelheiten zum Prozess siehe Abschnitt Continual Service Improvement ). Dieser Prozess hat zum Ziel, über Daten zu gesicherten Informationen zu gelangen. Durch Analyse dieser Informationen sind anschließend geeignete Verbesserungsmaßnahmen zu implementieren. Im Rahmen dieses 7-Step Improvement-Prozesses werden sowohl strategische, als auch taktische und auch operative Ziele verfolgt und beleuchtet, die innerhalb von Service Strategy und Service Design definiert wurden. Die identifizierten Verbesserungsmaßnahmen werden in dem Service Improvement-Plan (SIP) dokumentiert; einem Dokument, das ebenfalls in Qualitätsmanagementsystemen wie der ISO 9001 und der ISO gefordert wird. Wichtig für das Selbstverständnis dieser Phase des Service Lifecycle ist auch hier Business-Orientierung. Diese Orientierung zum Kunden und dessen Geschäftsprozessen besteht im Wesentlichen aus zwei Betrachtungsbereichen. Eine Messung der IT-Systeme hinsichtlich der Verfügbarkeit und Performance ist für jeden Service Provider selbstverständlich. ITIL spricht hier von technologischen Messungen. Auch die Messung der IT Service Management-Prozesse findet zunehmend Anwendung, die so genannten Prozess-Messungen. Aber hierbei handelt es sich in der Regel um eine ITinterne Sicht und Messung. Für den Kunden ist es viel wichtiger, ob die gelieferten IT Services den Vereinbarungen entsprechen und die Service Level-Ziele erreicht werden. Hierzu ist eine Messung der IT Services (aus Sicht des Kunden bzw. Geschäftsprozesses) notwendig. ITIL betont hier: Service-Messungen: Diese Messungen sind das Ergebnis eines end-to-end -Service. Ohne funktionierende IT Services können viele Geschäftsprozesse nicht mehr durchgeführt werden. Daher ist die Messung einzelner Komponenten wie Server oder Datenbanken nicht mehr ausreichend. Der IT Service ist als Ganzes zu betrachten und zu messen. Die folgenden drei Messungen finden hierbei in der Regel ihre Anwendung: 45

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

57 2.4 Die Struktur gemäß ITIL Version 3 Das Business Definition Reporting Policies und Rollen Sammlung Businesssichten Service Reporting Übersetzung und Anwendung Publikation Abbildung 26: Service Reporting orientiert am Kundenbedarf Das Continual Service Improvement hat vielfältige Schnittstellen zu den anderen Phasen des Service Lifecycle. Ein Schlüsselprozess ist der bereits beschriebene Prozess des Service Level Managements. Eine weitere wichtige Schnittstelle besteht zum Service Design, denn dort sind die notwendigen Messverfahren beim Design des IT Service zu berücksichtigen und zu entwickeln Der prozessorientierte Ansatz von ITIL Version 3 Mit der aktuellen ITIL Version 3 hat sich nicht nur der Scope des Service Managements erweitert, sondern auch die Anzahl der beschriebenen Service Management-Prozesse. Diese Erweiterung der bestehenden Prozesse betrifft insbesondere die Phase Service Transition. Bei den ITIL-Publikationen der Version ITIL Version 3 sind dies in den Publikationen Service Design, Service Transition, Service Operation und Continual Service Improvement insgesamt 26 IT Service Management-Prozesse (vgl. [OGC, 2007b-e]). Hinzu kommen aus der Phase Service Strategy noch die Aufgaben des Financial Managements, des Service Portfolio Managements und des Demand Managements, die ebenfalls als Prozesse anzusehen sind. 47

58 2 IT Service Management Diese umfangreiche Erweiterung mag den Leser vielleicht zunächst erschrecken, dabei darf aber nicht außer Acht gelassen werden, dass ein Teil dieser Prozesse in ITIL Version 2 bereits in anderen, weniger beachteten Publikationen, wie zum Beispiel Applikation Management oder ICT Infrastructure Management beschrieben waren. Andererseits sind nun Prozesse dokumentiert, die in vielen Organisationen bereits so implementiert sind, wie zum Beispiel das Event Management zur Entdeckung und Interpretation von Ereignissen, die über entsprechende Tools generiert und behandelt werden. Mit der ITIL Version 3 werden das notwendige Prozess-Management und die damit verbundenen Aspekte stärker hervorgehoben. Als Prozess wird definiert (vgl. Service Design, [OGC, 2007b]): Prozess: Ein strukturierter Satz an Aktivitäten, mit deren Hilfe ein bestimmtes Ziel erreicht werden soll. Ein Prozess wandelt einen oder mehrere definierte Inputs in definierte Outputs um. Ein Prozess kann beliebige Rollen, Verantwortlichkeiten, Hilfsmittel und Steuerungen für das Management enthalten, die für eine zuverlässige Bereitstellung der Outputs erforderlich sind. Ein Prozess kann den Anforderungen entsprechend Richtlinien, Standards, Leitlinien, Aktivitäten und Arbeitsanweisungen definieren. Prozesse weisen gemäß ITIL Version 3 die folgenden Merkmale auf: Messbar: Die Prozesse sind in einer relevanten Art zu messen. Prozesse sind leistungsgetrieben. Manager wollen Kosten, Qualität und andere Variable messen, während sich die Ausführenden mit Dauer und Produktivität beschäftigen. Spezifizierte Ergebnisse: Prozesse existieren, um ein bestimmtes Ergebnis zu liefern: Dieses Ergebnis muss individuell identifizierbar und zählbar sein. Kunden: Jeder Prozess liefert einem Kunden oder einer Interessengruppe seine Ergebnisse. Der Prozess muss den Erwartungen der internen oder externen Kunden entsprechen. Reagieren auf bestimmte Ereignisse: Da ein Prozess fortlaufend oder sich wechselseitig beeinflussend sein kann, sollte er zu einem spezifischen Trigger verfolgbar sein. Mit der ITIL Version 3 wurde das bestehende Prozessmodell umfassender beschrieben und dargestellt (im Hauptteil des Buches und nicht im Anhang) vgl. Service Design, [OGC, 2007b] (siehe Abbildung 27). 48

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

60 2 IT Service Management ITIL Version 3 sieht in den Prozessen entsprechende Metriken vor, die als Prozesskennzahlen ein Feedback zur Prozessdurchführung liefern. Effektivität und Effizienz eines Prozesses Der Output eines Prozesses muss den betrieblichen Anforderungen entsprechen, die aus den Geschäftszielen abgeleitet sind. Werden diese Anforderungen hinsichtlich des Outputs erreicht, so ist die Effektivität des Prozesses sichergestellt. Werden die damit verbundenen Aktivitäten mit einem minimalen Ressourceneinsatz durchgeführt, so ist die notwendige Effizienz gegeben. Prozessanalysen, Metriken und Prozessergebnisse sind in 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. Die Vielzahl mag den Eindruck erzeugen, hierfür auch eine Vielzahl von Mitarbeitern mit deren Verantwortung betrauen zu müssen. Dabei betont ITIL ausdrücklich, dass ein Mitarbeiter durchaus die Verantwortung mehrerer Prozesse wahrnehmen kann. Dabei muss allerdings sichergestellt werden, dass diese Prozesse nicht zu einem Interessenkonflikt führen. Rollen: Ein Satz von Verantwortlichkeiten, Aktivitäten und Kompetenzen, die einer Person oder einem Team zugewiesen sind. Eine Rolle wird in einem Prozess definiert. Einer Person oder einem Team können mehrere Rollen zugewiesen sein. Die Rolle des Configuration Managers und des Change Managers können beispielsweise von ein und derselben Person wahrgenommen werden. Bezüglich der Verantwortung für die Prozesse stellt die ITIL Version 3 folgende Anforderungen (vgl. Service Design, [OGC, 2007b): Jedem Prozess ist ein Process Owner 2 zugeordnet, der für die Zielereichung und die Verbesserung verantwortlich ist. Die Prozessziele sind in messbarer Hinsicht zu definieren und stehen in Bezug mit den Vorteilen für das Business und der zugrunde liegenden Unternehmensstrategie. 2 Im deutschen Glossar wird die Rolle als Process Owner definiert und nicht als Prozess Owner 50

61 2.4 Die Struktur gemäß ITIL Version 3 Während in der ITIL Version 2 keine exakte Definition und Beschreibung für den Process Owner und Prozess-Manager existieren, werden in der ITIL Version 3 diese Rollen definiert und unterschieden: Process Owner: Eine Rolle, verantwortlich für die Sicherstellung der Zweckmäßigkeit eines Prozesses. Zu den Verantwortlichkeiten des Process Owners gehören das Sponsoring, das Design, das Change Management sowie die kontinuierliche Verbesserung des Prozesses und seiner Messgrößen. Diese Rolle wird häufig derselben Person zugewiesen, der bereits die Rolle des Prozess-Managers zugewiesen ist. In größeren Organisationen können diese Rollen jedoch separat zugewiesen sein. Prozess-Manager: Eine Rolle, die für das operative Management eines Prozesses verantwortlich ist. Zu den Verantwortlichkeiten des Prozess-Managers gehören die Planung und die Koordination aller Aktivitäten, die zur Ausführung, dem Monitoring und der Berichtserstellung in Bezug auf einen Prozess erforderlich sind. Es können mehrere Prozess-Manager für einen Prozess vorhanden sein, z. B. regionale Change Manager oder IT Service Continuity Manager für jedes Rechenzentrum. Die Rolle des Prozess-Managers wird häufig der Person zugewiesen, der bereits die Rolle des Process Owners zugewiesen ist. In größeren Organisationen können diese Rollen jedoch separat zugewiesen sein. Process Owner und Prozess- Manager Um das Zusammenspiel zwischen den Prozessen und der Aufbauorganisation zu beschreiben, nutzt ITIL hierfür den Begriff der Funktion. Funktion: Ein Team oder eine Gruppe von Personen und die Hilfsmittel, die eingesetzt werden, um einen oder mehrere Prozesse oder Aktivitäten durchzuführen. Ein Beispiel dafür ist das Service Desk. Diese Funktionen (Organisationseinheiten) sind ausgestattet mit Fähigkeiten und Ressourcen (Service Assets) und bringen Struktur und Stabilität in die IT-Organisation. In der Regel wurden Funktionen technologisch definiert, wie zum Beispiel die Gruppe für das LAN. Dadurch besteht aber auch die Gefahr der Bildung von Funktionssilos, die den externen Bezug verlieren und eine Tendenz zur internen Optimierung bilden. Durch die Prozesse wird eine Koordination zwischen Funktionen ermöglicht, werden die IT Services den Bezug zum Kunden sicherstellen. 51

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

63 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Anteil der Störungen, die innerhalb der vereinbarten Reaktionszeit bearbeitet wurden Höhe der durchschnittlichen Kosten pro Störung Lösungsrate von Störungen im Service Desk Anzahl der bearbeiteten Störungen pro Arbeitsplatz im Service Desk Anzahl und Anteil der Störungen, die remote (d.h. ohne Vor-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); d.h. Zeitdauer vom Auftreten eines entsprechenden Problems bis zur Identifizierung des Bekannten Fehlers Anzahl und Auswirkung von Störungen, bevor das zugrunde liegende Problem gelöst ist Häufigkeit der Probleme unterteilt nach Status, IT Service, Auswirkung, Kategorie und Kunde Durchschnittliche und maximale Zeitdauer bis zum Abschluss des Problems Configuration Management Das Configuration Management dient der Definition, Kontrolle, Pflege und Verifizierung der Service- und Infrastrukturkomponenten sowie der Verwaltung korrekter Konfigurationsinformationen. 53

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

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

66 2 IT Service Management Anzahl der Kapazitätsanforderungen, die nicht im Kapazitätsplan enthalten sind Reduzierung von Überkapazitäten IT Service Continuity Management Das Ziel des IT Service Continuity Managements ist die Unterstützung des übergreifenden Business Continuity Managements, durch die gesicherte Wiederherstellbarkeit von IT Services innerhalb der erforderlichen und vereinbarten Zeit. Wesentliche Leistungsindikatoren gemäß der ITIL Best Practices sind: Anzahl festgestellter Mängel am IT Service Continuity-Plan Zeitspanne zwischen Änderungen mit Auswirkungen auf den IT Service Continuity-Plan und der Aktualisierung des Plans Anzahl durchgeführter Übungen / Tests des IT Service 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örungen aufgrund der Nicht-Verfügbarkeit Abweichung zwischen geplanter und tatsächlicher Verfügbarkeit Dauer der Nichtverfügbarkeit Security Management Ziel des Security Managements ist es, einen definierten Grad an Sicherheit für die Informationen und IT Services zu gewährleisten. Hierzu zählt einerseits die Erfüllung der Sicheranforderungen aus den SLAs und anderer externer Anforderungen. Andererseits ist ein definierter Grundschutz zu schaffen. Die Publikation ITIL Best Practice für Security-Management spezifiziert für diesen Prozess keine Leistungsindikatoren (vgl. [OGC, 2006a]). Die ITIL Best Practices zum Security-Management verfolgen das Konzept, dass die Sicherheitsanforderungen, bestehend aus Verfügbarkeit, Vertraulichkeit und Integrität, als Service Level-Ziele innerhalb der SLAs mit dem Kunden vereinbart werden. Diese Sicherheitsanforderungen gehen ein in die OLAs (Operational Level Agreements) und UCs (Underpinning Contracts). 56

67 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Die Leistungsindikatoren des Security-Managements entsprechen demzufolge den übrigen Service Level-Zielen eines SLA / OLA / UC und sind eine Ausprägung der Service-Berichte. Aus der Prozessaktivität Berichtswesen können folgende Leistungsindikatoren abgeleitet werden: Anteil von SLAs, OLAs und UCs mit Sicherheitsverletzungen Anzahl von Security-Incidents Reaktionszeit auf Security-Incidents Prozesse und ausgewählte Kennzahlen der ITIL Version 3 Wenn man sich mit den Kennzahlen der ITIL Version 3 beschäftigt, spielen die 5 Phasen des Service Lifecycle mit ihren entsprechenden Prozessen die grundlegende Rolle. Die aus der ITIL Version 2 bekannten Prozesse haben wir in Abbildung 28 hervorgehoben. Dabei wird deutlich, dass einige Prozesse der ITIL Version 2 teilweise hinsichtlich der Ziele und Aufgabenstellung verändert wurden. So werden zum Beispiel die Service Requests nicht mehr im Incident Management bearbeitet oder Aufgaben des Service Level Managements aus der ITIL Version 2 finden sich in anderen, neuen Prozessen wieder. Bei den aus der ITIL V2 bekannten Prozessen gilt es aber zu beachten, dass diese Prozesse zum Teil verändert wurden. So finden sich Inhalte aus dem Service Level Management gemäß der ITIL V2 nun in den Prozessen Service Katalog Management, Service Level Management, Supplier Management und Service Reporting wieder. Diese durchgeführten Anpassungen gegenüber der ITIL Version 2 haben auch Auswirkungen auf die damit verbundenen Kennzahlen und Metriken, deren Definition und deren Vergleichbarkeit. Im Folgenden werden die 5 Phasen des Service Lifecycle mit ihren Prozessen vorgestellt und die seitens der ITIL Best Practices dokumentierten Key Performance-Indikatoren beispielhaft beschrieben. 57

68 2 IT Service Management 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 28: Die 5 Phasen des Service Lifecycle und ihre Prozesse 58

69 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Service Strategy Service Portfolio M. Service Strategy Demand M. Financial Management Abbildung 29: Service Strategy Die Publikation Service Strategy ([OGC, 2007a]) weicht von den übrigen vier Publikationen dahingehend ab, dass sie kein Kapitel Prozesse enthält. Im Rahmen des Kapitels Service Economics werden Aspekte beschrieben, die einen Charakter von Prozessen haben. Als Prozesse sind dabei das Financial Management, das Service Portfolio Management und das Demand Management anzusehen. Innerhalb der Service Strategy werden in ITIL V3 zu den Prozessen keine Kennzahlen ausgewiesen. Financial Management Financial Management quantifiziert IT Services, ihre zugrunde liegenden Assets und sogar operationelle Vorhersagen mit Metriken aus der Finanz- Terminologie. Die Frage, die hier im Raum steht, ist die nach dem Wert für das Business und die zugrunde liegende IT. Auf strategischer Ebene ist über die Entwicklung von IT Services und den damit verbundenen Mehrwert zu entscheiden. Hierzu ist für den jeweiligen IT Service der Business Case zu betrachten. Der Business Case beinhaltet Informationen zu Kosten, Nutzen, Optionen, offenen Punkten, Risiken und möglichen Problemen. Es gibt einen Wandel in der Wahrnehmung der IT und ihres Wertes für das Business. Financial Management hilft bei der Identifizierung, Dokumentation und Akzeptanz des Wertes des erhaltenen IT Service und ermöglicht die Modellierung und das Management von Service-Anforderungen. 59

70 2 IT Service Management Das Financial Management ist innerhalb von Service Strategy beschrieben, aber die finanziellen Aspekte sind grundsätzlich ein übergreifendes Thema, in dem viele Bereiche eines Unternehmens interagieren wie zum Beispiel das Change Management in der Bewertung von Requests for Change (RfC). Durch diesen übergreifenden Ansatz des Financial Managements wird sichergestellt, dass die Investitionen in IT Services so getätigt werden, dass der gesamte Wert und die gesamten Kosten über den gesamten Service Lifecycle betrachtet werden. Ein wichtiger Nutznießer des Financial Managements ist das Service Portfolio Management. Auf Basis der Informationen aus dem Financial Management können zum Beispiel Entscheidungen über ein Outsourcing von Leistungen besser getroffen werden. Financial Management: Die Funktionen und die Prozesse mit der Verantwortung für den Umgang mit den Anforderungen eines IT Service Providers an die Budgetierung, die Kostenrechnung und die Leistungsverrechnung. Service Portfolio Management Ein Serviceportfolio beschreibt die IT Services eines IT Service Providers im Hinblick auf deren Wert für die Geschäftsprozesse (Business Value). Service Portfolio Management formuliert die geschäftlichen Anforderungen und ist die Antwort des IT Service Providers auf diese Bedürfnisse. Die Definition des Serviceportfolios ist eine der wichtigsten Aufgaben innerhalb von Service Strategy. Das Serviceportfolio enthält nicht nur alle in Nutzung befindlichen IT Services (= Servicekatalog), sondern auch alle beantragten und in Entwicklung befindlichen IT Services (= Servicepipeline) sowie sämtliche IT Services, die außer Kraft gesetzt sind. Mit dem Service Portfolio Management stellt der IT Service Provider die mittel- und langfristige wirksame Integration seiner IT Services in die Geschäftsprozesse des Kunden und die Generierung eines Mehrwertes für die Business-Prozesse sicher. Der IT Service Provider wird so in die Lage versetzt, frühzeitig seine IT Services an den Marktanforderungen auszurichten. Aber auch nicht mehr bzw. zukünftig nicht mehr gefragte IT Services werden identifiziert und deren Außerkraftsetzung festgelegt. Damit verbunden werden Ressourcen freigesetzt, die für andere IT Services genutzt werden können, und ansonsten notwendige Investitionen werden vermieden. Der Prozess besteht aus den Aktivitäten Definition, Analyse, Freigabe und Ausgestaltung. Innerhalb der Definition gilt es, die bestehenden IT Services und Anforderungen zu analysieren. Hierzu wird für 60

71 2.5 ITIL Kennzahlen für IT Service Management-Prozesse jeden IT Service der Business Case definiert. Bei der Analyse wird der Inhalt der Servicestrategie festgelegt. Hierzu werden die langfristigen Ziele festgelegt und ermittelt, welche IT Services hierzu notwendig sind. In Verbindung mit diesen IT Services sind die damit verbundenen Ressourcen und Fähigkeiten zu spezifizieren. Mit einer Betrachtung zwischen dem Wert für das Business und den damit in Verbindung stehenden Kosten können IT Services priorisiert werden. Die Freigabe stellt die Autorisierung des Serviceportfolios sicher. Nach der Freigabe stellt die Aktivität Ausgestaltung sicher, dass die IT Services kommuniziert und die damit verbundenen Ressourcen eingeplant werden. Das Serviceportfolio wird für das Management über den gesamten Lifecycle aller IT Services genutzt. Service Portfolio Management: Der Prozess, der für das Management des Serviceportfolios verantwortlich ist. Beim Service Portfolio Management steht der Wert der Services im Vordergrund, den diese für das Business darstellen. Demand Management Demand Management behandelt kritische Aspekte des Service Managements: Unsicherheiten bei der Anforderungsaufnahme bergen Risiken für IT Service Provider, wie Überkapazitäten oder ungenügende Kapazitäten mit Auswirkung auf die Qualität der Services. Service Level Agreements, Vorhersagen, Planung und feste Koordination mit dem Kunden können die Unsicherheiten bei den Anforderungen reduzieren, diese aber nicht vollständig eliminieren. Ausgangspunkt des Demand Managements sind die Business Prozesse und deren Aktivitäten. Auf Basis einer differenzierten Analyse der Servicenachfrage einzelner Businessaktivitäten können zum Beispiel die IT Services innerhalb von Service Design besser entwickelt werden, und das Service Portfolio Management kann Investitionen in zusätzliche Kapazitäten, neue IT Services oder zu ändernde IT Services rechtfertigen. Mit der Identifizierung der zukünftigen Aktivitäten innerhalb der Business-Prozesse liefert das Demand Management einen wichtigen Beitrag zur angemessenen Ausgestaltung der IT Services. Überkapazitäten werden vermieden und dadurch die Kosten für den jeweiligen IT Service reduziert. Andererseits werden Unterkapazitäten vermieden, so dass die Business Prozesse nicht in Mitleidenschaft gezogen und planmäßig durchgeführt werden können. 61

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

73 Service Catalogue Management 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Ziel des Prozesses Service Catalogue Management (SCM) ist die Erstellung und Pflege eines Servicekatalogs mit genauen Informationen über alle aktuellen und geplanten operationalen Services. Hierzu werden die vom Service Portfolio Management definierten Services entsprechend spezifiziert und sind als Teilmenge bzw. konkrete Ausprägung des Serviceportfolios anzusehen. Der Servicekatalog enthält Angaben zu Lieferergebnissen, Preisen, Bestellungen und Anfragen sowie Kontaktinformationen zu allen Live IT Services, einschließlich der Services, die für das Deployment verfügbar sind. Es ist der Bereich des Serviceportfolios, der von den Kunden eingesehen werden kann. Aber nicht nur für den Kunden und den Vertrieb von IT Services ist der Servicekatalog von Bedeutung. Der Servicekatalog sollte strukturiert aufgebaut werden. Der so genannte Business-Servicekatalog beinhaltet die Details aller IT Services, die den Kunden geliefert werden, und stellt die Beziehungen zwischen den IT Services und den davon abhängigen Geschäftsbereichen und Business Prozessen dar. Nur dieser Bereich ist für den Kunden sichtbar. Ein Technischer Servicekatalog untermauert den Business-Servicekatalog mit den notwendigen technischen IT Services, die die Business-Services ermöglichen. Der Technische Servicekatalog enthält Details zu allen IT Services sowie die Beziehungen zu den unterstützenden Services, CIs, etc., die notwendig sind, den IT Service für das Business bereitzustellen. Das Service Katalog Management stellt sicher, dass sowohl die Inhalte, als auch die hinterlegte Struktur erstellt und gepflegt werden. Die seitens der ITIL Best Practices dokumentierten Key Performance- Indikatoren sind zum Beispiel: die Anzahl der aufgenommenen und verwalteten Services innerhalb des Servicekatalogs als Prozentsatz der Services, die ausgeliefert und übergeben wurden und sich in der Live-Umgebung befinden die Anzahl von Abweichungen zwischen den Informationen im Servicekatalog und der realen Welt. Service Level Management Der Service Level Management-Prozess definiert und vereinbart für alle aktuellen und zukünftigen IT Services die damit verbundenen Service Level und die erreichbaren Zielwerte (Service Level-Ziel). Außerdem stellt er sicher, dass Services auf diesem Level ausgeliefert werden. Proaktive Messungen und Reports helfen bei den notwendigen Verbesserungen zur Zufriedenheit der Kunden. 63

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

75 Capacity Management 2.5 ITIL Kennzahlen für IT Service Management-Prozesse 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. Hierzu muss das Capacity Management hinsichtlich der Kosten und Kapazitäten sowie Angebot und Bedarf einen Balanceakt durchführen. Einerseits muss das Capacity Management sicherstellen, dass die Verarbeitungskapazitäten zu vertretbaren Kosten dem Bedarf des Business nachkommen und möglichst effizient genutzt werden. Andererseits ist es die Aufgabe, dass das verfügbare Angebot der Verarbeitungsleistungen dem aktuellen und zukünftigen Bedarf des Business gerecht wird. Hierzu finden im Capacity Management drei Sub-Prozesse ihre Anwendung: Business Capacity Management (BCM): Im Kontext von ITSM die verantwortliche Aktivität, um die zukünftigen Business-Anforderungen für die Verwendung im Capacity-Plan nachzuvollziehen. Service Capacity Management (SCM): Dient der Gewinnung von Erkenntnissen zur Performance und Kapazität von IT Services. Die Ressourcen, die von jedem IT Service verwendet werden, werden für die Nutzung im Capacity-Plan erfasst, aufgezeichnet und analysiert. Component Capacity Management (CCM): Verantwortlich für die Aspekte der Kapazität, Auslastung und Performance von Configuration Items. Hier werden Daten im Capacity-Plan gesammelt, erfasst und analysiert. Die Messung und die Trendverfolgung bestehender Kapazitäten und der erzielten Performance ist die Grundvoraussetzung für diesen Prozess. Das Review derzeitiger Kapazitäten und Performance liefert den Input für deren Verbesserung. Die Beurteilung neuer Anforderungen ermöglicht eine rechtzeitige Planung neuer Kapazitäten, verhindert Panikkäufe und liefert so einen wichtigen Beitrag für kostenwirksame IT Services. Andererseits werden Performance-Engpässe vermieden. Capacity Management: Der Prozess, bei dem sichergestellt wird, dass die Kapazität der IT Services und die IT-Infrastruktur ausreicht, um die vereinbarten Service Level-Ziele wirtschaftlich und zeitnah erreichen zu können. Beim Capacity Management werden 65

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

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

78 2 IT Service Management effektives Review und Verfolgung aller Verletzungen bei SLAs, OLAs und UCs prozentuale Verbesserung in der allumfassenden end-to-end - Verfügbarkeit von Services. IT Service Continuity Management Das IT Service Continuity Management (ITSCM) unterstützt den allumfassenden Business Continuity Management (BCM)-Prozess. Es stellt sicher, dass die IT-technischen Betriebsmittel und Services (einschließlich Rechnersysteme, Netzwerke, Anwendungen, Datenbestände, Telekommunikationsanlagen, technischer Support und Service Desk) nach einem Ausfall oder einer Störung innerhalb der erforderlichen und vereinbarten Zeitgrenzen wieder in Betrieb gehen und verfügbar sind. Zielsetzung des IT Service Continuity Managements besteht nicht in der Überlebensfähigkeit der IT im Katastrophenfall, sondern darin, den ordnungsgemäßen Geschäftsbetrieb schnellstmöglich zu ermöglichen. Daher wird die Integration des IT Service Continuity Managements in das übergeordnete Business Continuity Management nicht nur ausdrücklich betont, sondern es wird auch die Verantwortung des Business Continuity Managements für einzelne Phasen im ITSCM-Prozess dokumentiert. Die Prozessphasen bestehen aus der Initiierung, Anforderung und Strategie, Implementierung und Laufender Betrieb. Die Aufgaben der Initiierung und Definitionen der Anforderungen sind vornehmlich Aktivitäten des Business Continuity Managements. Das ITSCM sollte in dieser Phase beteiligt werden, um einerseits die Aktivitäten des BCM zu unterstützten, aber primär, um die Beziehungen zwischen den Business- Prozessen und deren Bedeutung zu verstehen. Die erste wirkliche verantwortliche Aktivität des ITSCM ist es, eine Strategie zu entwickeln, die die Strategie des BCM untermauert. Voraussetzung für ein wirkungsvolles ITSCM ist die Kenntnis der bereits im Availability Management beschriebenen Analyse der Business-Auswirkungen, wenn der vereinbarte IT Service nicht zur Verfügung gestellt werden kann. Verbunden mit einer Analyse der Risiken kann eine angemessene Strategie festgelegt werden. Innerhalb der Implementierung wird diese Strategie umgesetzt und in den laufenden Betrieb integriert. Die beste Planung wird nicht funktionieren, wenn sie nicht einmalig und laufend getestet wird. Die Durchführung laufender Tests ist eine wichtige Aufgabe des laufenden Betriebs. Der Nachweis dieser Überprüfungen findet verstärkt Berücksichtigung bei Wirtschaftsprüfungen und anderen Auditierungen oder Revisionen. 68

79 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Weiterhin muss sichergestellt werden, dass das ITSCM in den Change Management-Prozess eingebunden wird und im Rahmen von geplanten Changes beurteilen kann, ob mögliche Auswirkungen auf den IT Service Continuity Plan bestehen. Im IT Service Continuity Plan sind die erforderlichen Schritte für eine Wiederherstellung eines oder mehrerer IT Services dokumentiert und identifizieren darüber hinaus die Bedingungen für das Auslösen des Plans sowie die zu berücksichtigenden Mitarbeiter. IT Service Continuity Management: Der Prozess, der für die Verwaltung von Risiken verantwortlich ist, die zu schwerwiegenden Auswirkungen auf IT Services führen können. Das ITSCM stellt sicher, dass der IT Service Provider stets ein Mindestmaß an vereinbarten Service Level bereitstellen kann, indem die Risiken auf ein akzeptables Maß reduziert werden und eine Wiederherstellungsplanung für IT Services erfolgt. Das ITSCM sollte so konzipiert sein, dass es das Business Continuity Management unterstützt. Die seitens der ITIL Best Practices dokumentierten Key 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 regelmäßige, mindestens jährliche Reviews der Business- und IT Continuity-Pläne mit den Geschäftsbereichen. Information Security Management Informations-Sicherheit muss auf das Sicherheitsbedürfnis des Business abgestimmt werden. Information Security Management verfolgt dieses Ziel über ein effektives Management der Informations-Sicherheit in allen Services und Service Management-Aktivitäten. Schon aufgrund gesetzlicher Verpflichtungen kann es sich keine Organisation leisten, die damit verbundenen Aspekte nicht zu beachten. Daher ist die Information Security eine Managementaktivität und Bestandteil des "Corporate Governance Framework. Die Information Security ist für die Assets, Informationen, Daten und IT Services einer Organisation angemessen sicherzustellen und umfasst die Aspekte der Vertraulichkeit, Integrität und Verfügbarkeit: 69

80 2 IT Service Management Vertraulichkeit: Ein Sicherheitsprinzip, das fordert, dass ausschließlich autorisierte Personen auf Daten zugreifen können. Integrität: Ein Sicherheitsprinzip, das sicherstellt, dass Daten und Configuration Items nur durch autorisierte Mitarbeiter und Aktivitäten modifiziert werden. Die Integrität berücksichtigt alle möglichen Ursachen einer Modifikation, wie Ausfälle von Software oder Hardware, Umgebungs-Events und Eingriffe durch Personen. Verfügbarkeit: Fähigkeit eines Configuration Items oder IT Service, bei Bedarf die dafür vereinbarte Funktion auszuführen. Die Verfügbarkeit wird durch Aspekte in Bezug auf Zuverlässigkeit, Wartbarkeit, Servicefähigkeit, Performance und Sicherheit bestimmt. Die Verfügbarkeit wird in der Regel als Prozentwert ausgedrückt, der häufig basierend auf der vereinbarten Servicezeit und der Ausfallzeit berechnet wird. Gemäß der Best Practice wird die Verfügbarkeit mithilfe von Messgrößen aus dem Business-Ergebnis des IT Service berechnet. Das Information Security Management System (ISMS) liefert die Basis für die Entwicklung kostenwirksamer Information Security-Programme, die die Geschäftsziele unterstützen. Das System schließt die vier Ps von Personen, Prozessen, Produkten und Partnern ein, um so sicherzustellen, dass ein hohes Niveau der Security erzielt wird. Mit der ISO "Information Security Management" existiert eine anerkannte Norm, um das Information Security Management zu zertifizieren und so dessen Implementierung nachzuweisen. Das Information Security Management System basiert auf einem Regelkreis, bestehend aus der Steuerung, Planung, Implementierung, Evaluierung und Aufrechterhaltung. Der Input in diesen Regelkreis besteht aus den in den SLAs vereinbarten Sicherheitsanforderungen. Information Security Management: Der Prozess, bei dem die Vertraulichkeit, Integrität und Verfügbarkeit der Assets, Informationen, Daten und IT Services einer Organisation sichergestellt werden. Das Information Security Management ist in der Regel Teil eines organisatorischen Ansatzes für das Security Management, der über den Aufgabenbereich des IT Service Providers hinausgeht, und berücksichtigt die Verwaltung papierbasierter Dokumente, Zutrittsrechte, Telefonanrufe etc. für die gesamte Organisation. Die seitens der ITIL Best Practices dokumentierten Key Performance- Indikatoren sind zum Beispiel: 70

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

82 2 IT Service Management Anstieg der Anzahl von Lieferanten, die vertraglich vereinbarte Ziele einhalten Anstieg der Anzahl der mit Lieferanten durchgeführten Serviceund Vertrags-Reviews Reduzierung der Anzahl von durch Lieferanten verursachten Service-Verletzungen Anstieg der Anzahl von Lieferanten mit ernanntem Lieferanten-Manager 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 31: Service Transition Transition Planning and Support Transition Planning and Support plant und koordiniert Ressourcen für eine effektive Realisierung der in Service Strategy definierten und in Service Design entwickelten und umgesetzten Anforderungen. Potentielle Risiken und Störungen der Transitions-Aktivitäten werden identifiziert und kontrolliert. Ein wirksamer Prozess Transition Planning and Support soll die Voraussetzung dafür schaffen, dass der Service Provider ein hohes Volumen von Changes und Releases bearbeiten kann. Hierzu ist die Planung von Kapazitäten und Ressourcen für die Inbetriebnahme von neuen oder geänderten Services erforderlich, so dass die Anforderungen aus Service Strategy und Service Design umgesetzt werden können. Der Prozess Transition Planning and Support deckt dazu die notwendigen Planungen im Vorfeld der Einführung von Changes und Releases ab. Um diese Anforderungen bzw. Ziele erfüllen zu können, empfiehlt ITIL eine Service Transition Policy formal zu vereinbaren. Darin soll unter anderem geregelt werden, dass alle Veränderungen (= Changes) am Service Portfolio und insbeson- 72

83 2.5 ITIL Kennzahlen für IT Service Management-Prozesse dere am Service Katalog über das Change Management umgesetzt werden. Dadurch soll eine frühzeitige Einbindung in den Service Lifecycle und die Ausrichtung der Transition Pläne an den Business-Anforderungen sichergestellt werden. Eine wichtige Aktivität besteht in der Definition einer Service Transition- Strategie. Diese Strategie definiert den umfassenden Ansatz zur Organisation der Service Transition und Ressourcenzuordnung und berücksichtigt unter anderem die folgenden Aspekte: Zweck und Ziele Kontext (Kunden, Verträge etc.) Relevante Standards, Vereinbarungen, Gesetze und Verträge Identifizierung der Anforderungen und Inhalte von neuen oder geänderten Services Personal (Verantwortlichkeit, Ausbildung etc.) Ergebnisse der Aktivitäten mit obligatorischen und optionalen Dokumentationen Meilensteinplanung Finanzielle Mittel (Budget) Zu den weiteren Aktivitäten im Prozess gehören die Vorbereitungen, die integrierte Planung und die Unterstützung der einzelnen Transition- Prozesse. Transition Planning and Support: Der Prozess, der für die Planung aller Service Transition-Prozesse und die Koordinierung der hierfür benötigten Ressourcen verantwortlich ist. Zu diesen Service Transition-Prozessen zählen Change Management, Service Asset and Configuration Management, Release and Deployment Management, Service Validation and Testing, Evaluation und Knowledge Management. Die 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. 73

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

85 2.5 ITIL Kennzahlen für IT Service Management-Prozesse lohnenden Changes bei einer minimalen Unterbrechung der IT Services zu ermöglichen. Die seitens der ITIL Best Practices dokumentierten Key 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 an den Kosten des Änderungsprozesses Reduzierung der Anzahl von Störungen am Service, Mängel und Überarbeitungen, die durch nicht exakte Spezifikation oder schlechte/unvollständige Bewertung der Auswirkungen verursacht wurden. Reduzierung der Anzahl nicht autorisierter Änderungen Reduzierung des Rückstands von Änderungsanträgen. Service Asset and Configuration Management Service Asset and Configuration Management liefert ein logisches Modell der IT-Infrastruktur und stellt falls erforderlich den Zusammenhang zwischen den IT Services mit notwendigen IT-Komponenten her. Durch diese Bereitstellung von Informationen für den gesamten Service Lifecycle unterstützt das Service Asset and Configuration Management (SACM) unter anderem bei der Beurteilung der Auswirkung und Ursache von Incidents und Problemen, bei der Beurteilung der Auswirkung von Changes, bei der Planung und Design neuer oder geänderter Services und der Planung der Aktualisierung von Technologie und Software. Darüber hinaus liefert das Service Asset and Configuration Management analog zum Change und IT Service Continuity Management einen wichtigen Beitrag zum Nachweis der Einhaltung von Compliance Anforderungen. Die Configuration Items können nach den folgenden Aspekten kategorisiert werden. Die Auflistung dieser Aspekte vermittelt einen Eindruck über den Geltungsbereich des Configuration Managements: Service Lifecyle CIs, wie der Business Case oder der Service Management-Plan Service CIs, wie die Service-Fähigkeiten (Organisation, Prozesse, Personen, etc.) und die Service Ressourcen (Systeme, Applikationen, etc.) 75

86 2 IT Service Management Organisatorische CIs, wie zum Beispiel Dokumentationen wie Policies Interne CIs, wie Software, um den Service bereitstellen zu können Externe CIs, wie Service Level Anforderungen Schnittstellen CIs, die notwendig für einen end-to-end -Service sind. Diese Kategorien und die Definition des Configuration Items (CI) zeigen deutlich, dass das Configuration und Service Asset Management erheblich mehr ist, als die Verwaltung von Hard- und Software. Die Prozessaktivitäten bestehen aus Management und Planung, Configuration Identifizierung, Configuration Steuerung (Control), Status Accounting und Reporting sowie Verfikation und Audit. Service Asset and Configuration Management: Der Prozess, der sowohl für das Configuration Management als auch das Asset Management verantwortlich ist. Asset Management: Das Asset Management ist der Prozess, der für die Verfolgung der Werte und Besitzverhältnisse in Bezug auf finanzielle Assets sowie deren Erfassung in Berichten während ihres gesamten Lebenszyklus verantwortlich ist. Configuration Management Der Prozess, der für die Pflege von Informationen zu Configuration Items einschließlich der zugehörigen Beziehungen verantwortlich ist, die für die Erbringung eines IT Service erforderlich sind. Diese Informationen werden über den gesamten Lebenszyklus des CI hinweg verwaltet. Die seitens der ITIL Best Practices dokumentierten Key Performance- Indikatoren sind zum Beispiel: prozentuale Verbesserung bei der Zeitplanung für Wartungsarbeiten eines Assets (nicht zu viel, nicht zu lange) Grad der Abstimmung zwischen unterstützter Wartung und Business Support als Ursache von Service-Ausfällen identifizierte Assets verbesserte Geschwindigkeit für das Incident Management zur Identifizierung fehlerhafter CIs und die Wiederherstellung des Service Auswirkung von Incidents und Fehlern mit Bezug auf bestimmte CI-Typen, z.b. von bestimmten Lieferanten oder Entwicklungsgruppen. 76

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

88 2 IT Service Management Jedes Release durchläuft die Prozessaktivitäten Planung, Vorbereiten von Build, Test und Deployment, Build und Test, Service Tests und Piloten, Planung und Vorbereitung Deployment, Durchführung Transfer, Deployment und Außerkraftsetzung, Early-Life Support und Review und Abschluss Deployment. Hier ist zu beachten, dass ein Release nicht mit dem Deployment abgeschlossen ist, sondern der Early Life Support und das Review die Prozessaktivitäten abschließen. Release and Deployment Management: Der Prozess, der sowohl für das Release Management als auch für das Deployment verantwortlich ist. Release Management: Der Prozess, der für die Planung, den zeitlichen Ablauf und die Steuerung des Übergangs von Releases in Test- und Live-Umgebungen verantwortlich ist. Das wichtigste Ziel des Release Managements ist es, sicherzustellen, dass die Integrität der Live-Umgebung aufrechterhalten wird und dass die richtigen Komponenten im Release enthalten sind. Deployment: Die Aktivität, die für den Übergang neuer oder geänderter Hardware, Software, Dokumentation, Prozesse etc. in die Live-Umgebung verantwortlich ist. Die seitens der ITIL Best Practices dokumentierten Key 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. Dieser Prozess soll das Vertrauen des Business in die Erfüllung der Erwartungen und getroffenen Vereinbarungen sicherstellen. Daher ist dieser Prozess nicht auf diese Phase des Service Lifecycle (= Service Transition) begrenzt, sondern setzt bereits innerhalb von Service Strategy an. 78

89 Die Zielsetzung des Prozesses besteht in: 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Sicherstellung, dass ein Service den Wertbeitrag für Kunden und Business liefert Planung und Implementierung eines strukturierten Validierungsund Test-Prozesses für den objektiven Nachweis gemäß der vereinbarten Anforderungen und Service Level-Ziele Qualitätssicherung von Release, Komponenten, Service und Servicefähigkeit Identifizierung, Bewertung und Zuordnung von Vorfällen, Fehlern und Risiken während der Transition Phase Vertrauen schaffen, dass die erwarteten Ergebnisse und der Wert für das Business tatsächlich entstehen Bestätigung, dass der Service fit for purpose ist. Kunden/Business Anforderungen definieren Service Anforderungen definieren Design Service Lösung Service Package Angebote, Verträge validieren Serviceabnahme testen Betriebsbereitschaft testen Design Service Release Design Lösung entwickeln Service Release Package Test Komponenten & Komponentengruppen Test Level für Configuration und Testen Build & Test Abbildung 32: Das Service V-Modell Mithilfe des Service V-Modells (Abbildung 32) kann sichergestellt werden, dass Service Validation and Testing früh in den Service Lifecycle eingebunden und eine Validierung und Test über alle Ebenen erfolgt (aus OGC, 2007c). 79

90 2 IT Service Management Von Bedeutung für das Verständnis dieses Prozesses ist es, dass der Prozess Service Validation and Testing nicht nur Fehlerfreiheit überprüft, sondern auch die Einhaltung des zugesicherten Wertes für das Business. Dieser Wert setzt sich zusammen aus der Utility und Warranty. Service Validation and Testing: Der Prozess, der für die Validation und das Testen eines neuen oder geänderten IT Service verantwortlich ist. Service Validation and Testing stellt sicher, dass der IT Service den jeweiligen Designspezifikationen entspricht und den Bedürfnissen des Business gerecht wird. Die seitens der ITIL Best Practices dokumentierten Key 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 neue oder geänderte IT Services, um mögliche Risiken zu managen und so sicherzustellen, dass mit dem Service Change fortgefahren werden kann. Mit dieser Zielsetzung liefert der Prozess Evaluation eine Entscheidungsvorlage für das Change Management, ob ein Change genehmigt oder abgelehnt wird. Die Lieferung von relevanten und genauen Informationen für das Change Management stellt sicher, dass Service Changes mit negativen Auswirkungen und Risiken nicht ungeprüft umgesetzt werden. Der Prozess Evaluation stellt hierzu ein konsistentes und standardisiertes Mittel zur Bewertung eines Service Changes bereit. Diese Beurteilung erfolgt gemeinsam mit dem Kunden und identifiziert sämtliche gewünschten und unerwünschten Auswirkungen. Hierzu ist die Objektivität, Fairness, Konsistenz und Offenheit in der Bewertung unumgänglich. 80

91 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Evaluation: Der Prozess, der für die Bewertung eines neuen oder geänderten IT Service verantwortlich ist, um sicherzustellen, dass Risiken verwaltet wurden, und festlegen zu können, ob mit dem Change fortgefahren werden soll. Eine Evaluierung bezeichnet darüber hinaus den Vergleich eines Ist-Ergebnisses mit dem beabsichtigten Ergebnis oder den Vergleich unterschiedlicher Alternativen. Die seitens der ITIL Best Practices dokumentierten Key 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. Knowledge Management Knowledge Management liefert die Grundlage für fundierte Entscheidungen. Die im Verlauf des Lebenszyklus der Services gewonnenen Informationen und Daten werden bereitgestellt. Dem Knowledge Management liegt das DIKW-Modell (Data-to-Information-to-Knowledge-to-Wisdom) zugrunde. Innerhalb der Organisation des Service Providers fällt eine Unmenge von Daten an, die aber noch keine Entscheidung ermöglichen. Durch die Analyse der Daten werden Informationen gewonnen. Hier werden Informationen zu den Schlüsselfragen Wer?, Was?, Wann?, und Wo? generiert. Das Knowledge entsteht durch die Anwendung der Informationen für bestimmte Maßnahmen. Das Wisdom stellt schließt die Anwendung und Umsetzung des Wissens dar. Dieses Modell ermöglicht die Schlüsselfrage des Warum? zu beantworten. In Verbindung mit dem Knowledge Management definiert ITIL das Service Knowledge Management System (SKMS). Das SKMS besteht aus einer Sammlung von Hilfsmitteln und Datenbanken, die zur Verwaltung von Wissen und Informationen verwendet werden. Ein wesentliches System für das SKMS ist das Configuration Management System. Das Knowledge Management soll die Entscheidungsqualität verbessern und die Effizienz des Service Providers erhöhen. Daher ist ein wirksames Knowledge Management als ein mächtiges Asset für alle Beteiligten (und damit auch für Kunden/Anwender) anzusehen. Knowledge Management: Der Prozess, der für die Sammlung, die Analyse, das Speichern und die gemeinsame Nutzung von Wissen und Informationen innerhalb einer Organisa- 81

92 2 IT Service Management tion verantwortlich ist. Wichtigster Zweck des Knowledge Managements ist eine gesteigerte Effizienz, indem bereits vorhandenes Wissen nicht erneut entwickelt werden muss. Die seitens der ITIL Best Practices dokumentierten Key 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 33: Service Operation Event Management Event Management befähigt zur Entdeckung und Interpretation von Ereignissen (Events) und ermöglicht deren Steuerung. Deshalb ist Event Management die Basis vieler Routine-Aktivitäten des Operation Managements und liefert die Eingangsstelle für viele Prozesse und Aktivitäten des Service Operation. 82

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

94 2 IT Service Management Anzahl und Prozentsatz an Ereignissen, die in Incidents oder Änderungen resultierten. Incident Management Das primäre Ziel des Incident Management-Prozesses ist die schnelle Wiederherstellung des Service-Betriebs mit der Qualität, wie sie in den Service Level Agreements (SLA) vereinbart wurde. Hierbei soll die Auswirkung des Incidents auf die Business-Prozesse minimiert werden. Die auftretenden Incidents sind zu kategorisieren und zu priorisieren. ITIL empfiehlt, die Priorisierung auf Basis der Auswirkung und Dringlichkeit durchzuführen und hilft, den erforderlichen Zeitbedarf für die auszuführenden Aktionen zu ermitteln. Die Business-Orientierung wird bei der Definition der Auswirkung und Dringlichkeit sehr deutlich. Die Auswirkung eines Incidents wird durch die Folgen auf die Business-Prozesse bestimmt und basiert häufig darauf, inwieweit Service Level betroffen sind. Die Dringlichkeit ist ein Wert, der wiedergibt, wie lange es dauert, bis ein Incident maßgebliche Auswirkungen auf das Business hat. Für die Effizienz des Incident Managements ist es von Vorteil, im Vorfeld Incident-Modelle zu definieren. Diese Modelle ermöglichen es, den Umgang mit einer bestimmten Art des Incidents im Vorfeld festzulegen und sichern in der Umsetzung eine konsistente Durchführung. Beispiele für Incident Modelle sind sicherheitsrelevante Incidents, deren Informationen an das Security Management automatisch weitergeleitet werden oder performancerelevante Incidents, die automatisiert an das Capacity Management weitergeleitet werden. Eine Herausforderung in diesem Prozess besteht in der Überzeugung aller Mitarbeiter, dass alle Incidents protokolliert werden müssen. Darüber hinaus ist die Trennung zwischen Incident und Problem Management von großer Bedeutung. Die Aufgabe des Incident Managements besteht in einer schnellen Lösung des Incidents und nicht darin, die zugrunde liegende Ursache zu ermitteln. Die Ermittlung dieser Ursache und mögliche Umgehungslösungen zu entwickeln ist die Aufgabe des Problem Managements. Incident Management: Der Prozess, der für die Verwaltung des Lebenszyklus aller Incidents verantwortlich ist. Wichtigstes Ziel des Incident Management ist eine schnellstmögliche Wiederherstellung des IT Service für die Anwender. Die seitens der ITIL Best Practices dokumentierten Key Performance- Indikatoren sind zum Beispiel: 84

95 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Gesamtzahl der Incidents (als Kontroll-Wert) Aufschlüsselung der Incidents in jeder Stufe (z.b. aufgezeichnet, in Bearbeitung, geschlossen) Rückstand aktueller Incidents Anzahl und Prozentsatz schwerwiegender (major) Incidents mittlere Ablaufzeit bis zur Lösung/Wiederherstellung oder Umgehungslösung, aufgeschlüsselt nach Auswirkung (impact code). Request Fulfilment Request Fulfilment ist der für die Behandlung der Service Requests verantwortliche Prozess. Er stellt definierte Informationskanäle für die Anwender bereit, mit denen Anforderungen gestellt und Services entgegengenommen werden können. Darüber hinaus werden Informationen über die Verfügbarkeit von Services und Prozeduren für deren Nutzung bereitgestellt. Standardleistungen, wie zum Beispiel Lizenzen und Software- Medien, werden beschafft und ausgeliefert. Ein Service Request könnte zum Beispiel die Anfrage eines Anwenders nach Informationen, Beratung, einem Standard-Change oder nach Zugriff auf einen IT Service sein. Das Zurücksetzen eines Passworts oder die Bereitstellung standardmäßiger IT Services für einen neuen Anwender sind Service Requests, die an jeden Service Provider gerichtet werden. Viele an den Service Provider gerichtete Service Requests wiederholen sich, so dass ein vordefinierter Prozessablauf (ein Modell) entworfen werden kann, wie diese Anforderungen einheitlich mit einer gleich bleibenden Service-Qualität bearbeitet werden können. Diese Modelle beinhalten: beteiligte Personen oder Support-Gruppen geplante Zeitdauer Eskalationswege. Die Service Requests werden normalerweise durch Implementierung eines Standard Change abgedeckt. Der Standard Change ist ein vorab genehmigter Change, der von geringem Risiko ist, relativ häufig eingesetzt wird und einem bestimmten Verfahren oder einer Arbeitsanweisung folgt. Mit dem Standard Change wird auch die Dokumentation der durchgeführten Maßnahme sichergestellt. Die Verantwortung der Aufnahme, Überwachung, Eskalation und Zuweisung der Service Requests liegt im Service Desk. Request Fulfilment: Der Prozess, der für das Management des Lebenszyklus aller Service Requests verantwortlich ist. 85

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

97 2.5 ITIL Kennzahlen für IT Service Management-Prozesse tenbank (KEDB), die Bestandteil des Configuration Management Systems (CMS) und des Service Knowledge Management (Systems) ist. So wird der Zugriff des Incident Managements auf diese Umgehungslösungen sichergestellt. Mitarbeiter im Incident Management können diese Informationen abfragen, die beschriebenen Maßnahmen durchführen und konsistente und mit einer hohen Qualität verbundene Wiederherstellungsmaßnahmen durchführen. Eine gute KEDB ermöglicht eine hohe Erstlösungsquote im Service Desk. Die im Problem Management entwickelten Lösungskonzepte werden nicht vom Problem Management eigenständig umgesetzt und implementiert, sondern führen zu einem Request for Change (RfC) und unterliegen so dem Change Management. Innerhalb des Problem Managements wird zwischen dem reaktiven und proaktiven Problem Management unterschieden. Das reaktive Problem Management wird allgemein in Service Operation durchgeführt. Das proaktive Problem Management wird in Service Operation initiiert, aber generell innerhalb von Continual Service Improvement vorangetrieben. Problem Management: Der Prozess, der für die Verwaltung des Lebenszyklus aller Probleme verantwortlich ist. Wichtigstes Ziel des Problem Managements ist es, Incidents zu verhindern bzw. die Auswirkungen von Incidents zu minimieren, die nicht verhindert werden können. Die seitens der ITIL Best Practices dokumentierten Key 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. Aus den gestiegenen Compliance Anforderungen (zum Beispiel Sarbanes Oxley Act, SOX) resultiert die Notwendigkeit einer Regelung für den 87

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

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

100 2 IT Service Management Sun verschiedene Strukturen. Im Rahmen der Implementierung des Service Managements gilt es dann, die für die jeweilige Organisation geeignete Struktur zu spezifizieren. Die seitens der ITIL Best Practices dokumentierten Key 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 wurden Prozentsatz gelöster Calls ohne Unterstützung anderer Gruppen Prozentsatz gelöster Calls mit Unterstützung anderer Gruppen 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 34: Continual Service Improvement The 7 Step Improvement Process Hier werden Fragen gestellt nach den Business-Treibern hinter der ITIL- Implementierung, der finanziellen Bewertung von IT-Investitionen, dem Reifegrad, der Effektivität und Effizienz aktueller Prozesse, den Lücken (Gaps) und Problemen bei der Bereitstellung von Services, der Bewertung 90

101 2.5 ITIL Kennzahlen für IT Service Management-Prozesse von Ressourcen (Time and Budget) zum Schließen der Lücken und schließlich nach den Ergebnissen der Aktivitäten beim Streben nach Service Improvement ROI. Der 7 Step Improvement Process umfasst die folgenden Forderungen: 1. Definieren, was gemessen werden soll 2. Definieren, was gemessen werden kann 3. Daten sammeln 4. Daten bearbeiten 5. Daten analysieren 6. Informationen präsentieren und nutzen 7. Korrekturen durchführen. Abbildung 35 aus Continual Service Improvement (vgl. [OGC, 2007e]) veranschaulicht diesen Prozess: Identifiziere: Vision Strategie Taktische Ziele Operative Ziele 1. Definiere, was Du messen solltest 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 35: 7 Step Improvement-Prozess 1. Definiere, was Du messen solltest (should) Als erster Schritt sollte ein Satz möglicher Messungen definiert werden, der die Ziele des IT Service Providers und deren Messung vollständig abdeckt. Der Fokus sollte hier bei der Definition liegen, welche Daten gebraucht werden und um die Zielerreichung vollständig zu messen. Eine 91

102 2 IT Service Management Betrachtung, ob die Daten aktuell verfügbar sind und mit einem vertretbaren Aufwand gewonnen werden können, findet hier nicht statt. Was gemessen werden sollte, ist innerhalb von Service Strategy und Service Design zu Beginn des Service Lifecycle zu identifizieren. 2. Definiere, was Du messen kannst (can) Während im ersten Schritt mögliche Daten für Messungen definiert werden, gilt es im zweiten Schritt festzustellen, was tatsächlich gemessen werden kann. Dabei können Service Provider unter Umständen feststellen, dass nicht alle Anforderungen umgesetzt werden können. Für den Service Provider ist es wichtig, die Lücken und damit verbundene mögliche Risiken zu erkennen. Die identifizierten Lücken und die damit verbundenen Auswirkungen sind dem Business, den Kunden und dem IT-Management zu berichten. Eine mögliche Abhilfe kann in der Beschaffung neuer Tools liegen, dabei sind die damit verbundenen Kosten und erzielten Vorteile zu prüfen. 3. Sammle Daten (gather) Die Zielsetzung des Continual Service Improvement besteht in der Überwachung der Service-Qualität. Hierzu sind durch eine geeignete Kombination von Monitoring-Tools und manuellen Prozessen die notwendigen Messungen zur Mittlung der erforderlichen Daten einzuführen. Der Betrachtungsbereich erstreckt sich von der Effektivität der Services, über Prozesse, Tools und Organisation bis zu den CIs. Dabei werden nicht nur Ausnahmesituationen betrachtet, sondern auch Entwicklungen wie zum Beispiel eine schleichende Verschlechterung der Verfügbarkeit. Eine Automatisierung der Datensammlung ist anzustreben und wie bereits ausgeführt Messpunkte sowohl so zu wählen, dass eine durchgängige Betrachtung ( end-to-end ), als auch eine zeitliche Betrachtung möglich wird. Die in diesem Schritt gesammelten Daten sind aber noch Rohdaten und erlauben keine Rückschlüsse. Hierzu sind die gesammelten Daten entsprechend zu erarbeiten. 4. Bearbeite Daten (process) Die gesammelten Rohdaten werden in diesem Schritt so bearbeitet und in das erforderliche Format transformiert, dass über eine end-to-end - Betrachtung die Bewertung der Leistungsfähigkeit der Prozesse und / oder IT Services möglich wird. 92

103 2.5 ITIL Kennzahlen für IT Service Management-Prozesse Hierzu werden unter anderem Daten aus verschiedenen Quellen konsolidiert, auf Zeitskalen abgebildet und führen zu den definierten KPIs und Kennzahlen. Die Kennzahlen können in drei Betrachtungsebenen dargestellt werden: Technische Kennzahlen sind häufig mit den eingesetzten Komponenten und Applikationen verbunden und betrachten technische Aspekte wie Performance, Verfügbarkeit etc. Prozess-Kennzahlen erfassen CSFs, KPIs und Messgrößen für Tätigkeiten der Service Management-Prozesse. Diese Metriken ermöglichen eine Beurteilung der Prozesse. Die Metriken sollten die vier Aspekte Qualität, Performance, Nutzen und Compliance abdecken. Service Kennzahlen sind das Ergebnis einer end-to-end -Betrachtung der Services. 5. Analysiere Daten (analyse) Durch eine Analyse der generierten Informationen können die Ergebnisse analysiert werden, um Fragen zu beantworten wie: Erreichen wir die Ziele? Gibt es klare Trends? Sind Korrekturmaßnahmen erforderlich? Welche eingeleiteten Korrekturmaßnahmen waren erfolgreich? Welche Kosten entstehen? Insbesondere der umfassende Ansatz des Continual Service Improvement stellt sicher, dass sich die Identifizierung von möglichen Korrekturmaßnahmen nicht auf einen Bereich oder eine Phase des Lifecycle konzentriert. So kann zum Beispiel sichergestellt werden, dass auftretende Probleme in Service Operation zu Korrekturmaßnahmen innerhalb von Service Design führen. 6. Präsentiere und Nutze die Informationen (present) Dieser Schritt dient der Präsentation des gewonnenen Wissens. Hierzu sind die Ergebnisse so aufzubereiten und zu präsentieren, das sie leicht zu verstehen sind und es so ermöglicht wird, strategische, taktische und operative Entscheidungen zu treffen. Grundvoraussetzung hierzu ist eine Zielgruppen-ausgerichtete Präsentation der Ergebnisse. Insbesondere ist ein Bezug zum Business und zu den Business-Zielen herzustellen. Dabei stellt es sich als großer Vorteil dar, dem Business mögliche Verbesserungen in Verbindung mit ihrem Wertbeitrag zu präsentieren. 93

104 2 IT Service Management Dieser Schritt sollte aber nicht nur dazu dienen, mögliche Schwachpunkte zu präsentieren, sondern auch als Marketingmaßnahme die exzellenten IT Services herauszuheben. Hier eröffnet sich die Chance, dass die IT nicht nur als Kostenfaktor empfunden wird, sondern auch als Leistungsgeber für den Erfolg der Business-Prozesse. 7. Implementiere Korrekturmaßnahmen (implement) Das gewonnene Wissen wird verwendet, um die IT Services, die Prozesse und alle anderen unterstützenden Aktivitäten und Techniken zu optimieren, zu verbessern und zu korrigieren. Die Verbesserungsmaßnahmen, die den IT Service verbessern, sind zu identifizieren und innerhalb der Organisation zu kommunizieren. Innerhalb des Continual Service Improvement werden unter Umständen mehr Verbesserungsmöglichkeiten identifiziert, als mit den vorhandenen Ressourcen und Budget umgesetzt werden können. Daher muss der Service Provider auf Basis der Zielsetzung und der Business-Vorteile die Umsetzung der Verbesserungsmaßnahmen priorisieren. Die Umsetzung einer Verbesserungsmaßnahme führt zu einem Durchlauf des beschriebenen Zyklus. Innerhalb von The 7 Step Improvement sind allgemeine Fragestellungen hinsichtlich der Definition von KPIs dokumentiert: Was sagt uns der KPI über die Zielerreichung aus? Wie leicht ist es, den KPI zu interpretieren? Wann brauchen wir die Information? Wie oft? Wie rasch sollte die Information verfügbar sein? In welchem Maße ist der KPI stabil und genau? Ist er von externen unkontrollierbaren Einflüssen abhängig? Wie leicht ist es, den KPI selbst zu ändern? Wie leicht ist es, das Maßsystem an sich verändernde Umstände anzupassen oder Änderungen in Bezug zu den Zielen durchzuführen? Wer ist der Owner des KPIs? Wer ist verantwortlich für das Sammeln und die Analyse der Daten? Wer ist für Verbesserungen basierend auf den gewonnenen Informationen verantwortlich? Key Performance-Indikatoren sind zu diesem Prozess nicht ausgeführt, sondern allgemeine Anforderungen an die Metriken. Service Reporting Das Service Reporting liefert die notwendigen korrekten Berichte, die den Kundenerwartungen entsprechen. Aus der Vielzahl der vorliegenden Da- 94

105 2.5 ITIL Kennzahlen für IT Service Management-Prozesse ten sind hierzu die Daten so aufzubereiten, dass das Business die notwendigen Informationen erhält. Für das Business ist eine historische Betrachtung des geleisteten IT Service mit den erreichten Service Level und der Performance wichtig. Aber viel wichtiger sind die daraus gezogenen Kenntnisse und welche Maßnahmen eingeleitet werden, um erkannte Defizite zu beheben. Das Business verlangt eine nachvollziehbare Darstellung von den Ereignissen und wie der Service Provider sicherstellt, dass das nochmalige Geschehen nicht wieder eintritt und wie der Service Provider generell den Service verbessern wird. Service Reporting: Der Prozess, mit dem Berichte zu Ergebnissen und Trends hinsichtlich bestimmter Service Level erstellt und bereitgestellt werden. Beim Service Reporting sollte das Format, der Inhalt und die Häufigkeit der Berichte zuvor mit den jeweiligen Kunden abgesprochen werden. Key Performance-Indikatoren sind zu diesem Prozess nicht ausgeführt. Service Measurement Das Service Measurement stellt sicher, dass die Services bezüglich der Aspekte der Verfügbarkeit (Availability), Zuverlässigkeit (Reliability) und Performance gemessen werden können. Dabei ist die Kundensicht auf den Service (d. h. end-to-end ) von großer Bedeutung, da hiervon die Geschäftsprozesse des Business abhängig sind. Vielfach berichten Service Provider dem Kunden aus der internen Sicht oder versuchen zum Teil nur über die Komponenten zu berichten, die der Service Provider sicher beherrscht, wie zum Beispiel der Server oder die Applikation war zu 99,99 % verfügbar. Aber wie kann der Kunde den Server nutzen, wenn zum Beispiel das LAN ausgefallen ist? Eine Messung auf Ebene der Komponenten ist notwendig und sinnvoll, aber die Messung eines IT Service muss weitergehen und den gesamten IT Service hinsichtlich seiner Unterstützung des Business-Prozesses umfassen. Eine Service Messung muss der Kundensicht und Wahrnehmung auf den IT Service entsprechen, hierzu ist eine end-to-end -Messung erforderlich. Service-Messungen sollten nicht nur die Vergangenheit betrachten, sondern auch Informationen zur Entwicklung liefern, um Verbesserungen rechtzeitig zu ergreifen. Das sollte eine sichere Basis für operationelle, taktische oder strategische Entscheidungen liefern. Als Key Performance-Indikatoren für das Service Management werden aus Kundensicht demzufolge herausgestellt: 95

106 2 IT Service Management Verbesserte Verfügbarkeit (durch Service / Systeme / Applikationen) Verringerung der Service Level Verletzungen (durch Service / Systeme / Applikationen) Verringerung mean time to repair (gemessen anhand von Prioritäten) Verringerung von Major Incidents. Return on Investment (ROI) for CSI Um die Aufgabe des Return on Investments (ROI) für das Continual Service Improvement (CSI) erfüllen zu können, sind viele Faktoren in Betracht zu ziehen. Auf der einen Seite sind dies die Kosten für die Durchführung dieser Phase des Service Lifecyle, bestehend zum Beispiel aus den Personalkosten, Tools, Beratungskosten, etc. Auf der anderen Seite ist zu bewerten, welche geschäftlichen Vorteile durch diese Tätigkeiten erzielt werden. Letztlich geht es um eine geschäftliche ROI-Betrachtung. Daher sind die Vorteile auch nicht nur aufseiten des Service Providers zu bewerten, sondern primär aus Sicht des Business. Eine mögliche Betrachtung wäre zum Beispiel die Kosten von Ausfallzeiten auf der Seite des Business. Key Performance-Indikatoren sind zu diesem Prozess nicht ausgeführt The Business Questions for CSI Die Business Integration von ITIL Version 3 wird auch dadurch zum Ausdruck gebracht, dass das Business in das Continual Service Improvement einzubinden ist. Mögliche Verbesserungen sind dahingehend zu bewerten, welche Maßnahmen den größten Vorteil für das Business mit sich bringen. Hierzu ist zu bewerten Wo stehen wir heute? und gemeinsam zu definieren Was wollen wir?. Die Definition Was wollen wir? kann nur in Partnerschaft zwischen dem Business und dem Service Provider erarbeitet werden. Zunächst mögen sich einige Wünsche des Business wie 100%ige garantierte Verfügbarkeit als Wunschliste anführen. Hier gilt es, die zugrunde liegenden Begründungen zu erkennen und sich diesen Anforderungen zu stellen. Die Gründe aus Sicht des Business können zum Beispiel bestehen in: Einhaltung zu neuen/bevorstehenden Gesetzen (Compliance Anforderungen) Wettbewerb Finanzielle Beschränkungen. Es ist für den Service Provider wichtig, lang-, mittel- und kurzfristige Ziele und Zielsetzungen für das Business zu identifizieren, so dass die zugrunde liegenden IT Services und Service Assets sich dementsprechend ausrichten können. 96

107 2.6 ISO Die Aktivitäten des Continual Service Improvement setzen einen betriebsbereiten IT Service voraus. Die Aktivitäten des CSI können innerhalb der Lifecycle-Phasen: Service Strategy, Service Design, Service Transition und Service Operation ausgeführt werden. Key Performance-Indikatoren sind zu diesem Prozess nicht ausgeführt. Service Level Management Service Level Management ist ein für das CSI kritischer und wichtiger Prozess. Das Service Level Management entscheidet darüber, was gemessen wird, welche Anforderungen an die Überwachungen gestellt werden, wie das Erreichen von Service Level-Zielen berichtet wird und wo mit dem Business bei neuen Service Requests oder Änderungen an existierenden Services zusammengearbeitet wird. So werden die Aktivitäten des CSI unterstützt und Verbesserungsprojekte priorisiert. Der SLM Prozess ist innerhalb der Service Lifecycle-Phase von Service Design dokumentiert. Dabei ist es wichtig das CSI zu beteiligen, um so sicherzustellen, dass messbare Ziele zur Identifizierung potenzieller Service-Verbesserungen geschaffen werden. Das Service Level Management stellt einen wichtigen Trigger für den Service Improvement-Plan (SIP) dar. Der Service Improvement-Plan ist ein formeller Plan, um mögliche Verbesserungen zu einem Prozess oder einem IT Service durchzuführen. Durch die Identifizierung notwendiger Verbesserungen und deren Management mittels des SIP wird eine nachhaltige Verbesserung sichergestellt. Das Management dieses Plans ist ein Teil des Continual Service Improvement. Service Improvement-Plan (SIP): Ein formeller Plan zur Implementierung von Verbesserungen für einen Prozess oder IT Service. Key Performance-Indikatoren sind zu diesem Prozess nicht ausgeführt. 2.6 ISO 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 Auditie- 97

108 2 IT Service Management rungs-organisation auf der Basis einer internationalen Qualitätsnorm zertifizieren zu lassen. Mit dieser Norm wird dem steigenden Bedarf des Nachweises eines wirksamen IT Service Managements Rechnung getragen. In diesem Zusammenhang muss nochmals die Zielsetzung von ITIL herausgestellt werden: Innerhalb der IT Infrastructure Library sind bewährte Vorgehensweisen (Best Practices) dokumentiert. Sie sind als Leitfaden (Guidelines) für die Implementierung von IT Service Management-Prozessen gedacht. Dabei bleibt es den Organisationen überlassen, wie und in welchem Maße dieser Leitfaden zur Gestaltung der unternehmensspezifischen IT Service Management-Prozesse genutzt wird. Aufgrund der steigenden internationalen Anerkennung und Nutzung wird ITIL auch als De-facto-Standard für das IT Service Management bezeichnet und zum Teil irrtümlich als Standard im Sinne einer Norm verstanden. ITIL ist kein Standard im Sinne einer Norm. Eine ITIL Zertifizierung für Organisationen ist nicht möglich. Eine Zertifizierung von Organisationen ist nur auf Basis der ISO 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. 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. 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]). 98

109 2.6 ISO 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 Übereinstimmung 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, so dass 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-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 ISO enthält die Muss-Anforderungen ISO enthält die Soll-Anforderungen 99

110 2 IT Service Management ITIL und ISO stehen nicht im Wettbewerb, sondern ergänzen sich zweckmäßig , 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 erfolgreichen 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 100

111 2.6 ISO 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. 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 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 Release- Prozesse Relationship- Prozesse Business Relationship Management Supplier Management Abbildung 36: IT Service Management-Prozesse der ISO 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 101

112 2 IT Service Management Service Managements in die IT-Strategie sichergestellt. Innerhalb der folgenden Abbildung 36 werden die geforderten IT Service Management- Prozesse, ergänzt um das übergeordnete Managementsystem der ISO 20000, dargestellt (vgl. [ISO , 2005]). Unternehmen, die eine ISO Zertifizierung anstreben, müssen alle dargestellten Prozesse implementieren. Eine Zertifizierung für einzelne Prozesse ist nicht möglich. Dagegen können einzelne IT-Bereiche zertifiziert werden, sofern in diesen Bereichen sämtliche Prozesse verantwortlich durchgeführt werden 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 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 37). Dieser kontinuierliche Verbesserungsprozess ist nicht nur für die übergeordneten Managementaufgaben, sondern auch für die einzelnen IT Service Management-Prozesse zu etablieren. Wie in Kapitel 3 IT Prozess-Management ausgeführt, ist die Messung von Prozessen die unabdingbare Voraussetzung dafür, deren Wirksamkeit sicherzustellen (vgl. [van Bon, 2006]): You cannot control what you cannot measure. 102

113 2.7 COBIT 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 37: PDCA-Methodik 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. Im Rahmen einer ISO Zertifizierung werden Prozesskennzahlen überprüft. 2.7 COBIT Je bedeutender und kritischer die IT-Unterstützung für die Geschäftsprozesse einer Organisation ist, umso wichtiger ist der Einsatz eines geeigneten Steuerungsinstruments für die Aktivitäten der IT. Vor diesem Hintergrund wurde COBIT (Control Objectives for Information and Related Technology) als Steuerungsmodell der gesamten IT konzipiert. Ursprünglich wurde COBIT von der Information Systems Audit and Control Foundation (ISACF) entwickelt, dem Forschungsinstitut der Information Systems Audit and Control Association (ISACA). Wie der Organisationsname bereits verrät, war COBIT speziell für den Einsatz bei Wirtschaftsprüfern vorgesehen. Aufgrund der Ausrichtung an der Auditierung liegen die Stärken von COBIT naturgemäß in den definierten Steu- 103

114 2 IT Service Management erungszielen und insbesondere in der damit verbundenen Überprüfung und Auditierung von IT-Prozessen. Vergleichbar mit den ITIL Best Practices konzentriert sich COBIT darauf zu dokumentieren, Was erreicht werden soll. Dabei wird in COBIT ausdrücklich betont, dass die praktische Ausgestaltung organisationsspezifisch und durch die Integration mit anderen eingesetzten Methoden und Verfahren erfolgen sollte (vgl. [COBIT, 2005]). Häufig wird COBIT im Zusammenhang mit IT Governance genannt. Es existiert keine einheitliche Definition des Begriffs IT Governance. Allgemein werden unter dem Thema IT Governance Grundsätze, Verfahren und Maßnahmen zusammengefasst, die sicherstellen, dass mit Hilfe der eingesetzten IT die Geschäftsziele abgedeckt, die Ressourcen verantwortungsvoll eingesetzt und Risiken angemessen überwacht werden. COBIT, aber auch die ITIL Best Practices, sollen diese Maßgaben der IT Governance sicherstellen. ITIL Version 3 definiert den Begriff IT Governance und bezieht sich dabei auf eine Definition des IT Governance Instituts (vgl. [OGC, 2007e]): IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership, organizational structures and processes that ensure that the organization s IT sustains and extends the organization s strategies and objectives. (Board Briefing on IT Governance, 2nd Edition, 2003, IT Governance Institute ITGI) 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, so dass diese verschiedenen Best Practices besser aufeinander abgestimmt sind. 104

115 2.7 COBIT Speziell im Zusammenhang mit der Nachweispflicht des Sarbanes-Oxley Acts (SOX) 4 (vgl. [COBIT, 2006]) für an der amerikanischen Börse notierte Unternehmen hat die Nutzung von COBIT zugenommen. Bis zum Jahr 2008 soll die COBIT Version 5 entwickelt werden, wobei strategische Betrachtungen größere Berücksichtigung finden sollen als bisher. So ist unter anderem die Zusammenfassung von IT-Prozessen in einem Bereich (Domain) IT Governance geplant. Die im folgenden Kapitel beschriebenen Prozesse und Kennzahlen basieren auf der COBIT Version Struktur von COBIT Analog zu ITIL definiert COBIT Best Practices, die sicherstellen, dass die eingesetzte IT die Geschäftsziele unterstützt, dass Ressourcen verantwortungsvoll eingesetzt und Risiken angemessen überwacht werden. Speziell beim Aufbau eines internen Steuerungssystems in der IT und bei der Messung der Zielerreichung soll COBIT die zuvor genannten Aufgaben der IT Governance unterstützen. COBIT identifiziert und dokumentiert insgesamt 34 Prozesse, die für ein erfolgreiches Management der IT erforderlich sind. Diese 34 IT-Prozesse werden in vier übergeordneten Domains gruppiert, die einen geschlossenen Lebenszyklus (Lifecycle) bilden (vgl. [COBIT, 2005], Abbildung 38). COBIT sind Best Practices. Für jeden der 34 IT-Prozesse dokumentiert COBIT die jeweilige Best Practice in folgender Form: Generische Prozessbeschreibung Prozessziele Wichtigste Aktivitäten Input und Output des Prozesses Mögliche organisatorische Verantwortlichkeiten Wichtigste Metriken Verknüpfte IT-Ziele. Zusätzlich bietet COBIT die Möglichkeit, den Reifegrad dieser Prozesse zu bestimmen. Hierzu sind zu jedem Prozess die Reifegradanforderungen spezifiziert. 4 Der Sarbanes-Oxley Act wurde benannt nach seinen Verfassern, dem Senator Paul S. Sarbanes und dem Abgeordneten Michael Oxley, die ein Gesetz zur Verschärfung der Rechnungslegungsvorschriften in Folge der Bilanzskandale von Unternehmen wie Enron oder Worldcom erließen. 105

116 2 IT Service Management Prozesse - Überwache und bewerte IT-Performance - Überwache und bewerte interne Controls - Stelle die angeordnete Compliance sicher - Sorge für IT-Governance 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 38: COBIT Prozess-Übersicht Control Objectives dienen der Steuerung, nicht der Kontrolle Prozess-Management gemäß COBIT In COBIT sind für jeden Prozess Control Objectives definiert. COBIT versteht Control Objectives als Minimalanforderungen für ein wirkungsvolles Prozess-Management (vgl. [COBIT, 2005]). Control wird häufig mit Kontrolle übersetzt, wodurch die eigentliche Bedeutung der Steuerung bzw. des Managements verfälscht wird. Aus diesem Grund wird im Folgenden der englische Begriff verwendet. 106

117 2.7 COBIT Die Control Objectives dokumentieren das Ziel oder den Zweck eines Prozesses und definieren so die Mindestanforderung, die zu erreichen ist. Pro Prozess existiert immer ein übergeordnetes Control Objective. Die Prozesse sind so bezeichnet, dass sich das übergeordnete Control Objective direkt aus dem Prozessnamen ergibt. Zu jedem Prozess stellt COBIT eingangs das übergeordnete Control Objective gemeinsam mit den wichtigsten Prozesszielen und Metriken dar. Zusätzlich sind anschließend zu jedem Prozess mehrere daraus abgeleitete, detaillierte Control Objectives beschrieben. Diese detaillierten Control Objectives können als Best Practice für das Management des jeweiligen Prozesses angesehen werden. Es sind Minimalanforderungen, die die Zielerreichung sicherstellen. Beispiel Manage Changes (AI6 Manage Changes): Innerhalb des übergeordneten Control Objective wird als Zielsetzung für das Manage Changes gefordert, dass sämtliche Changes an der Infrastruktur und den Applikationen in der produktiven Umgebung nach standardisierten Methoden und Verfahren vorgenommen werden. Zu diesen Changes zählen auch Notfall-Changes und Patches. Jeder Change muss vor der Implementierung aufgezeichnet, bewertet und autorisiert sowie nach der Implementierung anhand der geplanten Ergebnisse überprüft werden. Diese Aktivitäten schließen Changes an Verfahren, an Prozessen, an Systemen und an Services ein. Durch diese Aktivitäten sollen die Risiken von Changes minimiert werden, die sich negativ auf die Stabilität und Integrität der Produktivumgebung auswirken. COBIT definiert für den Prozess Manage Changes insgesamt 6 detaillierte Control Objectives. Ein detailliertes Control Objective lautet Notfall Changes (AI6.3: Emergency Changes). Dieses Control Objective fordert, einen Prozess für die Definition, Aufnahme, Beurteilung und Genehmigung von Notfall-Changes zu erstellen. Dokumentationen und Tests können unter Umständen auch nach der Implementierung erfolgen. Abbildung 39 (textuell angelehnt an [COBIT, 2005]) stellt die detaillierten Control Objectives für den Prozess Manage Changes dar. Die COBIT Control Objectives sind den Prozesszielen und Prozessaufgaben der ITIL Best Practices gleichzusetzen. Durch definierte Prozessaktivitäten soll sichergestellt werden, dass die Control Objectives erreicht werden, was gleichbedeutend damit ist, dass der Prozess die gewünschten Zwecke erfüllt. 107

118 2 IT Service Management AI6: Manage Changes AI6.1: Standard-Changes und Prozeduren AI6.2: Bewertung von Auswirkungen, Priorisierung und Freigabe AI6.3: Notfall-Changes AI6.4: Statusverfolgung und Reporting AI6.5: Abschluss und Dokumentation Abbildung 39: Zusammenhang zwischen Control Objectives in COBIT COBIT gliedert die Performance- Messung in Kriterien für Effektivität und Effizienz Während ITIL die Leistungsindikatoren der Prozesse pauschal als Key Performance-Indikators (KPIs) bezeichnet, betrachtet COBIT die Leistungsmessung der Prozesse als Performance-Messung und unterscheidet bei den Metriken zwischen den Key Goal Indicators (KGIs) und den Key Performance Indicators (KPIs). Mit den KGIs wird gemessen, ob ein Prozess seine definierten Ziele erreicht (Effektivität). KGIs sind daher an dem jeweiligen Prozess-Output orientiert. Mit den KPIs wird dagegen die Leistungsfähigkeit eines Prozesses in Relation zu den eingesetzten Ressourcen gemessen (Effizienz). Der Fokus der KPIs liegt also auf einer Messung der prozessinternen Aktivitäten. Die KGIs sind demzufolge die wichtigeren Kennzahlen für die Bewertung eines Prozesses, da sie dem Management aufzeigen, ob ein Prozess die definierten Anforderungen erfüllt. Die KGIs messen die Effektivität eines Prozesses, während die KPIs die Effizienz betrachten. Hauptaugenmerk sollte zunächst auf den KGIs liegen. COBIT beschreibt aber nicht nur Metriken für die einzelnen IT-Prozesse, sondern legt auch Ziele und Metriken für den gesamten IT-Bereich fest. Dabei werden die Ziele und Metriken von den Geschäftsanforderungen bestimmt. Die Vorgehensweise erfolgt top down. Aus den Geschäftsanforderungen ergeben sich die Ziele für den IT-Bereich. Diese übergeordneten Ziele bestimmen dann die jeweiligen Prozessziele, und mit den Pro- 108

119 2.7 COBIT zesskennzahlen (KGIs, KPIs) erfolgt die Messung, ob die Prozesse die Zielsetzungen erfüllen. Prozessziele und Kennzahlen für Prozesse werden top down definiert. Sie ergeben sich aus den IT-Zielen aus den Geschäftsanforderungen. 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 aufgezeichneten und mit automatisierten Tools verfolgten Änderungen % der Änderungen, die formale Änderungskontrollprozesse 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 40: Ziele, Prozesse und Metriken in COBIT Die Messgrößen für die übergeordneten IT-Ziele bezeichnet COBIT als IT Key Goal Indicators. Da die Prozessziele mit den übergeordneten IT-Zielen korrespondieren bzw. aus ihnen abgeleitet werden, stehen die Prozesskennzahlen mit den IT Key Goal Indicators in einem unmittelbaren Zusammenhang. Bei den Metriken auf Basis der COBIT Best Practices wird so aus dem KGI für die 109

120 2 IT Service Management Prozessmessung ein KPI für die Messung der IT-Ziele. COBIT definiert dies als Performance-Messung. So ist zum Beispiel Nacharbeiten an Applikationen, die durch mangelnde Spezifikation hervorgerufen werden ein KGI für den Prozess Manage Changes. Für das zugeordnete IT-Ziel Reduziere Mängel und Nacharbeiten bei Lösungen und dem Servicebetrieb ist diese Kennzahl dagegen ein KPI. COBIT definiert KPIs und KGIs auf Ebene der Prozesse und der IT-Ziele. Dabei wird aus einem KGI der Prozessebene ein KPI auf Ebene der IT-Ziele. Die Metriken und deren Ebenen stellen sich in COBIT wie folgt dar (hier verdeutlicht am Beispiel Manage Changes, vgl. [COBIT, 2005], siehe Abbildung 40). Während COBIT Version 3.0 (vgl. [COBIT, 2000]) für die einzelnen Prozesse noch die kritischen Erfolgsfaktoren (Critical Success Factors, CSFs) dokumentierte, werden die CSFs in der Version 4.0 nicht mehr gesondert ausgewiesen. Die CSFs wurden aufgeteilt in die Input-Beschreibung ( was benötige ich von anderen ) und in die Aktivitätenbeschreibung ( was muss ich in meinem Prozess durchführen ). COBIT enthält darüber hinaus generelle Anforderungen an das Management von Prozessen. Die folgenden Kriterien sind für jeden Prozess zu erfüllen: Für jeden Prozess ist der Process Owner und dessen Verantwortung zu definieren Jeder Prozess muss wiederholbar sein Für die Prozesse sind klare Ziele und Vorgaben zu definieren Die Rollen, Aktivitäten und Verantwortlichkeiten sind zu definieren Die Prozesse sind hinsichtlich ihrer Zielerreichung zu messen Die dokumentierten, überprüften, aktuellen und unterzeichneten Grundsätze (Policy), Pläne und Verfahren sind allen Beteiligten zu kommunizieren. Die hier beschriebenen Best Practices von COBIT für das Prozess-Management stellen sich wie folgt dar (siehe Abbildung 41): 110

121 2.7 COBIT Anforderung Prozessmanagement Control Objectives KPI KGI Prozess Input Ziele Output Aktivitäten Abbildung 41: Prozess, Ziele und Kontrollebenen in COBIT COBIT und die IT Service Management-Prozesse COBIT enthält relevante Prozesse und Metriken für den gesamten IT-Bereich. Die Prozesse, die innerhalb der ITIL Best Practices für das IT Service Management beschrieben sind, können als eine echte Teilmenge des Spektrums der in COBIT dargestellten Prozesse betrachtet werden. Die in COBIT beschriebenen Prozesse stehen somit nicht im Widerspruch zu den ITIL Best Practices. Mit der Veröffentlichung von COBIT Version 4.0 hat sich COBIT den ITIL Best Practices sogar noch weiter angenähert. Während in älteren Versionen von COBIT zum Beispiel das Incident und Problem Management in einem gemeinsamen Prozess beschrieben wurden, hat COBIT Version 4.0 die ITIL Prozessstruktur mit getrennten Prozessen für das Incident und Problem Management übernommen. Es geht daher nicht um den Wettstreit konkurrierender Best Practices, sondern vielmehr darum, wie die verschiedenen Best Practices konvergieren und gewinnbringend genutzt werden können. Die Vorteile und Stärken von ITIL liegen zum einen in der generischen und sehr ausführlichen Beschreibung von Prozessaktivitäten und in den Empfehlungen zur Gestaltung und Umsetzung der Prozesse. Zum anderen erhöht die enge Verbindung zur ISO die praktische Relevanz des ITIL Ansatzes. 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. 111

122 2 IT Service Management Bei der Prozessbeschreibung begnügt sich COBIT hingegen mit einer kurzen Aufzählung von Aktivitäten. Für den Prozess Manage Changes beispielsweise sind die Prozessaktivitäten in fünf Sätzen dokumentiert. COBIT liefert jedoch im Gegensatz zu ITIL gute Ansätze für die Definition von Metriken, die zum Teil Wirtschaftsprüfern bekannt sind und bei einer Auditierung hilfreich sind. Während die Vorteile von ITIL in den Prozessbeschreibungen und Empfehlungen für die Umsetzung liegen, bietet COBIT gute Ansätze für Metriken. Die Prozesse für das IT Service Management stimmen in den Best Practices grundsätzlich überein, so dass aus beiden Ansätzen die Stärken zusammengeführt werden können. Prozesse - Überwache und bewerte IT-Performance - Überwache und bewerte interne Controls - Stelle die angeordnete Compliance sicher - Sorge für IT-Governance 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 42: Mapping der Prozesse in ITIL Version 2 und COBIT Eine Analyse der COBIT Best Practices und der IT Service Management- Prozesse auf Basis der ITIL Best Practices zeigt eine große Überstimmung von Prozessen und deren Ziele bzw. Aktivitäten (vgl. [Kurth, 2006]). 112

123 2.7 COBIT Die übereinstimmenden IT Service Management-Prozesse zwischen den ITIL Best Practices Version 2 und COBIT wurden seitens des IT Governance Institute analysiert und dokumentiert (vgl. [COBIT, 2007]). Der folgenden Abbildung 42 können diese übereinstimmenden Prozesse für das IT Service Management entnommen werden. Innerhalb des dokumentierten Mappings zwischen ITIL und COBIT wird der Prozess DS 5 Stelle Systemsicherheit sicher nicht als übereinstimmend ausgewiesen. Im Rahmen der ISO ist aber das Security Management als Prozess des IT Service Managements definiert. Daher wurde in der folgenden Darstellung aus [COBIT, 2007] (Abbildung 42) der Prozess DS 5 Stelle Systemsicherheit sicher ebenfalls hervorgehoben. Mit der ITIL Version 3 wird eine noch größere Abdeckung erreicht. Ein entsprechendes Mapping ist aber zurzeit noch nicht publiziert 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]). 113

124 2 IT Service Management COBIT Metriken für IT Service Management-Prozesse Manage Service Desk und Incidents (Manage Service Desk and Incidents: DS8) Zielsetzung dieses Prozesses ist die wirkungsvolle Nutzung der IT-Systeme durch die Lösung und Analyse von Anwenderanfragen und Incidents. Zur Zielerreichung ist die Etablierung eines Service Desks und eines Incident Managements notwendig. Die in COBIT dokumentierten KPIs sind: Anzahl der pro Mitarbeiter im Service Desk stündlich bearbeiteten Anrufe (Calls) Anteil der Incidents, die einen Vor-Ort-Support benötigen Arbeitsrückstand ungelöster Anfragen Die in COBIT dokumentierten KGIs sind: Durchschnittliche Bearbeitungszeit nach Gewichtung (severity) Anteil wieder geöffneter (reopen) Incidents Durchschnittliche Reaktionszeit Die in COBIT dokumentierten IT Key Goal Indicators sind: Anwenderzufriedenheit mit dem Service Desk Anteil der innerhalb der vereinbarten Zeit gelösten Incidents Manage Probleme (Manage Problems: DS10) Das Ziel des Problem Managements ist die Gewährleistung der Anwenderzufriedenheit und die Reduzierung von Mängeln an Services. Dies soll durch die Ermittlung der zugrunde liegenden Ursachen für alle wichtigen Probleme und durch die Definition von Lösungen für die identifizierten Probleme erreicht werden. Die in COBIT dokumentierten KPIs sind: Durchschnittliche Dauer zwischen Problemerfassung und der Identifizierung der Ursache Anteil der Probleme, für die eine Ursachenanalyse betrieben wurde Häufigkeit der Berichte oder Aktualisierung über anhaltende Probleme, basierend auf deren Gewichtung (severity) Die in COBIT dokumentierten KGIs sind: Anteil der Probleme, die innerhalb der vorgeschriebenen Zeit gelöst wurden Mittelwert und Standardabweichung der Zeitdauer zwischen der Identifizierung und der Problemlösung 114

125 2.7 COBIT Mittelwert und Standardabweichung der Zeitdauer zwischen der Problemlösung und dem Abschluss Die in COBIT dokumentierten IT Key Goal Indicators sind: Anzahl der wiederkehrenden Probleme mit Auswirkung auf das Business Anzahl der Geschäftsunterbrechungen aufgrund operationeller Probleme Manage die Konfigurationen (Manage the configuration: DS9) Das Configuration Management hat die Optimierung der IT-Infrastruktur, der Ressourcen und Kapazitäten sowie den Nachweis der IT-Anlagen zum Ziel. Basis hierfür ist die fehlerfreie und vollständige Erfassung und Speicherung der Konfigurationsattribute der IT-Anlagen und der Baselines, sowie die Prüfung, ob sie mit den tatsächlichen Konfigurationen übereinstimmen. Die in COBIT dokumentierten KPIs sind: Anzahl der Abweichungen in Bezug auf unvollständige oder fehlende Konfigurationsinformationen Durchschnittliche Zeitdauer zwischen der Identifizierung einer Abweichung und deren Korrektur Die in COBIT dokumentierten KGIs sind: Anzahl der Abweichungen zwischen den gespeicherten und tatsächlichen Konfigurationsdaten Anteil der erworbenen Lizenzen und der nicht in der Datenbank gespeicherten Lizenzen Die in COBIT dokumentierten IT Key Goal Indicators sind: Anteil der Compliance-Probleme aufgrund unzulässiger Konfigurationen von IT-Anlagen Manage Changes (Manage Changes: AI6) Das Ziel des Manage Changes ist, Änderungen innerhalb der Produktivumgebung auf eine formell gesteuerte Art und Weise durchzuführen. Zu Changes zählen neben Änderungen an der Infrastruktur und an bestehenden Anwendungen auch Notfall-Changes und Patches. Die in COBIT dokumentierten KPIs sind: Verhältnis zwischen den akzeptierten und den abgelehnten RfCs Anzahl und Art der Notfall-Changes Anzahl und Art der Patches Die in COBIT dokumentierten KGIs sind: 115

126 2 IT Service Management Anteil der Notfall-Changes am gesamten Change-Aufkommen Reduzierter Aufwand und Zeitaufwand zur Durchführung von Changes Anteil nicht erfolgreicher Changes aufgrund von untauglichen Change-Spezifkationen Die in COBIT dokumentierten IT Key Goal Indicators sind: Anteil der Serviceunterbrechungen durch ungenaue Spezifikationen oder fehlerhafte Beurteilung der Auswirkungen Installiere und genehmige Lösungen und Changes (Install and accredit solutions and changes: AI7) Dieser Prozess hat das Ziel, sicherzustellen, dass neue oder geänderte Systeme nach der Installation ohne größere Probleme betrieben werden können. Dieses Ziel soll unter anderem durch eine Releaseplanung und die Etablierung von Testmethoden erreicht werden. Die in COBIT dokumentierten KPIs sind: Anteil der Fehler, die während des Qualitätsmanagement-Reviews bei der Installations- und Zulassungsprüfung gefunden werden Anzahl der beim Post-Implementation-Review erkannten Verbesserungen Anteil der Projekte mit dokumentierten und genehmigten Testplänen Die in COBIT dokumentierten KGIs sind: Anteil der Installations- und Zulassungsfehler, die während Audits gefunden werden Nacharbeiten nach der Implementierung, die auf ungenügende Akzeptanztests zurückzuführen sind Ausfallzeiten der Anwendung, die durch ungenügende Tests hervorgerufen werden Die in COBIT dokumentierten IT Key Goal Indicators sind: Anteil der Interessenvertreter, die mit der Daten-Integrität der neuen Systeme zufrieden sind Definiere und Manage Service Level (Define and manage service levels: DS1) Das Service Level Management hat die Ausrichtung der wesentlichen IT Services an der Geschäftsstrategie zum Ziel. Hierzu sind Serviceanforderungen zu identifizieren, die Service Level (Anmerkung: ITIL bezeichnet 116

127 2.7 COBIT dieses als Service Level-Ziele) sind zu vereinbaren und deren Einhaltung ist zu überwachen. Die in COBIT dokumentierten KPIs sind: Anzahl der jährlichen SLA-Reviews mit dem Business Anteil der berichteten Service Level Anteil der automatisch berechneten Service Level Die in COBIT dokumentierten KGIs sind: Anzahl der erbrachten Services, die nicht im Katalog enthalten sind Anteil der eingehaltenen Service Level Anteil der gemessenen Service Level Die in COBIT dokumentierten IT Key Goal Indicators sind: Anteil der Interessenvertreter, die mit den erreichten Service Level zufrieden sind Identifiziere und verrechne Kosten (Identify and allocate cost: DS6) Dieser Prozess soll die Transparenz und das Verstehen von IT-Kosten gewährleisten und auf der Basis dieser Informationen eine Steigerung der Kosteneffizienz durch kostenbewusste Verwendung der IT Services erreichen. Hierzu sind die IT-Kosten vollständig und genau zu erfassen, ein faires Verrechnungssystem ist zu vereinbaren, und über die IT-Kosten und die IT-Nutzung ist rechtzeitig zu berichten. Die in COBIT dokumentierten KPIs sind: Anteil der Kosten, die automatisch / manuell verrechnet werden Häufigkeit der Überprüfung des Verrechnungsmodells Die in COBIT dokumentierten KGIs sind: Anteil der Abweichungen zwischen Budget, vorhergesagten und aktuellen Kosten Anteil der Gesamtkosten, die nach dem vereinbarten Kostenmodell verrechnet wurden Anteil der Kosten die mit dem Business umstritten sind Die in COBIT dokumentierten IT Key Goal Indicators sind: Anteil der vom Business akzeptierten, verrechneten Services Kundenzufriedenheit mit dem Verrechnungsmodell für IT Services Manage die IT-Investitionen (Manage the IT-Investment PO5) Innerhalb dieses Prozesses ist ein System zum Management der Investitionsplanung zu etablieren und zu betreiben. Dieses Managementsystem 117

128 2 IT Service Management umfasst die Betrachtung der Kosten, des Nutzens und der Priorisierung von Investitionen innerhalb des geplanten Budgets. Die in COBIT dokumentierten KPIs sind: Prozent der Projekte mit einem definierten Nutzen Prozent der Projekte, für die ein Review nach dem Abschluss durchgeführt werden Die in COBIT dokumentierten KGIs sind: Anzahl von Budgetabweichungen Prozentuale Darstellung der Budgetabweichung gegenüber dem Gesamtbudget Prozentualer Anteil der IT-Investitionen, die den zuvor definierten Nutzen erzielen Die in COBIT dokumentierten IT Key Goal Indicators sind: Prozentualer Anteil der IT-Investitionen, die den zuvor definierten Geschäftsnutzen erzielen oder übertreffen Prozent der IT-Werttreiber, abgebildet auf die Business-Werttreiber Manage Performance und Kapazitäten (Manage performance and capacity DS3) Das Ziel des Capacity Managements liegt in der Performanceoptimierung der IT-Infrastruktur, der Ressourcen und Kapazitäten in Übereinstimmung mit den Geschäftsanforderungen. Hierzu sind die im SLA vereinbarten Antwortzeiten einzuhalten, die Ausfallzeiten zu minimieren und eine kontinuierliche Verbesserung der IT-Perfomance und Kapazitäten durch Monitoring und Messungen sicherzustellen. Die in COBIT dokumentierten KPIs sind: Häufigkeit der Performance- und Kapazitätsprognosen Anteil der Anlagen, die in Kapazitäts-Reviews betrachtet werden Anteil der Anlagen, die durch zentrale Systeme überwacht werden Die in COBIT dokumentierten KGIs sind: Lastspitzen und Auslastungsrate Anteil der Spitzenlastzeiten, die über die Zielauslastung hinausgehen Anteil der Antwortzeiten, die nicht den SLAs entsprechen Die in COBIT dokumentierten IT Key Goal Indicators sind: Anzahl der Ausfallstunden pro Anwender und Monat aufgrund unzureichender Kapazitätsplanung 118

129 Manage kontinuierliche Services (Ensure continuous service: DS4) 2.8 Monitoring und Reporting von SLAs Dieser Prozess soll sicherstellen, dass mögliche Ausfälle der IT Services minimale Auswirkungen auf die Geschäftsprozesse haben. Die in COBIT dokumentierten KPIs sind: Zeitdauer zwischen den Tests aller Bestandteile des IT-Kontinuitätsplans Häufigkeit der Reviews des IT-Kontinuitätsplans Anteil der kritischen IT-Komponenten mit automatisierter Verfügbarkeitsüberwachung Die in COBIT dokumentierten KGIs sind: Anteil der SLAs, die die Verfügbarkeitszeit erfüllen Anteil der erfolgreichen Tests der IT-Kontinuitätspläne Häufigkeit der Serviceunterbrechung bei kritischen Systemen Die in COBIT dokumentierten IT Key Goal Indicators sind: Anzahl der Ausfallstunden pro Anwender und Monat aufgrund ungeplanter Unterbrechungen Stelle Systemsicherheit sicher (Ensure system security: DS5) Das Security Management hat die Aufrechterhaltung der Integrität von Informationssystemen und die Minimierung der Auswirkungen von Sicherheitsschwachstellen und Security Incidents zum Ziel. Die in COBIT dokumentierten KPIs sind: Häufigkeit und Art der gemeldeten Security Incidents Anzahl und Art von veralteten Benutzerkonten Anzahl der Zugriffsberechtigungen, die autorisiert, widerrufen, gelöscht oder geändert wurden Die in COBIT dokumentierten KGIs sind: Anzahl und Art der vermuteten und tatsächlichen Zugangsverstöße Anzahl und Art von verhinderten bösartigen Codes Anteil der Anwender, die die Password-Standards nicht einhalten Die in COBIT dokumentierten IT Key Goal Indicators sind: Anzahl der Incidents mit Auswirkungen auf das Business 2.8 Monitoring und Reporting von SLAs Die drei Hauptziele des IT Service Managements bestehen darin, die IT Services auf die gegenwärtigen und zukünftigen Anforderungen des Unternehmens und seiner Kunden auszurichten, die Qualität der erbrachten 119

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

131 2.8 Monitoring und Reporting von SLAs Technologische Lösungen können ausgetauscht und ersetzt werden. Aber das Verständnis der Business-Anforderungen, die professionelle Ausrichtung der IT Services an die Business-Anforderungen und deren Sicherstellung differenziert eine professionelle IT-Organisation von Technologiebetreibern Definition und Interpretation des Begriffs IT Service Bedingt durch die historische Entwicklung innerhalb der IT konzentrierte sich die IT-Organisation zunächst auf die Bereitstellung von technischen Systemen. Diese Systeme, zum Beispiel eine auf dem Host implementierte Applikation, unterstützten die Durchführung geschäftlicher Aktivitäten. Mit der steigenden Komplexität der Applikationen und deren zunehmender Bedeutung für einen reibungslosen Geschäftsprozess wurde offensichtlich, dass die ausschließliche Betrachtung des technischen Betriebs eines Systems nicht mehr ausreichend ist. Hieraus hat sich zum Beispiel der Aufbau eines Service Desk als Unterstützungssystem für den Anwender entwickelt. Mit der Weiterentwicklung innerhalb der Informations- Technologie greift eine Vielzahl von einzelnen Systemen ineinander, um die Durchführung von Geschäftsprozessen des Kunden zu gewährleisten. Damit wandelte sich auch die Sicht des Kunden auf die IT. Der Kunde sieht nur den Output der miteinander in Verbindung stehenden Systeme. Hierzu führt ITIL aus Bei der Erbringung von Services steht die 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. 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 Von der System- zur Service- Orientierung. 121

132 2 IT Service Management Unternehmens bewusst zu werden, ist die Frage was würde beim Ausfall der IT-Systeme geschehen sehr hilfreich. Damit die geschäftlichen Aktivitäten entsprechend unterstützt werden können, ist in der Regel das Zusammenwirken verschiedener IT-Systeme notwendig. In IT-Organisation herrscht heute aber zum Teil noch eine technologische Betrachtung vor. Systemspezialisten fokussieren sich auf ihr System. Dieses System stellt aber nur ein Rädchen im Getriebe dar, und die Funktionalität des Gesamtsystems ist für die Unterstützung der Geschäftsprozess entscheidend. Die IT-Organisation muss erkennen, dass der Systembetrieb keinen Selbstzweck darstellt, sondern zweckdienliche Geschäftsprozesse mit der notwendigen IT-Unterstützung für den Unternehmenserfolg entscheidend sind. Für das Selbstverständnis der IT ist es wichtig zu erkennen, dass die Bereitstellung der IT Services in erster Linie der Unterstützung der betrieblichen Primäraktivitäten bzw. der Kerngeschäftsprozesse dient und damit über den Erfolg eines Unternehmens entscheidet. ITIL stellt den IT Service in direkten Bezug zum Geschäftsprozess So führt Porter 5 in seinem Wertschöpfungsdiagramm aus, dass die primären Aktivitäten eines Unternehmens die Kundenanforderungen bedienen und die Wertschöpfung eines Unternehmens sicherstellen. Die unterstützenden Prozesse oder sekundären Aktivitäten unterstützen die Durchführung der primären Aktivitäten bzw. Geschäftsprozesse. Die IT gehört in der Regel zu den unterstützenden Aktivitäten und muss demzufolge in erster Linie die übergeordneten Wertschöpfungsprozesse sicherstellen (vgl. Abbildung 43). Aus Sicht der IT gibt es eine Vielzahl von unterschiedlichen Business- und Kundenanforderungen, die aus den primären und sekundären Prozessen bzw. Aktivitäten resultieren. Die erforderliche IT-Unterstützung für die Geschäftsprozesse definiert ITIL Version 2 prägnant als einen IT Service; der IT Service ist ein oder mehrere IT-Systeme, die einen Geschäftsprozess ermöglichen (vgl. [OGC, 2006b]). Mit ITIL Version 3 wird der Kundenbezug des Service noch stärker herausgestellt (vgl. [OGC, 2007a]): IT Service Management: Die Implementierung und Verwaltung von qualitätsbasierten IT Services, die den Anforderungen des Business gerecht werden. Das IT Service Management 5 Michael E. Porter, Professor für Wirtschaftswissenschaften an der Harvard Business School und einer der führenden Ökonomen auf dem Gebiet des strategischen Managements. 122

133 2.8 Monitoring und Reporting von SLAs wird von IT Service Providern mithilfe einer geeigneten Kombination aus Personen, Prozessen und Informationstechnologie durchgeführt. IT Service Management Unternehmensinfrastruktur IT-Service 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 43: Wertschöpfungskette nach Porter Innerhalb des Glossars wird diese Gesamtsicht zum IT Service nochmals deutlich herausgestellt; Die Erbringungskriterien der IT Service Organisation aus Sicht der Kunden, die Services, umfassen nicht nur die Bereitstellung von Computerressourcen zur Verwendung durch die Kunden (vgl. [OGC, 2006b]). IT Service Ein Service, der für einen oder mehrere Kunden von einem IT Service Provider bereitgestellt wird. Ein IT Service basiert auf dem Einsatz der Informationstechnologie und unterstützt die Business-Prozesse des Kunden. Ein IT Service besteht aus einer Kombination von Personen, Prozessen und Technologie und sollte in einem Service Level Agreement definiert werden. Diese Anforderungen an einen IT Service unterscheiden sich in Abhängigkeit der Bedeutung der Geschäftsprozesse für das Unternehmen stark in 123

134 2 IT Service Management ihrer Art der Leistung und Qualität. Das Kundeninteresse liegt primär in der notwendigen Unterstützung der Geschäftsprozesse. Damit nimmt der Kunde die IT-Organisation mit den geleisteten IT Services als maßgeblichen Output wahr. Die damit verbundenen IT Service Management-Prozesse sind in der Regel eine interne Betrachtung der IT-Organisation. Die Kunden- und Geschäftssicht ist bei der Definition der notwendigen IT-Unterstützung entscheidend. Die geleisteten IT Services sind der maßgebliche Output und bestimmen die Wahrnehmung der IT Service Level Agreements Das Service Level Management hat die Kundenanforderungen an einen IT Service aufzunehmen. Diese Anforderungen werden in Service Level Requirements (SLRs, Service Level Anforderungen) dokumentiert. Auf der Basis dieser Anforderungen wird vom IT Service Provider die Möglichkeit der Leistungserbringung geprüft. Mit dem Kunden werden daraufhin Verhandlungen geführt, und es kommt zu einem iterativen Prozess, in dem die Kundenanforderungen auf die zu erbringende Servicequalität abgestimmt werden. Letztendlich wird zwischen dem Kunden und dem IT Service Provider eine Vereinbarung getroffen und in einem Service Level Agreement (SLA) dokumentiert. Die ITIL Best Practices definieren einen SLA als eine schriftliche Vereinbarung zwischen einem Service-Anbieter und einem Kunden, in der vereinbarte Service Level für einen Service dokumentiert sind. (vgl. [OGC, 2006b] und [OGC, 2007b]): Service Level Agreement: Eine Vereinbarung zwischen einem IT Service Provider und einem Kunden. Das SLA beschreibt den jeweiligen IT Service, dokumentiert Service Level-Ziele und legt die Verantwortlichkeiten des IT Service Providers und des Kunden fest. Ein einzelnes SLA kann mehrere IT Services oder mehrere Kunden abdecken. Zur Absicherung des SLAs werden intern Operational Level Agreements (OLAs) und extern Lieferantenverträge (Underpinning Contracts, UCs) abgeschlossen. Die Struktur und die möglichen Inhalte von SLA, OLA und UC werden im nächsten Kapitel erläutert. Sowohl in ITIL, als auch in COBIT wird die Aufgabe der Erstellung und Pflege der erforderlichen Dokumente, bestehend aus Servicekatalog, Service Level Agreement (SLA), Operational Level Agreement (OLA) und Underpinning Contract (UC) dem Prozess des Service Level Managements zugewiesen. 124

135 2.8 Monitoring und Reporting von SLAs COBIT nimmt bei der Definition von Control Objectives und Leistungsindikatoren (KGI, KPI) Bezug auf den Servicekatalog, die SLAs, die OLAs und die UCs. Aber: Anforderungen an deren inhaltliche Gestaltung sind in COBIT nicht dokumentiert. So weist lediglich das Control Objective DS1.3 Service Level Agreement darauf hin, dass die Rahmenbedingungen für Verfügbarkeit, Performance, Verlässlichkeit, Wachstumsfähigkeit, Support-Level, Kontinuitätsplanung, Sicherheit und Nachfrage im SLA zu berücksichtigen sind. Dagegen umfassen ITIL und die ISO die Best Practices zu den notwendigen Inhalten von SLAs. Diese Inhalte werden in Abschnitt beschrieben. ITIL und ISO enthalten Best Practices für die Inhalte von SLAs. 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 44 dient der Erläuterung und zeigt, wie zum Beispiel für einen IT Service Gehaltsabrechnung die Anforderungen an die Verfügbarkeit in einzelne OLAs und UCs einfließen könnten. 125

136 2 IT Service Management 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 44: Zusammenhang zwischen SLAs, OLAs und UCs Die Struktur der SLAs ist unternehmensspezifisch. IT Services werden system- und organisationsübergreifend erbracht 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. 126

137 2.8 Monitoring und Reporting von SLAs 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. 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 45). Hinzu kommen weitere Vorteile wie zum Beispiel geringere Aufwendungen für die Aktualisierung und die Reduzierung von Inkonsistenzen. Mehrschichtige SLAs bilden ein hierarchisches System. Auf der obersten Ebene werden allgemeine Regelungen getroffen, die für das gesamte Un- SLA-Strukturen reduzieren Aufwendungen. - Unternehmens-Ebene: - Unternehmensweite SLA- Vereinbarungen - Allgemeine Definitionen und Regelungen zum Monitoring - Kunden-Ebene: - Kundenbezogene SLA- Vereinbarungen - Unterstes Level: - Servicebezogene SLA- Vereinbarungen - Ausgestaltung des auf Unternehmens-Ebene definierten Monitoring Abbildung 45: Beispiel für mehrschichtige SLAs 127

138 2 IT Service Management Messwerkzeuge und einheitliche Messverfahren sollten einheitlich vorgegeben werden. 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 Die Inhalte von SLAs Service Level und Auslastungs-Kriterien sind zu vereinbaren und aufzuzeichnen 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 Levels und Auslastungs-Kriterien müssen zwischen den Parteien vereinbart und aufgezeichnet werden oder Jeder gelieferte Service muss in einem oder mehreren SLAs definiert, vereinbart und dokumentiert werden. (vgl. [ISO , 2005]). Vorgaben zur inhaltlichen Gestaltung der SLAs macht die ISO nicht. Die ISO enthält Mindestanforderungen an die Verwendung von SLAs. Im Fokus stehen dabei die Anforderungen an den Prozess des Service Level Managements. Innerhalb der ISO wird dagegen auf die inhaltliche Gestaltung der notwendigen Dokumente eingegangen. So sind Best Practices zum Servicekatalog und ein Leitfaden für die inhaltliche Gestaltung der SLAs dokumentiert. Im Zusammenspiel zwischen Servicekatalog und SLA empfiehlt die ISO , eine Referenzierung vom SLA zum Servicekatalog aufzubauen. 128

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

140 2 IT Service Management Die Einhaltung von Service Level und SLAs wird mittels vereinbarter Service- Ziele definiert, überwacht und berichtet. Service-Ziele sind aus der Kundenperspektive zu definieren. Konzentration auf die wesentlichen Service Level Zur Definition der Service Level-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 Level-Ziele in einer Sprache zu verfassen, die der Kunde versteht und die seiner Perspektive entspricht. So sollten zum Beispiel in einem SLA Begriffe wie Buchungsvorgänge und Anzahl gespeicherter Artikel verwendet werden. Messgrößen wie CPU-Auslastung oder Datenbankgröße entsprechen dagegen in der Regel nicht der Kundenperspektive und sind zu vermeiden. 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. 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 SLAs wie folgt: Einleitung - Parteien der Vereinbarung - Bezeichnung und Kurzbeschreibung der Vereinbarung - Unterzeichnende 130

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

142 2 IT Service Management Changes - Zielvorgaben für die Genehmigung, Bearbeitung und Implementierung von RfCs; üblicherweise bezogen auf Kategorie oder Dringlichkeit/Priorität Kontinuität und Sicherheit der IT Services - Eine kurze Benennung des IT Service Continuity Plans und wie er aktiviert wird - Ausführungen zu Sicherheitsfragen, insbesondere Verantwortungen des Kunden (zum Beispiel Backup von nicht angebundenen PCs, Passwort-Änderungen) - Einzelheiten zu verminderten oder geänderten 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 Reportings in die Verantwortung des Service Level Managements. Dabei werden die SLAs und die damit in Verbindung stehenden OLAs und UCs gemessen und die Ergebnisse den jeweiligen Organisationsbereichen berichtet. In der ISO heißt es hierzu: Service Level sind zu überwachen und gegenüber den vereinbarten Zielen (Service Level-Zielen) 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 Abschnitt 132

143 2.8 Monitoring und Reporting von SLAs 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 Service Level sind dort zu messen, wo der Service wahrgenommen wird. 133

144 2 IT Service Management und den Nachweis der Einhaltung der Service-Ziele einfordert, ist der Streit vorprogrammiert. Bei der Messbarkeit von SLAs darf nicht außer Acht gelassen werden, dass Kunden und Anwender die IT in der Regel nur dann bemerken, wenn sie ausfällt. Diese Ausfälle bestimmen daher häufig das Erscheinungsbild der IT. Durch das Monitoring und Reporting kann der IT Service Provider dazu beigetragen, diese negative Kundenwahrnehmung der IT zu verändern. Das Monitoring und Reporting der Service Level und der Nachweis der Einhaltung der Service-Ziele tragen zur Steigerung der Kundenzufriedenheit bei. Das Monitoring und das Reporting der Service Level und der eingehaltenen Service-Ziele muss im Eigeninteresse des IT Service Providers liegen. Daher sind die SLAs, OLAs und UCs eindeutig zu formulieren, dürfen keine mehrdeutigen Interpretationen zulassen und sind gegenüber den festgelegten Service-Zielen zu messen. Die ISO verlangt auch die Darstellung von Trends. 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 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 (d.h. Unterschreitung) der festgelegten Service-Ziele. 134

145 2.8.7 Abgrenzung der Kennzahlen 2.9 Integrationsinstrument: Balanced Scorecard 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 von Robert S. Kaplan und David P. Norton Anfang der 90er Jahre entwickelte Balanced Scorecard 6 ist nicht nur ein Messsystem, sondern vielmehr ein exzellentes Management- und Steuerungssystem. Sie kann in unterschiedlichen Unternehmensbereichen eingesetzt werden. Nach unserer Erfahrung eignet sie sich besonders gut als Management- und Reporting-Instrument für IT-Organisationen bzw. deren Bereiche. Wir verwenden die Balanced Scorecard als Integrationsinstrument, das in der Lage ist, Kennzahlen aus unterschiedlichen Systemen zusammenzuführen, zu verknüpfen und für entsprechende Adressatenkreise geeignet darzustellen. In den Projekten, die wir in IT-Organisationen unterschiedlicher Größen und Branchen durchgeführt haben, hat sich immer wieder gezeigt, dass es durch Anwendung der Balanced Scorecard möglich ist, die Lage der IT in ihrem jeweiligen Geschäftsumfeld realitätsnah, transparent und korrekt darzustellen. Richtig eingesetzt, hält die Balanced Scorecard Die Balanced Scorecard ist ein Kennzahlen- und Management- System. 6 Häufig abgekürzt als BSC, für den IT-Bereich als IT-BSC. 135

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

147 2.9 Integrationsinstrument: Balanced Scorecard ergänzt daher die traditionelle finanzielle Perspektive um drei weitere Perspektiven. Auf diese Weise erhält man ein 4-dimensionales Modell, das ein und dasselbe Objekt, z.b. einen Unternehmensteilbereich, aus verschiedenen Blickwinkeln beleuchtet und bewertet. Die von Kaplan und Norton vorgeschlagene Balanced Scorecard ist 4-dimensional. Sie enthält die 4 Perspektiven: Finanzen, Kunden, Prozesse 7 und Potenziale 8. Neben der Mehrdimensionalität des Zielsystems basiert die Balanced Scorecard auf einer weiteren Idee, die sich leicht im täglichen Leben wiederfinden lässt. Der Begriff balanced sagt aus, dass die Perspektiven ausgeglichen bzw. ausgewogen sein müssen. Bemüht man weitere wörtliche Übersetzungen des Begriffs, so bietet sich die technische Interpretation ausgewuchtet an, die verdeutlicht, dass das Gesamtsystem der Scorecard nur dann Sinn macht, wenn die einzelnen Komponenten richtig aufeinander abgestimmt sind. 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. Die Balanced Scorecard ist ein mehrdimensionales und ausgewogenes Zielsystem. Wendet man die Balanced Scorecard auf den IT-Bereich an, so hat dies eine gravierende Konsequenz: Die alleinige Bewertung der IT anhand von Kostenzahlen ist nicht mehr state of the art. Die Balanced Scorecard berücksichtigt insbesondere strategische Aspekte. Ein wesentliches Ziel ist in diesem Zusammenhang die Garantie des mittel- und langfristigen Erfolgs der zu betrachtenden Unternehmenseinheit. Es geht damit weniger um kurzfristig realisierbare Unternehmensgewinne sondern mehr um Kontinuitätsgesichtspunkte. Es geht nicht um kurzfristige Gewinne sondern um Kontinuität. Die Balanced Scorecard versucht, Wertschöpfungsprozesse mit dem richtigen Augenmaß zu bewerten und herauszufinden, welche Faktoren für den langfristigen Erfolg des Unternehmens ausschlaggebend sind. 7 Die Prozessperspektive wird im Original Interne Geschäftsprozesse genannt. 8 Die Potenzialperspektive wird im Original Lernen und Entwicklung genannt. 137

148 2 IT Service Management Die Balanced Scorecard ist ein top down- Instrument zur Strategieumsetzung. Wichtigstes Ziel der Balanced Scorecard ist die Umsetzung von Unternehmenszielen auf allen Ebenen. Dies wird dadurch erreicht, dass sich, ausgehend von der Vision, die Strategie des Unternehmens ableiten lässt und sich daraus konkrete Ziele definieren lassen. Der Aspekt der Vision und Strategie steht damit im Mittelpunkt einer jeden Balanced Scorecard. In [Kaplan et al., 1996] wird dies mit den Schlagworten translating strategy into action und measures that drive (future) performance herausgestellt. Finanzperspektive 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 46: Allgemeine Balanced Scorecard Um den Kern von Vision und Strategie ranken sich vier Betrachtungsweisen (vgl. Abbildung 46): Finanzielle Ziele: Wie soll das Unternehmen gegenüber Teilhabern und Kapitalgebern auftreten, um finanziellen Erfolg zu erreichen? Kundenbezogene Ziele: Wie soll das Unternehmen gegenüber Kunden auftreten, um seine Vision zu verwirklichen? 138

149 2.9 Integrationsinstrument: Balanced Scorecard Prozessbezogene Ziele: In welchen Geschäftsprozessen muss das Unternehmen an der Spitze stehen, um seine Teilhaber und Kunden zu befriedigen? Mitarbeiter- und Innovationsbezogene Ziele: Wie kann das Unternehmen Veränderungs- und Wachstumspotenziale fördern, um seine Vision zu verwirklichen? Diese Ziele lassen sich beispielsweise folgendermaßen detaillieren: 9 Finanzielle Ziele Kostenreduktion Strategische Ausrichtung von Investitionen Umsatzsteigerung Kundenbezogene Ziele Gewinnung neuer Kundensegmente Umsatzerhöhung pro Kunde Festigung der Kundentreue Prozessbezogene Ziele Lean Management realisieren Best of breed-technologien einsetzen Grundideen des Business Process Reengineering umsetzen Mitarbeiter- und Innovationsbezogene Ziele Erhöhung der Mitarbeiterzufriedenheit Etablieren eines Unternehmenswerte-Systems Durchführung von Qualifikationsmaßnahmen Die Verknüpfung der Unternehmensstrategie und der operativen Maßnahmenplanung erfolgt über Ursache-Wirkungsketten (siehe Abbildung 47). In der Praxis können diese Wirkungszusammenhänge sehr kompliziert, ja sogar konfliktär sein. In [Kaplan et al., 1996] sind die Schritte dargestellt, die notwendig sind, um ein Balanced Scorecard-Konzept zu erstellen. Dabei sind 10 Teilaufgaben zu lösen, ausgehend von Aufgabe 1: Select the appropriate organizational unit bis zu Aufgabe 10: Finalize the implementation plan. 9 Die Detaillierung leitet sich aus der IT-Strategie und dem Zielsystem des Unternehmens ab. 139

150 2 IT Service Management 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 47: Ursache-Wirkungskette Unternehmensziele Strategien Kundenzufriedenheit Kundenperspektive interne Prozessperspektive Finanzperspektive Lern- & Entwicklungsperspektive operative Umsetzung Erfolgskontrolle Abbildung 48: Stellung der BSC im Unternehmensplanungsprozess Es sollen nicht mehr als 25 Kennzahlen (4 bis 7 je Perspektive) verwendet werden. Die Kennzahlen sollen Vergangenheit, Gegenwart und Zukunft messen. Vor allen Dingen sollen die Kennzahlen strategisch dimensioniert sein, denn das Konzept der Balanced Scorecard dient der beschleunigten Strategieumsetzung. 140

151 2.9 Integrationsinstrument: Balanced Scorecard Dass sich die Balanced Scorecard immer aus den Unternehmenszielen und der Strategie ableitet, verdeutlicht Abbildung 48 aus [Preißner, 2006] 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 10 einen gewaltigen Schritt näher. Dies wird zumindest zu einer weiteren Vereinheitlichung von IT-Kennzahlensystemen führen. ITIL V3 schlägt in Anlehnung an Kaplan und Norton vier Perspektiven für eine IT Balanced Scorecard vor (vgl. [OGC, 2007e]): -- Zitatanfang -- Financial: As customers how do we view the costs of IT provision? Customer: What do we as customers expect of IT provision? Innovation: Does our IT infrastructure enable us to continue to improve the business? Internal: What must our IT providers (internally) excel at? -- Zitatende Hier ist insbesondere die Vereinheitlichung im Sinne der Etablierung eines allgemein akzeptierten Sprachstandards gemeint. 141

152 2 IT Service Management Die Grundidee von ITIL V3 ist richtig und bestätigt unsere Arbeiten in vielen Projekten, in denen es darum ging, Kennzahlensysteme zur Steuerung und zum Reporting einzusetzen: Es gibt viele Möglichkeiten, Perspektiven für eine IT Balanced Scorecard zu definieren. Allerdings wird sich in der Praxis beweisen müssen, ob die in ITIL V3 genannten vier Perspektiven für die IT die geeigneten sind und ob es nicht mehr oder weniger als vier sind 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 11, so bietet es sich an, das Beste aus allen Welten zu nehmen. Dies verdeutlichen wir später in unserem Kennzahlenmodell und in den Praxisbeispielen. 11 Wir sprechen hier immer von einer (!) Balanced Scorecard, um den Sprachgebrauch einfach zu halten. Für IT-Bereiche können auch mehrere Balanced Scorecards existieren, die gegebenenfalls zusammenhängen. 142

153 2.9 Integrationsinstrument: Balanced Scorecard 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 Kütz Wiggers, Kok und de Boerde Wit Schmid- Kleemann ITIL 2 und ITIL V3 Beitrag zum Kerngeschäft Kundenorientierung Operative Leistungen Zukunftsorientierung Finanzmanagement Kundenmanagement Prozess-Management Innovationsmanagement Mitarbeitermanagement Lieferantenmanagement 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

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

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

156 2 IT Service Management Eine IT Balanced Scorecard kann verschiedene Ansätze integrieren. 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 146

157 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 explizit 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 13 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 14 diesen Zyklus als Erster beschrieben hatte. Da- 13 William Edwards Deming, Walter Andrew Shewhart, amerikanischer Wissenschaftler,

158 3 IT Prozess-Management her wird der PDCA-Zyklus gelegentlich auch als Shewhart-Zyklus bezeichnet (siehe Abbildung 49). Act Verbessern Plan Planen Ständige Verbesserung Check Überprüfen Do Ausführen Abbildung 49: PDCA-Zyklus Der PDCA-Zyklus basiert auf einem prozessorientierten 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 148

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

160 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- Organisationen etabliert. Wie im vorhergehenden Kapitel bereits ausgeführt, werden unter dem IT Service ein oder mehrere IT-Systeme verstanden, die einen Geschäftsprozess unterstützen. In der Regel sind damit die Leistungen von mehreren Abteilungen verbunden. Für die IT Services muss es eine Gesamtverantwortung geben, die die Einhaltung der Service Level Agreements sicherstellt. Der Ansatz führt dazu, dass es organisationsübergreifende Verantwortungen geben muss. Analog wie IT Services organisationsübergreifend sichergestellt werden müssen, verhält es sich mit den IT Service Management-Prozessen. Auch diese Prozesse können nur dann wirkungsvoll sein, wenn die Prozesse und damit verbundenen Verantwortlichkeiten nicht an Abteilungsgrenzen enden. 150

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

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

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

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

165 3.3 Etablierung des Prozess-Managements gen. Dies erfolgt sowohl durch ein begleitendes Veränderungsmanagement, als auch durch Konsequenzen bei der Nichteinhaltung von getroffenen Vorgaben. Damit das IT Service Management erfolgreich innerhalb einer hierarchischen Organisationsstruktur betrieben werden kann, sind die Verantwortlichkeiten eindeutig zu definieren. Diese Definition betrifft einerseits die Abgrenzung zwischen der Linien- und Prozessverantwortung. Andererseits sind auch für das IT Service Management die Verantwortlichkeiten festzulegen. Dazu sind die wahrzunehmenden Rollen im Prozess- Management zu spezifizieren Rollen im Prozess-Management Die hier verwendeten Begriffe sind in IT-Organisationen zum Teil mit anderen Aufgaben und Verantwortlichkeiten hinterlegt. Es ist daher im Rahmen der Implementierung zu prüfen, ob für die folgenden Rollen bestehende Begriffsdefinitionen bzw. die hier dokumentierten Rollenbezeichnungen anzupassen sind. Analog zu den ITIL Best Practices stellen die folgenden Rollenschreibungen Empfehlungen dar, deren Umsetzung von der jeweiligen Situation abhängig ist. So wird eine kleine IT-Organisation nicht einen Prozess- Manager und einen Process Owner etablieren, sondern diese Aufgaben zusammenführen. Die hier beschriebenen Rollen entsprechen den ITIL Best Practices (vgl. [OGC, 2007b) bzw. der ISO (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]): Service Manager: Ein Manager, der für das Management des gesamten Lebenszyklus von einem oder mehreren IT Services verantwortlich ist. Zudem wird der Begriff Service Manager für alle Manager verwendet, die im Bereich des IT Service Providers beschäftigt sind. Am häufigsten wird der Begriff für Business Relationship Ma- 155

166 3 IT Prozess-Management nager, Prozess-Manager, Account Manager oder leitende Manager verwendet, die allgemein für IT Services verantwortlich sind. 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. Daraus folgt, dass es eine den einzelnen Process Ownern und Prozess- Managern vorgesetzte Instanz gibt und diese dem oberen Management angehört. Das IT Service Management und die damit verbundenen Prozesse dienen keinem Selbstzweck, sondern sind in die IT-Planung und -Strategie 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 Process Owner und Prozess-Manager entsprechende Vorgaben, die in die Prozessziele eingehen und letztendlich auch Auswirkungen auf das Kennzahlensystem haben. Diese Vorgaben werden vom oberen Management getroffen und liegen in der Verantwortung des Service Managers. Eine weitere Aufgabe des Service Managers besteht darin, eine Eskalationsebene für die Process Owner und Prozess-Manager zu bieten, da die einzelnen IT Service Management-Prozesse durchaus konkurrierende Ziele verfolgen können. Der Service Manager kann mit einem Städteplaner verglichen werden, während die Process Owner und Prozess-Manager die Architekten und die Bauaufsicht darstellen. Dieser Vergleich trifft aber die Aufgabenstellung nur zum Teil. Während die Tätigkeiten der Architekten und der Bau- 156

167 3.3 Etablierung des Prozess-Managements aufsicht mit der Fertigstellung des Gebäudes abgeschlossen sind, ist das Prozess-Management eine stetige Managementtätigkeit Process Owner Der Process Owner ist für die Zielerreichung des jeweiligen Prozesses verantwortlich. Der Process Owner hat demzufolge die Ergebnisverantwortung für den jeweiligen Prozess. Eine Möglichkeit, die Verantwortlichkeiten für Aktivitäten übersichtlich darzustellen, besteht mittels einer RACI-Matrix. Dabei leitet sich der Name aus den vier Verantwortlichkeiten Responsible, Accountable, Consulted und Informed ab. Dabei wird Responsible als Verantwortung für die Durchführung verstanden. Accountable ist dagegen die Person, die die Gesamt- und letztendlich die Ergebnisverantwortung trägt. Bei der Darstellung in Form der RACI-Matrix werden in einer Matrix Rollen gegenüber Aktivitäten aufgetragen (Abbildung 52). Durch Eintragen der Buchstaben R, A, C und I werden die Aktivitäten den Rollen zugeordnet. Diese Form zur Darstellung der Prozessaktivitäten und Rollen (Funktionen innerhalb der Organisation) wird von ITIL und COBIT genutzt. Role Responisibility Change 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 52: Ausschnitt der RACI-Matrix zum Change Management (vgl. [OGC, 2007c]) 157

168 3 IT Prozess-Management Die Definition von Kennzahlen setzt definierte Prozessziele voraus Die Definition der zu erreichenden Ziele wird mit dem Service Manager abgestimmt und entsprechend dokumentiert. In der ITIL Version 3 wird die Rolle des Process Owners wie folgt definiert (vgl. [OGC, 2007b): Process Owner: Eine Rolle, verantwortlich für die Sicherstellung der Zweckmäßigkeit eines Prozesses. Zu den Verantwortlichkeiten des Process Owners gehören das Sponsorship, das Design, das Change Management sowie die kontinuierliche Verbesserung des Prozesses und seiner Messgrößen. Diese Rolle wird häufig derselben Person zugewiesen, der bereits die Rolle des Prozess-Managers zugewiesen ist. In größeren Organisationen können diese Rollen jedoch separat zugewiesen sein. Auf Basis der definierten Ziele legt der Process Owner gemeinsam mit dem Prozess-Manager die damit verbundenen Kennzahlen fest. Erst mithilfe dieser Kennzahlen kann gesichert festgestellt werden, ob der Prozess die definierten Ziele hinsichtlich der erwarteten Effektivität und Effizienz erreicht. Die Kennzahlen (KGI, KPI) sind top down zu entwickeln. Aus den 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 Process Owner, ob die definierten Ziele erreicht werden. Es hat sich bewährt, dass der Process Owner dem IT-Management angehört. So ist einerseits die Abstimmung mit den Business-Anforderungen sowie mit der IT-Strategie sichergestellt. Anderseits erfährt der Prozess die notwendige Managementunterstützung. Es kann durchaus vorgekommen, dass der Prozess-Manager innerhalb der Organisation auftretende Widerstände überwinden muss. Hier kann ihm ein Process Owner aus dem 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. 158

169 Prozess-Manager 3.3 Etablierung des Prozess-Managements 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): Prozess-Manager: Eine Rolle, die für das operative Management eines Prozesses verantwortlich ist. Zu den Verantwortlichkeiten des Prozess-Managers gehören die Planung und die Koordination aller Aktivitäten, die zur Ausführung, dem Monitoring und der Berichtserstellung in Bezug auf einen Prozess erforderlich sind. Es können mehrere Prozess-Manager für einen Prozess vorhanden sein, z. B. regionale Change Manager oder IT Service Continuity Manager für jedes Rechenzentrum. Die Rolle des Prozess-Managers wird häufig der Person zugewiesen, der bereits die Rolle des Process Owners zugewiesen ist. In größeren Organisationen können diese Rollen jedoch separat zugewiesen sein. In kleineren IT-Organisationen erfolgt keine Unterteilung zwischen Process Owner und Prozess-Manager. Die Ergebnis- und Durchführungsverantwortung wird dann gemeinsam wahrgenommen. Im Rahmen der Durchführungsverantwortung gestaltet der Prozess- Manager den Prozess und definiert die durchführenden Aktivitäten. Er stellt sicher, dass der Prozess mit den notwendigen Ressourcen unterstützt wird. Der Prozess-Manager hat dazu die kritischen Erfolgsfaktoren (CSF: Critical Success Factors) zu identifizieren und durch geeignete Maß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. 159

170 3 IT Prozess-Management Die Kennzahlen sind für den Prozess-Manager ein äußerst wichtiges Management-Werkzeug. Sie signalisieren, was im Prozess passiert und in Verbindung mit Trenddaten wie sich der Prozess entwickelt. Nur mit entsprechenden Kennzahlen kann der Prozess-Manager seiner Verantwortung nachkommen. Um feststellen zu können, warum etwas passiert ist, muss der 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 über das beschriebene Grundlagenwissen zu allen IT Service Management-Prozessen verfügen. Andererseits muss er die Ermittlung bzw. Nutzung der benötigen Daten mit einem anderen Prozess-Manager abstimmen. Der Prozess-Manager benötigt Grundlagenwissen zu allen IT Service Management-Prozessen. Bei der Gestaltung des Prozesses und der Definition der Kennzahlen ist eine enge Zusammenarbeit mit den anderen Prozess-Managern von großer Bedeutung Prozess-Mitarbeiter Die Prozess-Mitarbeiter sind für bestimmte Aktivitäten in einem Prozess verantwortlich und berichten dem Prozess-Manager. Sie führen die Aktivitäten im Prozess durch, die ihrer fachlichen Qualifikation entsprechen. Neben der entsprechenden theoretischen Schulung benötigen die Mitarbeiter auch das Wissen über die konkrete Zielsetzung des Prozesses. Hierzu empfiehlt es sich, zunächst auch die Prozess-Mitarbeiter in den ITIL Grundlagen zu schulen und anschließend die Prozessschulungen durchzuführen. 160

171 3.4 Definition der Prozessziele und -Kennzahlen Mit der Einführung von Prozessen ändern sich häufig bestehende Abläufe und durchzuführende Aktivitäten. Kennzahlen unterstützen hierbei das notwendige Veränderungsmanagement. Anhand von Kennzahlen kann den Prozess-Mitarbeitern dargestellt werden, wie wirksam der Prozess ist und wie ihre Leistungen sowie die veränderten Arbeitsweisen zum erzielten Erfolg beitragen. Nach Möglichkeit sollten die Kennzahlen nicht nur dem Management zur Verfügung stehen. Auch die IT-Mitarbeiter sollten hierauf Zugriff haben 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. Kennzahlen sind informations- und/ oder mitbestimmungspflichtig 3.4 Definition der Prozessziele und -Kennzahlen Definition der Prozessziele 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. 161

172 3 IT Prozess-Management Die hier beschriebene Vorgehensweise stellt sicher, dass die IT Service Management-Prozesse den Geschäftsanforderungen entsprechen, in die IT-Strategie eingebunden sind und die definierten Ziele mit endlichen Ressourcen wirkungsvoll erreicht werden können. Die Kennzahlen und deren Zielwerte sind unmittelbar mit den Prozesszielen verbunden. Daher können die Kennzahlen und deren Zielwerte erst dann definiert werden, wenn die konkreten Prozessziele spezifiziert sind. Mithilfe von COBIT und ITIL kann dann geprüft werden, welche Best Practice-Kennzahlen sich hierfür anbieten. In Projekten mussten darüber hinaus aufgrund der Prozessziele zum Teil Kennzahlen definiert werden, die in COBIT und ITIL nicht spezifiziert sind. Mögliche KPI, KGI aus COBIT und ITIL auszuwählen, ohne die Prozessziele zuvor definiert zu haben, ist nicht zielführend. Gegebenenfalls sind Kennzahlen zu spezifizieren, die in COBIT und ITIL nicht dokumentiert sind. Die Prozessziele und die damit verbundenen Kennzahlen sowie deren Zielwerte sind in dem bereits zuvor angesprochenen top down-ansatz zu definieren. Ein wichtiger Ausgangspunkt bei der Definition von Prozesszielen sind die Anforderungen des Kunden bzw. dessen Geschäftsprozesse. Die Anforderungen aus den Geschäftsprozessen beziehen sich in erster Linie auf die bereitzustellenden IT Services. In der Regel liegen die damit verbundenen (internen) IT Service Management-Prozesse der IT nicht im Blickpunkt des Kunden. Der Kunde benötigt die IT Services zur Durchführung seiner Geschäftsprozesse, und die IT hat dies gemäß den getroffenen Vereinbarungen sicherzustellen. Wie diese Bereitstellung bestmöglich erfolgt, überlässt der Kunde der IT-Organisation, in deren Verantwortung die entsprechende Umsetzung grundsätzlich liegen sollte. Die Anforderungen an die IT Services werden mittels SLAs spezifiziert (siehe Abbildung 53). Daraus abgeleitet werden die OLAs sowie die UCs verhandelt und vereinbart. Anhand dieser Vereinbarungen sind die jeweiligen Service Level sowie die Kapazitätsanforderungen zu messen, zu berichten und regelmäßigen Reviews zu unterziehen. 162

173 3.4 Definition der Prozessziele und -Kennzahlen Business Business-Anforderungen Messung IT-Services Service Level (Ziele) SLA (OLA/UC) Kapazitäten Abbildung 53: Definition der IT Services Werden Verbesserungsmaßnahmen identifiziert, sind diese gemäß ITIL und der ISO 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 54). 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. 163

174 3 IT Prozess-Management 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 54: Definition der IT Services Service Improvement-Plan Bei Kunden-Anforderungen an neue IT Services und bei veränderten Anforderungen an bestehende IT Services (siehe Abbildung 55) ist zu prüfen, ob die etablierten IT Service Management-Prozesse diesen Anforderungen genügen oder unter Umständen die Prozessziele sowie die damit verbundenen Prozessaktivitäten anzupassen sind. Außer den Anforderungen an die IT Services gibt es weitere übergeordnete Kunden- und Geschäfts-Anforderungen an die IT-Organisation, die Auswirkungen auf die IT Service Management-Prozesse haben (siehe Abbildung 56). Zu den Geschäftsanforderungen des Business gehören zum Beispiel die Forderungen nach einem IT Qualitätsmanagement, nachgewiesen durch die ISO 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. 164

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

176 3 IT Prozess-Management Auf Basis der geschäftspolitischen Ziele des Unternehmens, die größtenteils bereits in den zuvor genannten Anforderungen beschrieben sind, wird die IT-Strategie entwickelt (siehe Abbildung 57). Im Rahmen der Entwicklung und Weiterentwicklung der IT Service Management-Prozesse sind diese strategischen Ziele ebenfalls zu berücksichtigen. Business Business-Anforderungen 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 57: Definition der Prozessziele IT-Strategie Auch mögliche finanzpolitische Aspekte haben Auswirkungen auf die IT Service Management-Prozesse und deren Ziele. Dies wird in der ITIL 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. 166

177 3.4 Definition der Prozessziele und -Kennzahlen Eine weitere Quelle für die Definition der Prozessziele der IT Service Management-Prozesse, damit deren Kennzahlen und Sollwerte, sind die Ergebnisse der Prozess Improvement-Pläne (PIPs). In diesen Plänen ist prozessbezogen der jeweils identifizierte Verbesserungsbedarf der IT Service Management-Prozesse dokumentiert (siehe Abbildung 58). Der Verbesserungsbedarf wird im Rahmen von Audits und Reviews sowie anhand der vorliegenden Prozess-Kennzahlen, deren Sollwerte und der nachfolgenden Analysen des Prozesses ermittelt. Business Business-Anforderungen 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 58: Definition der Prozessziele Prozess Improvement-Plan 167

178 3 IT Prozess-Management Diese Informationen sind der Input für die Planung und Implementierung des IT Service Managements (siehe Abbildung 59). Im Rahmen der Planung und Implementierung des IT Service Managements wird die Ausgestaltung des gesamten Systems durchgeführt. Dazu zählt auch die Festlegung der Ziele für die einzelnen Service Management-Prozesse. Business Business-Anforderungen 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 59: Definition der Prozessziele Planung und Implementierung Diese übergeordnete Management-Aufgabe ist nicht als einmaliger Vorgang zu verstehen, sondern sie ist eine fortlaufende Aktivität und entspricht dem kontinuierlichen Verbesserungsprozess gemäß PDCA-Zyklus. Die Planung und Implementierung des IT Service Managements ist kein Projekt, sondern ein übergeordneter Management-Prozess. Mit diesem übergeordneten Management-Prozess wird sichergestellt, dass die IT Service Management-Prozesse auf die Geschäftsziele und daraus 168

179 3.4 Definition der Prozessziele und -Kennzahlen abgeleitete IT-Strategie ausgerichtet sind. Durch die kontinuierliche Anpassung an eine sich ändernde Umgebung und durch die laufende Erfolgsüberprüfung wird die Nachhaltigkeit der implementierten Prozesse sichergestellt. Das Ergebnis der Planung und Implementierung des IT Service Managements sind die Zielvorgaben für die einzelnen IT Service Management- Prozesse. Diese Vorgaben sind ein Teil des dokumentierten Service Management-Plans (SMP). Während im Service Improvement-Plan (SIP) die identifizierten Serviceverbesserungen definiert sind, enthält der Service Management-Plan (SMP) die Dokumentation des aktuellen IT Service Management-Systems. Dieser SMP wird als Dokumentation von der ISO gefordert. Zusätzlich fließen die Ergebnisse aus Planung und Implementierung des IT Service Managements in die Prozess-Management-Pläne (PMPs) ein (siehe Abbildung 60). Durch die PMPs werden auf Prozessebene die übergeordneten Managementziele für den jeweiligen Prozess konkretisiert. Der PMP kann als Prozessdokumentation mit allen notwendigen Informationen wie Prozessbeschreibung, Kennzahlen und deren Zielwerte, etc. angesehen werden. Der hier beschriebene Managementansatz mag zunächst komplex und administrativ erscheinen, aber er stellt letztendlich die wirksame Ausrichtung des IT Service Managements sicher und sorgt für einen zielgerichteten Einsatz der Ressourcen. Die Verantwortung für diesen übergeordneten Prozess liegt beim Top-Management der IT-Organisation in der Rolle des Service Managers. Der Service Manager führt diese Aufgaben durch und stellt das übergeordnete Management-System sicher. Ein Prozess-Management führt mittel- und langfristig zu Erfolgen. Gegebenenfalls sind Quick-Wins abhängig von der bestehenden Ist-Situation zu erzielen, sie stehen aber nicht im Fokus eines Prozess-Managements. 169

180 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) Anforderungen Anforderungen Service Management Plan (SMP) IT Service Management- Prozesse Prozess Management Pläne (PMP) Abbildung 60: Definition der Prozessziele Service Management-Plan 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 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 61). Die konkrete Umsetzung ist Projektaufgabe. 170

181 3.4 Definition der Prozessziele und -Kennzahlen 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 61: Konformität des Managementsystems Es können zwar dezentral einzelne Service Management-Prozesse implementiert werden und einzelne beschriebene Aktivitäten umgesetzt werden. Aber die Etablierung eines IT Service Managements verlangt unabdingbar das Management-Commitment und eine Integration in die bestehenden Management-Prozesse sowie in die IT-Strategie Definition der Prozess-Kennzahlen Auf der Basis der definierten Ziele sind die Control Objectives zu spezifizieren, die Prozessaktivitäten zu definieren und die kritischen Erfolgsfaktoren zu ermitteln. Das Prozessdesign erfolgt dann auf der Basis der zuvor festgelegten Prozessziele (siehe Abbildung 62). Der Umfang der zu erstellenden Prozessdokumentation ist abhängig von der jeweiligen Unternehmenskultur. Es ist ein Kompromiss zu finden zwischen der Dokumentation notwendiger Informationen und Vorgaben ei- Die Prozessdokumentation stellt die Leitlinien dar. 171

182 3 IT Prozess-Management nerseits und einem ausreichenden Gestaltungsspielraum für die Mitarbeiter andererseits. Service Management Plan (SMP) Prozess Management Plan (PMP) IT Service Management- Prozesse Wird sichergestellt durch Aktivitäten Kritische Erfolgsfaktoren Control Objectives Abbildung 62: Prozess-Management Prozessdesign Hier sollte nicht der Anspruch bestehen, dass der erste Entwurf alle Eventualitäten abdeckt und fehlerfrei ist. Erfahrungsgemäß ergibt sich im täglichen Betrieb ein Optimierungsbedarf. Diese Einstellung und Erwartungshaltung sollte auch gegenüber den Mitarbeitern kommuniziert werden. Die Mitarbeiter sollten aufgerufen werden, den notwendigen Verbesserungsbedarf zu identifizieren und an den Prozess-Manager weiterzugeben. Es darf nicht an fehlerhaften Abläufen festgehalten werden. Allerdings sind notwendige Abweichungen in die richtigen Bahnen zu lenken, und Änderungen müssen Einzug in die Prozessdokumentation finden. Zeitgleich mit dem Prozessdesign und vor der Implementierung sind die Kriterien festzulegen, die die Überprüfung des Prozesses sicherstellen. Zunächst geht es darum, zu überprüfen, ob die definierten Prozessziele erreicht werden. Das heißt, es wird die Effektivität des Prozesses überprüft. Darüber hinaus gilt es im Rahmen der Prozessdurchführung festzustellen, ob und wie die definierten Prozessaktivitäten durchgeführt werden und ob die Control Objectives und die kritischen Erfolgsfaktoren sichergestellt werden. Diese Überprüfungen können mit Kennzahlen und den zugehörigen Sollwerten, Reviews und Audits durchgeführt werden. Dabei gehen die Ergebnisse aus den durchgeführten Reviews und Audits wiederum in Kennzahlen ein (siehe Abbildung 63). 172

183 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 Abbildung 63: Prozess-Management Überprüfung Mit diesen Überprüfungen wird die Wirksamkeit des Prozesses, betrachtet in den Dimensionen Effektivität und Effizienz, sichergestellt. Die Kennzahlen stehen in einem unmittelbaren Bezug zu den Prozesszielen. Die Kennzahlen und die damit verbundenen Sollwerte werden aus den Prozesszielen abgeleitet. Bei der Ausgestaltung (Prozessdesign) der Prozesse und der Definition der Kennzahlen (KGI, KPI), sowie bei den durchzuführenden Audits und Reviews unterstützen die Best Practices von COBIT und ITIL (siehe Abbildung 64). Diesen Publikationen können entsprechende praxiserprobte Empfehlungen entnommen werden. Unter Umständen können aber zu den definierten Prozesszielen keine entsprechenden Kennzahlen aus COBIT und ITIL entnommen werden. In diesem Falle müssen die entsprechenden Kennzahlen und deren Zielwerte im Rahmen des Prozessdesigns definiert werden. 173

184 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 COBIT ITIL Abbildung 64: Prozess-Management Nutzung von COBIT und ITIL COBIT und ITIL enthalten dokumentierte Best Practices für Kennzahlen. Es ist aber ein Irrglaube, diese Kennzahlen einfach übernehmen zu können. Vielmehr sind zunächst die Prozessziele zu definieren. Aus den Prozesszielen werden Kennzahlen und Sollwerte abgeleitet. Dabei können die Best Practices entsprechend unterstützen und herangezogen werden. Sind die Kennzahlen und Zielwerte definiert, so empfiehlt es sich, als Qualitätscheck zu prüfen, ob von der Kennzahl eine unmittelbare oder mittelbare Verbindung zu einem Geschäftsziel besteht. Möchte die IT-Organisation die Konformität mit der ISO 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 65). 174

185 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 Konformität COBIT ITIL ISO Abbildung 65: Prozess-Management Konformität 175

186 3 IT Prozess-Management Die Kennzahlen und deren laufende Überprüfung stellen die Basis für die gegebenenfalls notwendigen Verbesserungen der Prozesse dar. Ohne ausreichende Messung kann letztendlich keine zielgerichtete Verbesserung erreicht werden. Die Ergebnisse dieser Verbesserungsphase finden Einzug in dem Prozess Improvement-Plan PIP (siehe Abbildung 66). Service Management Plan (SMP) Prozess 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 66: Prozess-Management Prozess Improvement-Plan 176

187 3.4 Definition der Prozessziele und -Kennzahlen Der hier beschriebene Managementansatz entspricht der Methode, die in der ITIL Version 3 empfohlen wird und in Continual Service Improvement [OGC, 2007e] beschrieben ist. Aus der übergeordneten Vision werden die Ziele definiert und mittels Kennzahlen gemessen. Dies stellt die nachfolgende Abbildung 67 aus [OGC, 2007e] dar. Vision Mission Ziele Objectives CSFs KPIs Metriken Messungen Abbildung 67: Entwicklung von Kennzahlen 177

188 3 IT Prozess-Management Dokumentation der Prozess-Kennzahlen Für die Dokumentation empfiehlt es sich, die Kennzahl mit der entsprechenden Definition, der Messmethode und anderen relevanten Informationen zu dokumentieren. Dazu bietet sich die Dokumentation in Form eines Kennzahlen-Steckbriefes an. Bestandteil des Steckbriefs 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 Nutzens und ihrer Verwendung überprüft wird Anmerkungen Zusatzinformationen Bei Bedarf können weitere Informationen wie zum Beispiel Empfänger der Kennzahl, Risiken, etc. aufgenommen werden. Im Rahmen der Prozessdokumentation ist zu prüfen, wie der Kennzahlen- Steckbrief zu dokumentieren ist. Es empfiehlt sich, die Beschreibung der Kennzahlen in den Service Management-Plan (SMP) aufzunehmen. 178

189 3.4 Definition der Prozessziele und -Kennzahlen Reporting der Prozess-Kennzahlen An der Zieldefinition und der Ausrichtung der IT Service Management- Prozesse sind verschiedene Management-Ebenen beteiligt. In einem top down-ansatz erstreckt sich dieser Prozess vom Top-Management bis zum Prozess-Manager. So unterschiedlich die beteiligten Managementebenen sind, so 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. Kennzahlen müssen ebenengerecht sein. Die Kennzahlen müssen ebenengerecht aufbereitet und präsentiert werden. Diese Anforderung des ebenengerechten Reportings lässt sich für die Rollen des Prozess-Managers und zum Teil des Process Owners leicht umsetzen. Die für diese Rollen benötigten Kennzahlen sind die, die im Rahmen des Prozessdesigns zur Überprüfung des Prozesses definiert wurden. Die Kennzahlen hierzu sind als KPIs bzw. KGIs in COBIT und ITIL dokumentiert. Anders verhält es sich, wenn eine Gesamtbewertung knapp und präzise erfolgen muss. Dies ist beispielsweise immer der Fall, wenn der Service Manager eine Übersicht benötigt bzw. an das Top (IT-) Management berichtet. Nehmen wir an, die Fragestellung würde lauten: Hat der Prozess Change Management seine Zielsetzung erfüllt? Dann müssen die Prozess- Kennzahlen zu einer Kennzahl zusammengefasst werden. Hierfür sind die einzelnen Kennzahlen zu gewichten und zu aggregieren. So ist es für die Beurteilung seitens des Service Managers zunächst wichtig, zu erkennen, ob alle Services und alle Prozesse die Zielsetzung erfüllen d.h. ob sie im grünen Bereich sind. Am Beispiel des Change Managements könnte sich eine zusammengesetzte Kennzahl zum Prozess durch die Gewichtung der einzelnen Ziele und der damit verbundenen Kennzahlen wie folgt ergeben (siehe Abbildung 68): 179

190 3 IT Prozess-Management 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% Effizienz Change Management 60% 30% Abbildung 68: Zusammengesetzte Prozess-Kennzahlen Es ist zu empfehlen, Gesamtzusammenhänge beispielsweise in Form einer Ampel darzustellen. Dabei ist es in den meisten Fällen so, dass in die Ampelbewertung auch qualitative Dinge einfließen. So könnte sich zum Beispiel eine Gesamtübersicht der Zielerreichung aller SLAs wie folgt darstellen (siehe Abbildung 69): Abbildung 69: Darstellung der SLAs mit dem Q-Board von Q to be 180

191 3.4 Definition der Prozessziele und -Kennzahlen Die operativen Systeme, wie zum Beispiel die Tool-Unterstützung für das Change Management, liefern die notwendigen Basis-Informationen, aus denen durch entsprechende Datenselektionen und Aggregation die Prozess-Kennzahlen gewonnen werden können. Durch weitere Aggregationen erhalten dann der Service Manager und das Mittlere sowie das Top Management die notwendigen Informationen. Dabei sind aber nicht nur Kennzahlen zu den IT Service Management- Prozessen zu kreieren, sondern auch die erfolgreiche Umsetzung der im Service Management-Plan (SMP) und Service Improvement-Plan (SIP) festgelegten Verbesserungsmaßnahmen zu belegen (siehe Abbildung 70). 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 70: Das IT Service Management Kennzahlensystem Generell empfiehlt es sich, auf allen Hierarchieebenen für das Reporting auf grafische Elemente zurückzugreifen und Kennzahlen in den Ampelfarben darzustellen, nach dem Motto Ein Bild sagt mehr als tausend Worte. Hierzu wird der dargestellte Wert in Abhängigkeit der Sollwerte entsprechend farbig dargestellt oder grafisch animiert. Dazu können zum Beispiel Ampelsymbole oder Tachoscheiben herangezogen werden. 181

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

193 3.4 Definition der Prozessziele und -Kennzahlen 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 72: Exemplarischer Prozess-Bericht Darstellung der Kennzahlen 183

194 3 IT Prozess-Management 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 73. Abbildung 73: Darstellung des Management Cockpits von iet Solutions 184

195 3.5 Von der Kennzahl zur Verbesserungsmaßnahme 3.5 Von der Kennzahl zur Verbesserungsmaßnahme Die definierten Kennzahlen mit ihren jeweiligen Zielwerten, beschrieben als KGI (Key Goal Indicator) oder KPI (Key Performance Indicator), sollen erkennbar machen, dass ein Zielwert bzw. Prozessziel nicht erreicht wird. In Verbindung mit Trenddaten soll aufgezeigt werden, dass die Erreichung eines Prozesszieles gefährdet ist. Dabei kann der Indikator lediglich etwas aufzeigen. Die eigentliche Ursache ist vom Prozess-Manager festzustellen. So kann dem Prozess-Manager zum Beispiel aufgezeigt werden, dass sich die Erstlösungsquote im Incident Management verschlechtert (siehe Abbildung 74). Abbildung 74: Beispiel für eine Trenddarstellung Der Prozess-Manager hat durch detaillierte Auswertung festzustellen, warum sich die Erstlösungsquote verschlechtert. Hierzu muss der 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, 185

196 3 IT Prozess-Management könnte die Betrachtung der Erstlösungsquote in Abhängigkeit von dem durch die aufgetretene Störung betroffenen IT Service sein hilfreich sein (siehe Abbildung 75). Abbildung 75: Beispiel 1 für eine Analyse möglicher Ursachen Hierzu wird die vorherige Auswertung der Erstlösungsquote in Abhängigkeit vom betroffenen Service ausgewertet. In diesem Beispiel zeigt die Auswertung eine schlechter werdende Erstlösungsquote für die Services und Kfz-Dialog. 186

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

198 3 IT Prozess-Management 3.6 Kennzahlen müssen reifen So wie die IT Service Management-Prozesse sich entwickeln und reifen müssen, so müssen auch die Kennzahlen reifen. Werden noch keine Prozesse gemessen, so empfiehlt es sich zunächst, die wichtigsten Prozessziele mit Kennzahlen zu hinterlegen. Mit diesen Kennzahlen kann das Managementsystem aufgebaut werden, und es können erste Erfahrungen gesammelt werden. Liegen noch keine gesicherten Informationen zu einem Prozess vor, so muss sich der Prozess-Manager zunächst einen Eindruck über das zu bewältigende Volumen im Prozess verschaffen. Welche Inputs hat der Prozess zu bewältigen? Zum Beispiel: Wie viele Incidents sind zu bearbeiten oder wie viele Changes sind auszuführen? Werden diese Vorgänge für das Incident, Problem und Change Management in Kategorien und Prioritäten unterteilt, so liegen bereits erste wichtige Informationen vor. Die Informationen zum Umfang des Inputs sind auch für die späteren Auswertungen als Referenzgröße von großer Bedeutung. Mögliche Veränderungen in den ermittelten Kennzahlen lassen sich häufig auf einen veränderten Input zurückführen. Zunächst gilt es, das Volumen des Inputs (Durchsatz) zu messen. Die Größe ist auch für vergleichende Betrachtungen von großer Bedeutung. Eine weitere wichtige Betrachtung für den Prozess-Manager ist die zeitliche Entwicklung. Trendinformationen können frühzeitig Handlungsbedarf aufzeigen und ermöglichen es, Maßnahmen zu ergreifen, bevor die Sollwerte unter- bzw. überschritten werden. Damit Trends dargestellt werden können, ist eine Stabilität im Kennzahlensystem notwendig. Sobald Kennzahlen vorliegen, sollten Änderungen der Berechnungsmethoden sorgsam geprüft werden. Die Berechnungsgrundlagen der Kennzahlen sollten nur nach sorgsamer Prüfung verändert werden. Ansonsten können keine verlässlichen Trends ausgewertet werden. Die Prozesse sind hinsichtlich ihrer Zielerreichung (Key Goal Indicator = Effektivität) und ihrer Leistungsfähigkeit (Key Performance Indicator = Effizienz) zu messen. Dabei steht die Zielerreichung, die Betrachtung des Outputs, im Vordergrund. Demzufolge gilt es, sich zunächst auf die Einführung dieser Kennzahlen zu konzentrieren. 188

199 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 Kennzahlen liegen. 3.7 Der Umgang mit Kennzahlen 3.7 Der Umgang mit Kennzahlen Die Kennzahlen dienen primär als Management-Werkzeug für den Prozess-Manager und den Process Owner. Diese können anhand der Kennzahlen erkennen, ob die Prozessziele erreicht werden und ob der Prozess wirkungsvoll durchgeführt wird. Darüber hinaus unterstützen die Kennzahlen den Prozess-Manager bei der Identifizierung eines möglichen Verbesserungspotenzials, bei der Darstellung komplexer Sachverhalte und bei der Begründung möglicher Veränderungsmaßnahmen. Durch die Definition einer Kennzahl stellt das Prozess-Management die Bedeutung der damit verbundenen Aktivitäten heraus. Die Organisation wird demzufolge ihr Handeln auf die Erreichung des festgelegten Sollwerts für die Kennzahl ausrichten. Dieses Ziel wird jedoch auch dann angestrebt werden, wenn sich dies für das Unternehmen nachteilig auswirken sollte! Wird beispielsweise für den Service Desk eine maximale Bearbeitungszeit von 5 Minuten pro Telefonat als Zielwert vorgegeben, so werden die Mitarbeiter sich an dieser Kennzahl orientieren. Die Telefonate werden innerhalb dieser Zeit abgeschlossen, auch wenn eine mögliche Störung innerhalb der nächsten 30 Sekunden gelöst werden könnte. Das Verhalten der Mitarbeiter wird sich an den festgelegten Kennzahlen orientieren. Der Prozess-Manager muss sich dieses Verhaltens bewusst sein. Eine Möglichkeit, dem zu begegnen, besteht darin, mit einer anderen Kennzahl negativen Auswirkungen entgegen zu wirken. Viel wichtiger ist es aber, den Nutzen der Kennzahlen in der Organisation herauszustellen. Die Kennzahlen dürfen nicht als Bedrohung, sondern müssen als Chance verstanden werden. Werden dem Top-Management einzelne Kennzahlen berichtet, so muss das Top-Management auch die Prozessziele der damit verbundenen IT Service Management-Prozesse kennen und verstehen. Ansonsten besteht 189

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

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

202 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 15 oder CAPIs 16. Aber mit welcher Fragestellung lässt sich die Anwenderzufriedenheit ermitteln? 15 Diese werden auch User Quality Surveys genannt. 16 CAPI steht für Computer Assisted Personal Interview. 192

203 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-Zielen gar nicht bekannt. Auch wenn der IT Service Provider diese Anforderungen vollständig erfüllt, kann es so vorkommen, dass die Anwenderzufriedenheit nicht gegeben ist. Der Versuch, die Anwenderzufriedenheit indirekt zu messen, ist ebenfalls nicht einfach. Legt man beispielsweise die Anzahl der Kontaktaufnahmen mit dem Service Desk zugrunde, so gibt es mindestens zwei Interpretationsmöglichkeiten. Ein Service Desk, der wenig kontaktiert wird, kann eine hohe Anwenderzufriedenheit im Sinne Alles läuft reibungslos bedeuten, aber auch, dass die Anwender es aufgegeben haben, sich an die IT zu wenden, beispielsweise wegen Inkompetenz oder Arroganz des 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 193

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

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

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

207 4.3 Überblick Diebold 1984 Herkunft Diebold Deutschland GmbH Quelle Idee Struktur Beispiele Fazit 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,...) 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) Diebold stellt ein abstraktes Kennzahlensystem dar, das für eine praktische Nutzung stark konkretisiert und angepasst werden muss. Es stellt sich auch die Frage, wie sich (durchaus wichtige) Aspekte wie Innovationsverhalten und Zukunftsorientierung praktisch und objektiv messen lassen. Die hierarchische Struktur bietet Vorteile dadurch, dass eine an den jeweiligen Adressaten angepasste Informationstiefe erreicht werden kann. Zu klären ist dabei allerdings, auf welche Art und Weise die Kennzahlen einer Gruppe zur jeweils höheren Hierarchiestufe zusammengerechnet werden können. 197

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

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

210 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 18, dienen abstrakte Klassifizierungssysteme wie Diebold 1984 eher als Basis für das Zusammenstellen und Strukturieren eines eigenen Systems. Stellt man sich die spannende Frage Welches IT-Kennzahlensystem soll man so, wie es ist, in der Praxis einsetzen?, so lautet die enttäuschende Antwort: Keines 19. In der Praxis zeigt sich: Der Überdeckungsgrad der Kennzahlensysteme ist eher gering, d.h. jedes Kennzahlensystem liefert neue Aspekte. Die Anforderung, dass Prozessmodelle des IT Service Managements zu berücksichtigen sind, liefert nicht weniger, sondern mehr Kennzahlen. Kein Kennzahlensystem ist ohne Modifikation in der Praxis einsetzbar: Zu viele Kennzahlen werden genannt. 18 Dies gilt im Übrigen auch für COBIT (vgl. Kapitel 3.3). 19 Vielleicht etwas hoffnungsvoller, versöhnlicher (und diplomatischer): Keines ohne Modifikation. 200

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

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

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

214 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 den IT-Kunden darzustellen. Vielen Unternehmen bereitet diese Sicht Schwierigkeiten und daher implementieren sie nur unzureichende Möglichkeiten zur Kommunikation. Dies ist schade, denn dadurch verpufft einerseits viel Innovationskraft und andererseits bauen sich leicht Konfliktsituationen auf, die für das Unternehmen und die IT schädlich sein können. Sehr zu empfehlen ist ein Management Report zur Lage der IT im Unternehmen. Wir haben diese Art des Reportings in vielen Unternehmen verschiedener Größen und Branchen erfolgreich eingeführt. In den meisten Fällen wird dieser Report mit Interesse von der Geschäftsführung entgegengenommen. 205

215 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. 20 Aus dem Management Report müssen die Ziele für das nächste Jahr abgeleitet werden. Insgesamt muss der Business Value der IT erkennbar sein. In unseren Projekten verwenden wir als Instrument zum Reporting an das Top Management in den meisten Fällen die Balanced Scorecard. Sie ist nicht nur für Management Meetings hervorragend geeignet, sondern auch zum Aufbau von Management Reports. Die Frage, die sich hier stellt ist, welche Zahlen und Ergebnisse interessieren das Top Management? Dies sind sicherlich nicht die technischen Details der IT, die man ja reichlich reporten könnte. Es geht im Grunde darum, mit Fakten aufzuzeigen, wie erfolgreich die IT ist. Diese Kennzahlen nennen wir Key Success-Faktoren (KSF). Sie setzen sich im Allgemeinen aus anderen Kennzahlen zusammen und sind damit selbst mehrdimensional. Es bietet sich an, die Dimensionen einer Balanced Scorecard als Key Success-Faktoren zu nehmen (vgl. Abbildung 78). Die Kennzahlen können Key Performance-Indikatoren 21 oder Customer Satisfaction Indices aus der Ebene des IT-Managements sein, die durch Aggregation entstehen. Im Folgenden geben wir einen Ausschnitt aus einem solchen Kennzahlensystem an: 20 ROI im Sinne Return on IT. 21 KPIs im Sinne einer betriebswirtschaftlichen Begriffsbestimmung (vgl. den Exkurs zum Begriff KPI in Kapitel ) 206

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

217 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 79: Key Success-Faktoren zur Gruppierung von KPIs und CSIs Hilfreich ist es auch, für Kennzahlen Benchmarks anzugeben, falls diese verfügbar sind. Dies ist in einigen Branchen der Fall. Oft gibt es auch allgemeine Benchmarks, die dem Management zeigen, ob die eigene IT noch im grünen Bereich liegt. Ein Beispiel ist die Kennzahl IT-Kosten pro Umsatz, die zwischen 2 und 3 % liegen sollte. Dies ist aber von Branche zu Branche verschieden und sollte auf die aktuelle Situation des Unternehmens bezogen werden Key Performance und Customer Satisfaction Alle IT Service Management-Ansätze sehen IT-Organisationen als IT Service Provider, die Leistungen für ihre Kunden erbringen. Der Kunde ist in diesem Zusammenhang derjenige, der für Leistungen bezahlt. Kunden werden von Anwendern unterschieden, die lediglich die IT-Infrastruktur nutzen. 208

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

219 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Zwischen Leistungserwartung und Servicewahrnehmung kann es eine Lücke geben. Dies ist in der Praxis oft der Fall, wenn IT- Marketingaspekte zu kurz kommen. Zwischen Leistungserwartung des Kunden und der durch den Provider wahrgenommenen Kundenerwartung kann ebenfalls eine Lücke klaffen. Das ist in der Praxis der Fall, wenn das Service Level Management keine Engagement -Funktion hinsichtlich der Kunden wahrnimmt. Sind die Leistungsspezifikationen schwach ausgeprägt, so ist dies ebenfalls ein Nährboden für Wahrnehmungsstörungen. Wir haben diesen Fall in der Praxis oft gesehen, wenn SLAs nicht hinreichend genau formuliert waren und zu große Interpretationsspielräume zuließen. In [OGC, 2007e] werden 16 Lücken (Gaps) identifiziert, die sich im Service Lifecycle in allen möglichen Phasen Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement wiederfinden. Das Service Management hat dafür Sorge zu tragen, dass diese Lücken geschlossen werden, und muss gegebenenfalls ein entsprechendes Service Improvement-Program (SIP) initiieren. Die Abbildung 81 ist angelehnt an Continual Service Improvement [OGC, 2007e] und stellt diese Gaps dar. Interessant ist, dass sie beim Kunden, beim Provider und auch zwischen Kunde und Provider auftreten können. Gap 5 beschreibt beispielsweise ein Kommunikationsproblem bzw. eine falsche Erwartungshaltung, die auf Seiten des Kunden besteht. Für IT-Kennzahlensysteme bedeutet dies, dass CSIs auf der Ebene des 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 dasteht. Andere Quellen sind natürlich das Service Level Management, aber auch der Service Desk sowie das Projekt Management. 210

220 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 81: Gaps nach OGC (aus [OGC, 2007e]) Exkurs: Zum Begriff Key Performance Indicator (KPI) Es sei an dieser Stelle angemerkt, dass der Begriff Key Performance Indicator (KPI) in vielen Zusammenhängen verwendet wird. Betriebswirtschaft / Management (vgl. [Wikipedia, 2007]): Key Performance Indicators (KPI) are financial and non-financial metrics used to quantify objectives to reflect strategic performance of an organization. KPIs are used in Business Intelligence to assess the present state of the business and to prescribe a course of action. KPIs are typically tied to an organization's strategy (as exemplified through techniques such as the Balanced Scorecard). The KPIs differ depending on the nature of the organization and the organization's strategy. COBIT (vgl. [COBIT, 2005]): Hier werden die wesentlichen Leistungsindikatoren als Key Goal Indicators (Effektivität) bezeichnet, während KPIs lediglich die Effizienz beschreiben. 211

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

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

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

224 5.3 Prozess-Kennzahlen Wie bereits im Kapitel Prozess-Management ausgeführt, stehen die Ziele Ihrer IT-Prozesse im Vordergrund. Daher sind auch die hier aufgeführten Prozesse hinsichtlich deren Relevanz kritisch zu prüfen. Damit die aufgeführten Kennzahlen die notwendigen Informationen liefern können, müssen sie jeweils als Trend, in Bezug zum Sollwert und in Relation zu anderen Kennzahlen dargestellt werden. So ist zum Beispiel die Information einer schlechter werdenden Erstlösungsquote erst dann hilfreich, wenn gleichzeitig die Anzahl der eingehenden Störungsmeldungen dargestellt wird. Kennzahlen sind als Trend und Relation darzustellen. Durch die Darstellung von Trends für die im Anschluss beschriebenen Kennzahlen steigt der Informationsgehalt. Bei der Trenddarstellung sind die Sollwerte als Bezugslinien auszuweisen. Die Kennzahlen sind nach dem Motto Keep It Simple, Stupid (KISS) oder In der Kürze liegt die Würze zu definieren. Einerseits sollten die Kennzahlen möglichst einfach verständlich sein. Andererseits gilt es, auch den Aufwand zu betrachten, der zur Generierung einer Kennzahl notwendig ist. Hier muss jeweils der Aufwand zur Generierung mit der Steuerungsrelevanz der Kennzahl und des möglichen Verbesserungspotenzials bewertet werden. Um Zusatzaufwendungen zu vermeiden, sollten die Kennzahlen möglichst ohne zusätzlichen Erfassungsaufwand aus den operativen IT-Systemen gewonnen werden. Speziell die Kennzahlen für die Prozesse Incident Management, Request Fulfilment, Problem Management, Access Management, Service Asset and Configuration Management, Change Management und Release and Deployment Management generieren sich weitestgehend aus dem eingesetzten IT Service Management-Tool. Kennzahlen werden zum Teil durch die Verknüpfungen von Daten aus verschiedenen Prozessen gewonnen. Dies erfordert eine hohe Integrität der zugrunde liegenden Datenbasis über verschiedene Prozesse hinweg. 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. 215

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

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

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

228 Service Portfolio Management Dieser Prozess ist für das Management des Serviceportfolios verantwortlich. Er berücksichtigt die Services in Bezug auf den für das Business gelieferten Wert. 5.3 Prozess-Kennzahlen 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 Serviceportfolios Name der Kennzahl Definition Relevanz Messwert Anteil gelieferter Services Anteil der im Serviceportfolio definierten Services, die von Kunden genutzt werden. Diese Kennzahl zeigt die Nachfrage der angebotenen Services auf. Auswertung der Services im Servicekatalog und im Serviceportfolio. 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 Serviceportfolios. Name der Kennzahl Definition Relevanz Messwert Anteil Veränderungen im Serviceportfolio Anteil der im Serviceportfolio vorgenommenen Veränderungen an den enthaltenen Services. Die Kennzahl ist ein Kennzeichen für die Dynamik der geplanten und angebotenen Services. Auswertung des Serviceportfolios. 219

229 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl Definition Relevanz Messwert Bemerkung Status der Services im Serviceportfolio Status der Services im Serviceportfolio Die Kennzahl zeigt den Anteil der produktiven Services in Relation zu den in Entwicklung/ Überführung sowie den in Aussonderung befindlichen Services. Auswertung des Serviceportfolios und Gruppierung anhand des Status. Die Services können den folgenden Status annehmen Servicekatalog, Servicepipeline (Service noch nicht produktiv) und Retired Services Demand Management Das Demand Management hat die Kundenanforderungen an die IT Services aufzunehmen und zu beeinflussen, so dass die notwendigen Kapazitäten bereitgestellt werden können, die diesen Forderungen entsprechen. Name der Kennzahl 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 220

230 5.3 Prozess-Kennzahlen Messwert beschaffen. Häufig auftretende Anpassungen 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 Servicekatalog Anzahl und Anteil der im Betrieb befindlichen Services, die im Servicekatalog beschrieben sind. Der Servicekatalog soll alle im Betrieb befindlichen Services enthalten. Diese Kennzahl zeigt die Qualität und Aktualität des Servicekatalogs auf. Vergleich der SLAs mit dem Servicekatalog. 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 Servicekatalog Anteil der inhaltlichen Abweichungen der im Betrieb befindlichen Services gegenüber den Spezifikationen im Servicekatalog. Der Servicekatalog dient auch der Standardisierung von Services. Weichen die tatsächlichen Services von den Beschreibungen im Servicekatalog ab, so wird diese Standardisierung nicht erreicht. Vergleich der SLAs mit dem Servicekatalog. Bei der Messung wird vorausgesetzt, dass für 221

231 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen alle im Betrieb befindlichen Services SLAs existieren Service Level Management Der Prozess Service Level Management (SLM) ist für das Verhandeln von Service Level Agreements verantwortlich und hat sicherzustellen, dass diese SLAs eingehalten werden. Das SLM hat sicherzustellen, dass alle IT Service Management-Prozesse, Operational Level Agreements (OLAs) and Underpinning Contracts (UCs) den vereinbarten Service Level-Zielen entsprechen. Das SLM führt hierzu ein Monitoring und Reporting der Service Level sowie regelmäßige Reviews mit den Kunden durch. Name der Kennzahl 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 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. 222

232 5.3 Prozess-Kennzahlen Bemerkung Hierzu muss definiert werden, wann ein SLA als eingehalten zählt. Zum Beispiel, wenn alle einzelnen Service Level eines SLAs eingehalten werden. Name der Kennzahl 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 Anteil SLA Verletzungen durch UCs Anteil der SLA-Verletzungen, die aufgrund nicht eingehaltener UCs bzw. Contracts entstanden sind. Können SLAs nicht eingehalten werden, weil der Lieferant seine Zusagen nicht einhält, so 223

233 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Messwert müssen entsprechende Folgeaktivitäten eingeleitet werden. Hier sollte auf ein professionelles SLM-Tool zurückgegriffen werden, mit dessen Hilfe die einzelnen SLAs und UCs gemessen und die Ergebnisse berichtet werden können. Name der Kennzahl 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 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. 224

234 5.3 Prozess-Kennzahlen Messwert Bemerkung Auswertung der offenen Maßnahmen im SIP. Die Maßnahmen sollten im Plan mit einem Status versehen werden. Dadurch können offene Maßnahmen, in der Umsetzung befindliche oder bereits umgesetzte Maßnahmen dargestellt werden 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 Lastspitzen und Gesamtauslastungsrate Darstellung der Lastspitzen und Gesamtauslastung pro SLA. Zielsetzung des Capacity Managements ist die Einhaltung der Service Level-Ziele, aber auch der Wirtschaftlichkeit. Daher sollte sich die Auslastung in Abhängigkeit der IT-Strategie dem Soll-Wert annähern. Lastspitzen können ggf. Zusatzbedarf oder die Notwendigkeit von Verlagerungen aufzeigen 225

235 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Messwert Die Auslastungen werden in der Regel aus dem System-Management oder zum Beispiel mit Robotern (Antwortzeiten) ermittelt. Name der Kennzahl 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 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. 226

236 5.3 Prozess-Kennzahlen Messwert Die Anzahl ist dem System Management zu entnehmen, ggf. auch dem Configuration Management. Die Anzahl der zentralen Systeme kann dem Configuration Management System entnommen werden. Name der Kennzahl 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. 227

237 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Messwert Vergleich über mehrere Tage, Wochen, Monate der Anzahl der eingehenden zu den ausgehenden Mails 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. 228

238 5.3 Prozess-Kennzahlen Name der Kennzahl Definition Relevanz Messwert 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äftszeiten 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 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 ver- 229

239 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Bemerkung bundenen 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 Abkürzung für Mean Time to Restore verwendet. Es ist daher stets zu prüfen, ob die Zeitspanne die Recovery-Zeit einschließt. Eine Drill-Down-Funktion sollte eine detaillierte Analyse der einzelnen Zeitstrecke ermöglichen. Name der Kennzahl 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. 230

240 IT Service Continuity Management Der Prozess IT Service Continuity Management (ITSCM) ist verantwortlich für das Management der Risiken, die schwere Auswirkungen auf den IT Service haben. Das ITSCM reduziert Risiken auf eine akzeptable Ebene und plant des Recovery von IT Services. Dadurch stellt es sicher, dass der IT Service Provider immer die minimal vereinbarten Service Level-Ziele einhalten kann. Das ITSCM sollte zur Unterstützung des Business Continuity Managements entworfen werden. 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 Anzahl und Anteil erfolgreicher ITSCM-Tests Anzahl und Anteil der erfolgreich durchgeführten ITSCM-Tests. Es muss sichergestellt werden, dass die ITSCM- 231

241 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Messwert Bemerkung Pläne im Notfall auch funktionieren. Daher sind sie regelmäßig zu testen. Auswertung der durchgeführten Testprotokolle. 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 ge- 232

242 genüber dem IT Service Provider hat und die Handhabung von Schriftstücken, Gebäudezugängen, Telefonanrufe usw. für die gesamte Organisation beinhaltet. 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öglicher Bedrohungen und deren präventive Reduktion. Diese Kennzahl zeigt die Qualität der Prävention auf und ist Indikator für mögliche Verbesserungen. 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 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. 233

243 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Messwert Bemerkung Auswertung durchgeführter Audits und Revisionen. Festgestellte Verletzungen von Compliance- Anforderungen sind besonders herauszustellen. 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.. 234

244 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. 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 sind. 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 unter- 235

245 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen schieden werden, wie zum Beispiel bemängelte Rechnungen oder Verletzungen von Compliance-Anforderungen. Name der Kennzahl Definition Relevanz Messwert Anzahl der Reviews mit Lieferanten Anzahl der mit Lieferanten zum Service und 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 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. 236

246 5.3 Prozess-Kennzahlen Bemerkung Es kann auch der Lieferant zur Zufriedenheit befragt werden 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. 237

247 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl Definition Relevanz Messwert Bemerkung Kundenzufriedenheit Service Transition-Pläne Ergebnis der Kundenzufriedenheit bezüglich der Service Transition-Pläne. 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. 238

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

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

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

251 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Bemerkung Existieren hierfür keine Datenfelder, so können zur Generierung auch die Ergebnisse aus dem Review herangezogen werden. Name der Kennzahl 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, so dass der Prozess umgangen wird. Insbesondere für Unternehmen, die Compliance-Anforderungen wie SOX erfüllen müssen, ist diese Kennzahl von besonderer Bedeutung. Es werden die Ergebnisse des Verification and Audit im Prozess Service Asset und Configuration Management ausgewertet. Name der Kennzahl Definition Relevanz Anteil zurückgewiesener RfCs Die Kennzahl zeigt an, wie viele der eingereichten RfCs vom Change Management zurückgewiesen wurden. RfCs können zurückgewiesen werden, wenn sie 242

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

253 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Messwert Bemerkung 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.). Name der Kennzahl Definition Auswirkungen fehlerhafter CIs Anzahl der fehlerhaften Changes, deren Ursa- 244

254 5.3 Prozess-Kennzahlen Relevanz Messwert Bemerkung chen 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. 245

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

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

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

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

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

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

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

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

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

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

265 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen SLAs, OLAs oder UCs vereinbart werden. Dann ist die Lösungszeit in Bezug auf den jeweiligen IT Service zu berechnen. Entscheidend für die Lösung ist, dass der Anwender wieder arbeiten kann. Es ist mit dem Kunden festzulegen, wann ein Incident als abgeschlossen gewertet werden kann. Name der Kennzahl Anteil Remote-Lösungen Definition Anteil der bearbeiteten Störungen, die Remote das heißt ohne Vor-Ort-Service gelöst werden konnten. Relevanz Der Vor-Ort-Service ist gegenüber einer Remote Lösung mit mehr Aufwand (Arbeitszeit und Kosten) verbunden. Hinzu kommt, dass die Lösungszeiten dadurch höher sind. Diese Kennzahl ist ein Indikator für die Effizienz des Prozesses. Messwert Ausgewertet wird der Anteil der Incidents, bei denen keine Vor-Ort Support-Einheit in die Behebung eingebunden waren. Name der Kennzahl 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- 256

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

267 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 Messwert 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. Dem Service Request muss ein Workflow mit 258

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

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

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

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

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

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

274 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 messen wollen werden durchzuführende Aktivitäten bis zur Implementierung korrigierende Aktionen beschrieben. 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 Service Reporting Der Prozess ist für die Erstellung und Lieferung von Berichten über Leistung und Trends gegenüber den Service Level verantwortlich. Das Service Reporting sollte das Format, den Inhalt und die Häufigkeit von Berichten mit den Kunden vereinbaren. 265

275 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen 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 Service Measurement Aufgabe des Service Measurement ist die Messung der IT Services. Hierzu betont ITIL, dass es nicht mehr genügt, die Leistung einer einzelnen Komponente, wie eines Servers oder einer Applikation zu messen und zu berichten. Die IT muss in der Lage sein, end-to-end -Services zu messen und zu berichten. Hierzu gibt es mit der Verfügbarkeit, Zuverlässigkeit und Performance drei Grundmessungen, von denen die meisten Organisationen Gebrauch machen. 266

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

277 5 IT Praxisleitfaden für die Entwicklung von Kennzahlensystemen Name der Kennzahl Definition Relevanz Messwert Mehrwert Business Mehrwert der durchgefü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 Abschnitt (Prozess Service Level Management innerhalb von Service Design) beschrieben. Speziell die Service Improvement-Programme (SIP) und die damit verbundenen Kennzahlen betreffen die Maßnahmen innerhalb des Continual Service Improvements. 268

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

279 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 d.h. allein die Maßnahmen durchführt. Die wesentliche Aufgabe des Beraters besteht vielmehr darin, Sie zu begleiten. Sie benötigen einen Coach, der den Wissenstransfer sicherstellt. Fungiert Ihr Berater nicht als Coach, so kann sowohl die Implementierungsanalyse, als auch die spätere Erweiterung und/oder Umsetzung schwierig werden. Ohne Akzeptanz des Beraters als Coach in Ihrer Organisation verlieren Sie Zeit und nutzen Ressourcen nicht optimal. Die Motivation zur Etablierung der Prozesse wird sinken. Auf der Basis von ITIL sollten Sie analysieren und vergleichen, welche der dort beschriebenen IT Service Management-Prozesse und Aktivitäten bereits (zumindest vermeintlich) in Ihrer IT-Organisation etabliert sind. Dabei ist zunächst eine generische Betrachtung der Prozesse ausreichend. Als Hilfestellung hierbei bietet sich eine tabellarische Darstellung an: Tragen Sie als Zeilen (-überschriften) die IT Service Management-Prozesse ein, wie zum Beispiel Incident Management, Change Management, Service Level Management. Auf der vertikalen Achse erfolgt eine Einstufung der bestehenden Situation hinsichtlich Konzeption, Prozesse, Verfahren, Methoden und Nutzungsgrad. Diese ITIL-Prozesslandkarte ist eine erste, einfache Darstellung des bestehenden Reifegrades, die Sie gemeinsam aus 270

280 Ihrer Einschätzung, aber auch mit Ihren Mitarbeitern und dem gewählten Berater befüllen, analysieren, vergleichen und bewerten können. Die ITIL-Prozesslandkarte soll aus den Prozessbedürfnissen der IT-Organisation im Bezug auf die Unternehmensstrategie entwickelt werden, ggf. unter Beteiligung eines Coaches. Dadurch lernen Sie und Ihre Mitarbeiter die ITIL Best Practices erheblich besser kennen. 6.2 ITIL-Einführung Für die Einstufung der Prozesse ist ausreichendes internes oder externes Prozesswissen von großer Wichtigkeit. Speziell im Bereich des Incident und Problem Managements bedarf es einer entsprechenden Erfahrung, um eine Abgrenzung der Prozessaktivitäten vornehmen zu können. Sie müssen bei der Ist-Aufnahme unterstreichen, dass die Zielsetzung in der neutralen Aufnahme der bestehenden Prozesse besteht. Nur so ist eine echte Standortbestimmung möglich. Bei der Ist-Aufnahme ggf. festgestellte Fehler sowie Abweichungen von bestehenden Richtlinien, festgelegten Abläufen oder Standards dürfen keine negativen Auswirkungen auf die betroffenen Personen haben. Sie benötigen eine objektive Feststellung der 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 ist die mangelnde Akzeptanz der geplanten Maßnahmen und die damit verbundene Verzögerung bei der Umsetzung. Initiierung der geplanten Maßnahmen 271

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

282 6.2 ITIL-Einführung Nutzen Sie die Kundenanforderungen, um die Notwendigkeit der geplanten Maßnahmen in Ihrer Organisation herauszustellen. Nach dem Motto: Wir implementieren IT Service Management, nicht weil es uns Spaß macht, sondern weil es ein im Markt anerkannter Standard für die optimale Zusammenarbeit zwischen IT und Kunde ist. Wir werden in Zukunft Ihre Businessprozesse noch optimaler unterstützen können. Eine besondere Rolle bei der geplanten Implementierung fällt Ihren Kunden bzw. dem Markt zu. Häufig verlangen Ihre Kunden in Angebotsaufforderungen oder bei Ausschreibungen, dass die anbietende IT-Organisation (IT Service Provider) ITIL-konforme Prozesse bzw. eine ISO (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. 273

283 6 Lessons learned: Empfehlungen und Ratschläge Informieren Sie Ihre Mitarbeiter frühzeitig über die geplanten Maßnahmen und die damit verfolgten Ziele. Motivieren Sie die Mitarbeiter und begegnen Sie den Ängsten Ihrer Mitarbeiter. Wertschätzung des Bestehenden Für eine erfolgreiche Etablierung der geplanten IT Service Management- Prozesse ist die Akzeptanz seitens Ihrer Mitarbeiter eine unabdingbare Voraussetzung. Bei der Analyse der ITIL-Prozesslandkarte werden Sie wahrscheinlich feststellen, dass die bestehenden Prozesse die Anforderungen der ITIL Best Practices nicht vollständig erfüllen. Beispiel: Es existiert bereits ein Change Management, aber dieses Change Management bietet gegenüber ITIL Verbesserungspotenzial. Trotzdem hat dieser Prozess bisher Erfolge gezeigt, und Ihre Mitarbeiter haben sich in diesem bestehenden Prozess engagiert. Sie sollten die bisher bestehenden Abläufe und Leistungen nicht gering schätzen, sondern als Basis für eine Verbesserung würdigen. Zeigen Sie Ihre Wertschätzung für die bestehenden Abläufe und für die damit erzielten Erfolge. Stellen Sie ITIL als Chance für eine Verbesserung dar. Nutzen Sie die bestehenden Prozesse und zeigen Sie die positiven Möglichkeiten der ITIL Best Practices auf, um diese Prozesse weiter zu verbessern. Ihre Mitarbeiter sollten ITIL als Angebot verstehen, auf das darin dokumentierte Wissen zurückzugreifen. Dafür muss ITIL als Chance gesehen werden, nicht als Damoklesschwert, das Bestehendes entwertet. Ihre Mitarbeiter und Manager sollen ITIL als Chance verstehen, aus den Best Practices zu lernen und sich weiterzuentwickeln. Ihr Ziel muss es sein, ein Verständnis von ITIL als Chance für eine ganzheitliche Betrachtung der IT in Ihrer Organisation zu verankern. Selbst erarbeiten statt fertig kaufen Prozess-Einführungen Sie müssen mit Widerständen bei der Implementierung der geplanten Prozesse rechnen. Sehr hilfreich ist es hier, wenn die IT Service Management-Prozesse aus Ihrer IT-Organisation heraus, von Ihren Mitarbeitern entwickelt werden. Ihre Mitarbeiter können dabei Ihre praktischen Erfahrungen einbringen und so sicherstellen, dass die geplanten Prozesse auf die Geschäftsprozesse Ihres Kunden ausgerichtet sind sowie den Anforderungen der IT-Organisation entsprechen. Ihre IT Service Management-Prozesse auf Basis von ITIL können Sie nicht extern einkaufen, sondern Sie müssen sie unbedingt selbst erarbeiten. 274

284 6.2 ITIL-Einführung Externe Berater können und sollten Ihnen hierbei helfen. Der Berater soll Ihre Mitarbeiter ansprechen können und als Coach tätig sein. Dazu muss der Berater nicht nur über die erforderlichen ITIL- (und ISO 20000) Kenntnisse verfügen, sondern auch Erfahrungen aus vergleichbaren Projekten und vergleichbaren Organisationen mitbringen. Nicht zuletzt ist die Sozialkompetenz des Beraters dabei ein weiterer wichtiger Erfolgsfaktor: Die Chemie muss stimmen. Der Berater muss in der Lage sein, ggf. mit anderen Beratern zusammenzuarbeiten. Hierbei kann es sich unter Umständen um Berater handeln, die im Rahmen von IT Governance-Projekten tätig sind oder die Veränderungsprozesse Ihrer Organisation unterstützen. Beauftragen Sie keine Zertifizierungsorganisation mit der Beratung: Ist eine spätere Zertifizierung der IT Service Management-Prozesse geplant, muss Unabhängigkeit zwischen Berater und Zertifizierer gewährleistet sein. Zertifizierungsorganisationen konzentrieren sich außerdem häufig auf die formalen Anforderungen des Standards, während ein Berater praxisorientiert vorgehen wird. Der Betriebsrat sollte von Ihnen bzw. vom Top-Management frühzeitig über die geplanten Maßnahmen informiert werden. Mit der Einführung von Prozessen auf Basis der ITIL Best Practices ist das Ziel verbunden, die Wirksamkeit der Prozesse zu messen und ggf. den Bedarf an notwendigen Optimierungsmaßnahmen zu identifizieren. In vielen Fällen führt dies dazu, dass die Prozess-Aktivitäten der Mitarbeiter erfasst und aggregiert werden. Zum Beispiel wird die Kennzahl Einhaltung der Lösungszeiten von Incidents oder Dauer der Nichtbearbeitung der Tickets aus dem Incident-Prozess oder aus Tools gewonnen. Einbeziehung des Betriebsrats Nach deutschem Recht ist der Betriebsrat zumindest über diese Maßnahmen zu informieren; in Teilbereichen wird möglicherweise die Zustimmung des Betriebsrates erforderlich sein. Informieren und beteiligen Sie den Betriebsrat frühzeitig. Unterstreichen Sie, dass Prozesse ausgewertet werden sollen und nicht die Leistung einzelner Mitarbeiter. Machen Sie klar, dass die geplanten Maßnahmen der internen Optimierung und damit auch dem Schutz von Arbeitsplätzen dienen. Zur Information und Abstimmung mit dem Betriebsrat hat sich folgendes Vorgehen bewährt: Das Top-Management hat den Betriebsrat frühzeitig über die Ziele der geplanten Prozesseinführung und das Erreichen von Meilensteinen informiert. Es wurde mit dem Betriebsrat vereinbart, dass die 275

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

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

287 6 Lessons learned: Empfehlungen und Ratschläge Zur Identifizierung der verschiedenen Motivationsgründe ist es hilfreich, über einen externen Berater mit entsprechenden Erfahrungen zu verfügen. 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 oft in IT Rechenzentren dem Kunden unter anderem berichtet, welche Probleme identifiziert wurden und welche Maßnahmen ergriffen werden, um die identifizierten Probleme zu beheben. Für interne IT-Organisationen ist es ideal, über erreichte Kosteneinsparungen berichten zu können. In von uns beratenen Unternehmen konnte zum Beispiel mit Hilfe des Prozesses Capacity Management dargestellt werden, welche Kosteneinsparungen durch die Konsolidierung der 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 Process Owner sind der Originalliteratur zur ITIL Version 2 nicht zu entnehmen. Hier liefert aber entsprechende Sekundärliteratur Empfehlungen (vgl. [OGC, 2005a]). Die ITIL Version 3 greift diesen leichten Mangel aus Version 2 auf und gibt Handlungsempfehlungen für die Etablierung der organisatorischen Rollen Process Owner und Prozess-Manager. Diese generischen Rollenbeschreibungen sind im Rahmen der Umsetzung entsprechend der jeweiligen Organisation zu operationalisieren. 278

288 Diesen Empfehlungen gemäß ist der Prozessinhaber (Process Owner) für die Prozessergebnisse verantwortlich, während der Prozess-Manager für die Durchführung und die Einrichtung des Prozesses verantwortlich ist. Der Process Owner dient dem Prozess-Manager primär als Coach. 6.2 ITIL-Einführung 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 Process 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 (natürlich auch den Process Owner) Letztendlich liegt die Gesamtverantwortung für das Service Management in der Rolle des Service Managers (vgl. Continual Service Improvement, [OGC, 2007e] Die Rolle des Prozess- Managers Die Rolle des Service Managers Seine Verantwortung umfasst die Entwicklung der Geschäfts-Strategie, Marktund Kunden-Analyse, Lieferanten-Management, Inventarisierung, Kosten Management und insbesondere das Auslieferungs- und Lebenszyklus-Management von Produkten und Services. 279

289 6 Lessons learned: Empfehlungen und Ratschläge Für die Einführung der IT Service Management-Prozesse und der identifizierten Optimierungsmaßnahmen ist der Service Manager richtungsweisend, er erstellt den Bebauungsplan. Die Rolle des Service Managers muss mit einem erfahrenen Manager besetzt werden. Die Rolle des 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 Process Owner mit Personen aus dem mittleren Management besetzt werden. Dem mittleren Management kommt eine wichtige Rolle in der Unterstützung des Wandels zu. Die Rolle der Mitarbeiter Mit der Einführung von IT Service Management-Prozessen kann sich die Rolle von Mitarbeitern im IT Service aus deren Sicht verkomplizieren. Waren sie vorher ausschließlich einem Vorgesetzten verantwortlich (und dort der Ergebniserbringung), wird ihre Tätigkeit nun in verschiedenen Prozessen überwacht, und die Weisungen unterschiedlicher Prozess- Manager steuern auf Qualitätsebene die operative Arbeit der Mitarbeiter. 280

290 6.3 Kontinuierlicher Verbesserungsprozess Stellen Sie sicher, dass Ihre Mitarbeiter sich in dieser Situation nicht verloren vorkommen. Die Hierarchie, insbesondere das mittlere Management, muss die Prozesse aktiv unterstützen, um damit die Ziele der ITIL-Einführung nachhaltig zu unterstützten. Die Prozess-Manager geben den Mitarbeitern Leitplanken (Prozessleitlinien) vor, innerhalb derer sie sich sicher bewegen können. Durch diese Konzentration auf klare Prozesse geben sie ihren Mitarbeitern ein Gefühl der Sicherheit. Transparente Ziele und veröffentlichte Kennzahlen als Erfolgsnachweis der eigenen Arbeit steigern die Zufriedenheit der Mitarbeiter im Unternehmen. Beziehen Sie Ihre Mitarbeiter und deren Know-how bei der Entwicklung der neuen IT Service Management-Prozesse mit ein und gewinnen Sie dadurch weitere Akzeptanz. Damit die ITIL Best Practices erfolgreich zur Gestaltung und Implementierung Ihrer IT Service Management-Prozesse genutzt werden können, müssen Sie einen Veränderungsprozess in Ihrer IT-Organisation initiieren. Ohne flankierende Maßnahmen führt das Einführen von ITIL zu Akzeptanzproblemen und scheitert nicht selten. Die ITIL Best Practices sind eine Methode, aber nicht das Ziel. Sie nutzen lediglich die Best Practice-Erfahrungen, um von Ihnen bei der Definition Ihrer IT Service Management-Prozesse zu profitieren. Die angepassten IT Service Management-Prozesse müssen innerhalb Ihrer 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 82. Von wesentlicher Bedeutung für die Qualität der IT Services und der Prozesse ist, dass Sie eine fortlaufende Überprüfung, ein Monitoring sämtlicher implementierten IT Service Management-Prozesse durchführen. Auf die dazu notwendige Ermittlung von Kennzahlen wird im nächsten Kapitel eingegangen. 281

291 6 Lessons learned: Empfehlungen und Ratschläge In der Publikation Best Practice für Service Support vgl. [OGC, 2005b]) heißt es hierzu: Dieser Ansatz bedingt, dass ein Unternehmen nach definierten Prozessen agiert, seine Aktivitäten in Bezug auf die Zielerreichung misst, sowie die aus den Prozessdurchläufen folgenden Outputs im Hinblick auf mögliche Prozessverbesserungen überprüft. Abbildung 82: Deming (oder PDCA) Zyklus Die Norm ISO 20000, der (einzige) internationale Standard für das IT Service Management, konkretisiert diesen Ansatz der ITIL Best Practices weiter. So fordert die ISO 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). 282

292 6.3.1 KVP der bestehenden Prozesse 6.3 Kontinuierlicher Verbesserungsprozess Ausgangspunkt ist die oben beschriebene Analyse der bereits innerhalb der IT-Organisation bestehenden IT Service Management-Prozesse. Prozess-Manager von bereits bestehenden IT Service Management-Prozessen befinden sich dabei in einer vermeintlich komfortablen Ausgangsposition: Während andere Prozesse noch zu definieren und zu entwickeln sind, bestehen deren Prozesse bereits. In diesem Zusammenhang mag es zunächst paradox erscheinen, aber speziell die Prozess-Manager von bestehenden Prozessen benötigen die intensivste Unterstützung durch eine externe Begleitung. Sie müssen die IT Service Management-Prozesse, die am weitesten entwickelt sind (mit der höchsten Prozessreife), besonders eng begleiten. Ansonsten besteht die große Gefahr, dass sich der betroffene 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. 283

293 6 Lessons learned: Empfehlungen und Ratschläge Dem Prozess-Manager mit dem bereits am weitesten entwickelten Prozess kommt hierbei eine besondere Rolle zu. Er muss auf die anderen Prozess- Manager zugehen und die Vernetzung der einzelnen Prozesse aktiv vorantreiben und sicherstellen. Planen Sie zum Beispiel die Etablierung des Incident, Problem und Change Managements und ist der Prozess des Incident Managements am weitesten fortgeschritten, so muss der Prozess-Manager des Incident Managements die führende Rolle bei der erforderlichen Vernetzung der drei Prozesse einnehmen. Bei den bestehenden Prozessen zeichnet sich der KVP dadurch aus, dass die Prozesse gleichmäßig (vertikal) entwickelt werden und kein Process Owner oder Manager die Entwicklung isoliert vorantreibt. Nicht zu früh beginnen KVP der neuen Prozesse Mit dem Start des kontinuierlichen Verbesserungsprozesses darf bei neuen Prozessen nicht zu früh begonnen werden. Stellen Sie zunächst sicher, dass der Prozess bereits wirklich komplett eingeführt ist. Am Bild einer Treppe verdeutlicht: Sie sollten die Stufen stetig, mit ruhigen Schritten emporsteigen. Nehmen Sie nicht mehrere Stufen auf einmal, überspringen Sie keine Stufen. Um das Ziel sicher zu erreichen, sollten Sie auf jeder Stufe erst einmal verharren und Kraft tanken, um dann erholt die nächste Stufe zu erklimmen. Ihre Organisation muss die Prozesse angenommen haben und damit verbundene (Ver-) Änderungen müssen verkraftet sein. Die Einführung von IT Service Management-Prozessen auf Basis der ITIL Best Practices ist eine Maßnahme der Organisationsentwicklung und bedarf eines Veränderungsmanagements. Der Soziologe Kurt Lewin gilt als Wegbereiter der Organisationsentwicklung. Aufbauend auf seiner Grundannahme, dass sich eine Organisation ändert, wenn sich ihre Akteure ändern, entwickelte er sein Phasenmodell (vgl. Abbildung 83) zum Veränderungsmanagement (vgl. [Lewin, 1958]). 284

294 6.3 Kontinuierlicher Verbesserungsprozess Neue Welt Alte Welt Einfrieren Auftauen Bewegen Abbildung 83: 3-Phasen-Modell nach Lewin Im Ausgangszustand befindet sich eine Organisation im Gleichgewicht. Die bestehenden Abläufe und Prozesse werden in Frage gestellt. Hierzu kann auf die ITIL Best Practices und die damit in anderen IT-Organisationen erzielten Erfolge verwiesen werden. Die bestehende IT-Organisation wird aufgetaut. Ist das Auftauen der IT-Organisation (und der Mitarbeiter) erreicht, werden in der Phase der Bewegung neue Prozesse implementiert und die Mitarbeiter in deren Handhabung ausgebildet und eingewiesen. Es ist dann von großer Bedeutung, dass dieser Zustand zunächst eingefroren wird. Mit den alten Abläufen waren Ihre Mitarbeiter vertraut. Die Implementierung der neuen IT Service Management-Prozesse führt zu einer Instabilität. Die Mitarbeiter sind mit den neuen Prozessabläufen und den damit verbundenen Abläufen noch nicht vertraut. Sie fühlen sich unsicher. Ihre Aufgabe besteht jetzt darin, den Mitarbeitern die notwendige Sicherheit zu vermitteln. Das heißt, Sie müssen den Mitarbeitern die Chance geben, sich mit den neuen Prozessen auseinander zu setzen und deren Handhabung im täglichen Betrieb einzuüben. Die Mitarbeiter Ihrer IT-Organisation müssen die Veränderungen bewältigen. Geben Sie ihrer Organisation die Chance, sich mit neuen Abläufen vertraut zu machen, und planen Sie Phasen des Einfrierens ein. 285

295 6 Lessons learned: Empfehlungen und Ratschläge Das Service Improvement- Programm 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. Beginnen Sie zu früh mit den nächsten Verbesserungsmaßnahmen, so nehmen Sie ihrer IT-Organisation und Ihren Mitarbeitern die Chance, die bisher erzielten Vorteile zu erleben. Innerhalb der ITIL Best Practices wird lediglich im Rahmen des Service Level Management-Prozesses auf ein Service Improvement-Programm (SIP) eingegangen. Die ISO 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. 286

296 6.3 Kontinuierlicher Verbesserungsprozess Damit entsteht eine Kombination aus formellen Reviews zur Service- und Prozessoptimierung und einem betrieblichen Vorschlagswesen. In Ihrer Organisation existiert damit ein Verbesserungsprozess, der Input für neue und eingeführte IT Service Management-Prozesse aus der IT-Organisation (Reviews) und von den Mitarbeitern bezieht. Aufgabe des Prozess-Managers ist die Bewertung des Inputs für den Service Improvement-Plan und die Erstellung einer Umsetzungsplanung. Die Einführung und der Ausbau der IT Service Management-Prozesse sollten in Stufen und mit Stabilisierungsphasen (Projektpausen) erfolgen. Dazu muss der Prozess-Manager die zuvor geplanten Projektphasen sowie den Input aus dem SIP bewerten, die mit den Maßnahmen verbundenen Vorteile identifizieren und die Umsetzung planen. Diese Verbesserungstätigkeit ist mit dem IT Service Management-Prozess des Release Management vergleichbar. Es ist nicht zweckmäßig, eine Reihe von Änderungen jeweils einzeln und nacheinander zu implementieren. Sie sollten vielmehr die Einzelmaßnahmen bündeln und als Aufgabenpaket (Release) durchführen. ITIL- Einführung erfordert ein Release Bündeln Sie die einzelnen Verbesserungs- und Erweiterungsmaßnahmen zu einem Aufgabenpaket (Release). Dem Process Owner kommt hierbei als Coach eine qualitätssichernde Aufgabe zu. Zum Beispiel hat der Process Owner beim Prozess-Manager kritisch zu hinterfragen, ob die nächste Umsetzungsmaßnahme sowohl inhaltlich als auch vom Zeitpunkt her die IT-Organisation nicht überfrachtet. Sobald diese Abstimmung erfolgt ist, muss der Prozess-Manager die geplanten Verbesserungen und Erweiterungen in der IT-Organisation gegenüber dem Management und den Mitarbeitern kommunizieren. Kommunizieren Sie als Prozess-Manager Ihre geplanten Maßnahmen (SIP für Ihre IT Service Management-Prozesse) in der IT-Organisation. Die Initiierung zur Entfaltung weiterer IT Service Management-Prozesse muss vom IT-Management erfolgen. Haben Sie zum Beispiel bereits Incident, Problem, Configuration und Change Management implementiert, so muss eine Erweiterung um das Release Management vom IT-Management initiiert werden. Die Verantwortung für die Prozessentfaltung d.h. die Erweiterung der bestehenden IT Service Management-Prozesse liegt beim Service Manager (beraten und unterstützt durch die Process Owner, als auch die IT- Leitung) und dem prozessverantwortlichen Prozess-Manager. Der Entfaltungsprozess 287

297 6 Lessons learned: Empfehlungen und Ratschläge Es ist hilfreich, wenn die Process Owner für alle IT Service Management- Prozesse zu Beginn benannt werden, auch wenn die Prozesse noch nicht implementiert wurden. Die Prozess-Manager können mit der Entscheidung des Managements über die Einführung eines Prozesses benannt werden. Wichtig ist, nicht nur die implementierten Prozesse hinsichtlich ihrer Zielerreichung zu messen, sondern auch die Einführung von Prozessen zu messen und zu überwachen. Der Service Manager hat hierzu ein prozessorientiertes Führungssystem aufgebaut, in dem pro Prozess die folgenden Stufen vom Service Manager gemessen und berichtet werden: 1. Stufe Prozess verstanden 2. Stufe Prozessnutzung initiiert 3. Stufe Prozess implementiert 4. Stufe Prozess wird kontinuierlich verbessert (KVP) Damit die Implementierung der Prozesse vom Management besser verfolgt werden kann, könnten die obigen Stufen der IT Service 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 in vollem Umfang genutzt (es kommen Vorschläge zur Verbesserung); die Prozesstools werden ausgereizt. Stufe 4: die Organisation denkt darüber nach, Erweiterungen und Verbesserungen umfänglich einzuführen. Mit diesem Ampelsystem verfügt der Service Manager (auch die Process Owner und die IT-Leitung) und damit indirekt auch das gesamte Management über ein gutes Führungssystem zur Überwachung der geplanten Maßnahmen und der erzielten Prozessreife. 288

298 6.3 Kontinuierlicher Verbesserungsprozess Sie benötigen nicht nur ein System zur Messung der Effizienz und Effektivität der Prozesse, sondern auch ein Messsystem für die Prozessimplementierung. Mit einem Ampelsystem können Sie die Einhaltung der Prozesse und deren Wirksamkeit in der Linie überprüfen 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änderungsmanagement werden Sie nicht alle Mitarbeiter von den geplanten Maßnahmen überzeugen können. Mit den Quick-Wins können Sie erste Erfolge nachweisen, die die Richtigkeit des Vorhabens demonstrieren. Die Einführung wird anschließend durch eine größere Akzeptanz beschleunigt. Die ITIL-Einführung benötigt eine durchgängige Kommunikationsplattform. Hier berichten die Prozess-Manager dem Service Manager und dem Process Owner sowie der IT-Leitung über die bereits erzielten Erfolge. Diese Erfolge können aus einer Verbesserung der Prozessreife und der damit verbundenen Änderung der Ampelfarbe bestehen, wie zum Beispiel der erreichten Dokumentation eines Prozesses. Ein Erfolg kann aber beispielsweise auch darin bestehen, dass Probleme erfolgreich behoben wurden und dadurch die Anzahl der Störungen gesenkt werden konnte. Mit der Zeit lernen die Prozess-Manager, wie sie der Organisation die Wirksamkeit ihrer Prozesse darstellen können. Zum Beispiel kann der Prozess-Manager Configuration Management dem Produktionsleiter demonstrieren, wie mithilfe des Configuration Managements sehr viel schneller wichtige Informationen abgerufen werden können. Dadurch, dass die Prozess-Manager erste Erfolge aufzeigen, entsteht innerhalb der IT-Organisation ein Wettbewerb der Prozesseinführung. Andere Prozess-Manager haben ein Interesse daran, ebenfalls Erfolge aufzuzeigen. Es entsteht eine Sogwirkung. Durch die gemeinsame Kommunikationsplattform ist die notwendige Transparenz gegeben. Zusammen mit dem kontinuierlichen Verbesse- 289

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

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

301 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 (vgl. [OGC, 2005b]) führt hierzu aus: Um ermitteln zu können, ob Ihre Aktivitäten einen optimalen Beitrag der vom Prozess verfolgten geschäftlichen Zielsetzung leisten, sollten Sie regelmäßig ihre Effektivität messen. Die Durchführung von Messungen ermöglicht Ihnen, das tatsächlich Erreichte mit dem Geplanten zu vergleichen sowie eine eventuell erforderliche Verbesserung zu erwägen bzw. einzuleiten. Angesichts der Komplexität und der großen Zahl von durchgeführten Aktivitäten innerhalb einer IT-Organisation kann in der Praxis nur über Kennzahlen verfolgt werden, ob die IT Service Management-Prozesse die definierten Ziele erreichen bzw. welche Entwicklungen sich in den IT Service Management-Prozessen abzeichnen. Die Prozesssteuerung von IT Service Management-Prozessen ist ohne Kennzahlen unmöglich. Sie benötigen Kennzahlen für jeden einzelnen IT Service Management-Prozess. Die Kennzahlen werden dabei zum Teil aus den operativen Systemen gewonnen, wie zum Beispiel aus den in einem Tool für das Incident Management dokumentierten Aktivitäten. Die gespeicherten Informationen werden dabei zu aussagekräftigen Kennzahlen verdichtet, mit denen die Effektivität und Effizienz der jeweiligen IT Service Management-Prozesse gemessen werden kann. Wenn Sie zum ersten Mal Ihre IT Service Management-Prozesse messen, also erste Kennzahlen gewinnen, können die Ergebnisse für das Management sehr ernüchternd sein. Einzelwerte können sogar erschreckend sein. Sehen Sie diesen ersten Eindruck als Chance für das Management. Sie können die Prozesse messen und haben dadurch die Basis für ein erfolgreiches Management der Prozesse geschaffen. Ein Nutznießer der Kennzahlen ist Ihr IT-Management, z.b. Gruppenoder Abteilungsleiter. Anhand weniger signifikanter Kennzahlen kann sich das IT-Management einen Überblick über die aktuelle Situation verschaffen. 292

302 6.4 Kennzahlen Folgende Kennzahlen können von Interesse sein: Incidents pro Monat und Gruppe Probleme pro Monat und Gruppe Changes pro Monat und Gruppe Die Anzahl der Changes zeigt die Änderungsdynamik im Unternehmen auf und dient außerdem als Indikator für die Arbeitsbelastung der Mitarbeiter. Ein sprunghaftes Ansteigen von Incidents kann auf eine Flächenstörung hinweisen. Das Management sollte jeweils die Gründe hinterfragen und ggf. die notwendigen organisatorischen Maßnahmen veranlassen. Stellen Sie in Ihrer IT-Organisation heraus, dass die Ermittlung und Auswertung von Kennzahlen für das Management der IT Service Management-Prozesse unbedingt notwendig sind. Betonen Sie, dass die Kennzahlen nicht zur Messung und Beurteilung Ihrer Mitarbeiter dienen und auch nicht dazu genutzt werden. Wenn Sie noch über keine Messwerte zu einem Prozess verfügen, sollten Sie sich zunächst auf die wichtigsten Kennzahlen konzentrieren. Denken Sie bei der Definition der Kennzahlen an die 80/20-Regel (Pareto-Regel): Der Aufwand und das Ergebnis stehen oft in einem nicht-linearen Verhältnis. 80 % der Arbeit lässt sich mit 20 % Aufwand erledigen. Die restlichen 20% erfordern dagegen 80 % Aufwand. 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. 293

303 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 Process Owner geben. Aufgrund der Anforderungen und seinen Erfahrungen aus dem Tagesgeschäft ist der Process Owner der ideale Partner, um die notwendigen Kennzahlen zu diskutieren und zu definieren. Interessante Kennzahlen für den Beginn eines Kennzahlenmonitorings können sein: Anzahl der mit Ihren Kunden vereinbarten SLAs Anzahl der Notfall / BCM-Übungen pro Jahr in Bezug auf das IT Service Continuity Management Anzahl der vorhandenen Assets pro Gruppe (Windows, Unix, Host etc.) in Bezug auf das Configuration Management Anzahl der Ausfälle > 120 min pro Applikation und Monat in Bezug auf das Availability Management. Verwendete Kennzahlen müssen für das Management prägnant und beeinflussbar sein. Kann ein Linien-Manager die Kennzahlen nicht sinnvoll nutzen, so findet ITIL beim Management keine Anerkennung! Im Rahmen der schrittweisen Weiterentwicklung Ihrer IT Service Management-Prozesse können Sie ggf. auf einzelne Kennzahlen verzichten oder Kennzahlen ergänzen. Haben Sie zum Beispiel im Incident Management mit der Kennzahl Anzahl Incidents insgesamt begonnen, so können Sie dann die Incidents auf einzelne Kunden, IT Services oder IT-Systeme gruppieren. Im Rahmen dieser schrittweisen Erweiterung können Sie dann auch auf Best Practices wie ITIL oder COBIT zurückgreifen. Prüfen Sie die dort 294

304 6.4 Kennzahlen dokumentierten Kennzahlen auf sinnvolle Nutzung in Ihrer IT-Organisation, und übernehmen Sie sie nur bei einer positiven Bewertung. Wollen Sie eine Revision Ihrer IT Service Management-Prozesse auf der Basis von COBIT sicherstellen, so sollten Sie die Umsetzung dieser Anforderung als Stufe Ihres KVP planen und nicht zu Beginn des Prozesses integrieren. Im weiteren Reifegrad der ITIL-Einführung können folgende Kennzahlen signifikanter werden: Anzahl der Changes mit Auswirkungen auf die Availability, somit die Referenz von Changes zu Incidents. Anzahl der Incidents die auf ein Problem referenzieren, somit die Übersicht darüber, wie viele Maßnahmen im Problem Management aktuell betrachtet werden. Anzahl der Service Level Agreements in verschiedenen monetären Volumina (z.b. < Euro; < Euro) und damit eine Gruppierung nach A,B,C Kunden ITIL abgestimmt auf Business- und IT-Strategie Charakteristisch für IT Service Management-Prozesse auf der Basis der ITIL Best Practices ist ihre Ausrichtung auf die Geschäftsprozesse Ihres (internen oder externen) Kunden. Hierzu heißt es in Best Practice für Service Support (vgl. [OGC, 2005b]): ITIL richtet den Fokus auf die Bereitstellung qualitativ hochwertiger Services und unterstreicht insbesondere die Bedeutung von Kundenbeziehungen. Dies bedeutet, dass die IT-Organisation bereitstellen sollte, was immer mit dem Kunden vereinbart wurde, was wiederum eine enge Beziehung zwischen der IT-Organisation und deren Kunden und Partnern voraussetzt. Planen Sie die Einführung von kundennahen IT Service 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 Service wahrnimmt. Dies ist in der Regel der Arbeitsplatz, und dieser Ansatz führt damit zu einer end-to-end -Messung des IT Service. Den Kunden rechtzeitig einbinden. 295

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

306 6.4 Kennzahlen Sie sollten die IT Service Management-Prozesse schrittweise einführen. Dies betrifft sowohl die Anzahl der einzuführenden Prozesse, als auch den stufenweisen Ausbau (KVP). Dieses schrittweise Vorgehen bedingt eine Priorisierung der Einführung durch das Management. Ein Aspekt ist dabei der so genannte Pain-Faktor. Gibt es innerhalb Ihrer IT-Organisation in bestimmten Bereichen besonderen Handlungsdruck, so empfiehlt sich eine Priorisierung derjenigen IT Service Management-Prozesse, die hier Abhilfe schaffen können. Stellen Sie zum Beispiel fest, dass durchgeführte Änderungen häufig zu Betriebsstörungen geführt haben, so sollte der Change Management-Prozess priorisiert eingeführt werden. Ein weiterer wichtiger Aspekt für die Priorisierung von IT Service Management-Prozessen ist das Wissen um die Geschäftsstrategie Ihres Kunden. Sie müssen diese Strategie verstehen, um zu entscheiden, wie Sie ihre Prozessentfaltung vorantreiben, d.h. wie Sie die stufenweise Einführung und den Ausbau der IT Service Management-Prozesse planen. Befindet sich Ihr Unternehmen bzw. Ihr Kunde in einer Wachstumsphase, so würde sich die Priorisierung der Planungsprozesse (Service Delivery) und des Release Managements empfehlen. Denn damit stellen Sie sicher, dass die notwendigen Kapazitäten rechtzeitig bereitgestellt werden können und die Geschäftsprozesse nicht durch fehlende IT-Kapazitäten in Mitleidenschaft gezogen werden. Betreibt Ihr Unternehmen dagegen eine Kostendämpfungsstrategie, so bietet sich eine Konzentration auf das Problem und Change Management an. Durch das Problem Management identifizieren Sie die Ursachen von Störungen und können die Qualität der IT Services steigern. Die Anzahl von Störungen und Geschäftsausfällen wird abnehmen und Sie leisten einen Beitrag zur Kosteneinsparung. Betrachten Sie die Gründe für 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. 297

307 6 Lessons learned: Empfehlungen und Ratschläge Das Reporting der Kennzahlen muss kundenorientiert erfolgen Grundsätzlich besteht Ihre Verantwortung darin, Ihrem Kunden die erreichten Service Level zu berichten. Es gilt die Maxime, dieses Reporting in einer Sprache und Darstellung vorzunehmen, die der Kunde versteht, also in der Sprache des Kunden, nicht in der Sprache des Technikers. Beispielsweise kann es sinnvoll sein, darzustellen, welche Folgen Störungen hatten, welche Konsequenzen ein Ausfall einzelner Standorte hatte und welche Verbesserungsmaßnahmen eingeleitet wurden, um diese Ausfälle in Zukunft zu vermeiden. Ein monatlicher Report könnte beispielsweise folgende Informationen enthalten: Im Monat März hatten wir am eine Störung in der Anwendung XYZ. Diese Störung wurde hervorgerufen durch den Austausch einer technischen Komponente, die zu einem Ausfall des Netzwerkes von 6.00 Uhr 7.30 Uhr führte. Um dies zukünftig zu vermeiden, haben wir unseren Servicepartner angewiesen, eine weitere redundante Komponente im Falle eines Hardware-Wechsels vor Ort verfügbar zu haben, um damit eine schnellere Reparatur zu ermöglichen und so die Verfügbarkeit zu erhöhen. Berichte zu den geleisteten IT Services und den Kennzahlen aus den IT Service Management-Prozessen müssen aus der Sicht und in der Sprache des Kunden erfolgen. Das Management hat die Weiterentwicklung zur Aufgabe ITIL Refresh oder wie geht es weiter? Nachdem Sie auf Basis der ITIL Best Practices Ihre IT Service Management-Prozesse gestaltet und eingeführt haben, bedarf es eines regelmäßigen Refresh. Dieser Refresh betrifft alle Beteiligten Ihrer IT-Organisation mit unterschiedlichen Ausprägungen und Inhalten. In diesem Abschnitt stellen wir die wichtigsten Aspekte gruppiert nach den beteiligten Bereichen vor. Falls Sie eine Zertifizierung Ihrer IT Service Management-Prozesse durchführen, wird von der Zertifizierungsorganisation auch geprüft, ob eine Aus- und Weiterbildungsplanung existiert, und mögliche Defizite werden aufgezeigt. Das Top-Management, der Service Manager, die Process Owner und die Prozess-Manager sollen beobachten, wie sich die Umsetzung der ITIL Best Practices im Unternehmen weiterentwickelt. Hierbei ist auch relevant, wie sich vergleichbare andere IT-Organisationen weiter entwickeln und wie sich diese Weiterentwicklung in Bezug auf Ihre Organisation darstellt. 298

308 6.4 Kennzahlen Die dokumentierten ITIL Best Practices unterliegen zwar einer stetigen Weiterentwicklung, aber diese geht erst mit einem Zeitverzug in die offiziellen Publikationen ein. Auf Kongressen, wie dem ITIL-Forum oder dem Jahreskongress der itsmf Deutschland e.v., wird aktuell über Erfahrungen mit der Umsetzung der ITIL Best Practices und über in Unternehmen vollzogene Ausgestaltungen und Erweiterungen berichtet. Auf diesen Kongressen können Sie nicht nur vergleichen, wo Ihre IT-Organisation in Bezug auf andere IT-Organisationen steht. Sie können Ideen aufnehmen und prüfen, ob diese Ideen auch für Ihre IT-Organisation eine Innovation darstellen und einen Mehrwert generieren können. Insbesondere für den Service Manager, den Process Owner und den Prozess-Manager stellt dieser Informationsprozess eine wichtige Aufgabe dar. Es ist sehr wichtig, dass Sie sich mit den erreichten Maßnahmen nicht zufrieden geben. Sie müssen die Weiterentwicklung von ITIL und von anderen IT-Organisationen beobachten, andere Ansätze prüfen und mehrwertschaffende Konzepte adaptieren. Auf der Ebene der Mitarbeiter ist es von großer Bedeutung, dass neue Mitarbeiter über ITIL Know-how verfügen bzw. entsprechend geschult werden. Diese Schulung sollte in drei Teilen erfolgen: Die Mitarbeiter benötigen zunächst einen Gesamtüberblick über die Ziele des IT Service Managements sowie aller Prozesse. Ansonsten werden die Mitarbeiter den Nutzen von ITIL nicht verstehen. Es empfiehlt sich, diese Schulungen extern wahrnehmen zu lassen. Gegebenenfalls könnte dies auch von einem Service Manager mit entsprechender Schulungserfahrung übernommen werden. Sind die theoretischen Aspekte bekannt, so sollten die Prozess- Manager die Mitarbeiter in denjenigen Prozessen schulen, in denen diese eingebunden sind. Hierbei wird insbesondere geschult, wie die jeweiligen Prozesse innerhalb der jeweiligen Organisation des Unternehmens ihre Anwendung finden (von der Theorie zur Praxis). Sind die IT Service Management-Prozesse auf Basis der ITIL Best Practices eingeführt, so ist unbedingt darauf zu achten, dass es regelmäßige Nachschulungen für die geschulten Mitarbeiter gibt (Wissen erhalten und erweitern) und neue Mitarbeiter ebenfalls die Stufen des aufgesetzten ITIL-Schulungsprozesses durchlaufen. Mitarbeiter müssen geschult werden Ein erfolgreiches IT Service Management bedingt, dass Ihre Mitarbeiter die Prozesse kennen und verstehen. Sie müssen sicherstellen, dass dieses Verständnis auch bei neuen Mitarbeitern ausreichend gegeben ist. 299

309 6 Lessons learned: Empfehlungen und Ratschläge 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 bewährt. Damit werden auch für die Prozess-Manager die erzielten Erfolge sichtbar. Die IT Service Management-Prozesse haben eine eindeutige Ausrichtung auf die Geschäftsprozesse Ihres Kunden und müssen daher Bestandteil Ihrer IT-Strategie sein. Diese Anforderung bedeutet nicht nur, dass die IT Service Management- Prozesse aufgrund Ihrer IT-Strategie eingeführt werden, sondern auch, dass sich deren Ziele stets aus der IT-Strategie ableiten. 300

310 6.4 Kennzahlen Logische Konsequenz hieraus ist, dass sich auch die Kennzahlen und deren Soll-Werte aus der IT-Strategie ergeben. Um alle Bereiche auf die IT-Strategie auszurichten, sollten sie anfänglich eine einfache Balanced Scorecard (BSC) nutzen. Dazu werden aus den übergeordneten strategischen Betrachtungen konkrete Maßnahmen und Leistungen in den IT Service Management-Prozessen identifiziert und mit entsprechenden Kennzahlen hinterlegt. Die Ziele und Zielwerte (Soll-Werte) der IT Service Management-Prozesse leiten sich aus der IT-Strategie ab. Durch die Verknüpfung der Balanced Scorecard mit den Kennzahlen der jeweiligen IT Service 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 Process Owner In den vorhergehenden Kapiteln wurde bereits auf die Rolle des Service Managers, des Prozess-Managers und des Process Owners eingegangen. Oft können Process Owner und Prozess-Manager organisatorisch über Kreuz besetzt werden dass heißt, der Process Owner kommt aus einem anderen Bereich als der Prozess-Manager und so kann die Vernetzung innerhalb der IT-Organisation gestärkt werden. Bestehende Abteilungsgrenzen können erfolgreich überbrückt werden. Voraussetzung hierfür ist die Stärkung der Rolle des Prozess-Managers, ansonsten dominiert der Process Owner allein aufgrund der hierarchischen Stellung den Prozess- Manager. Service Manager In den ITIL Best Practices finden sich zwar an einigen Stellen Hinweise zum Service Manager, aber eine durchgängige Beschreibung dieser Rolle ist in ITIL nicht zu finden. Dabei ist diese Rolle für ein IT Service Management von existenzieller Bedeutung und damit auch die organisatorische Verankerung dieser Rolle. Die IT Service Management-Prozesse sollen sicherstellen, dass die IT Services auf die Geschäftsprozesse des Kunden ausgerichtet sind und deren Anforderungen optimal unterstützen. Daher bieten sich zwei Bereiche an, denen die Rolle des Service Manager organisatorisch zugeordnet werden kann. Zunächst wäre die Kundenschnittstelle der IT-Organisation zu nennen. Damit wird sichergestellt, dass die geforderte Ausrichtung der IT Service Management-Prozesse auf die Kundenanforderungen gewährleistet ist. 301

311 6 Lessons learned: Empfehlungen und Ratschläge Alternativ bietet sich eine Stabstelle zur IT-Geschäftsführung an. Hierfür sprechen die dann kurzen Wege zur Geschäftsführung und die enge Verknüpfung mit der IT-Strategie. Sie müssen für Ihre IT-Organisation entscheiden, welche Zuordnung für Ihren Bereich zweckmäßig ist. Der Service Manager muss unbedingt über eine langjährige Erfahrung im Bereich des IT Service Managements und mit dem Management von 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 Process Owner ab. Prozess-Manager Der Prozess-Manager sollte aus der Linienfunktion besetzt werden, in der wesentliche Prozessaktivitäten durchgeführt werden. Der Prozess-Manager sollte weiterhin in der Linienorganisation angesiedelt bleiben und nicht herausgelöst werden, da ansonsten der Tagesbezug verloren geht. So ist zum Beispiel der Change Manager des Rechenzentrums innerhalb der Produktion angesiedelt. So ist sichergestellt, dass der Change Manager unmittelbar erfährt, wie erfolgreich die Implementierungen von Changes sind bzw. welche Auswirkungen auftreten. Damit ergibt sich auch die Anforderung, dass der Prozess-Manager aus dem Bereich besetzt werden sollte, der über die meisten Erfahrungen mit dem jeweiligen Prozess verfügt. Process Owner Innerhalb des RZs hat es sich als vorteilhaft erwiesen, die Rolle des Process Owners rotieren zu lassen. Durch die wechselnden Process Owner wird der Blickwinkel des Prozess-Managers im Laufe der Zeit erweitert. Wenn möglich, wird die Rolle des Process Owners aus dem Bereich besetzt, der die größten Auswirkungen des Prozesses erfährt. So kommt zum Beispiel der Process Owner für das Change Management nicht aus der Produktion, sondern aus dem Kunden-Management, da dort die Auswirkungen der Changes unmittelbar zu spüren sind. Die Process Owner werden aus einer Hierarchieebene besetzt, die gegenüber der IT-Organisation weisungsbefugt ist. Innerhalb des Rechenzentrums unseres Beispiels sind die Process Owner Bereichs- und Abteilungsleiter, die direkt der Geschäftsführung berichten. 302

312 6.4 Kennzahlen IT im Wandel und wie unterstützt ITIL Ein ständiger Abgleich Ihrer IT Service Management-Prozesse mit der Business- und der IT-Strategie ist unumgänglich. Sie müssen diese Strategien nicht nur während der Einführung berücksichtigen, sondern auch während der gesamten Prozessphase. Wurden die IT Service Management-Prozesse beispielsweise während einer Wachstumsphase eingeführt, dürfte die spezifische Ausrichtung des Capacity Managements darin bestehen, zukünftige Erweiterungen der 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 werden, wenn sich die Organisation in einer sehr starken Wachstumsphase befindet. Logische Konsequenz ist, dass die Business- und IT-Strategie einen Input für den kontinuierlichen Verbesserungsprozess der IT Service Management-Prozesse liefern. Der Process Owner ist die Person, die diesen Input sicherstellt. Der Process Owner erfährt aufgrund seiner hierarchischen Stellung frühzeitig von Veränderungen in der Business- oder IT-Strategie. Er muss als Coach unter Einbeziehung des Service Managers den Prozess-Manager auf die veränderten Rahmenbedingungen aufmerksam machen. Aufgabe des Prozess- Managers ist es dann, notwendige Maßnahmen abzuleiten, sie mit dem Process Owner und dem Service Manager abzustimmen und schließlich im Prozess umzusetzen. 303

313 6 Lessons learned: Empfehlungen und Ratschläge Für die organisatorische Einbindung der IT Service Management-Prozesse ist die Besetzung des Prozess-Managers von großer Bedeutung. Der Prozess-Manager sollte aus der Linien-Organisation stammen und auch dort verbleiben. Als Bereich ist die Organisationseinheit zu wählen, in der die wesentlichen Aktivitäten des Prozesses stattfinden. Das Überkreuzen von Prozess-Manager und Process Owner hat sich sehr bewährt. Dadurch konnte unter anderem eine bessere Vernetzung in der IT-Organisation erzielt werden. Ein wichtiger Nebeneffekt ist, dass der Prozess nicht durch Bereichsdenken geprägt wird. Diese Gefahr besteht, wenn Owner und Prozess-Manager aus dem gleichen Bereich kommen. Die Rotation der Process Owner erweitert den Horizont der Prozess- Manager. Sehr oft kommt dem Process Owner die Rolle eines Coaches zu. 304

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

315 7 Praxisbeispiel: ALTANA Pharma AG Gartner hat 1999 folgende vier Trends ausgemacht, die zu signifikanten Änderungen in der IT führen werden: Trend 1: Prozessbasierendes Arbeiten Trend 2: Outsourcing Trend 3: Spezialisierung in Kompetenzzentren Trend 4: Einbeziehung der Applikationsentwicklung im Business IS Lite, als Ergebnis dieser Trends, stellt eine flexible und erweiterbare Organisation zur Verfügung, um die unterschiedlichen Geschäftsanforderungen beherrschen zu können. Bei ALTANA Pharma waren hierzu strukturelle Änderungen in der IT- Organisation notwendig. Es wurde unter anderem das Global CIO Office aufgebaut und Abteilungen wie Project Management, Business Process Management, Architektur, Account Management und IT Service & Vendor Management dort etabliert. IT Service Management im regulierten Umfeld Sauber definierte IT Service-Prozesse stellen einen professionellen IT- Betrieb sicher. Ein professionelles Vendor Management ist Voraussetzung für eine erfolgreiche Beschaffung von IT Services, intern wie extern. Die Zielsetzungen des IT Service Managements bei ALTANA Pharma, Einführung einheitlicher, standardisierter IT Serviceprozesse, um die Qualität und Quantität der IT Services für den Kunden zu steuern, zu überwachen und sicherzustellen, sowie die Ausrichtung der IT Services auf die Bedürfnisse der Kunden in den Fachbereichen und Standorten, haben ausdrücklich den Kunden und seine Zufriedenheit mit den erbrachten Dienstleistungen im Focus. Die Anforderungen der Kunden an einen IT Service sind oft zusätzlich durch Compliance-Vorgaben beschrieben. In dem sehr stark regulierten Bereich der Pharmaindustrie gibt es nationale und internationale Vorgaben, an die sich auch die ALTANA Pharma halten muss. Dazu zählen die Good x Practices (GxP) (x steht für Laboratory, Clinical oder Manufacturing), die 1978 von der amerikanischen Gesundheitsbehörde FDA (Food and Drug Administration) aufgestellt wurden, um die Sicherheit und Produktqualität von Medikamenten sicher zu stellen. Auch der Sarbanes-Oxley Act (SOX) mit seiner Sektion 404 stellt seit 2002 an die IT der ALTANA Pharma hohe Anforderungen, die von an US- Börsen notierten Firmen erfüllt werden müssen. 306

316 Hier haben sich so genannte Best Practices wie 7 Praxisbeispiel: ALTANA Pharma AG Good Automated Manufacturing Practice (GAMP) Control objectives for information and related technology (CobiT) IT Infrastructure Library (ITIL) bewährt, um die IT bei der Erfüllung der genannten regulatorischen Vorgaben zu unterstützen. Auch wenn diese drei einen unterschiedlichen Focus haben, so sind doch viele Basisaktivitäten gleich. Um das IT Service & Vendor Management der ALTANA Pharma zu optimieren wurde das Projekt SMILE (Service Management ImpLEmentation) 2004 initiiert. Im Vordergrund stand dabei die Ausrichtung der IT-Prozesse nach ITIL. Damit verbunden war die Optimierung und Stabilisierung bestehender Prozesse, auch um größere Transparenz zu schaffen und eine Grundlage für die Messung von Kennzahlen zu ermöglichen. Das Projekt hatte initial den Fokus auf den IT Service Support Prozessen und verfolgte die folgende Zielsetzung: Erstellung eines ALTANA Pharma spezifischen Konzepts zum IT Service Management nach ITIL (bzgl. der betrachteten Disziplinen) Aufbau eines Account Managements für interne Kunden der IT Aufbau eines Service Level Management-Prozesses, insbesondere Einführung eines Leistungs- und Servicekatalogs Überarbeitung der Incident- und Problem Management-Prozesse sowie deren inhaltliche Trennung Finetuning des Change Management-Prozesses sowie die Erstellung der Grobstruktur für eine Konfigurationsdatenbank Definition eines Release Management-Prozesses. Die Einführung der Prozesse nach ITIL wurde unterstützt, indem nahezu alle IT-Mitarbeiter und weitere wichtige Ansprechpartner aus den Fachbereichen von der Firma KESS DV-Beratung GmbH in ITIL geschult worden sind und erfolgreich mit dem Foundation Certificate in IT Service Management abschlossen. Neben dem Verständnis für die ITIL-Prozesse wurde so auch ein einheitlicher Sprachgebrauch gefördert. Um eine spätere Akzeptanz der Prozesse zu erzielen, wurden für jeden Prozess mit abteilungsübergreifenden Teams Workshops veranstaltet. Die Ergebnisse wurden, wie in einem Pharma-Unternehmen üblich, in Standard Operating Procedures (SOPs) festgehalten. Diese SOPs dienten auch als Schulungsunterlagen. Logische Konsequenz dieser Vorbereitungen war die Unterstützung der IT Service Management-Prozesse mit einem integrierten System, auch um Messungen der Prozessperformance zu ermöglichen. Bis auf das Incident 307

317 7 Praxisbeispiel: ALTANA Pharma AG Management war dies durch die teilweise papierbasierende Vorgehensweise nicht oder nur schlecht möglich. Das Folgeprojekt esmile wurde initiiert. esmile: Einführung einer integrierten Systemunterstützung Die Zielsetzung des Projektes esmile lässt sich in den folgenden Punkten zusammenfassen: Integration aller betrachteten IT Service Management-Prozesse Durchgängiger Informationsfluss und Transparenz Etablierung der Configuration Management Database (CMDB) als zentrale Datenbank für alle Configuration Items (CIs) Elektronische Autorisierung von Change Requests über ein Self Service-Portal Vorbereitung auf den Roll-out in anderen Niederlassungen weltweit esmile als Integrationsplattform für alle externen und internen Dienstleister. Gerade der letzte Punkt, dass esmile von fast allen externen Dienstleistern verwendet wird, hat verschiedene Vorteile. Bei Neuausschreibungen von Service-Verträgen wurde diese System-Vorgabe deswegen mit in die Angebotsaufforderungen aufgenommen. Dadurch wird auch sichergestellt, dass die Verantwortung für das Prozess-Management im Hause liegt und durch eine gemeinsame Datenbasis die Prozess-Verantwortlichen ohne Medienbrüche Informationen und Kennzahlen über den gesamten Prozess erhalten. Das System wurde nach dem V-Modell validiert eingeführt. Das V-Modell ist eine im Pharma-Umfeld gängige Vorgehensweise. Es beschreibt Aktivitäten und Ergebnisse, die bei der Einführung von IT-Systemen durchzuführen bzw. zu erzielen sind, und Bereiche wie Anforderungen, Umsetzung und Tests zur Qualitätssicherung beinhaltet. Validierung eines computergestützten Systems ist der dokumentierte Nachweis, dass das System den GxP-Anforderungen genügt und so arbeitet und in Zukunft arbeiten wird, wie es dies laut Spezifikationen soll. Nach der Validierungsfreigabe im April 2006 wurde die Produktivschaltung des Systems zweiphasig umgesetzt. In der ersten Phase kamen die Prozesse Problem, Change und Configuration Management zum Einsatz. Hier hat man sich erhofft, durch die Ablösung des papierbasierenden Change Managements mit einem System, in dem weltweit über einen webbasierenden Self Service elektronisch unterschrieben werden kann, einen Quick-Win zu erhalten. Dies hat sich bestätigt, da trotz der Verdoppelung der eingegangenen RfCs die Bearbeitung im Change Management handhabbar geblieben ist. 308

318 7 Praxisbeispiel: ALTANA Pharma AG In der zweiten Phase wurde kurz darauf das Incident Management mit dem Service Level Management aktiviert. Nach einer Eingewöhnungsphase kamen dann schnell die notwendigen Daten zustande, um ein aussagekräftiges Management Reporting zu beginnen und mit Kennzahlen die unterstützten Prozesse zu bewerten. Ansatz für Kennzahlen und KPIs In der IT der ALTANA Pharma haben sich mit der Einführung der IT Service Management-Prozesse auch unterschiedliche Gremien etabliert. In diesen Gremien werden Kennzahlen zur Steuerung benötigt. Hierzu zählt das Incident-, Problem- und Change-Meeting (IPC-Meeting), das die Prozesse mit den internen Support-Einheiten bespricht. Es dient einer Verbesserung der Organisation der IPC-Bearbeitung (Organisatorisches Meeting, keine Diskussionsplattform), der Vermittlung des Status Quo an die Teamleiter, Ableitung von erforderlichen Maßnahmen sowie Nachverfolgung der beschlossenen Maßnahmen. Das Change Advisory Board (CAB) wie auch das Betriebsmeeting haben eine Schnittstelle zu den externen Providern. Gerade hier sind Kennzahlen wichtig. Einmal um die getroffenen Vereinbarungen zu überprüfen, aber auch, um Probleme zu identifizieren und gemeinsam Verbesserungen zu erarbeiten. Die Kennzahlen werden je nach Anforderung wöchentlich, 14-tägig und monatlich erhoben und zur Verfügung gestellt. Incident Management Im Incident Management beziehen sich die erstellten Berichte überwiegend auf die mit dem externen Service Provider vereinbarten Service Level. Hauptaugenmerk wird auf den dorthin vergebenen Service Desk gelegt. Neben allgemeinen mengenorientierten Kennzahlen werden die folgenden berichtet: Erreichbarkeit Longest Wait Call Wartezeit Direktlösungsrate Lösungsrate Erfüllungsgrad Weiterleitung Reset / Aktivierung von Passwörtern Account Administration Dabei werden die Erreichbarkeit, Wartezeit und Longest Wait Call durch Auswertungen der Telefonanlage berechnet, alle anderen auf Basis des IT Service Management Systems esmile. Durch eine direkte Datenbankanbin- 309

319 7 Praxisbeispiel: ALTANA Pharma AG dung werden die monatlichen Reporte teilweise auch automatisiert erzeugt. Change Management Aus den genannten Gremien heraus wurden immer wieder Informationen über den Change Management-Prozess benötigt. Die Kennzahlen wurden meistens nach der Bottom-up Methode erstellt, d.h. dort wo der Schuh am meisten drückte. Dies sind mengenorientierte Kennzahlen wie Anzahl RfCs pro Kalenderwoche / Monat (siehe Abbildung 84) / Jahr / Workgroup / Priorisierung / Service # of RfCs Mai 2006 Juni 2006 Juli 2006 August 2006 September 2006 Oktober 2006 November 2006 Dezember 2006 Januar Februar 2007 März 2007 April 2007 Mai 2007 Abbildung 84: Anzahl der RfCs pro Monat (Demo-Daten) um eine Auslastung der Supporteinheiten darzustellen, aber auch Kennzahlen, welche die Prozessqualität beschreiben können wie Status aller RfCs (siehe Abbildung 85) pro Workgroup / Priorisierung / Service Durchlaufzeiten der einzelnen Phasen (Initiierung, Prüfung, Genehmigung, Test, Implementierung, Abschluss) Anzahl RfCs ohne Planungsdatum / ohne CIs / mit mehrmaligem Routing Anzahl nicht implementierter RfCs, bei dem das vorgegebene Datum des Änderungsanforderers überschritten ist Anzahl RfCs mit verknüpften Incidents oder Problems 310

320 7 Praxisbeispiel: ALTANA Pharma AG Rejected Abbildung 85: New Assessed Authorized Development Completed Release to Production Technically Completed User Acceptance Finished Status aller RfCs (Demo-Daten) New 4 2,2% Assessed 1 0,6% Authorized 6 3,3% Development Completed 1 0,6% Release to Production 6 3,3% Technically Completed 3 1,7% User Acceptance 3 1,7% Finished ,9% Rejected 25 13,8% Summe: ,0% Eine Darstellung für die Qualität der erbrachten Leistungen durch einen Change wird durch die Auswertung des Post Implementation Review (PIR) ermöglicht, in dem neben der technischen Umsetzung auch die Zufriedenheit des Kunden abgefragt wird. Ein auch in der ITIL-Literatur beschriebenes Thema ist der Audit. Ähnlich werden Systeme und Verfahren auch im GxP- und SOX-Umfeld auditiert. Hier ist als Kennzahl die Anzahl und Reduzierung der Findings pro Kategorie (Critical, Major, Minor) wichtig. Ausblick Während der Erarbeitung der für ALTANA Pharma angepassten IT Service Management-Prozesse nach ITIL wurden für jeden Prozess auch die Prozessziele angegeben. Durch den Change Management-Prozess wird beispielsweise sichergestellt, dass alle Änderungen an den IT-Systemen notwendig, begründet und getestet sind, dokumentiert sind, hinsichtlich Abhängigkeiten der betroffenen Schnittstellen überprüft sind, auf Basis einer nachvollziehbaren Ressourcenplanung durchgeführt werden, eine transparente Darstellung von Kosten zu Nutzen haben und gegenüber den Anwendern, der Hotline und anderen betroffenen Funktionen kommuniziert werden. 311

321 7 Praxisbeispiel: ALTANA Pharma AG Durch die Etablierung des Change Management-Verfahrens wird den Validierungsanforderungen bezüglich der Änderungskontrolle nachgekommen. Ein nächster Schritt wird sein, diese Prozessziele als Ansatz zu nehmen und Top-down die entsprechenden Kennzahlen und KPIs zu ermitteln und zuzuordnen. Hier werden Informationen wie der Forward Schedule of Changes (FSC) stärker betrachtet werden, da dies ein wichtiges Instrument ist, um eine Planungssicherheit zu haben und frühzeitig über Änderungen informieren zu können. 312

322 8 Praxisbeispiel: Autobahn Tank & Rast GmbH IT Kennzahlensystem der Autobahn Tank & Rast GmbH Gerhard Göttert Leiter Technologie- und Innovationsmanagement Autobahn Tank & Rast GmbH Dienstleister Nr. 1 auf deutschen Autobahnen Die Autobahn Tank & Rast ist der führende Anbieter von Services und Dienstleistungen entlang der Autobahn in Deutschland: Rund 500 Millionen Gäste besuchen jedes Jahr die Servicebetriebe der Tank & Rast. Mit seinen Pächtern betreibt das Unternehmen rund 340 Tankstellen und rund 370 Raststätten (einschließlich ca. 50 Hotels). Durchschnittlich alle 60 Autobahnkilometer finden Kunden eine Tank- und Raststätte des Unternehmens. Autobahn Tank & Rast: Auftanken und Abschalten 1998 hervorgegangen aus einer bundeseigenen Gesellschaft, hat sich das Unternehmen mit seinen rund 720 Servicebetrieben zu einem Dienstleister entwickelt, der in Kundenbefragungen ein Höchstmaß an Anerkennung genießt. Tankstellen, Raststätten und zahlreiche Shops stehen den Autobahn-Reisenden sieben Tage die Woche rund um die Uhr zur Verfügung. Bestnoten vor allem in der Wertung Gastronomie und Service in europaweit durchgeführten Tests des ADAC bestätigen immer wieder die Leistungen der Tank & Rast. Gründe für die Entwicklung eines IT Kennzahlensystems Die Entwicklung der T&R wird von einer Vielzahl technologischer Projekte begleitet. Wesentlichen Einfluss auf den Projekterfolg haben dabei die benötigten IT-Services. Die Herausforderungen für das IT-Management sind, die verfügbaren Ressourcen und Mittel effektiv und effizient einzusetzen. Dabei stehen Flexibilität, Innovationsstärke und Wirtschaft- 313

323 8 Praxisbeispiel: Autobahn Tank & Rast GmbH lichkeit im Focus der mittel- und langfristigen Ziele. Um dies zu gewährleisten wurde ein IT-Kennzahlensystem entwickelt, das die Steuerung des IT-Bereichs nach den genannten Kriterien ermöglicht und gleichzeitig eine hohe Transparenz der Prozesse und der Leistungsfähigkeit sicherstellt. Entwicklung eines eigenen IT Kennzahlensystems Die Entwicklung eines IT-Kennzahlensystems ist ein nicht unerhebliches Unterfangen. Dies war dem IT-Management bereits zum Start des Projekts bewusst. Neben der Nutzung des Kennzahlensystems als strategisches Instrument zur Steuerung und Entwicklung des IT-Bereichs, verfolgt das IT-Management auch den Ansatz, das Kennzahlensystem, zumindest teilweise, zur operativen Steuerung des IT-Bereichs zu nutzen. Um größtmöglichen Nutzen zu gewährleisten muss jedes IT-Kennzahlensystem auf die individuellen Anforderungen eines Unternehmens abgestimmt sein. Es ist deshalb nicht sinnvoll, Kennzahlensysteme wie z.b. das Diebold- oder das Brogli-Kennzahlensystem einfach eins zu eins in das Reporting eines Unternehmens zu übernehmen. In Zusammenarbeit mit der Victor GmbH, Bonn, hat Tank & Rast deshalb ein Kennzahlenkonzept entwickelt, das explizit auf die Anforderungen des Unternehmens abgestimmt ist. Dieses Konzept wurde im weiteren Verlauf des Projekts gemeinsam mit der Victor GmbH erfolgreich umgesetzt und implementiert. Die Umsetzung des Projekts erfolgte in folgenden Schritten: Im ersten Step wurden Interviews mit IT-Mitarbeitern aus ausgewählten IT-Serviceeinheiten geführt. In diesem Kreis erfolgte eine Bestandsaufnahme der vorhandenen IT-Kennzahlen, und die Relevanz der einzelnen Kennzahlen für die jeweiligen IT-Serviceeinheiten wurde diskutiert. Dabei stellte die Victor GmbH Kennzahlen aus verschiedenen Kennzahlensystemen, teilweise aus den klassischen aber auch aus neueren Systemen (COBIT) zur Diskussion. Im weiteren Verlauf erfolgten zwei Interviews mit der IT-Leitung. Ziel war die finale Festlegung des zuvor erarbeiteten IT Kennzahlen-Pools. Es wurde für jede Kennzahl geprüft, welchen Mehrwert sie isoliert oder im Verbund weiterer Dimensionen aufweist, für wen sie bestimmt ist, wer für sie verantwortlich ist und wie und wie oft sie gemessen wird. Zur Sicherstellung des strategischen Ziels des neuen Kennzahlensystems, wurde bereits zu diesem Zeitpunkt der Controlling-Bereich der Tank & Rast in das Projekt eingebunden. 314

324 8 Praxisbeispiel: Autobahn Tank & Rast GmbH Das Ergebnis war eine Tabelle mit ca. 35 Kennzahlen, die für die IT der Tank & Rast strategisch und operativ relevant sind. Strukturierung der Kennzahlen anhand der Balanced Scorecard Tank & Rast verfolgte bereits zu Begin des Projekts das Ziel, eine IT Balanced Scorecard zur Steuerung der IT einzusetzen. Eine Herausforderung bestand darin, festzulegen, welche Perspektiven diese BSC haben sollte. Die operative und strategische Nutzung des IT-Kennzahlensystems setzt eine vernünftige Clusterung in valide und zuverlässige Dimensionen des Systems voraus. Diese müssen mit einer sinnvollen Anzahl von Kennzahlen ausgebildet sein. Für das Kennzahlensystem der Tank & Rast wurden folgende Dimensionen auf der obersten Ebene erarbeitet: Finanzdimension Kundendimension Technologie-/Innovationsdimension und die Mitarbeiterdimension. Jede der Dimensionen beinhaltet 4 bis 6 Kennzahlen. Erfahrungen und Ratschläge Mitte 2006 hat Tank & Rast damit begonnen, das IT-Kennzahlensystem zu entwickeln. Innerhalb weniger Monate konnten das notwendige Reporting aufgebaut und in das Berichtswesen der IT integriert werden. Die frühe Einbindung des Unternehmenscontrollings hat sich als sehr sinnvoll und zielführend herausgestellt. Durch die Mitarbeit fand eine Sensibilisierung der Mitarbeiter des Controllings für die IT-Besonderheiten statt. Zudem konnten die Projektbeteiligten beim Aufbau des strategischen Berichtswesens umfassend vom Know-how der Controlling-Mitarbeiter partizipieren. Die fachliche Unterstützung durch die Victor GmbH hat dazu geführt, das Projekt in kurzer Zeit umzusetzen. Die Auswahl der für Tank & Rast sinnvollen Kennzahlen aus den vielen möglichen Werten der bekannten Kennzahlensysteme war eine der wesentlichen Aufgaben der Victor GmbH. Dabei bildeten international anerkannte Kennzahlensysteme die Basis des Auswahlprozesses. Zusätzlich wurde Tank & Rast durch Victor GmbH bei der Einbindung der neuen IT-BSC in die bereits vorhandenen ITIL- Prozesse, insbesondere den Prozess des Service-Level-Managements, unterstützt. Das IT Kennzahlensystem liefert heute verlässliche und zeitnahe Daten. Neben der effizienten Steuerung der IT mit der IT-BSC wurde die Basis geschaffen, die strategische Entwicklung des IT-Bereichs transparent darzustellen. 315

325 9 Praxisbeispiel: Flughafen München Service Management des Flughafens München Michael Zaddach Leiter Servicebereich IT Flughafen München GmbH Zum Autor Michael Zaddach ist Leiter des Servicebereichs IT bei der Flughafen München GmbH. In seinen Verantwortungsbereich fallen die Servicefelder Projekte und Entwicklung, sowie Betrieb & Service und Field-Services für alle IT- und Kommunikationssysteme am Flughafen. Nach dem Abschluss des Studiums der Nachrichtentechnik war M. Zaddach bei Siemens, AEG und debis Systemhaus in verschiedenen Funktionen wie zum Beispiel Systementwicklung, Product-Line-Management, Projektmanagement und Consulting tätig. Bei debis Systemhaus leitete er von eine Business Unit für IT Service Management. In dieser Funktion begleitete er auch viele Outsourcing-Vorhaben von debis Systemhaus. Im Jahr 2000 übernahm er die Leitung der Hauptabteilung Informatik und Kommunikation am Flughafen München. Firmenportrait Am 22. Dezember 2006 hat der Flughafen München den 30-millionsten Passagier des Jahres 2006 begrüßt und damit den Grundstein für eine dauerhafte Präsenz Münchens unter den großen Luftverkehrsdrehscheiben Europas gelegt. Die Planung für das Jahr 2007 ist ebenso ambitioniert und geht von 32,5 Mio. Passagieren aus. Die Erfolgsstory des Münchner Flughafens, die den letzten Höhepunkt im Jahr 2003 mit der Eröffnung des neuen Terminal 2 hatte, geht damit in die nächste Runde. Die Planer arbeiten bereits wieder an neuen Infrastrukturprojekten und reagieren damit auf die weiterhin überproportionalen Steigerungsraten bei Passagieren, Flugbewegungen und beim Frachtaufkom- 317

326 9 Praxisbeispiel: Flughafen München men. Im Jahr 2007 beginnen die Arbeiten an einem neuen Speditionsgebäude und einem weiteren Hotel. Die Planungen zum Bau einer dritten Start- und Landebahn laufen seit Die Flughafen München GmbH rechnet mit der Inbetriebnahme im Jahr Im Eröffnungsjahr werden für den Flughafen München ca. 40 Millionen Passagiere prognostiziert. Der Münchner Flughafen verfügt dann über drei Bahnen mit jeweils 4000 Meter Länge und kann damit die aus dem weiteren Ausbau des Drehkreuzes erwarteten Verkehrssteigerungen bewältigen. Der Erfolg des Münchner Flughafens als Drehkreuz des Südens liegt nicht zuletzt in der starken Verzahnung der Flughafen-Kernprozesse mit unterstützenden IT-Lösungen. So kann dank effizientem IT-Einsatz im Terminal 2 eine kürzeste Umsteigezeit von nur 30 Minuten garantiert werden. Um diesen Wert einhalten zu können, werden Passagier- und Gepäckströme sowie die Umsteigebeziehungen der Passagiere und Crews laufend überwacht und gesteuert. Dazu wurde gemeinsam mit dem Home-Carrier Lufthansa eine interdisziplinäre und unternehmensübergreifende Kontrollzentrale, das HCC (Hub-Control-Center) eingerichtet. Dort laufen alle abfertigungsrelevanten Informationen zusammen und werden über individuelle prozessunterstützende Systeme angezeigt und verarbeitet. So kann frühzeitig auf Abweichungen in den Hub-Prozessen reagiert werden. Verspätungen im Flugzeugumlauf durch Probleme in der Hub- Koordination werden so auf ein Minimum reduziert. Neben dem Flugbetrieb spielt aber auch das so genannte Non-Aviation- Business eine immer größere Rolle. Mit der Vermietung, Verpachtung, Retail-Business, Gastronomie und dem Parken generiert der Airport heute bereits fast die Hälfte seines Gesamtumsatzes. Der Servicebereich IT Der Servicebereich IT des Flughafens versteht sich nicht nur als ICT-Provider für die Flughafengesellschaft, sondern auch für die weiteren am Flughafen ansässigen Unternehmen. So zählen heute über 500 Firmen, wie zum Beispiel Airlines, Speditionen, Behörden und viele weitere Dienstleistungsunternehmen zu den Kunden des Servicebereichs. Die Forderungen nach Qualität und der professionellen Abwicklung der Leistungen bekommen dadurch nochmals einen höheren Stellenwert. Mit 180 Mitarbeitern erwirtschaftet der Servicebereich IT einen Gesamtumsatz von ca. 42 Millionen Euro. Ein Drittel dieser Leistung wird dabei mit Kunden außerhalb der Flughafengesellschaft generiert. 318

327 9 Praxisbeispiel: Flughafen München Der Servicebereich IT des Flughafens München stellt die IT Services auch für externe Kunden mit wachsendem Anteil bereit. Die Organisation des Servicebereichs IT gliedert sich in drei Servicefelder und drei Unterstützungsbereiche, wie in der folgenden Abbildung 86 dargestellt. Servicebereich IT Projekte und Entwicklung ITE Operation & Service ITO Field Service ITF Interne Services ITS Controlling & Sales ITK CIM ITC ITEA - AS Aviation ITEG - AS Ground- Handling ITET - AS Technik ITEP - AS Personal ITES - SAP-CCC und AS Rechnungsw. ITEV - AS Vertrieb ITED - CC-Anwendungsentwicklung ITEC - CC Basistools ITOS -Systems Management ITOP - Plattforms ITOC - Communications ITOR -Rollout Management ITOI - Internal Services Schichtleiter 1 Schichtleiter 2 Schichtleiter 3 Abbildung 86: Organisationsstruktur Flughafen München, Servicebereich IT Zu den Leistungen gehört neben dem Betrieb und dem Service für die eingesetzten Systeme auch die Entwicklung und Implementierung von flughafenspezifischen Applikationen. Die Mengenangaben zu den betriebenen Systemen sind der folgenden Aufstellung zu entnehmen. Betriebene PCs ca Aktive LAN-Anschlüsse ca Telefone FIDS Displays CCTV-Kameras ca Zentrale Server 240 Speicherkapazität (brutto) > 100 TB Applikationen ca

328 9 Praxisbeispiel: Flughafen München Sämtliche Leistungen werden den internen, wie auch den externen Kunden als Full-Services verkauft. Der Servicebereich steht dabei ständig unter dem Druck, die angebotenen Leistungen zu marktüblichen Preisen anzubieten, und muss die Marktfähigkeit über entsprechende Benchmarks nachweisen. Andererseits haben die vereinbarten IT Services häufig hohe Auswirkungen auf die Geschäftsprozesse und die Services der internen und externen Kunden. Daher muss die Servicequalität auf einem sehr hohen Niveau sichergestellt und nachgewiesen werden. Speziell die reibungslose Abwicklung der "just in time"-abfertigungsprozesse am Flughafen verlangt diese hohe Qualität und Stabilität der Leistungen. "Eine hohe Servicequalität zu möglichst geringen Kosten zu erbringen ist die Zielsetzung des Servicebereichs IT. Implementierung des Service Managements Zielsetzung des Service Managements Damit der Flughafen München auch den zukünftigen Anforderungen gerecht werden kann und die erzielten Ergebnisse verbessert werden können, wurden ausgehend von den Unternehmenszielen und der Unternehmensstrategie des Flughafens München die IT-Ziele definiert und dementsprechende Umsetzungsmaßnahmen erarbeitet (siehe Abbildung 87). Zur Effizienzsteigerung wurde ein umfangreiches Optimierungsprogramm durchgeführt, das unter anderem eine Reorganisation des IT-Bereichs und die Implementierung des Service Managements beinhaltete. Die Implementierung des IT Service Management war kein Selbstzweck, sondern ergab sich als Umsetzungsmaßnahme aus der Unternehmensstrategie des Flughafens München. 320

329 9 Praxisbeispiel: Flughafen München Zielsetzung FMG Ideenfindung Zielsetzung IT Maßnahmen IT Umsetzung Frage Wie kann die FMG in Zukunft im Wettbewerb wirtschaftlich bestehen? Mit welchen Mitteln können wir das gesteckte Ziel erreichen? Welche Zielsetzung ergibt sich für den Bereich IT? Welche konkreten Maßnahmen sind zur Zielerreichung erforderlich? Wie erfolgt die Umsetzung? Ergebnis Strategische Neuausrichtung Ergebnisverbesserung Neue Organisation FMG-weit 1000 Ideen aus Workshops Effizienzsteigerung und Generierung zusätzlicher Erlöse zur nachhaltigen Senkung der IT- Kosten um 10% im Konzern 13 Umsetzungsmaßnahmen zur Senkung der Kapitalkosten Fremdleistungen Personalkosten und Erhöhung der Marktdurchdringung Effizienzsteigerung in den Service- Prozessen Verbesserung der Projektabwicklung Systemkonsolidierung Stärkung des Vertriebs Abbildung 87: Von den Unternehmenszielen zu der Umsetzung in der IT Um eine durchgängig hohe Servicequalität zu niedrigen Kosten anbieten zu können, hatte der Servicebereich IT in den letzten Jahren bereits umfangreiche Maßnahmen zur Optimierung der IT Serviceprozesse durchgeführt. Die Ziele waren dabei klar gesteckt. Steigerung der Effizienz in den Serviceprozessen und die Konsolidierung von Systemen auf gemeinsamen technischen Plattformen. In der Konsequenz bedeutete diese Optimierung auch für die Organisation und die Mitarbeiter des Servicebereichs eine gravierende Veränderung. So wurde die Organisation von der rein systemorientierten auf eine prozessorientierte Struktur umgestellt, ein 90- Grad-Schwenk in der Organisation und in den Köpfen aller Beteiligten (siehe Abbildung 88). 321

330 9 Praxisbeispiel: Flughafen München Abbildung 88: Prozessorientierte Sicht des Servicebereichs IT Der Abschied von den Technik-Silos Die Organisationsänderung war dabei kein Selbstzweck, sondern die logische Folge der Konvergenz in der eingesetzten Systemtechnik. Früher gab es zum Beispiel für Anzeigesysteme, Videoüberwachung und die Datenkommunikation vollständig unterschiedliche und voneinander getrennte Systemlandschaften. Heute wachsen diese Welten technisch zusammen. Die Kommunikation der Systeme wird zukünftig einheitlich über das flughafenweite MPLS-Netz abgewickelt. Die Individualität der Systeme zeigt sich nur noch in den eingesetzten Endgeräten und in den verwendeten Applikationen auf Client- und Serversystemen. Eine sehr weit reichende Standardisierung der verwendeten Systemkomponenten ist möglich und wird konsequent durchgeführt. Dies führt zu erheblichen Kostensenkungen beim Einkauf der IT-Infrastruktur, die dann meist nur noch aus Standardkomponenten besteht. Spezialwissen für das Engineering, die Betreuung und den Betrieb von "Silo-Technik" ist in Zukunft immer weniger erforderlich. Die Verfolgung dieser Strategie der konsequenten Standardisierung und Konvergenz bedingt natürlich die Übernahme des Integrationsrisikos und erfordert die entsprechende Integrationskompetenz. Die beteiligten Mitarbeiter müssen sich also von Silo- Spezialisten zu Integrations-Spezialisten entwickeln. Das Wissen in der Breite und die guten Kenntnisse der Standards werden wichtiger als das extrem tiefe Spezialisten-Know-how für individuelle Systeme. 322

331 9 Praxisbeispiel: Flughafen München Die Abkehr von den Silo-Systemen bietet enorme Chancen in der effizienteren Gestaltung der Serviceprozesse. Während früher zum Beispiel die Bereiche Telekommunikation (TK), Anzeigesysteme (FIDS), Videoüberwachung, Office-Systeme und Netzwerk eine eigene Auftragsannahme und eigenes Störmanagement unterhielten, werden in der neuen Struktur alle Aufträge und Störungen vom zentralen Service Desk angenommen und durchgängig bearbeitet. Auch beim Betrieb und bei den Field-Services können erhebliche Synergien erschlossen werden. Die Konvergenz der Systeme und die Konzentration auf standardisierte Plattformen werden damit in der Organisationsstruktur nachvollzogen. Voraussetzung für einen reibungslosen und effizienten Ablauf in der neuen Organisation sind dokumentierte und kommunizierte Prozesse. Und weiterhin erfordert dieser Transformationsprozess für eine zeitgerechte Umsetzung eine klare Definition des angestrebten Zielzustands und einen Endtermin, auf den alle Beteiligten gemeinsam hinarbeiten. Das Prozessmodell und die Verantwortlichkeiten Die strategische Ausrichtung der Prozesse Die Prozessziele werden in regelmäßigen Planungsrunden aus der Strategie abgeleitet und definiert. Durch die Einhaltung der Prozesse ist sichergestellt, dass von der Führungs- bis zur Mitarbeiterebene die IT-Strategie einheitlich verstanden und deren Umsetzung unterstützt wird (siehe Abbildung 89). Die Service Management-Prozesse verbinden die langfristige Ausrichtung des Servicebereichs IT mit der kurzfristigen Zieldefinition und -verfolgung. 323

332 Kunde Finanz Kunde Finanz Prozess Mitarbeiter. Prozess Mitarbeiter. Kunde Finanz Prozess Mitarbeiter. 9 Praxisbeispiel: Flughafen München Strategische Grundausrichtung langfristig (3 5 Jahre) Strategieklausur jährlich Strategieelemente langfristig (3 5 Jahre) Strategische Initiativen Ziele (Führungskräfte) Quartalsreview mittelfristig (1-3 Jahre) kurzfristig (1 Jahr) bezogen auf Meilensteine der Initiativen Maßnahmenpläne Ziele (Mitarbeiter) Projektmonitoring, Mitarbeitergespräche kurzfristig (1 Jahr) kurzfristig (1 Jahr) Abbildung 89: Ausrichtung der Prozesse an der IT-Strategie Skill-Management und Soft Factors In einem Unternehmen mit einer etablierten IT und akzeptierter Qualität sind die Implementierung von ITIL-Prozessen und die Zertifizierung nach ISO nicht ohne weiteres einzusehen. Dies gilt sowohl für die Mitarbeiter des IT-Bereichs, als auch für die Kunden. Es werden immer wieder Fragen gestellt, wie zum Beispiel: "... was haben wir denn falsch gemacht, dass nun alles geändert wird?", oder "... wer soll denn die Zusatzkosten für diesen ganzen Overhead zahlen?". Die besondere Herausforderung liegt an dieser Stelle sicherlich darin, von Beginn der Planungen an die Mitarbeiter intensiv an dem Prozess zu beteiligen und immer wieder Erfordernisse, angestrebte Ziele und die Verbesserungspotenziale zu verdeutlichen. Aus diesem Grund wurde bereits zu Beginn des Projekts ein Team aus 15 Mitarbeitern den späteren Process Ownern eingesetzt. Gemeinsam wurden die Vorgaben und Rahmenbedingungen festgelegt und vom Groben ins Feine entwickelt. Schnittstellen wurden diskutiert und beleuchtet und in ihrem bürokratischen Aufwand reduziert. Die Mitarbeiter wurden dabei extern begleitet und unterstützt. Aber für die Entwicklung waren die Mitarbeiter des Servicebereichs IT verantwortlich, der externe Dienstleiter nahm die Rolle eines Coachs ein und war für den notwendigen Wissenstransfer verantwortlich. Der folgenden Abbildung 90 können die im Servicebereich IT implementierten Service Management-Prozesse entnommen werden. 324

333 9 Praxisbeispiel: Flughafen München Abbildung 90: Die Prozesslandkarte des Servicebereichs IT Für die Definition und Beschreibung der Prozesse wurde das folgende Vorgehen definiert: Prozesse werden generisch gestaltet Rollen und Verantwortlichkeiten werden festgelegt Verzahnung der Prozesse über Schnittstellen Über ein Kennzahlensystem erfolgt die Messung der Prozesse Die Ergebnisse der Prozesssteuerung fließen in einen kontinuierlichen Verbesserungsprozess ein Die Vorgehensweise zur Inbetriebnahme der Prozesse erfolgte wie folgt: Erarbeitung der Prozesse gemäß Vorgaben Freigabe der Prozessdokumentation durch den IT-Qualitätsbeauftragten Veröffentlichung der Prozesse im ITSM-Portal im Intranet Ausbildung der Mitarbeiter Leben der Prozesse Internes Audit als Vorbereitung auf die Zertifizierung Externes Audit mit der Zertifizierung gemäß ISO

334 9 Praxisbeispiel: Flughafen München Die Prozesse wurden vom Projektteam so dokumentiert, dass sie die tägliche Arbeit der Mitarbeiter unterstützten, aber wann immer sinnvoll trotzdem eigenverantwortliche Handlungsspielräume zulassen und vor allem die Kompetenz der Mitarbeiter berücksichtigen. Die Grundsätze der Transparenz, Wirtschaftlichkeit und Zielstrebigkeit im Sinne des Kunden standen dabei immer im Mittelpunkt. Vorgabe der Prozessentwicklung war es, nicht in einen ARIS Rausch zu verfallen, sondern einerseits so viel Prozessdokumentation wie nötig zu erstellen, andererseits aber so viel Eigenständigkeit und Serviceorientierung wie möglich zuzulassen. Die zu implementierenden Prozesse und deren Dokumentation sollten als Leitplanken verstanden werden, die den Mitarbeitern die notwendige Sicherheit und Entscheidungskompetenz geben, aber den Handlungsspielraum nicht unnötig einengen sollen. Der Servicebereich IT wird auch weiterhin von der Leistungsbereitschaft und Serviceorientierung der Mitarbeiter getragen. Die Prozessdurchführung und der kontinuierliche Verbesserungsprozess Alle Mitarbeiter des Servicebereichs IT haben einen Zugriff auf das ITSM- Portal und können über dieses Portal auf die Prozessdokumentation, Arbeitsanweisungen, Templates und weitere unterstützende Dokumentation zugreifen (siehe Abbildung 91). Den Mitarbeitern des Servicebereichs IT wurde im Rahmen der Trainings und Einweisungen verdeutlicht, dass sie wenn nötig auch vom vorgegebenen Prozess abweichen dürfen. Dann besteht allerdings die Verpflichtung zu erläutern, warum die abweichende Durchführung notwendig war, und zu definieren, wie der Prozess zukünftig entsprechend anzupassen ist. Dieses Feedback aus der praktischen Prozessdurchführung ist ein wichtiger Input in den kontinuierlichen Verbesserungsprozess (Prozess Improvement-Plan). 326

335 9 Praxisbeispiel: Flughafen München Abbildung 91: Das ITSM-Portal des Servicebereichs IT Trainings Um die Mitarbeiter in die Lage zu versetzen, die ITIL Prozessanforderungen auf den Servicebereich IT zu adaptieren, galt es in einer ersten Trainingsphase den Process Ownern und deren Mitarbeiter die notwendigen ITIL Best Practices zu vermitteln. Prozesse können nur dann erfolgreich implementiert werden, wenn die beteiligten Mitarbeiter die Notwendigkeit dieser Prozesse, deren Aktivitä- 327

336 9 Praxisbeispiel: Flughafen München ten, Abhängigkeiten und Schnittstellen verstehen. In einer zweiten Phase wurden hierzu alle Mitarbeiter des Servicebereichs ausgebildet. Für die Durchführung dieser Trainings war es wichtig, dass die Dozenten nicht nur über das theoretische Know-how verfügten, sondern auch praktische Umsetzungsbeispiele vermitteln konnten. Das Trainingsprogramm für die Mitarbeiter des Servicebereichs IT hatte den folgenden Umfang: - ITIL-Foundation Trainings für alle Mitarbeiter des Servicebereichs mit abschließender Prüfung, durchgeführt vom beratenden Unternehmen - Prozesstrainings für alle Prozess-Manager und die weiteren betroffenen Mitarbeiter mit dem Ziel, ein einheitliches Verständnis für die implementierten Prozesse zu erreichen, durchgeführt von den Process Ownern - ITSM-Praxistrainings mit Fallbeispielen und Toolnutzung für die Prozesse Incident-, Problem- und Change-Management, durchgeführt von den Process Ownern und Prozess-Managern Die ISO IT Service Management Obwohl die Zertifizierung nach der ISO des Servicebereichs IT zunächst nicht im Fokus der Zielsetzung stand, hat der klare Zieltermin und der klar definierte Umfang der Zertifizierung allen Beteiligten enorm geholfen. Bei einer solch umfassenden Neugestaltung der Prozesslandschaft besteht die Gefahr, dass man sich sonst in den Tiefen der Prozessgestaltung verliert. Die Zertifizierung hilft in diesem Zusammenhang zur Einhaltung einer pragmatischen Flughöhe und zwingt zur rechtzeitigen Landung. Als Motivationsfaktoren für eine ISO Zertifizierung findet man in der Literatur häufig die folgenden Gründe: Verbesserung der Qualität der Services und dadurch verbessertes Vertrauen der Kunden in die IT-Abteilung Verbessertes Ansehen sowie Verbesserung der Stabilität und Zusammenarbeit Transparente Darstellung der Leistungsfähigkeit Ihrer IT bestätigt durch einen unabhängigen Dritten (Zertifizierer) Manager und Mitarbeiter erhalten ein besseres Verständnis für das Geschäft, die Rollen und die Verantwortlichkeiten Die genannten Gründe trafen für den Servicebereich IT des Flughafens München nur eingeschränkt zu. Der Hauptgrund lag in der gewünschten 328

337 9 Praxisbeispiel: Flughafen München Effizienzsteigerung des Servicebereichs IT und einer angestrebten Prozessorientierung der gesamten Organisation. Da der Servicebereich IT nicht nur intern Leistungen erbringt, wurde die Definition des Scopes der ISO Zertifizierung bereits zu Beginn der Planungen auf das gesamte Leistungs- und Kundenspektrum bezogen. Die Scope-Definition lautet daher: "The IT Service Management System that supports the provision of IT services to internal and external customers of Flughafen Muenchen GmbH" Und wenn zum Zertifizierungsdatum noch nicht alles perfekt ist? Die Zertifizierung nach der ISO umfasst grundsätzlich immer die gesamte in der Norm definierte Prozesslandschaft mit den in der Norm definierten Mindestanforderungen an den jeweiligen Prozess. Dieser sehr große Umfang stellt für viele Organisationen eine große Hemmschwelle dar und die Frage liegt nahe: "Wie ist denn eine Vorbereitung auf diesen Umfang in passabler Zeit machbar und wie bringt man dann auch die Prozesse in diesem Umfang zum "Leben"?". Prozess-Kennzahlen und Prozesssteuerung Eine wesentliche Komponente der Prozessdefinitionen und der Prozesssteuerung stellt die Festlegung von Kennzahlen (KPIs) und deren Controlling dar. Die Kennzahl soll Schlüsselindikator für die Leistungsfähigkeit des Prozesses sein und Messgrößen liefern, die anzeigen, wie schnell und zu welchem Grad störungsfrei ein Prozess abläuft. Besonders hier ist jedoch zu beachten, dass jede definierte Kennzahl erhoben werden muss und auch interpretiert werden will, um als Steuerungsinformation einen Nutzen zu liefern, d.h. entsprechende Messindikatoren sind zu implementieren. In der Euphorie der Prozessdefinition werden gerne Kennzahlen definiert, die beiden Kriterien nicht gerecht werden. In der Praxis hat sich im Servicebereich IT gezeigt, dass die Anzahl der ursprünglich definierten Kennzahlen nach einem Jahr um etwa 50 % reduziert wurde. Weiterhin ist nicht jede Kennzahl auf jeder Organisationsebene gefragt. So ist zum Beispiel die Anzahl der geöffneten und geschlossenen Problem- Records je Prioritätsklasse" für den Process Owner Problem-Management und seinen Linienverantwortlichen von großem Interesse, jedoch weniger für die Geschäftsführung des Unternehmens. Die folgende Tabelle (Abbildung 92) zeigt einen Auszug der ersten Ebene der Prozess-Kennzahlen: 329

338 9 Praxisbeispiel: Flughafen München Abbildung 92: Auszug der ersten Ebene der Kennzahlen des SB IT Im Rahmen der jährlichen IT-Strategie werden konkrete Prozessziele und die Sollwerte für die einzelnen Kennzahlen mit dem Process Owner festgeschrieben. Der Prozess Improvement-Plan Im Laufe der Vorbereitung auf die Zertifizierung wird sehr schnell klar, dass es viele Prozessdetails gibt, die eine gewisse Reifezeit brauchen, bis sie in der Organisation wirklich umgesetzt sind und Wirkung zeigen. Zum Zeitpunkt der Zertifizierung wird in den meisten Unternehmen noch nicht alles absolut perfekt laufen. Diese Erfahrung hat auch der Servicebereich IT des Flughafens München gemacht. Um dennoch zertifizierungsfähig zu sein, ist zum Zeitpunkt der Zertifizierung eine klare Aussage zur Weiterentwicklung der Prozesse und 330

339 9 Praxisbeispiel: Flughafen München die Definition von angestrebten Zielzuständen erforderlich; der so genannte Prozess Improvement-Plan (Schema siehe Abbildung 93). Prozess: Problem-Management Datum: Freigabe (FK1 / FK2): Definierte Einschränkungen: Werden die Zielzeiten bei Incidents überschritten erfolgt noch nicht zwingend die Analyse mittels Problem-Management Maßnahmen- und Zeitplan für die Erhöhung des Abdeckungsgrades und zur Verbesserung der inhaltlichen Ausgestaltung: Maßnahme Ziel Zieldatum Verantwortlicher Ausweitung der Problem-Management Einbindung aller Mitarbeiter in den Prozess-Owner, Prozess-Manager Verfahren auf den gesamten Bereich IT Prozess Problem-Management Schulungen aller IT-Mitarbeiter über die Inhalte und Arbeitsanweisungen zum Problem-Management Einbindung aller Mitarbeiter in den Prozess Problem-Management Prozess-Owner, Prozess-Manager Arbeitsanweisung zum Problem- Management erweitern um Vor-gehen bei Zielzeitüberschreitungen von Incidents zu berücksichtigen Sicherstellen daß Known Errors und Workarounds für die Incident- Bearbeitung zur Verfügung gestellt werden Prozess-Owner, Prozess-Manager Verbesserungen am ARS-Tool und ARS- Masken Vereinfachtes Bearbeiten und Erhöhung der Akzeptanz Prozess-Owner, Prozess-Manager Abbildung 93: Auszug aus dem Service Improvement-Plan des SB IT In diesem Plan sind für jeden Prozess, die zum Zertifizierungstermin getroffenen und bekannten Einschränkungen hinsichtlich der Prozess Implementierung zu beschreiben und der Plan für die Weiterentwicklung der Prozesse mit klaren Zielen, Terminen und Verantwortlichkeiten zu hinterlegen. Aber Vorsicht! Im Zuge der Vorbereitung auf die Zertifizierung arbeiten alle beteiligten Mitarbeiter mit einer sehr hohen Intensität und Euphorie an dem Thema. Dieser Aufwand ist in der späteren betrieblichen Praxis im Rahmen des kontinuierlichen Verbesserungsprozesses nicht zu halten. Bei der Definition des Prozess Improvement-Plans besteht daher die potentielle Gefahr, dass die Messlatte für die angestrebten Ziele zu hoch gelegt wird und nach kurzer Zeit die Enttäuschung einsetzt, weil eine Zielerreichung aufgrund von Aufwandslimitierungen nicht möglich ist. 331

340 9 Praxisbeispiel: Flughafen München Der ITSM-Maßnahmenkatalog Auch nach der Zertifizierung werden viele neue Erkenntnisse in Hinblick auf eine Verbesserung oder Abrundung der definierten Prozesse aufkommen. Um diese Informationen von Mitarbeitern und weiteren Prozessbeteiligten konsequent verfolgen zu können, ist ein strukturiertes Vorgehen erforderlich. Der Servicebereich IT hat dazu eine Datenbank realisiert, in der alle Probleme, Änderungs- und Erweiterungsanforderungen erfasst und überwacht werden. Das Qualitätsmanagement hat in diesem Kontext die Aufgabe des Moderators übernommen und hinterfragt die geforderten Aspekte, definiert gemeinsam mit den Linienverantwortlichen die Verantwortlichkeiten für die Maßnahmenbearbeitung, überprüft die Zielerfüllung und eskaliert ggf. bei Terminüberschreitungen. Ein Reporting über den Bearbeitungsstatus der Maßnahmen an das Bereichsmanagement erfolgt einmal im Quartal, an die direkten Linienverantwortlichen monatlich. Erfolge Die Erfolge der konsequent verfolgten Strategie sprechen bereits jetzt für sich. In den letzten drei Jahren konnte der Faktor IT-Kosten zum Umsatz des Unternehmens um fast 1,4%-Punkte verbessert werden. Sowohl die Kosten für die eingesetzten Systeme, als auch die Kosten für Fremdleistungen konnten bei gleich bleibender Personalkapazität erheblich reduziert werden. Die IT-Organisation der Flughafen München GmbH hat als fünftes deutsches Unternehmen und als erster Flughafen weltweit ein ISO Zertifikat erhalten und weist damit seine exzellente Servicequalität aus. Speziell für neue Kunden, die die Qualität und Leistungsfähigkeit des Servicebereichs IT noch nicht beurteilen können und den Zusicherungen vertrauen müssen, ist die Zertifizierung und damit Nachweis des Service Managements ein wichtiger Indikator für die Servicequalität. Der Anteil des externen Geschäfts konnte auch in 2006/2007 weiter gesteigert werden. Aus diesem Grund hat sich der Flughafen entschlossen, innerhalb des SB IT eine neue Business-Unit für externes Geschäft zu gründen, um Leistungen im Airport-Sektor, aber auch an andere Unternehmen mit Campus-Charakter anzubieten und den Anteil an externer Leistung weiter auszubauen. Dies ist eine gute Perspektive für weiteres wirtschaftliches Wachstum des Münchner Flughafens und für die Umsetzung neuer innovativer Ideen für den Airport der Zukunft. 332

341 10 Praxisbeispiel: VOSS Gruppe IT Management Report der VOSS Gruppe Gottfried Weibler Leiter Informationstechnologie VOSS Automotive GmbH Firmenportrait VOSS ist eine mittelständische Unternehmensgruppe mit Stammsitz in Wipperfürth. Unter dem Dach der VOSS Holding betreuen die organisatorisch eigenständigen Unternehmen VOSS Automotive und VOSS Fluid, unterstützt von zehn Auslandsgesellschaften, die internationalen Märkte von Fahrzeug- und Maschinenbau. Die VOSS Gruppe beschäftigt ca Mitarbeiter. VOSS ist einer der führenden Systempartner für Leitungs- und Verbindungstechnik im internationalen Fahrzeug- und Maschinenbau und versteht sich als kompetenter Entwicklungspartner seiner Kunden. Ergebnis der Entwicklungspartnerschaft sind maßgeschneiderte Lösungen der Leitungsauslegung, der Leitungsführung und der Verbindungstechnik. Dies gilt für Pneumatik, Hydraulik, Kraftstoff- und Klimasysteme, insbesondere auch für Anwendungen im Serienfahrzeug von morgen, wie etwa Brennstoffzellen oder CO2-Klimaanlagen. In der Automobilindustrie hat VOSS Automotive als technischer Dienstleister nachhaltig den Stand der Technik geprägt, z.b. in der Verbindungstechnik für die Druckluftbremse in Nutzfahrzeugen und für die Luftfederung in PKW. Als einer der führenden Anbieter hydraulischer Verbindungstechnik ist VOSS Fluid ein international gefragter Partner. Im engen Kundenkontakt optimiert VOSS Fluid die Verbindungsauslegung der Hydraulik und übernimmt damit wesentliche Aufgaben innerhalb der gesamten Hydrauliksysteme. Durch ein Komplettprogramm in der Rohrverschraubung wird unser Anspruch, den Kunden ein umfassendes Lieferprogramm zu bieten, erweitert. Darüber hinaus liefert die VOSS Fluid weitere Komponenten 333