ITIL Erfahrungsberichte

Erfahrungen mit der Umsetzung von ITIL-Empfehlungen in den Bundesbehörden

Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung

Schriftenreihe der KBSt

Band 94

April 2007

Seite 1 von 54

Publikation der KBSt

Nachdruck, auch auszugsweise, ist genehmigungspflichtig

Dieser Band wurde erstellt von der KBSt im Bundesministerium des Innern in Zusammenarbeit mit HiSolutions AG

Redaktion: HiSolutions AG, Berlin

Interessenten erhalten die derzeit lieferbaren Veröffentlichungen der KBSt und weiterführende Informationen zu den Dokumenten beim

Bundesministerium des Innern

Referat IT 2 (KBSt)

11014 Berlin

Homepage der KBSt: www.kbst.bund.de

E-Mail: IT2@bmi.bund.de

Seite 2 von 54

ITIL Erfahrungsberichte

Erfahrungen mit der Umsetzung von ITIL-Empfehlungen in den Bundesbehörden

Version 1.0

Herausgegeben vom Bundesministerium des Innern

Seite 3 von 54

Inhaltsverzeichnis

1 Einleitung....................................................................................................................7

1.1 Zielsetzung ...........................................................................................................8

1.2 Zielgruppen...........................................................................................................9

1.3 Dokumentaufbau ..................................................................................................9

1.4 Hinweise zum Inhalt............................................................................................10

2 Veränderungsprozesse in der Bundesverwaltung ................................................11

3 Ausgangssituation und Zielstellungen für die Umsetzung von ITIL-Prozessen.14

3.1 Kundenorientierte Ausrichtung der IT-Organisation............................................15

3.1.1 Unzureichende Qualität in der Anwenderbetreuung ...............................15 3.1.2 Serviceangebote für andere Behörden ...................................................15 3.1.3 Paradigmenwechsel von der übersteuerten zur auftragsgesteuerten IT.16

3.2 Restrukturierung der IT-Organisation .................................................................16

3.2.1 Bündelung von Behörden .......................................................................16 3.2.2 Standortwechsel der IT-Organisation .....................................................17

3.3 Konsolidierung der IT und Outsourcing ..............................................................17

3.3.1 Konsolidierung der Infrastruktur..............................................................17 3.3.2 Aufwandssenkung in der Leistungserstellung.........................................18 3.3.3 Outsourcing und Steuerung externer Dienstleister .................................18

3.4 Technologiewechsel in der IT-Landschaft ..........................................................19

3.5 Fazit....................................................................................................................19

4 Erwartungen, Strategien und Umsetzungsschwerpunkte ....................................21

4.1 Erwartungen der IT-Leitung ................................................................................21

4.1.1 Verbesserung der Service-Qualität .........................................................21 4.1.2 Verbesserung der Service-Effizienz........................................................22 4.1.3 Verbesserung der Service-Transparenz .................................................22

4.2 Strategien und Umsetzungsschwerpunkte .........................................................23

4.2.1 (A) Professionalisierung der Anwenderbetreuung ..................................23 4.2.2 (B) Standardisierung der IT-Services......................................................25 4.2.3 (C) Konsolidierung und Optimierung des IT-Betriebs .............................26 4.2.4 Fazit ........................................................................................................26

5 Vorgehen und Umsetzungserfahrungen ................................................................28

5.1 Vision..................................................................................................................28

5.1.1 Einbindung der IT-Leitung und Unterstützung des Veränderungsprozesses ........................................................................28

Seite 4 von 54

5.1.2 Formulierung der Vision..........................................................................29 5.2 Standortbestimmung...........................................................................................31

5.3 Zieldefinition .......................................................................................................32

5.3.1 Einführung von Managementgrundsätzen ..............................................34 5.3.2 Standardisierung der IT-Prozesse ..........................................................34 5.3.3 Effizienzsteigerung .................................................................................35 5.3.4 Servicestandardisierung .........................................................................35 5.3.5 Anforderungen aus neuen IT-Prozessen ................................................36 5.3.6 Sicherstellung der Support- und Delivery-Aufgaben ...............................36 5.3.7 Optimierung der Outsourcing-Schnittstelle .............................................36 5.3.8 Standardisierung in der IT.......................................................................37 5.3.9 Erwartungen der IT-Leitung an das Vorgehen ........................................38 5.3.10 Einbindung der Kunden und Dienstleister...............................................38

5.4 Planung und Umsetzung ....................................................................................38

5.4.1 Verbindlichkeit der ITIL-Empfehlungen...................................................38 5.4.2 Organisation des Umsetzungsprojekts ...................................................39 5.4.3 Schwerpunkte und Umfang des Umsetzungsprojekts ............................40 5.4.4 ITIL-Ausbildung.......................................................................................41 5.4.5 Einheitliches Begriffsverständnis ............................................................43 5.4.6 Prozesseigentümer und Prozessverantwortlicher...................................44 5.4.7 Rollendefinition .......................................................................................45 5.4.8 Gestaltung und Dokumentation der Prozesse ........................................45 5.4.9 Einsatz von Beratern in der Umsetzung..................................................47 5.4.10 Einsatz von Werkzeugen im IT-Service Management ............................48

5.5 Kontrolle .............................................................................................................49

6 Erreichung der Ziele.................................................................................................50

7 Weiterentwicklung der Maßnahmen .......................................................................51

8 Kontakte....................................................................................................................52

8.1 Ansprechpartner der befragten Bundesbehörden...............................................52

8.2 Ansprechpartner der Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik (KBSt)....................................................................................52

9 Glossar......................................................................................................................53

Seite 5 von 54

Tabellenverzeichnis Tabelle 1: Glossar ..........................................................................................................54

Abbildungsverzeichnis Abbildung 1 Triebkräfte für die ITIL-Umsetzung in den befragten Bundesbehörden ......14

Abbildung 2 Optimierung der Leistungsfähigkeit der IT (Quelle: HiSolutions AG) ..........20

Abbildung 3 Erwartungen an das IT-Service Management ............................................21

Abbildung 4 Einführungsstrategien für das IT-Service Management..............................23

Abbildung 5 Methodik der IT-Service-Management-Einführung (Quelle: OGC) .............28

Seite 6 von 54

1 Einleitung In der Bundesverwaltung besteht ein grundsätzlicher Bedarf für den Austausch praktischer Umsetzungserfahrungen bei der Implementierung der IT-Service-Management-Prozesse gemäß ITIL-Empfehlungen. Das Ziel besteht darin, die bestehenden Praxiserfahrungen zu multiplizieren und damit Chancen schneller zu nutzen sowie Risiken früher zu erkennen. Dabei sollte berücksichtigt werden, dass »

»

»

»

» » » » »

» » »

es durchaus viele Gemeinsamkeiten, aber auch Unterschiede zwischen den Bundesbehörden gibt, was die Ausgangssituation und die Ziele für die Implementation eines IT-Service Managements betrifft, die Schwerpunkte und das Vorgehen für die Einführung häufig ähnlich aber in konkreten Fällen auch sehr unterschiedlich sind, die Einführung durchgängiger IT-Prozesse und ihre Ausrichtung auf Kunden- und Serviceorientierung überwiegend eine komplexe organisatorische Aufgabe darstellt und die besonderen Anforderungen und Rahmenbedingungen in der Bundesverwaltung häufig spezifische Fragen aufwerfen, die mit den branchenneutralen ITIL-Empfehlungen mitunter nicht klar beantwortbar sind.

Um so wichtiger erscheint hier ein wirksamer Austausch bestehender Erfahrungen, um Synergien zu nutzen und eine wirtschaftliche Umsetzung zu ermöglichen. Im Jahr 2005 hat die KBSt eine schriftliche Befragung zum Stand der ITIL-Umsetzung durchgeführt, an der sich ca. 70 Bundesbehörden aktiv beteiligt haben. Hier wurde auch der Wunsch nach einem effektiven Erfahrungsaustausch zum Ausdruck gebracht. Daraufhin hat die KBSt u.a. beschlossen, diesen Erfahrungsaustausch zu fördern. Eines der Ziele bestand darin, das intensivere Gespräch mit Bundesbehörden zu suchen, die bereits umfassendere Maßnahmen in der Implementation eines IT-Service Managements durchgeführt haben. Hierzu wurden vertiefende Interviews geplant und durchgeführt, an denen sich folgende Behörden beteiligt haben:

Bundesministerium des Innern (BMI) Bundesverwaltungsamt / Bundesstelle für Informationstechnik (BVA / BIT) Bundesanstalt für Wasserbau, Fachstelle der WSV für Informationstechnik (BWA) Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit (BMU) Zentrum für Informationsverarbeitung und Informationstechnik in der Bundesfinanzverwaltung (ZIVIT)

Struktur, Aufgaben und Größe der IT-Organisation in den befragten Bundesbehörden sind sehr unterschiedlich. Die Befragung sollte verschiedene Perspektiven berücksichtigen, insbesondere die Erwartungshaltung und Einbindung der IT-Leitungsebene, die Planung und Steuerung der Umsetzungsvorhaben, als auch die Erfahrungen und Ergebnisse in der Umsetzung konkreter Prozesse. Deshalb wurden die Interviews geführt mit

der IT-Leitung dem Koordinator bzw. Projektleiter für die Service-Management-Umsetzung und den Verantwortlichen für ausgewählte Service-Management-Prozesse

Seite 7 von 54

Neben Fragen zur grundsätzlichen Herangehensweise an die Einführung wurde der Schwerpunkt auf folgende Service-Management-Disziplinen gelegt, sofern diese Gegenstand der Einführung waren: » » » »

»

Service Desk (Zentrale Schnittstelle der IT-Organisation zum IT-Anwender) Incident und Problem Management (Behebung von Störungen und deren Ursachen) Change Management (Planung und Durchführung von Änderungen) Configuration Management (Bereitstellung und Management der Konfigurationsdaten) Service Level Management (Management der IT-Services, damit verbundener Qualitätszusagen und entsprechender Servicevereinbarungen mit Kunden)

Die Ergebnisse sind in diesem Dokument zusammengefasst.

1.1 Zielsetzung Was dieses Dokument erreichen kann. Ziel dieser Veröffentlichung ist es, die diskutierten Erfahrungen allen Bundesbehörden in zusammengefasster und strukturierter Form zur Verfügung zu stellen. Hierbei wird vermieden, pauschale Empfehlungen auszusprechen. Mit Blick auf die mitunter recht besonderen Ziele und Rahmenbedingungen für eine Umsetzung im konkreten Fall sollen vielmehr solche Fragen aufgeworfen werden, die aus der Erfahrung der befragten Bundesbehörden im Rückblick einen besonderen Einfluss auf den Umsetzungserfolg hatten. In vielen Fragen ähneln sich die Erfahrungen, insbesondere was die kritischen Erfolgsfaktoren und die wesentlichen Projektrisiken betrifft. Mitunter wurden aber auch in konkreten Umsetzungsfragen auf unterschiedlichen Wegen positive Erfahrungen gesammelt, die durchaus Anregungen für alternative Entscheidungen liefern können. Deshalb sind die hier zusammengefassten Aspekte nicht mehr und nicht weniger als eine Anregung, sich mit den bestehenden Erfahrungen auseinanderzusetzen und daraus Schlussfolgerungen für die Umsetzung in der eigenen Organisation zu ziehen. Hierfür sollen Impulse geliefert werden. Gleichzeitig soll die Aufmerksamkeit auf besonders kritische Fragen gelenkt werden, die immer wieder als Stolperstein in konkreten Projekten sichtbar wurden. Zudem soll auch der Zugang zu konkreten Ansprechpartnern ermöglicht werden, die für einen direkten Erfahrungsaustausch mit anderen Bundesbehörden zur Verfügung stehen. Was dieses Dokument nicht erreichen kann. Das Dokument ersetzt nicht die intensive Auseinandersetzung mit den konkreten Implementationsanforderungen. Es liefert auch keine allgemeingültigen Vorgehensmodelle, Einführungsleitfäden oder Entscheidungsvorlagen.

Seite 8 von 54

1.2 Zielgruppen Das Dokument wendet sich an alle IT-Organisationen der Bundesverwaltung, die konkrete Umsetzungsmaßnahmen durchgeführt haben, derzeit durchführen oder aber solche planen. Sie sollen mit diesen Inhalten zum Dialog angeregt werden. Die Informationen sind relevant für

»

»

»

»

IT-Leiter, die das IT-Service Management als Instrument für die serviceorientierte Ausrichtung ihrer IT-Organisation bzw. für die Steuerung externer IT-Dienstleister einführen und Anforderungen an eine effektive und effiziente Umsetzung stellen, IT-Organisatoren und Projektleiter in den Umsetzungsprojekten, die ein geeignetes Vorgehen entwickeln und die Projektziele und –risiken angemessen formulieren, IT-Prozessverantwortliche, die ihre Prozesse auf der Grundlage konkreter Ziele und Rahmenbedingungen etablieren, IT-Revisoren, die Planung, Verlauf und Wirksamkeit der Umsetzungsprojekte verfolgen und prüfen.

1.3 Dokumentaufbau Das Dokument umfasst folgende Kapitel: Kapitel 2: Veränderungsprozesse in der Bundesverwaltung

Dieses Kapitel beschreibt wesentliche aktuelle Triebkräfte für die Einführung des IT-Service Managements in den Bundesbehörden.

Kapitel 3: Ausgangssituation und Zielstellung für die Umsetzung von ITIL-Prozessen Dieses Kapitel beschreibt, welch ähnliche und unterschiedliche Situationen Ausgangspunkt für Umsetzungsentscheidungen in den befragten Bundes-behörden waren und welchen Einfluss dies auf die konkreten Ziele der Implementation hatte.

Kapitel 4: Erwartungen, Strategien und Umsetzungsschwerpunkte Dieses Kapitel beschreibt, welchen Fokus die Bundesbehörden für die Um-setzung von ITIL-Empfehlungen gesetzt haben, um die konkreten Heraus-forderungen zu bewältigen.

Kapitel 5: Vorgehen und Umsetzungserfahrungen Dieses Kapitel beschreibt, welche Fragestellungen sich im Verlauf der Um-setzung aus sicht der befragten Behörden als wesentlich herausgestellt ha-ben.

Kapitel 6: Erreichung der Ziele Dieses Kapitel fasst zusammen, in welcher Weise die gesetzten Ziele er-reicht werden konnten und worin Abweichungen bestanden.

Kapitel 7: Weiterentwicklung der Maßnahmen Dieses Kapitel liefert einen Ausblick auf die gegenwärtigen und künftigen Weiterentwicklungsmaßnahmen in den befragten Bundesbehörden.

Kapitel 8: Ansprechpartner der befragten Bundesbehörden

Seite 9 von 54

Kapitel 9: Glossar

1.4 Hinweise zum Inhalt Das Dokument hebt bestimmte Aussagen in Blöcken hervor, die wie folgt zu interpretieren sind:

Beispiel Aussagen werden anhand eines konkreten Falles aus der Gruppe der befragten Bundesbehörden erläutert.

! Hinweis Die Aussagen werden durch Hinweise der Redaktion ergänzt, die über

die über die besprochenen Erfahrungen hinaus Gültigkeit haben.

? Frage Die Aussagen und Hinweise werden durch Fragen abgerundet, die dem

Leser helfen sollen, die Wirksamkeit in der eigenen Organisation zu hinterfragen?

Seite 10 von 54

2 Veränderungsprozesse in der Bundesverwaltung ITIL beschreibt den Weg und das Ziel für eine serviceorientierte Gestaltung der IT-Or-ganisation. Dafür liefert ITIL nicht nur Empfehlungen, die sich in der Praxis bewährt ha-ben. ITIL standardisiert auch Begriffe und unterstützt ein einheitliches Prozessverständ-nis innerhalb der IT-Organisation. Wenn es also darum geht, eine gemeinsame Sprache in der IT zu finden, dann kann hier der ITIL-Beitrag nicht hoch genug eingeschätzt wer-den. Die Anforderungen der Bundesbehörden resultieren aus verschiedenen Richtungen: »

»

»

Umsetzung strategischer Vorgaben der Bundesregierung: Mit dem Regierungsprogramm „Moderner Staat – Moderne Verwaltung“ verfolgt die Bundes-regierung eine Strategie, die die Adressaten- und Dienstleistungsorientierung für Verwaltungsprozesse in den Mittelpunkt rückt. Dabei sollen sich die Ziele, Aufgaben und Zuständigkeiten in der Bundesverwaltung konsequent an den Anforderungen der Zielgruppen ausrichten, die ein Anliegen an die Verwaltung haben. Dies bedeutet auch für die IT, ihre Services, Prozesse und Infrastruktur konsequent an den Anforde-rungen der Verwaltungsprozesse und der IT-Anwender auszurichten. Der Defacto-Standard ITIL liefert hierfür bewährte Prozessempfehlungen, die das kundenorien-tierte IT-Service Management in den Mittelpunkt der IT-Steuerung rücken. Modernes Staatsverständnis und Leitbild des Aktivierenden Staates: Das mo-derne Staatsverständnis misst dem Begriff „Governance“ eine zunehmende Bedeu-tung bei. Im politisch-gesellschaftlichen Zusammenhang wird mit dem Governance-Begriff die Aussage verbunden, dass die Steuerung und Regelung des gesellschaftli-chen Systems nicht allein durch die Regierung (Government) erfolgt. Neben dem Staat (1. Sektor) wird auch durch die Wirtschaft (2. Sektor) sowie durch Vereine, Ver-bände und Interessenvertretungen (3. Sektor) Verantwortung wahrgenommen. Das moderne Leitbild sieht den aktivierenden und verhandelnden Staat. Er steuert die Balance aus Regulation und Selbstregulation. Dies setzt eine gut abgestimmte und auf klaren Grundsätzen basierende Zusammenarbeit zwischen den Sektoren voraus. Sichtbar wird dies auch vermehrt z.B. über PPP-Projekte (Public Private Partner-ships). Solche Überlegungen haben auch Auswirkungen auf die IT der Bundesbehör-den. Die „IT-Governance“ definiert den Rahmen für eine ganzheitliche und durchgän-gige Führung der IT1. ITIL liefert hierfür mit den Service-Management-Prozessen ein zentrales Führungsinstrument. Letztendlich wird sichergestellt, dass die IT-Prozesse und IT-Infrastruktur konsequent auf die Erfüllung der Serviceziele abgestimmt wer-den. Mit der Umsetzung von IT-Governance werden Maßstäbe für eine qualitätsge-rechte und wirtschaftliche Steuerung der IT gesetzt. Hier greifen die gleichen Anforde-rungen, wie in IT-Organisationen anderer Sektoren. Schließlich geht es um die Zu-verlässigkeit und Effizienz der IT-Services. Nicht alle Anforderungen können optimal in der eigenen IT-Organisation erfüllt werden. Deshalb wird auch verstärkt die Opti-mierung der Fertigungstiefe eine Rolle spielen. Hierbei werden vermehrt Partner-schaften zwischen den IT-Bereichen der Bundesbehörden wie auch mit Anbietern auf dem Markt für IT-Services an Bedeutung gewinnen. Hiermit wachsen auch die Anfor-derungen an die Steuerung und Kontrolle extern bezogener IT-Services. Orientierung an den Anforderungen der Verwaltung: Die Veränderungsprozesse in der Organisation und in den Verfahren der Bundesverwaltung sind auch mit spür-

1 Siehe hierzu KBSt-Studie „ITIL und Standards für IT-Prozesse“ auf www.kbst.bund.de unter ITIL >

Studien

Seite 11 von 54

baren Veränderungen in den Anforderungen an die IT-Unterstützung verbunden. Diese betreffen Inhalt, Umfang, Qualität, Sicherheit und Wirtschaftlichkeit der IT-Ser-vices. Die Fähigkeit, diese Anforderungen frühzeitig zu erkennen, richtig zu bewerten und angemessen in der Servicegestaltung umzusetzen, steht und fällt mit geeigneten Prozessen des IT-Service Managements. Die ITIL-Empfehlungen gewinnen damit schnell in der Bundesverwaltung an Bedeutung, weil sie bewährte Praktiken zur Um-setzung einer kunden-, service- und prozessorientierten IT-Organisation liefern. Dabei können die Umsetzungsschwerpunkte vielfältig sein, wie diese Erfahrungsberichte zeigen.

»

»

»

Optimale Nutzung der Ressourcen in der Bundesverwaltung: Die effiziente Gestaltung der Verwaltungsprozesse ist eines der zentralen organisatorischen Ziele in der Bundesverwaltung. Dies ist gleich in zweifacher Hinsicht Triebkraft für ein wirk-sames Service-Management in den IT-Organisationen:

o Einerseits stellt die Optimierung der Verfahren meist auch konkrete Anforderungen an entsprechende IT-Services, die zügig und in angemessener Weise in der IT umzusetzen sind.

o Andererseits liefert die Effizienz der IT-Organisation selbst einen wesentli-chen Beitrag zur Wirtschaftlichkeit der Bundesbehörden, wenn es um die Angemessenheit der IT-Kosten geht.

Die ITIL-Empfehlungen für das IT-Service Management richten sich konsequent auf die anforderungsgerechte und effiziente Erstellung der IT-Services und deren konti-nuierliche Verbesserung aus. ITIL-Ursprung in der öffentlichen Verwaltung: Nicht zuletzt ist das besondere Inte-resse der Bundesverwaltung an den ITIL-Empfehlungen auch darin begründet, dass diese ihren Ursprung in den Erfahrungen der britischen Regierungsbehörden haben. Anfangs flossen hier also vor allem die Erfahrungen diverser Regierungsinstitutionen ein. Mit der Öffnung des ITIL-Modells wurden später auch Erfahrungen aus Unter-nehmen einbezogen. ITIL wird auch heute noch vom Office of Government Com-merce, einer Stabstelle der britischen Regierung fortgeschrieben. Es bietet eine Sammlung der wichtigsten Praktiken, wie Prozesse und Verfahren für den zweckmä-ßigen und wirtschaftlichen Einsatz von IT-Mitteln, unabhängig vom Einfluss jedweder Dienstleister, in den Verwaltungen und anderen Organisationen etabliert werden kön-nen. Da ein solches Modell bislang auch für die IT-Organisation in den Bundesbehör-den fehlte und vorhandene Ansätze wie z.B. V-Modell die Anforderungen des IT-Be-triebs nur am Rande berühren, ist ITIL auch für die Bundesbehörden ein sinnvoller Ansatz, der große Lücken schließt und sich mit den bestehenden Ansätzen integ-rieren lässt. IT-Konsolidierung im Bund: Mit den hohen Anforderungen an die Qualität und Wirt-schaftlichkeit der Servicebereitstellung nimmt auch innerhalb der Bundesverwaltung die Notwendigkeit zu, Aufgaben bei zentralen Dienstleistern zu bündeln. Ein Beispiel hierfür sind die diversen Competence Center, in denen Know-how und Ressourcen für die Erbringung konkreter IT-Leistungen oder für die Bereitstellung konkreter IT-Lö-sungen gebündelt werden. Diese Bündelung ermöglicht eine effiziente Nutzung des verfügbaren Know-hows. Aber hiermit wachsen auch die Anforderungen an die Mitar-beiter, die Kultur, die Organisation und die Prozesse dieser Center. Sie müssen un-terschiedlichen Kundenanforderungen gerecht werden, ihre IT-Services bedarfsge-recht planen und steuern und die Unterstützung der Kunden über den gesamten Ser-vicezyklus hinweg gewährleisten. Aber auch den Kunden, die auf solche zentralisier-ten Dienste zurückgreifen, stellen sich neue Herausforderungen. Sie müssen ihren

Seite 12 von 54

Servicebedarf erkennen und lernen, daraus verbindliche Service-Anforderungen ab-zuleiten, diese mit den Dienstleistern zu vereinbaren und die Dienstleister entspre-chend zu steuern. Hier verlagert sich der Schwerpunkt der IT-Steuerung auf Kun-denmanagement, Management bezogener Services und Dienstleistermanagement. ITIL liefert für das Zusammenwirken dieser Disziplinen die Best Practices.

» Wachsende Kritikalität von IT-Anwendungen: Die Anforderungen an eine systematische IT-Serviceplanung und –steuerung in der Bundesverwaltung nehmen auch mit Blick auf zwei weitere wesentliche Trends zu: Mit dem forcierten Einsatz neuer Informationstechnologien wächst die IT-Abhängigkeit in den Verwaltungspro-zessen. Gleichzeitig nimmt in vielerlei Hinsicht die Komplexität der Anwendungs- und Systemlandschaft zu, was stetig höhere Anforderungen an Beschaffung, Entwicklung, Betrieb und Support der eingesetzten IT-Lösungen stellt. Da deren Teilsysteme meist in ganz unterschiedlicher Verantwortung gemanagt werden, muß das Zusammenwir-ken dieser Bereiche organisiert und auf ein gemeinsames Serviceziel ausgerichtet werden. Das IT-Service Management stellt dieses Zusammenwirken mit Blick auf die Serviceanforderungen sicher.

Mit der Umsetzung eines IT-Service Managements erlangen die IT-Organisationen in der Bundesverwaltung die nachhaltige Fähigkeit, ihre IT-Services auf die Anforderungen ihrer Kunden und Nutzer auszurichten und die Erstellung dieser IT-Services gemäß Qualitäts-, Sicherheits- und Kostengesichtspunkten kontinuierlich zu managen – unab-hängig davon, ob diese in der eigenen Organisation oder extern erstellt werden. Somit ist die Umsetzung des IT-Service Managements eine der zentralen organisatorischen Herausforderungen für die IT.

Seite 13 von 54

3 Ausgangssituation und Zielstellungen für die Umsetzung von ITIL-Prozessen

In den befragten Bundesbehörden haben verschiedene Auslöser zur Einführung von Prozessen des IT-Service Managements gemäß ITIL geführt. Das Spektrum erstreckt sich hier von veränderten IT-Anforderungen in den Verwaltungsprozessen, über verschiedene Veränderungsprozesse in der IT-Organisation selbst bis hin zu technologischen Veränderungen mit Auswirkungen auf die Organisation der IT. Die folgende Abbildung veranschaulicht diese Einflussfaktoren.

Kunden-ausrichtung

Neue Anforderungen an IT-Services oder an

Kunden- und Anwenderschnittstellen

Triebkräfte für die ITIL-Umsetzung

Standardisierung und Technologie-

wechselTechnologische

Veränderungen in der IT-Landschaft

Konsolidierung und/oder

Outsourcing

Auslagerung von IT-Leistungen an Dienstleister

Reorganisation

Prozeßstandards und Veränderungen in der Organisationsstruktur

der IT-Bereiche

Kunde Technik

Organisation und Prozesse

Abbildung 1 Triebkräfte für die ITIL-Umsetzung in den befragten Bundesbehörden

Der Veränderungsbedarf in den IT-Service-Management-Prozessen war also bei den befragten Behörden kein Selbstzweck. Er war hier stets die notwendige Folge sich verändernder Rahmenbedingungen für die Arbeitsweise der IT. Die hier genannten Auslöser betrafen lediglich die befragten Bundesbehörden, darüber hinaus kann es noch weitaus mehr Auslöser für solche Veränderungsprozesse in der IT geben, weshalb diese Abbildung nur einen Ausschnitt darstellt, der im Rahmen dieser Befragung benannt wurde. Der Veränderungsbedarf selbst ähnelt sich in vielen Aspekten, weist aber auch in den befragten Behörden teilweise große Unterschiede auf. Dies macht deutlich, wie vielfältig

Seite 14 von 54

die Motivation für ein wirksames IT-Service Management sein kann und wie wichtig dieses Instrument für verschiedene Optimierungsfragen der IT ist. Dies werden die Erfahrungsberichte über das gesamte Dokument hinweg immer wieder deutlich machen. Zunächst aber mehr zu den Ausgangssituationen:

3.1 Kundenorientierte Ausrichtung der IT-Organisation Nahezu alle Teilnehmer sahen die Notwendigkeit, die Schnittstellen zu den internen Kunden – also den Verantwortlichen in den Fachabteilungen und Referaten – und den Anwendern – also den Mitarbeitern in den Fachabteilungen zu professionalisieren. Dies betraf aber durchaus verschiedene Aspekte:

3.1.1 Unzureichende Qualität in der Anwenderbetreuung Häufig war die unzureichende Qualität in der Anwenderbetreuung einer der wesentlichen Auslöser. Gerade hier wird die Leistungsfähigkeit der IT für den Anwender besonders sichtbar und dessen Arbeitsfähigkeit und Zufriedenheit direkt beeinflußt. Am Ausgangspunkt mangelte es hier stets an standardisierten Abläufen und Anwenderschnittstellen. Die Verantwortlichkeiten für die Betreuung der Anwender waren entweder nicht klar definiert oder in starkem Maße verteilt. Dies setzte sich häufig in den nachgelagerten Abläufen – insbesondere in der Störungs- und Auftragsbearbeitung fort. Folge waren lange Reaktions- und Bearbeitungszeiten sowie eine hohe Personalbindung in den Vorgängen. Die Qualität war nicht objektiv messbar, damit auch nicht gezielt verbesserbar. Die Anwender nahmen die gebotene Servicequalität direkt wahr und waren entsprechend latent unzufrieden. In einigen Fällen bestanden bereits Helpdesk-Funktionen an der Anwenderschnittstelle, die aber auf die Beantwortung von Fragen zur Produktnutzung beschränkt waren. Mitunter wurden auch mehrere solcher Funktionen parallel – zum Beispiel organisations- oder standortspezifische – unterhalten. Dass dies zum Nachdenken über ITIL-Standards führte, ist nicht verwunderlich, konzentrieren sich doch viele IT-Organisationen zunächst darauf, derartige Probleme mit der Einführung einer zentralen Service-Desk-Funktion und eines standardisierten Prozesses zur Störungsbearbeitung (Incident Management) zu lösen. Aber die Auslöser gingen auch mitunter weit darüber hinaus:

3.1.2 Serviceangebote für andere Behörden Einige, mitunter auch kleinere IT-Organisationen waren zudem mit der Anforderung konfrontiert, auch Kunden außerhalb der eigenen Behörde zu bedienen. Dies traf vor allem dort zu, wo spezialisierte Competence Center für konkrete Anwendungen aufgebaut wurden. Es ist nur logisch, dass dieses Know how auch Anwendern in anderen Behörden der Bundesverwaltung zur Verfügung gestellt wird, bevor derartige Kompetenzen und Services redundant aufgebaut werden. Hier stand nun die Frage, wie solche Kunden- und Anwenderschnittstellen zu organisieren sind, damit diese Services in der richtigen Weise angeboten, vereinbart, erbracht, überwacht und mitunter auch verrechnet werden können. Dies stellte über die Organisationsgrenzen hinweg besondere Anforderungen an eine kunden- und serviceorientierte Organisation und Kultur in der IT und führte zu weiteren Prozessanforderungen – insbesondere im Service Level Management.

Seite 15 von 54

3.1.3 Paradigmenwechsel von der übersteuerten zur auftragsgesteuerten IT Zentrale Aufgabe der IT-Organisation ist es, die Nutzeranforderungen an IT-Anwendungen und –Systeme zu erkennen und zu erfüllen. Um dies sicherzustellen, stellt sie vielfältigste Leistungen im Rahmen von Planung, Beschaffung, Implementation, Betrieb und Support sicher. Damit sind aber auch die Nutzeranforderungen einer der wesentlichen Treiber für IT-Kosten und Komplexität. Nur wenn die mit den Anforderungen verbundenen Konsequenzen von vorn herein bekannt sind, können gezielte und optimale Entscheidungen mit dem Kunden gefällt werden. Deshalb hat der Kunde ein Anrecht darauf, dass ihm die Folgen seiner Anforderungen transparent gemacht werden und er die damit entstehenden IT-Kosten direkt beeinflussen kann. Diese Folgen sind i.d.R. notwendige Veränderungen im Leistungsumfang, in den Qualitäts- und Sicherheitszusagen und auch in den Kosten der Serviceerstellung. Für den Kunden bedeutet dies eine gezieltere Beeinflussbarkeit der IT-Leistung und der IT-Kosten. Für die IT-Organisation bedeutet dies eine verbindlichere Auftragsschnittstelle zum Kunden. Häufig mangelt es heute noch an Servicestandards. Die Folge sind auch unzureichende Auftragsstandards. Damit werden auch Kundenanforderungen mitunter vollkommen entkoppelt von den Komplexitäts- und Kostenfolgen behandelt. Die Konsequenz ist, dass die IT-Organisation recht ungefiltert auch mit solchen Anforderungen konfrontiert wird, die unter Wirtschaftlichkeitsgesichtspunkten nicht gerechtfertigt sind, z.B. weil sie Vielfalt und Komplexität treiben oder schon in der Realisierung unwirtschaftlich sind. Eine der befragten Bundesbehörden sah dieses Problem als eine zentrale Herausforderung und nutzt die ITIL-Standards auch für die Professionalisierung der Auftragsschnittstellen. Ziel war es, von der Übersteuerung zu einer klar auftragsbasierenden Serviceerstellung zu gelangen, in der der Kunde bewusst über Inhalt und Umfang seiner Aufträge entscheiden kann und die IT-Organisation eine verbindliche Grundlage für die Leistungserstellung hat. Dies setzt natürlich eine Standardisierung der Services, Geschäftsvorfälle und Prozesse in der IT voraus und stellt besondere Anforderungen an das Service Level Management und das Auftrags- bzw. Change Management.

3.2 Restrukturierung der IT-Organisation Die Auslöser für die Auseinandersetzung mit ITIL-Prozessen waren aber auch häufig Veränderungen innerhalb der IT-Organisation – z.B. in Folge von Verwaltungsreformen.

3.2.1 Bündelung von Behörden Mitunter wurden Bundesbehörden zusammengelegt. Damit stand die Frage, mit welchen Strukturen und Prozessstandards die IT-Organisation künftig die Anwender in den unterschiedlichen Struktureinheiten und an verschiedenen Standorten betreut. Wieviel Zeit konnte man sich geben, um hier gemeinsame Standards zu schaffen? Lässt der schnelle Restrukturierungsprozess überhaupt eine halbwegs geordnete Prozessstandardisierung zu oder ist dies ein Zielkonflikt? Wie bewertet man überhaupt die Qualität der bislang unterschiedlich gewachsenen Prozesse? Können diese teilweise übernommen werden oder sollte man gemeinsam neue Standards schaffen? Man sah hier im Rahmen der Restrukturierung die Chance, gemeinsam neue Prozessstandards zu definieren, die sich zugleich an den ITIL-Empfehlungen ausrichten und ging diesen Weg konsequent.

Seite 16 von 54

3.2.2 Standortwechsel der IT-Organisation In einem Fall wurde der Standort der IT-Organisation komplett verlegt. Mit dem Umzug waren auch grundsätzliche organisatorische Veränderungen verbunden, denn nicht alle bisherigen IT-Mitarbeiter haben diesen Standortwechsel mit vollzogen. Deshalb stand die Frage im Raum, ob diese gravierenden personellen und räumlichen Veränderungen zum Überdenken der bestehenden Prozesse führen müssen. Diese Frage war sehr schnell mit „Ja“ beantwortet, weil unter den veränderten Rahmenbedingungen eine andere Form der Zusammenarbeit notwendig wurde. Dies war ein Anlass, auch über die Standardisierung wesentlicher Prozesse nachzudenken und hierbei die ITIL-Empfehlungen zugrunde zu legen.

3.3 Konsolidierung der IT und Outsourcing Die Zunahme an neuen und veränderten Verwaltungsverfahren löst auch neue oder veränderte Serviceanforderungen in der IT aus. Die IT-Anforderungen nehmen in Umfang und Qualität in nahezu allen befragten Bundesbehörden zu. Gleichzeitig besteht auch in den IT-Organisationen der Bundesverwaltung die Notwendigkeit, mehr Leistung mit konstanten oder sinkenden Kosten zu erbringen. Dies zwingt zur Rationalisierung der Leistungserstellung in der IT. Dies führt i.d.R. zu einem Mix von Entscheidungen:

3.3.1 Konsolidierung der Infrastruktur In einer der befragten Bundesbehörden waren Vielfalt und Umfang der Serverlandschaft der zentrale Auslöser für die Auseinandersetzung mit ITIL. Angesichts des bestehenden Problems interessierte sich die IT-Leitung für den Planungsprozess im Serverbereich. Schnell war klar, dass ein solcher Prozess nicht wirklich wirksam war. Die Entscheidungen für neue Server wurden fast stets im Projektzusammenhang gefällt. Bekanntermaßen kann die Verantwortung für eine kontinuierliche Ressourcenoptimierung im Serverbereich nicht aus der Perspektive eines jeden einzelnen Projekts und dessen Projektleiters wahrgenommen werden. So war klar, dass das Problem nur nachhaltig organisatorisch zu lösen war. In der betroffenen Behörde wurde schnell erkannt, dass man die Änderungsanforderungen und Änderungen im Serverbereich unter Kontrolle bringen musste, um Entscheidungen für neue Server gezielter treffen zu können und dass ITIL mit dem Change Management hierfür geeignete Empfehlungen liefert. In diesem Zusammenhang ließ sich auch das Auftragsmanagement für neue Server regeln. Darüber hinaus rückte auch das Capacity Management in den Fokus. Dieses stellt die kontinuierliche Optimierung der IT-Services hinsichtlich Erfüllung der Performanceanforderungen bei angemessenem Ressourceneinsatz sicher und liefert hiermit auch die Grundlagen für Investitionsentscheidungen im Bereich der Serverinfrastruktur. Daneben mussten auch die Rahmenbedingungen für die Prozesse mit den Kunden verbindlich geregelt werden, weshalb auch das Service Level Management mit Servicedefinition und Management von Service Level Agreements zusätzlich berücksichtigt wurde. Die im Rahmen der ITIL-Implementierung optimierten Prozesse fanden Berücksichtigung im Qualitätsmanagement der Behörde und wurden so dokumentiert, dass sie in einem Audit nach ISO 9001:2000 nachgewiesen werden konnten. Da außerdem die Einführung einer Kosten- und Leistungsrechnung parallel stattfand, lag es nahe, die Transparenz der Servicekosten herzustellen. Die Implementationsmaßnahmen dehnten sich damit auf das IT Financial Management aus. Für die im Rahmen des Service Level Managements in einem Servicekatalog

Seite 17 von 54

zusammengestellten Betriebsleistungen wurde ein Verrechnungspreismodell entwickelt und dieses zur Einführung der Kosten- und Leistungsrechnung im IT Bereich genutzt. Diese Bundesbehörde hat also auf Grundlage einer ganz konkreten Problemsituation einen passenden Weg gefunden, um konkrete Problemlösungen mit Hilfe der ITIL-Standards bereitzustellen. Sie hat sich sozusagen aus dem zunächst meist unüberschaubaren Werkzeugkasten zielgerichtet und ergebnisorientiert bedient.

3.3.2 Aufwandssenkung in der Leistungserstellung Alle befragten Bundesbehörden sahen die Notwendigkeit, den Aufwand im Betrieb und Support signifikant zu senken. In einigen Fällen war die IT-Organisation von spürbaren Budgetkürzungen betroffen, die in relativ kurzer Zeit zu drastischem Personalabbau führten. Hier war der Druck entsprechend hoch, mit dem verbleibenden Personal-bestand die bisherigen Services in der jeweiligen Qualität weiter sicherzustellen. In an-deren Fällen bestand die Notwendigkeit, mit dem bestehenden Personal zusätzliche Aufgaben sicherzustellen. Wie auch immer; in allen Fällen galt es, die Leistungserstel-lung zu optimieren. Auch hier unterscheiden sich die Rahmenbedingungen in den Bun-desbehörden nicht wesentlich von denen im Wirtschaftssektor. Der Druck auf den effi-zienten Ressourceneinsatz in der IT ist immanent – sind dies doch überwiegend wert-volle Ressourcen. Die IT-Leiter können sich zunehmend nur noch neue Budgetspiel-räume – z.B. für Innovation - schaffen, wenn sie ihr Tagesgeschäft stetig rationalisieren. Das heißt letztendlich, Abläufe konsequent zu standardisieren, soweit möglich auch zu automatisieren, unnötige Vorgänge zu vermeiden, besser zu planen, große Last-schwankungen zu vermeiden und damit die Kosten der Reaktionsfähigkeit zu senken, die Arbeitsteilung zu fördern und somit in bestimmten Rollen den Qualifikationsbedarf zu senken, etc. In dieser Situation sehen alle Teilnehmer das Ziel, die Prozesse gemäß bewährten ITIL-Empfehlungen zu standardisieren, um die Abläufe wirtschaftlicher zu machen. Da ein beachtlicher Teil der Leistungserstellung durch Anwender ausgelöst wird, wurden die Schwerpunkte hier meist auf die Einführung des Service Desks sowie die Prozesse Incident und Change Management gesetzt. Mit der Standardisierung der Störungs- und Auftragsbearbeitung trifft die Effizienzsteigerung einen beachtlichen Teil des Tagesgeschäfts in der IT.

3.3.3 Outsourcing und Steuerung externer Dienstleister Die Vielfalt der benötigten IT-Services ist nicht unbedingt abhängig von der Größe der Bundesbehörde. Jeder Arbeitsplatz nutzt i.d.R. eine Vielzahl von Standarddiensten. Hinzu kommen dann fachspezifische Anwendungen zur Unterstützung konkreter Ver-waltungsverfahren. Je kleiner die IT-Organisation, um so schwerer fällt es ihr, alle benötigten IT-Services mit den begrenzten Ressourcen selbst zu erstellen. Mit der stark zunehmenden Spezia-lisierung auf dem freien Markt für IT-Services stellen sich diese Fragen heute aber auch den sehr großen IT-Organisationen. Hier treibt zusätzlich die gewachsene Komplexität und die darin begründete Intransparenz Überlegungen, welche Services im eigenen Haus ordnungsgemäß sichergestellt werden können. Hierbei heißt ordnungsgemäß, dass die formalen Anforderungen gängiger Standards in den Prozessen erfüllt werden, die Sicherheitsrisiken bewertbar und steuerbar sind und die Servicekosten transparent und steuerbar sind. Alle befragten IT-Organisationen sehen sich dazu verpflichtet, ob-

Seite 18 von 54

jektiv zu prüfen, welche Services besser im eigenen Haus zu erstellen sind und welche besser extern bezogen werden können. Dies betrifft nicht nur die Nutzung von Serviceangeboten auf dem Markt, sondern auch die Nutzung der zentralen Dienstleister innerhalb der Bundesverwaltung. Diese entwi-ckeln spezifisches Know-how in Beschaffung, Entwicklung, Betrieb und Support kon-kreter Anwendungen, das natürlich umfassend in der Bundesverwaltung genutzt werden soll. Wer die Serviceerstellung auslagert, ist in noch stärkerem Maße gezwungen, klare An-forderungen an diese Services zu formulieren, verbindliche Servicevereinbarungen mit dem Dienstleister zu schließen und diesen angemessen zu kontrollieren. Die Serviceri-siken verbleiben letztendlich immer bei der IT-Organisation, die gegenüber ihren Kun-den für die Qualität, Sicherheit und Wirtschaftlichkeit der Services verantwortlich ist – unabhängig davon, wer die Leistungen hierfür erbringt. Diese Anforderungen treiben besonders den Bedarf für ein wirksames Service Level Management und Supplier Management. Ersteres definiert und vereinbart die zu bezie-henden Services. Letzteres steuert die Schnittstelle zu externen IT-Service Providern, entwickelt die Beziehungen zu diesen und kontrolliert diese.

3.4 Technologiewechsel in der IT-Landschaft Eine der befragten Behörden vollzog einen radikalen Technologiewechsel. Die bisher weitgehend hostbasierte Anwendungslandschaft wurde vollständig durch Client-Server-Strukturen ersetzt. Damit verlagerte sich der Organisationsbedarf auf vollkommen neue Mitarbeiterfähigkeiten und –erfahrungen, neue Rollen und neue Betriebsprozesse. Der Technologiewechsel war damit notwendigerweise auch mit einem radikalen organisato-rischen Veränderungsprozess verbunden. So stand die Frage im Raum: Wenn wir neue Rollen und Prozesse organisieren, sollten wir uns dann nicht gleich an den ITIL-Stan-dards orientieren? Hier standen vor allem die Support-Management-Prozesse im Fokus, die die Qualität des Systembetriebs sicherstellen helfen – Incident und Change Mana-gement.

3.5 Fazit Nie war nur ein Aspekt der hier genannten der Auslöser für die Orientierung an ITIL-Standards. Immer griffen verschiedene dieser Aspekte ineinander. Dies wundert auch nicht, stehen doch Erfüllung von Kundenanforderungen, Sicherstellung der Qualität, Kosten dieser Sicherstellung und Folgekosten der Minderqualität, Transparenz, Kom-plexität und Standardisierungsgrad sowie Grad der Automation und Toolunterstützung immer in einem Zusammenhang miteinander. So verschieden die Ausgangssituationen in den befragten Bundesbehörden sind,

»

»

»

die grundsätzlichen Fragestellungen unterscheiden sich in keiner Weise von de-nen anderer Bundesbehörden, alle haben in den ITIL-Standards ein Instrument zur Bewältigung konkreter Herausforderungen gesehen und haben sich dieser Aufgabe gestellt, am häufigsten wurden die Probleme angegangen, die mit der Standardisierung der Kunden- und Nutzerschnittstellen, mit der Professionalisierung der Störungs-,

Seite 19 von 54

Auftrags- und Änderungsbearbeitung sowie mit der Definition und Steuerung der IT-Services und Servicevereinbarungen zu tun haben.

»

»

wo die ITIL-Einführung eher aus dem Systembetrieb heraus getrieben wurde, wurden vor allem die Prozesse im Service Level Management, Change Manage-ment, Kapazitätsmanagement und in der Kostenrechnung und –verrechnung in den Blickpunkt gerückt. alle haben auf Grundlage ihrer Ziele eigene Umsetzungsschwerpunkte gesetzt und auch eigene Implementationsentscheidungen getroffen.

Wenn es um die Optimierung der Leistungsfähigkeit in der IT geht, dann zeigt die fol-gende Abbildung wesentliche Ansätze:

Leis

tung

sfäh

igke

it de

r IT

Qua

lität

, Sic

herh

eit,

Effi

zien

z

Klarheit der Anforderungen und Ziele

Klarheit der Verantwortung und Kompetenzen

Verfügbarkeit von Wissen und Erfahrung

Vielfalt der Regeln, Verfahren und Technologien

Verfügbarkeit der Ressourcen und Priorisierung

Grad der Standardisierung und Toolunterstützung

Org

anis

ator

isch

e Fa

ktor

en

RELEVANZ

ZUSTÄNDIGKEIT

FÄHIGKEIT

KOMPLEXITÄT

LAST

AUTOMATION

Klarheit der Anforderungen und Ziele

Klarheit der Verantwortung und Kompetenzen

Verfügbarkeit von Wissen und Erfahrung

Vielfalt der Regeln, Verfahren und Technologien

Verfügbarkeit der Ressourcen und Priorisierung

Grad der Standardisierung und Toolunterstützung

Verfügbarkeit von Wissen und ErfahrungVERBINDLICHKEIT Wirksamkeit der Regeln und Verfahren

Abbildung 2 Optimierung der Leistungsfähigkeit der IT (Quelle: HiSolutions AG)

Nachdem die Ausgangssituation der befragten Bundesbehörden dargestellt worden ist, werden nun die daraus abgeleiteten Umsetzungsstrategien und Umsetzungsschwer-punkte zusammengefasst.

Seite 20 von 54

4 Erwartungen, Strategien und Umsetzungsschwerpunkte

4.1 Erwartungen der IT-Leitung Die Befragung sollte auch Aufschluss darüber geben, welche Erwartungen mit der Umsetzung von ITIL-Vorgaben verknüpft wurden. Mit Blick auf die Ausgangssituation lassen sich die Erwartungen wie folgt zusammenfassen:

Senkung der Komplexität +Standardisierung der Abläufe

Objektive und verbindliche Maßstäbe +Qualitätsverbesserung für Anwender

Transparente Servicespezifikation +Transparente Servicekosten

Transparenz-verbesserung

Qualitäts-verbesserung

Effizienz-verbesserung

Abbildung 3 Erwartungen an das IT-Service Management

4.1.1 Verbesserung der Service-Qualität Die Qualitätsverbesserung in der IT war einer der zentralen Motivationsgründe für die IT-Leitung. Hinsichtlich der Erwartungen an die Qualitätssteigerung wurden mehrere Aspekte im Zusammenhang gesehen: »

»

Am stärksten wogen die Qualitätsauswirkungen, die direkt auf den Anwender wirken. Hier ging es überwiegend zunächst um eine spürbare Verbesserung der Qualität aller Leistungen im Rahmen der Anwenderbetreuung und Störungsbearbeitung. Die Anwender sollten zügig von den Umsetzungsmaßnahmen profitieren. Damit sollten die Effekte schnell in der Fläche sichtbar werden, um Rückenwind für die Veränderungen in der IT zu erzeugen. Die Effekte sollten über Anwenderzufriedenheitsbefragungen sichtbar werden. Daneben bestand aber häufig auch die Erwartung, objektive Qualitätsmaßstäbe für die Leistungserstellung in den IT-Services zu definieren und verbindlich zu regeln. Damit sollte die Leistungsfähigkeit der IT-Organisation objektiver bewertbar sein und damit unabhängiger von rein subjektiven Betrachtungen werden. Nach innen sollte dies möglichst über Qualitätsindikatoren in den Prozessen (KPI = Key Performance

Seite 21 von 54

Indicators) und teilweise auch zum Kunden über definierte Service Levels (Zusagen für konkrete Service-Qualitätsparameter) messbar gemacht werden.

4.1.2 Verbesserung der Service-Effizienz Mit Blick auf die teilweise sehr einschneidenden Rationalisierungserfordernisse war auch die Effizienzsteigerung einer der zentralen Motivationsgründe. Hier griffen ver-schiedene Aspekte ineinander. Mitunter wurden aber auch unterschiedliche Erwartun-gen verfolgt: »

»

»

»

»

Zunächst standen hier meist gar nicht die ITIL-Standards im Vordergrund. Vielmehr ging es zunächst darum, das Tagesgeschäft in der Anwenderbetreuung sowie Störungs- und Auftragsbearbeitung zu standardisieren, um zu einfacheren und klareren Abläufen zu kommen. Dies sollte eine schlanke und trainierbare Praxis ermöglichen. Zudem sollten diese Abläufe besser mit Tools unterstützbar werden. Die Prozessstandardisierung und –automation war hier also ein erfolgversprechender Weg für die IT-Leitung. Nun handelte es sich bei den hier fokussierten Abläufen um Prozesse, die ITIL im Rahmen des Support-Managements empfiehlt. Deshalb war meist klar, dass das Rad hierfür nicht neu zu erfinden ist und man besser auf bereits bewährte Prozessempfehlungen zurückgreifen sollte. Insofern lag eine Nutzung dieser Praxisempfehlungen sehr nahe, was dem Veränderungsprozess mehr Sicherheit und Akzeptanz verleihen sollte. Die Erwartungen richteten sich aber in einigen Behörden auch auf die Wirtschaftlichkeit der IT-Infrastruktur. Auch hier wurden in der Standardisierung – also in der Senkung der Komplexität – sowie in einer besseren Ressourcenplanung die wesentlichen Hebel gesehen.

4.1.3 Verbesserung der Service-Transparenz Nicht in allen befragten Behörden war die Einführung eines Service Level Managements zur Entwicklung und Steuerung standardisierter IT-Services bisher ein Thema. Einige Behörden gingen aber über die Standardisierung der Support-Prozesse hinaus und widmeten sich der Standardisierung der Leistungsangebote über definierte IT-Services. Damit wurden folgende Erwartungen verknüpft:

Die Servicespezifikation wurde als wesentliche Grundlage erkannt, internen und externen Kunden definierte Leistungen mit formulierten Qualitätszusagen anbieten zu können. Dies war gerade dort der Fall, wo die Serviceangebote von Competence Centern zu formulieren waren oder wo verbindliche Rahmenbedingungen mit dem Kunden für die Beauftragung und Inanspruchnahme von IT-Leistungen zu schaffen waren. Die Professionalisierung der Schnittstelle zu den Kunden setzte für diese Bundesbehörden zunächst eine klare Servicedefinition und einen formulierten Servicekatalog voraus. In einem Fall gingen die Erwartung noch über die Servicespezifikation hinaus. Hier war auch bereits die laufende Kostenkontrolle für IT-Services und deren Verrechnung im Rahmen einer Kosten- und Leistungsrechnung zu unterstützen. Die IT-Leitung knüpfte hieran die Erwartung, die Leistungen der IT-Organisation verursacher- und verursachungsgerecht den Kunden zuzuordnen.

Seite 22 von 54

4.2 Strategien und Umsetzungsschwerpunkte Je nachdem, wie der konkrete Handlungsbedarf priorisiert wurde, unterscheiden sich die bisherigen Umsetzungsschwerpunkte in den befragten Bundesbehörden. In den konkreten Fällen kristallisierten sich mit Blick auf die Einführungsstrategie drei Grundmuster heraus:

Ser

vice

Des

k

IncidentManagement

Problem Management

Auftrags- und Change Management

ConfigurationManagement

Ser

vice

Lev

el

Man

agem

ent IT Financial

Management

AvailabilityManagement

Release Management

CapacityManagement

ContinuityManagement

Support Management

Delivery ManagementAn

wen

der-

Sch

nitts

telle

Kund

en-

Sch

nitts

telle

A

B

C

Abbildung 4 Einführungsstrategien für das IT-Service Management

Vier der fünf befragten Bundesbehörden wählten die Einführungsstrategie A. Wiederum drei der vier kombinierten diese mit Strategie B. Die fünfte Behörde wählte mit der Strategie C einen eigenen Weg, um ihre Ziele zu errreichen. Die Grundmuster werden nachfolgend kurz erläutert.

4.2.1 (A) Professionalisierung der Anwenderbetreuung Fast alle Teilnehmer setzen zunächst auf die Optimierung der Anwenderschnittstelle mit der Einführung eines Service Desks und auf die Optimierung der nachgelagerten Betreuungsprozesse mit Schwerpunkt Incident Management und mitunter bereits Teilen des Problem Managements. Eine der Behörden priorisierte sehr stark die Auftragssteuerung der IT und bezog von Beginn an das Auftragsmanagement in die Implementation ein. Die anderen Behörden dehnten im zweiten Schritt ihr Support Management auf das Auftrags- und Change Management aus, nachdem der Service Desk grundsätzlich wirksam und akzeptiert war. Diese Einführungsstrategie konzentriert sich auf die Implementation des Support Managements und beginnt die Implementation bei den anwendernahen Funktionen und Prozessen. Wer diesen Weg geht, strebt frühzeitig sichtbare Qualitätseffekte bei den

Seite 23 von 54

Anwendern an, indem deren Betreuung standardisiert wird und die Serviceverfügbarkeit beim Anwender über ein wirksames Incident Management verbessert wird. Eine der befragten Behörden stellte fest, dass bereits mit der Einführung des Service Desks und Incident Managements grundlegende Praktiken im Change und Configuration Management erforderlich sind. Dies betraf z.B. die Bereitstellung von Konfigurationsdaten für die Anwenderunterstützung und Störungsanalyse oder die Annahme von Änderungsvorgängen infolge von Aufträgen am Service Desk. Deshalb wurden hier einige Maßnahmen im Change und Configuration Management bereits als Unterstützungsprojekt parallel durchgeführt. ! Hinweis Abgrenzung Incident und Problem: Bei Einführung des Incident

Managements sollte von Beginn an eine klare Abgrenzung zum Problem Management erfolgen. Empfehlenswert ist, beide Prozesse im Zusammenhang einzuführen. Mitunter erfolgt dies aber nicht, dann sollte zumindest das reaktive Problem Management zusammen mit dem Incident Management eingeführt werden. Die proaktiven Aufgaben können dann mit Wirksamkeit des Incident Managements nachgezogen werden.

! Hinweis Auftrags- und Änderungsmanagement: Wenn die Optimierung der Auftragsschnittstellen für den Anwender und des Auftragsmanagements angestrebt wird, dann sollte dies im Rahmen der Change Management Einführung organisiert werden.

! Hinweis Configuration und Change Management: Die Einführung des Change Managements sollte mindestens im Zusammenhang mit dem Configuration Management erfolgen (dies ist zwingend erforderlich) – möglichst aber auch mit dem Release Management. Die Erfahrung zeigt, dass in der Praxis häufig Fehler in der Abgrenzung von Change und Release Management gemacht werden, wenn nur einer der beiden Prozesse zunächst betrachtet wird. Häufig wird dieser dann zusätzlich mit Aufgaben des nicht betrachteten Prozesses überfrachtet.

! Hinweis Support Management bei Outsourcing von IT-Leistungen: Werden Leistungen des IT-Betriebs ausgelagert, haben das Incident, Problem und Change Management eine ebenso große Bedeutung. Im Falle des Outsourcings wird darüber die operative Steuerbarkeit der Dienstleister gewährleistet. Die Dienstleister fordern i.d.R. klare Prozeduren für die Störungsbearbeitung und Beauftragung. Hat die auslagernde IT-Organisation hierfür keine eigenen Prozessstandards, bleibt ihr häufig nur, sich denen ihrer Dienstleister unterzuordnen. Mit der Anzahl der Dienstleister führt dies dann zu einem Wildwuchs an Schnittstellen, Regeln und Prozeduren. Der Integrations- und laufende Prozessaufwand liegt dann beim Auslagernden. Delivery Management und Supplier Management: Unabhängig davon nehmen für die IT-Organisation die formalen Pflichten in der Steuerung und Kontrolle der Dienstleister zu, denn mit der Verlagerung der Verantwortung für die Leistungserstellung verbleibt das Servicerisiko bei der auslagernden IT-Organisation. Sie muß in der Lage sein, angemsesene Serviceanforderungen zu formulieren und deren Erfüllung zu kontrollieren. Damit wächst die Bedeutung des Delivery und Supplier Managements in Outsourcingsituationen.

Seite 24 von 54

Es gilt also: Ordnungsgemäßes Outsourcing setzt funktionsfähige Support-Management-Prozesse in der auslagernden IT-Organisation voraus. Damit wird IT-Service Management hier sogar zur zentralen Aufgabe der auslagernden IT-Organisation.

4.2.2 (B) Standardisierung der IT-Services Das zweite Grundmuster setzt bei der Standardisierung der Serviceangebote und damit bei der Entwicklung der Kundenschnittstelle an. Dies ist die zentrale Voraussetzung, um die Prozesse und Infrastruktur der IT auf die Geschäftserfordernisse konsequent auszu-richten. In der Wirtschaft wird diese Anforderung mit dem Begriff Business-IT-Alignment verbunden. Nahezu alle befragten IT-Organisation berücksichtigten frühzeitig die Einführung des Service Level Managements, einem der zentralen Prozesse im Service Delivery Mana-gement. Damit wurde einerseits das Ziel verfolgt, klare Serviceangebote zu formulieren, auf die die internen oder externen Kunden zurückgreifen können. Gleichzeitig werden damit klare Standards für die Aufträge im Rahmen dieser IT-Services und für verbindliche Ser-vicevereinbarungen geschaffen. Die Servicespezifikation – also die Festlegung, in welcher Weise der Service geboten wird, welche Leistungen er beinhaltet, in welcher Qualität diese erbracht werden und welche Prozeduren an der Schnittstelle zum Kunden und Anwender gelten – ist zugleich wesentliche Voraussetzung für die Planung und Steuerung der kontinuierlichen Service-erstellung. Deshalb wird diese Einführungsstrategie konsequent mit weiteren Prozessen des Delivery Managements fortgesetzt. Mit einer klaren Servicedefinition und –abgren-zung werden z.B. die Grundlagen für die Servicekostenrechnung und –verrechnung im IT Financial Management oder für die Performance- und Ressourcenplanung im Capa-city Management gelegt. Mit der Transparenz der Abhängigkeiten innerhalb der Struktur eines IT-Services ist auch die Analyse der Verfügbarkeitsabhängigkeiten und die Ver-fügbarkeitsplanung im Availability Management möglich sowie die Notfallvorsorge und die Planung von Widerherstellungsmaßnahmen im Notbetrieb über das Continuity Ma-nagement. Andererseits kann auch die Standardisierung der Auftragsschnittstellen und des Change Managements im Rahmen der definierten Services eine Folgemaßnahme sein. Das Service Delivery Management ist das zentrale Instrument, um standardisierte IT-Services entwickeln und steuern zu können und die IT hierüber konsequent an den Kundenanforderungen auszurichten. Die Einführung des SLM-Prozesses wiederum ist hierfür die zentrale Grundlage.

! Hinweis Mit der Einführung des Service Level Managements sollte zunächst die Definition und Spezifikation der IT-Services im Vordergrund stehen. Dies ist eine wesentliche Voraussetzung für die Implementation der weiteren Verfahren in der Serviceplanung, im Management von Servicevereinbarungen (SLA-Management), in der Überwachung der Service Levels, etc.

Seite 25 von 54

4.2.3 (C) Konsolidierung und Optimierung des IT-Betriebs Eine Behörde entwickelte das IT-Service Management aus dem Systembetrieb heraus. Hier ging es vor allem um die Prozesse, die eine RZ-Konsolidierung und ein nachhaltig optimales Management der IT-Ressourcen ermöglichen. Da der Systembetrieb hier u.a. die Plattformen für den Anwendungsbetrieb der IT bereitstellt, war die Optimierung der anwenderbezogenen Schnittstellen und Prozesse von nachrangiger Bedeutung. Dafür wurde das Auftrags- und Änderungsmanagement als primäres Einführungsziel ausge-wählt. In diesem Zusammenhang wurden auch das Kapazitätsmanagement im Systembetrieb, das Service Level Management incl. Servicedefinition sowie das IT Financial Management für die Servicekostenermittlung und –verrechnung mit in den Fo-kus genommen. Diese Stratege verfolgte also einen Optimierungsansatz für Planung und Betrieb zentra-ler IT-Systeme. Damit wurden die ITIL-Standards zunächst in einem begrenzten Pilotbe-reich der IT-Organisation entwickelt.

4.2.4 Fazit In den befragten Bundesbehörden wurde die Strategie B in fast allen Fällen mit berück-sichtigt. In den meisten Fällen war die Einführung eine begleitende Folgemaßnahme. Die Masterstrategien waren entweder Szenario A oder aber C. Tendenziell spielte das B-Szenario in genau den IT-Organisationen eine große Rolle, die IT-Services als zentra-le Dienstleister auch anderen Behörden anbieten oder die eine service- und auftragsori-entierte Steuerung der IT anstrebten. Hierfür war die Standardisierung der Serviceange-bote und die Einführung eines Managementprozesses unerlässlich. Es gibt keine sinnvolle pauschale Empfehlung für Umsetzungsschwerpunkte und ent-sprechende Einführungsstrategien. Die Schwerpunkte sind notwendige Folge der Um-setzungsziele. Diese wiederum sollten mit der Lösung konkreter bestehender Probleme verbunden sein. Was aber darüber hinaus berücksichtigt werden sollte, sind die zahlreichen Abhängig-keiten zwischen den Service-Management-Prozessen. Einige sind notwendige Grund-lage für die Einführung anderer. Einige können nur im Zusammenhang mit anderen ein-geführt werden. Und die Einführung konkreter Prozesse stößt mitunter an ihre Grenzen, wenn andere nicht auf ein konkretes Niveau nachgezogen werden.

? Frage Beruhen die Implementationsmaßnahmen in Ihrer Organisation auf einer formulierten Einführungsstrategie?

? Frage Berücksichtigt diese Einführungsstrategie » » » » »

»

die bestehende Ausgangssituation in Ihrer Organisation? konkrete Problemlösungsziele? einen definierten Prozessfokus? eine mittel- und langfristige Roadmap für die Einführungsstufen? bekannte Abhängigkeiten zwischen den einzuführenden und bestehenden Prozessen? Bekannte Abhängigkeiten mit anderen laufenden oder geplanten Implementationsprojekten?

? Frage Sind die benötigten Ressourcen identifiziert und im ausreichenden Maße (Qualität und Umfang) für die Umsetzung der Maßnahmen vorhanden?

Seite 26 von 54

? Frage Sind Sie bereit für » » »

spürbare Veränderungen in der bestehenden Ablauforganisation, für gemeinsame, bereichsübergriefende Prozesse und für die Festlegung einer klaren und ungeteilten Prozeßverantwortung?

? Frage Ist die durch das IT-Service Management zu liefernde Transparenz in Ihrer Organisation tatsächlich gewollt? Dies betrifft z.B. Transparenz hinsichtlich» » » » »

Kundenstruktur, Kundenanforderungen und Kundenzufriedenheit Inhalt und Qualität der IT-Services Qualität und Leistungsfähigkeit der eigenen IT-Prozesse Leistungsstruktur und Verantwortung für die Leistungserstellung Qualität und Leistungsfähigkeit der eingesetzten Dienstleister

Seite 27 von 54

5 Vorgehen und Umsetzungserfahrungen Nachfolgend werden die wesentlichen Erfahrungen der befragten Bundesbehörden in der Umsetzung zusammengefasst. Diese werden entlang eines grundsätzlichen Vorge-hensmodells für die Implementation erläutert. Dieses Vorgehensmodell wird für die Ein-führung von IT-Service Management Prozessen empfohlen, ist aber allgemeingültig für organisatorische Veränderungsprozesse:

VisionWer wollen wir sein?

StandortbestimmungWo stehen wir heute?

ZieldefinitionWo wollen wir hin?

Planung & UmsetzungWie kommen wir dort hin?

KontrolleWie messen wir den

Fortschritt?

VerbesserungWie verbessern wir

kontinuierlich?

Ziele der Geschäfts- und IT-Strategie

Assessments und Analyse

Konkretisierte Ziele und meßbare Indikatoren

Prozeßentwicklung und -optimierung

Messung und Metriken

Abbildung 5 Methodik der IT-Service-Management-Einführung (Quelle: OGC2)

5.1 Vision

5.1.1 Einbindung der IT-Leitung und Unterstützung des Veränderungsprozesses Stets war die IT-Leitung von Beginn an in die Entscheidungen über die Umsetzung der Prozesse involviert. Oft war sie sogar der Auslöser für die ITIL-Umsetzung.

Beispiel In einem Fall sah sich die IT-Leitung als Mandant der Anwender und hat den Handlungsbedarf in den Gesprächen und aus den Vorgaben der Abteilungsleiterrunden formuliert. Hauptziel war die schnellere, bessere und verbindlichere Bedienung der IT-Anwender. Hier bestand die Vision darin, eine IT-Organisation zu schaffen, deren Serviceangebote, deren Leistungserstellung und deren Bezug externer IT-Dienstleistungen durchgängig managbar sind und die auf Grundlage von Standards in den Services, Vereinbarungen, Prozessen und der

2 „Planning to Implement Service Management“

Seite 28 von 54

Infrastruktur arbeitet.

! Hinweis Warum sich ein durchgängiges IT-Service Management generell nicht

ohne aktive Einbindung der IT-Leitung einführen läßt, hat diverse handfeste Gründe, z.B.: »

»

»

»

Die kunden- und serviceorientierte Ausrichtung der IT-Prozesse ist mit einem tiefgreifenden Wandel im Selbstverständnis der IT-Organisation verbunden. Dieser muss in erster Linie durch die IT-Leitung getrieben und gestützt werden. Die Definition von Services und die serviceorientierte Planung und Steuerung der IT-Ressourcen müssen der IT-Strategie entsprechen. Jeder Service-Management-Prozess greift über verschiedene Bereiche der IT-Organisation hinweg und erfordert von diesen verbindliche Mitwirkung. Die Regelung einer klaren und ungeteilten Prozessverantwortung hat Auswirkungen auf die Organisation: Mit dem Management von durchgängigen Prozessen müssen auch entsprechende Kompetenzen geregelt werden. Diese ermöglichen dann in bestimmten Fällen, dass sich Bereichsentscheidungen mitunter auch einem gemeinsamen Prozessziel unterordnen. Diese Matrixorganisation muss von der IT-Leitung gewünscht sein.

? Frage Wenn die Einführung von IT-Service-Management-Prozessen nicht direkt

von der IT-Leitung ausging: »

»

»

»

Ist die grundsätzliche Bereitschaft in der IT-Leitung gegeben, sich mit den Best Practices auseinanderzusetzen? Ist das Wissen in der IT-Leitung darüber ausreichend vorhanden, worin der Mehrwert konkreter ITIL Best Practices zur Erreichung ihrer Ziele besteht? Sieht die IT-Leitung mit den ITIL-Best-Practices derzeit ein Instrument, das sie gezielt zur Erreichung konkreter Ziele einsetzt – sieht sie also einen Sinn in der Umsetzung? Ist die IT-Leitung grundsätzlich dazu bereit, das Zusammenwirken ihrer Bereiche verbindlich in Prozessen zu regeln und dafür klare Verantwortung zu schaffen?

5.1.2 Formulierung der Vision Die Vision sollte Aussagen über die künftige Positionierung der IT-Organisation zulas-sen. Die Vision lenkt ganz wesentlich die Umsetzungstrategien. Wenn das IT-Service Management das Managementinstrument für die kunden- und serviceorientierte Steue-rung der IT ist, dann sollte die Vision deutlich machen, was dies für die Kunden und die eigene IT-Organisation bedeutet. Die Bedeutung für die Bundesbehörden lässt sich z.B. aus der eGoverrment-Strategie oder aus vergleichbaren Regierungsprogrammen ablei-ten.

Seite 29 von 54

Beispiel Eine der befragten IT-Organisationen nimmt die Herausforderung an, ihre Services verstärkt als Shared Service Center anderen Behörden in einer hohen Qualität und Effizienz bereitzustellen, und ihnen hiermit Synergiepotenziale innerhalb der Bundesverwaltung zu erschließen. Dies macht eine kunden- und serviceorientierte Ausrichtung der IT zwingend notwendig.

! Hinweis Die Service-Management-Vision begleitet die IT-Mitarbeiter fortwährend

im Veränderungsprozess. Sie beschreibt das künftige Selbstverständnis der IT-Organisation und deren serviceorientierte Rolle in der Gesamtorga-nisation. Wenn diese frühzeitig festgeschrieben wird, schafft dies Klarheit und Akzeptanz für alle. So manche Diskussion wird später dadurch abge-kürzt weil diese strategische Vorgabe nicht in Frage gestellt oder zerredet werden kann.

! Hinweis Die Veränderung braucht Unterstützer. Wichtige Unterstützer benötigen Sie bei den Kunden, unter den IT-Anwendern, in den eigenen Reihen der IT-Mitarbeiter, in Bereichen, mit denen der IT-Betrieb intensiv zusammen-arbeitet (wie z.B. Softwareentwicklung, Beschaffungsmanagement, Ver-tragsmanagement, Controlling, etc), mitunter auch bei Partnern und Dienstleistern. Jeder dieser Unterstützer profitiert in anderer Weise von der Vision und liefert mitunter seinen ganz eigenen Beitrag. Deshalb ist wichtig, die Vision individuell an diese zu kommunizieren. Mitunter führt die Kommunikation der Vision auch zu sinnvollen Diskussio-nen und zur Konkretisierung. In jedem Fall ist das Verständnis der Vision wichtig, um Menschen, Prozesse und Werkzeuge in der richtigen Weise auf die Umsetzung auszurichten.

? Frage Sind die für die Umsetzung der Vision notwendigen Unterstützer

(Stakeholder) identifiziert?

? Frage Transportiert die Vision die wesentlichen Aspekte des Veränderungsbedarfs? » » »

»

Macht sie die Entwicklungsrichtung verständlich? Motiviert sie zur aktiven Unterstützung des Veränderungsprozesses? Ist sie eine plausible Grundlage für das Zusammenwirken aller Beteiligten? Stellt sie die Sicht der IT-Leitung unmissverständlich heraus?

? Frage Sind die Ausrichtung der IT an den Kunden- und Geschäftsprozessanforderungen sowie der Beitrag der IT-Organisation für die Kunden zentrale Aspekte der Vision? Läßt sich daraus ableiten, warum diese Ausrichtung zu Veränderungen in den Prozessen der IT führen muss?

? Frage Ist die Vision kommuniziert, wird sie verstanden und wird sie geteilt?

Seite 30 von 54

5.2 Standortbestimmung Hinsichtlich der Bedeutung einer Bestandsaufnahme und einer Analyse der Problemsi-tuation waren sich die Bundesbehörden einig.

! Hinweis Wer etwas nachhaltig verändern will, um es zu verbessern, muss den Nutzen formulieren können. Kann er dies nicht, wird ihm die Unterstützung versagt. Wer den Nutzen formulieren will, muss das zu lösende Problem verständlich machen. Dieses muss von den Beteiligten verstanden und geteilt werden. Gleichzeitig müssen die Rahmenbedingungen für die Ver-änderung bekannt sein – wer also etwas verändern will, sollte das zu be-ackernde Feld, die Eckpfeiler und Stolpersteine kennen. Nur dann kann er die Chancen, die Umsetzbarkeit und die Risiken richtig einschätzen. Sonst wird er zum Spielball der unterschiedlichen Interessen, Vorbehalte oder Vorschubargumente, die Veränderung mitunter unmöglich machen.

! Hinweis Ein optimaler Umfang und der daraus resultierender Aufwand für die Be-standsaufnahme lässt sich nicht pauschal abschätzen. Grundsätzlich ist darauf zu achten, dass die Ist-Aufnahme so tiefgründig ist, dass die Schwachstellen und Lösungsansätze überzeugend sichtbar werden. Auf der anderen Seite besteht bei einer zu feingliedrigen Aufstellung die Ge-fahr, dass über einen langen Zeitraum Ressourcen gebunden werden und sich für eine Akzeptanz der Veränderungen notwendige schnelle Umset-zungserfolge nur sehr spät einstellen. Mitunter verselbständigen sich Analysephasen und manchmal entfernen sie sich auch mit fortschreiten-der Zeit vom eigentlichen Ziel. Dies ist zu vermeiden. Es gilt demnach, eine optimale Dokumentations- und Erhebungsform durchzusetzen, die beiden Ansprüchen gerecht wird.

! Hinweis Zwei wesentliche Aspekte sollten aus der Standortbestimmung für jeden Einzelnen ableitbar sein, dessen Unterstützung wir brauchen: » »

Dringlichkeit der Veränderung: Was passiert, wenn nichts passiert? Motivation zur Veränderung: Was ist für mich dabei drin?

In der Praxis treten bereits hier häufig die Probleme zu Tage. Nicht selten wird der akzeptierte Nutzen als selbstverständlich vorausgesetzt. Das Nutzenverständnis ist aber so gut wie nie selbstverständlich. Dies gilt erst recht, wenn dieser Nutzen nur mit Aufwand realisierbar ist. Die Standortbestimmung muss also belastbar sein. Es schadet nicht, sich an den kritischsten Stimmen zu orientieren, wenn der Veränderungsbedarf und die Richtung der Veränderung plausibel zu begründen sind. Wenn diesen Fragen aus dem Weg gegangen wird oder die Standortbe-stimmung nicht im ausreichenden Maße erfolgt, dann werden die latenten Akzeptanzprobleme erst später mitten im laufenden Projekt sichtbar – und dies nicht einmal direkt, sondern vielmehr als Ursache für platzende Ter-mine und langsam versandende Maßnahmen oder aber für heftige Dis-kussionen um die Angemessenheit der Konzepte und deren Umsetzung.

! Hinweis Die Standortbestimmung sollte neben der Analyse des vorhandenen Pro-zess- und Toolumfelds folgende Fragen beantworten: » Compliance-Status: Wie erfüllen wir mit bestehenden Abläufen und

Verantwortungen unsere Verpflichtungen aus Gesetzen, Verträgen,

Seite 31 von 54

Richtlinien und gültigen Normen »

»

»

Reifestatus: Welchen Reifegrad haben unsere Prozesse bzw. Abläufe und Praktiken derzeit erreicht? Qualität und Sicherheit: In welcher Weise gewährleisten unsere Pro-zesse derzeit die Qualitäts- und Sicherheitsanforderungen an unsere IT-Services? Performance und Effizienz: In welcher Weise gewährleisten unsere Prozesse derzeit die Anforderungen an die Leistungsfähigkeit und Wirtschaftlichkeit in der Servicebereitstellung?

? Frage Sind die mit Hilfe von Prozessen im IT-Service Management zu lösenden

Probleme analysiert, formuliert und hinsichtlich Chancen und Risiken bewertet?

? Frage Berücksichtigen die ermittelten Chancen und Risiken die Sichtweisen unterschiedlicher Adressaten in der Organisation, deren Unterstützung wesentlich für den Veränderungsprozess ist?

? Frage Sind die Ergebnisse der Standortbestimmung qualitätsgesichert und den wesentlichen Adressaten bekannt?

? Frage Wird das Problemverständnis von allen geteilt und wurde dies als Grundlage für das weitere Vorgehen abgestimmt und festgehalten?

? Frage Wurden auch die „kritischen Geister“, deren Unterstützung im Veränderungsprozess benötigt wird, einbezogen und ihre Sichtweisen in der Bewertung ausreichend berücksichtigt?

? Frage Sind die Bedürfnisse der unterschiedlichen Adressaten (Stakeholder) bekannt und transparent gemacht?

Die Analysephase sollte sich also nach Erfahrung der befragten Behörden auf die For-mulierung der Probleme, die Konkretisierung der Umsetzungsziele und die Erhebung der kritischen Rahmenbedingungen konzentrieren. Das Ergebnis sollte dokumentiert und Grundlage für konkrete Umsetzungsentscheidungen sein. Und es sollte von den Entscheidern umfassend akzeptiert werden können, damit das Projekt den nötigen Rü-ckenwind erhält. Dies wird durch die Qualität und Effizienz der Bestandsaufnahme we-sentlich beeinflusst.

5.3 Zieldefinition Zunächst muss festgestellt werden, dass in allen befragten Behörden die klare Zieldefinition als ein immens wichtiger, aber auch schwieriger Aspekt angesehen wurde. Wie konkret können und müssen die Ziele zu Beginn formuliert werden, um eine gezielte Umsetzung zu ermöglichen? Und sind diese Ziele angemessen – was die Problemsitua-tion, aber auch die Umsetzbarkeit betrifft?

Beispiel In einem Fall wurde darauf hingeweisen, dass das Projekt eine „phase of blame“, also einen Ernüchterungszyklus durchmachte. Man hat hier festgestellt, dass die Ziele nicht im abgesteckten Rahmen erreichbar

Seite 32 von 54

waren, diese dann überdacht und heruntergeschraubt. Zudem wurden die möglichen Schnelleffekte (quick wins) gesucht und mit den Qualitätseffekten durch den Service Desk sowie mit der Prozessvereinfachung durch eine gute Toolunterstützung gefunden. Zudem wurde festgestellt, wie wichtig es ist, die Ziele anderer parallel laufender Projekte zu kennen, um diese ggf. zeitnah zu unterstützen oder aber Ziel- und Ressourcenkonflikte mit diesen rechtzeitig sichtbar zu machen. Dies scheint angesichts der Personalbindung in solchen Veränderungsprozessen ein wesentlicher Punkt, denn die Schlüsselpersonen in der ITIL-Umsetzung sind mit hoher Wahrscheinlichkeit zugleich auch die Schlüsselpersonen in anderen IT-Projekten. Dies macht deutlich, warum die Standortbestimmung so wesentlich ist, bevor die Umsetzungsziele konkretisiert werden.

! Hinweis Zunächst soll darauf hingeweisen werden, dass es einen wesentlichen

Unterschied zwischen allgemeinen Prozesszielen und konkreten Umsetzungs- bzw. Optimierungszielen gibt. Ein allgemeines Ziel im Incident Management ist, Störungen schnell zu beheben und damit die Serviceverfügbarkeit zu verbessern. Dieses Ziel lockt aber keinen Entscheider oder Mitarbeiter hinterm Ofen vor, wenn nicht klar ist, worin das Problem in der eigenen Organisation derzeit besteht. Dies könnte z.B. mit Feststellungen verbunden sein, wie 85% der Störungen erfordern die Mitwirkung von Spezialisten im Betrieb oder 30% der Störungen können nicht in angemessener Frist behoben werden. Daraus lässt sich ein Handlungsbedarf begründen und ein Verbesserungsziel konkretisieren. Das Problem in der Frühphase der ITIL-Umsetzung ist meist, dass diese Messgrößen noch nicht zur Verfügung stehen. Dann ist es ein notwendiges Ziel des Managements, diese Transparenz zu schaffen. Die Ziele sollten zweistufig definiert werden: 1. Ohne Ziele kann es kein Projekt geben. Sie müssen also definiert

werden. Im Rahmen der Projektinitialisierung sind die Umsetzungsziele i.d.R. noch allgemeiner gefasst. Aus ihnen sollten sich aber bereits Schwerpunkt und Prioritäten des Projekts nachvollziehbar ableiten lassen.

2. Im Ergebnis der Standortbestimmung (Analyse) sollten die konkret zu lösenden Probleme nachvollziehbar sein und daraus die Umsetzungsziele verfeinert werden. Dies ist jetzt entscheidend dafür, ob die benötigten Schlüsselpersonen im Projekt anschließend ihre Mitwirkung im erforderlichen Maß priorisieren, weil sie den Benefit dieser Maßnahmen akzeptieren. Für die IT-Leitung und die Projektleitung sind diese Feinziele Grundlage für die Erfolgsmessung.

! Hinweis Eine Möglichkeit der Erfolgsmessung in Folge der Prozesseinführung liefern Prozess-Assessments. Diese Überprüfungen messen z.B. den Reifegrad des Prozesses anhand formaler Kritierien und stellen die Vergleichbarkeit der Prozesse hinsichtlich ihres Reifegrades her. Heute

Seite 33 von 54

basieren derartige Assessments überwiegend auf dem Capability Maturity Modell (CMM/CMMI, ISO 15504)3. Im Ergebnis solcher Prozess-Assessments werden Ziele zur fokussierten Weiterentwicklung konkreter Prozesse formuliert. Auch wenn der Prozess also selbst keine Probleme verursacht, sollte er trotzdem kontinuierlich weiterentwickelt werden. Oft sind diese konkreten Probleme ja deshalb nicht bekannt, weil die Managbarkeit des Prozesses nicht gewährleistet ist. Genau dies stellen Prozesse mit höherem Reifegrad sicher. Es liegt also nahe, in den richtigen Schritten eine höhere Prozessreife anzustreben. Wer behauptet, dies wäre nicht für jeden Prozess sinnvoll, muss sich die Frage gefallen lassen, wie er Verbesserungen in seinem Prozess gezielt erkennt, plant, umsetzt und den Umsetzungserfolg kontrolliert. Für nähere Informationen zu den Assessment-Standards und deren Einsatz wird die bereits genannte KBSt-Studie empfohlen.

? Frage Sind neben den grundsätzlichen Prozesszielen auch konkrete

Umsetzungsziele formuliert?

? Frage Sind diese Ziele so formuliert, dass deren Erreichung tatsächlich eingeschätzt werden kann?

? Frage Leiten sich diese Ziele ausreichend klar aus den Chancen und Risiken im Ergebnis der Standortbestimmung ab, so dass diese plausibel sind?

? Frage Werden die zu schließenden Lücken zur derzeitigen Situation aus den Zielen sichtbar, so dass Gegenstand, Umfang und Inhalt der notwendigen Veränderungen ableitbar sind?

? Frage Sind diese Lücken priorisiert, so dass allen die Bedeutung bewusst ist?

? Frage Wurden sogenannte quick win’s – also kurzfristig erreichbare Erfolge – identifiziert, abgestimmt und gezielt eingeplant, um die Wirksamkeit bestimmter Maßnahmen zügig nachweisen zu können?

5.3.1 Einführung von Managementgrundsätzen Überwiegend wurde die Leistung der IT in den betroffenen Prozessfeldern ohne IT-Ser-vice Management als nicht steuerbar und für die Führungskräfte intransparent angese-hen. Dies betraf vor allem die Qualität der Leistungserstellung für Anwender und interne Kunden. Daher war in nahezu allen Fällen die Steuerbarkeit der Prozesse in der IT und die Fähigkeit zur kontinuierlichen Verbesserung ein zentrales Leitziel.

5.3.2 Standardisierung der IT-Prozesse Stets bestand das Ziel in einer Standardisierung der Rollen und Abläufe in den betref-fenden Prozessen. Dies wurde als Grundlage für die tägliche Sicherstellung der Qualität, die angemessene Qualifizierung des Personals, die Effizienz in den Abläufen sowie die Steuerbarkeit und Kontrollierbarkeit der Leistungserstellung gesehen. Letztere sind

3 Siehe KBSt-Studie „ITIL und Standards für IT-Prozesse“

Seite 34 von 54

grundsätzliche Anforderung an die Führungstätigkeit in der IT und ermöglichen erst die kontinuierliche Verbesserung. Dies schloss ein: » » » » » » »

»

»

Klare Rollendefinition und Schaffung eines Rollendenkens bei den IT-Mitarbeitern Festlegung der Rollen-Verantwortung – nicht nur der Aufgaben Klare Rollenzuweisung an konkrete IT-Mitarbeiter Gezieltere Qualifizierung des Personals auf Grundlage der Rollenanforderungen Definition und Abgrenzung der IT-Prozesse Festlegung konkreter Prozessschnittstellen für die Zusammenarbeit Beschreibung der Prozessabläufe im richtigen Maße

5.3.3 Effizienzsteigerung Das Kriterium Effizienz haben die befragten Bundesbehörden nicht nur auf die Wirt-schaftlichkeit der eigenen Abläufe bezogen. Hier ging es auch um die Effizienz auf der Seite der IT-Anwender. Dies liefert auch außerhalb der IT-Organisation einen wesentli-chen Hebel und Argumente für den Veränderungsprozess auf der Kundenseite. Letztendlich ging es überwiegend darum, alle Beteiligten in den Prozessen – Anwender wie IT-Mitarbeiter - von unnötiger Last zu befreien und die Abläufe flüssiger zu gestal-ten. Effizienzsteigerung für die Anwender hat aber auch wiederum viel mit der Zuverläs-sigkeit der IT-Services zu tun, die sie für ihre Tätigkeit benötigen. Hier greifen die Ziele ineinander. Dies schloss ein:

Vereinfachung bestehender Prozesse (z.B. Beschaffung, Lieferung und Rollout neuer Hardware und Bezug externer Dienstleistungen) Effizienzsteigerung für die Anwender, indem ihnen der Umgang mit der IT-Schnitt-stelle erleichtert wird oder die Servicequalität verbessert wird

Beispiel In einem Fall sah sich die IT-Organisation mit einem notwendigen Stellen-

abbau um 9 Stellen von ursprünglich 24 innerhalb von 12 Monaten kon-frontiert. Dies setzte voraus, dass die im Haus zu erstellenden Leistungen effizienter organisiert werden und andere zu externen Dienstleistern ver-lagert werden.

5.3.4 Servicestandardisierung In den Fällen, in denen die Leistungsangebote und Auftragsschnittstellen der IT transpa-rent gestaltet werden sollten – oder gar Grundlagen für eine Serviceplanung oder für die Kostentransparenz in Services geschaffen werden sollten, wurde die Servicestandardi-sierung zum Ziel erhoben. Dies schloss ein: » »

Formulierung der Serviceangebote Festlegung verbindlicher Servicezeiten

Seite 35 von 54

»

»

» » »

»

»

» » »

»

» »

Standardisierung der Auftragsschnittstellen und Beauftragungsverfahren für das Standardgeschäft und Regelung dieser in SLA Schaffung der Grundlagen für eine klare Kostenabgrenzung in den Services und ihre spätere Verrechnung

5.3.5 Anforderungen aus neuen IT-Prozessen Teilweise war das Ziel, auch neue IT-Prozesse zu unterstützen, die höhere Anforderun-gen an das IT-Service Management stellen. Dies betraf z.B.:

Software-Lizenzmanagement IT-Beschaffung (zentrale und dezentrale Teilprozesse) Anwendungs- und Systemüberwachung (Monitoring)

5.3.6 Sicherstellung der Support- und Delivery-Aufgaben Daneben wurden natürlich eine ganze Reihe von Zielen formuliert, die dazu beitragen, das operative Geschäft der IT mittels IT-Service Management zu optimieren. Dies schloss ein:

Schaffung eines bekannten und akzeptierten Single points of contact für die Anwen-der (Service Desk) Abschaffung des „Hey-joe“-Prinzips, bei dem die Anwender direkt auf die jeweiligen Spezialisten zugreifen Sicherstellung der Reaktionsfähigkeit außerhalb der Servicezeiten Nachvollziehbarkeit von Betriebsdaten und Dokumentation Nachvollziehbarkeit der Supportvorgänge und deren Abarbeitung in dokumentierten Tickets, um die Leistung und Qualität im Support objektivieren zu können Steuerbarkeit externer Dienstleister im Tagesgeschäft und in der gezielten Entwick-lung der Dienstleisterbeziehungen Verbindlichkeit der Servicezusagen über angemessene SLA mit Kunden Verbindlichkeit der Servicezusagen über Dienstleistervereinbarungen (Provider-SLA4)

5.3.7 Optimierung der Outsourcing-Schnittstelle In einem Fall führte die unklare Serviceschnittstelle und Rollenverteilung mit dem exter-nen Dienstleister zu Problemen in der eigenen IT-Organisation. Hier bestand ein Ziel in der Klärung der Supportabläufe über beide Einheiten hinweg.

4 In der ITIL-Terminologie werden diese zusammen mit anderen Dienstleisterverträgen als Underpinning

Contracts (UC) – also als Absicherungsverträge bezeichnet.

Seite 36 von 54

Beispiel Wurden Supportvorgänge vom Dienstleister in den Tickets erfasst und an-schließend daraus Aufgaben an interne IT-Mitarbeiter weitergeleitet, so haben diese die Aufgaben als Aufträge vom Dienstleister verstanden, was mitunter zu Unmut und Missverständnissen führte. Die Mitarbeiter haben sich gegenüber dem Outsourcing-Partner in der Rolle eines Kunden ver-standen und einige fühlten sich hier als „verlängerte Werkbank“ ihres Dienstleisters missbraucht. Dies führte zu Akzeptanzproblemen und Rei-bungsverlusten in der Abwicklung der Vorgänge. Deshalb bestand ein Ziel darin, die Servicekultur in der eigenen IT-Organisation im Sinne eines zu-verlässigen IT-Betriebs zu entwickeln und über klare Serviceziele, Rollen-verantwortung und durchgängige Abläufe die Zusammenarbeit zwischen den Prozessbeteiligten zu verbessern. Damit sollten auch klare Anforde-rungen an die internen Rollen formuliert und das Verständnis hierfür ge-schaffen werden.

5.3.8 Standardisierung in der IT In der Standardisierung der IT-Infrastruktur wurde in einigen Fällen eines der zentralen Ziele gesehen. Dies schloss ein: » »

Erhöhung des Anteils standardkonformer IT-Komponenten Anpassung der bestehenden Standards an die aktuellen Kundenanforderungen

Beispiel In einem Fall wurde eine Standardisierung der dezentralen Infrastruktur

für Anwender mit angestrebt. Dies betraf die Standards für Hardware, für Software und für deren gemeinsame Konfiguration in Form von Arbeits-platztypen. Ziel war, dass diese Planung einen Horizont von bis zu 5 Jah-ren berücksichtigt und in regelmäßigen Abständen an sich verändernden Bedarf angepasst wird. Dies führte auch zu Anforderungen an ein Release Management für Hardware, Software und komplette Desktop-Arbeitsplatz-ausstattungen. Ein großer Zielkonflikt hat sich hier aus den gültigen Ausschreibungsbe-dingungen ergeben, die eine langfristige Abstimmung von Produktstan-dards und Lieferantenbeziehungen kaum zulassen. Angesichts der Tatsa-che, dass der überwiegende Teil der Lebenszykluskosten für dezentrale Komponenten nicht die reinen Anschaffungskosten sind sondern Kosten der Leistungserstellung im Betrieb und Support, richten sich die Wirt-schaftlichkeitsanforderungen zunehmend auf die Prozesse und Dienstleisterschnittstellen. Die Lieferanten sind i.d.R. auch Leistungs-ersteller – mindestens im Rollout. Häufige Lieferantenwechsel sind des-halb auch immer mit der Veränderung bestehender Abwicklungsprozesse in der IT verbunden. Diese Anpassungs- und Integrationsaufwände sind nicht zu unterschätzen, aber meist nicht direkt messbar und fallen i.d.R. vor allem in der ausschreibenden Behörde an. Deshalb bestand hier auch ein Ziel darin, mit der Klärung eigener Prozessstandards zumindest ge-nauere Prozessanforderungen an die Lieferanten in die Ausschreibungen einfließen lassen zu können, um diese Aufwände zu senken und teilweise auf die Lieferanten verlagern zu können, die sich auf ihren Kunden proze-

Seite 37 von 54

dural einstellen sollen. Das grundsätzliche Problem der Durchsetzbarkeit langfristiger Standardisierungsstrategien ist damit aber nicht gelöst. Dies ist auch heute noch so.

5.3.9 Erwartungen der IT-Leitung an das Vorgehen Die IT-Leitung erwartete i.d.R. ein strukturiertes, nachvollziehbares und planbares Vor-gehen für die Umsetzung. Dieses sollte bereits bei der Erkennung und Formulierung der Optimierungsansätze beginnen und bis zum erfolgreichen Abschluss der Maßnahmen reichen. Keine der befragten Bundesbehörden sah die Möglichkeit, derartige Veränderungen ohne ein projekthaftes Vorgehen – also begleitend aus dem Tagesbetrieb heraus – zu bewältigen. Vielfach wurde auf die notwendige Projektorganisation und die richtige Be-setzung der Projektrollen hingewiesen. Dies schloss auch die Berufung eines Lenkungs-ausschusses und die Besetzung mit der IT-Leitung ein. Als besonders wesentlich wurde im Rückblick in allen Fällen die notwendige Kommuni-kation gesehen. Vielfach wurde darauf hingewiesen, dass die Kommunikation stetig projektbegleitend erfolgen müsse und für die verschiedenen Beteiligten (Stakeholder) auch unterschiedliche Formen der Information und Kommunikation genutzt werden müssen. Die IT-Leitung forderte i.d.R. klare Maßnahmenpläne und nahm sich das Recht heraus, konkrete Maßnahmen einzeln zu beauftragen, sobald die Voraussetzungen hierfür plau-sibel gegeben waren.

5.3.10 Einbindung der Kunden und Dienstleister In nahezu allen Fällen wurde auch die Leitungsebene der Behörde frühzeitig in den Veränderungsprozess eingebunden. Hierbei ging es darum, Ausgangssituation, Hand-lungsbedarf und die geplanten Vorhaben abzustimmen. Damit wurden das Verständnis und die Unterstützung auf der Kundenseite eingeworben. In den Fällen, wo bereits enge Dienstleisterbeziehungen bestanden, wurden auch die Outsourcing-Partner direkt in den Veränderungsprozess involviert. Die Prozesse wurden dann in einigen Fällen auch gemeinsam entwickelt, um die Dienstleisterschnittstellen passend zu gestalten.

5.4 Planung und Umsetzung

5.4.1 Verbindlichkeit der ITIL-Empfehlungen In allen Fällen wurden die ITIL-Standards nicht als Dogma betrachtet. Vielmehr ging es darum, diejenigen Empfehlungen zum passenden Zeitpunkt zu übernehmen, die verstanden wurden und die geeignet waren, konkrete Ziele besser zu erreichen.

! Hinweis Die ITIL-Empfehlungen wirken in vielen Aspekten zunächst abstrakt. Sie liefern aber wesentliche Impulse für eine konkrete Umsetzung. Häufig beschreiben sie, WAS sichergestellt werden sollte, manchmal auch beispielhaft, WIE dies umgesetzt werden sollte. Man muss aber generell

Seite 38 von 54

zur Kenntnis nehmen, dass die Empfehlungen nicht das eigene Umsetzungskonzept ersetzen können.

! Hinweis Wie kann dann aber ITIL-Konformität der eigenen Prozesse nachgewiesen werden? Wenn man sich an verbindlichen Anforderungen orientieren möchte, dann sollten hierfür die Prüfkritierien des Standards ISO 20000 zugrunde gelegt werden. Der Part 1 definiert notwendige Kriterien für wirksame ITIL-Prozesse. Part 2 liefert zusätzlich weitergehende Empfehlungen dazu, was diese leisten sollten. Nähere Informationen dazu können der bereits genannten KBSt-Studie „ITIL und Standards für IT-Prozesse“ entnommen werden.

5.4.2 Organisation des Umsetzungsprojekts Überwiegend wurden die Einführungsmaßnahmen als Projekt beschlossen und organi-siert. In Einzelfällen war dies zunächst nicht der Fall. Hier wurde im Rückblick unmissver-ständlich geschlussfolgert, dass dies ein Fehler war, der auch später korrigiert wurde. Wenn die Veränderungen ausschließlich Thema von Besprechungen in unterschiedli-chen Gremien und Workshops waren, dann erwies sich dieser Weg nicht als plan- und steuerbar und führte auch nicht zu den gewünschten Effekten. Unabhängig von den verfehlten Zielen wurde in diesen Fällen der „gefühlte“ und nicht direkt messbare Auf-wand als nicht gerechtfertigt angesehen.

! Hinweis Mehrere handfeste Gründe erfordern ein projekthaftes und strukturiertes Vorgehen: » »

»

»

»

»

»

»

Die Umsetzung muss auf Grundlage abgestimmter Ziele erfolgen. Die Ziele sollten den tatsächlichen Handlungsbedarf treffen, der nur im Ergebnis einer angemessenen Analyse klar formuliert werden kann. Vor Umsetzung sind die Maßnahmen zu autorisieren, damit sie auch verständlich und durchsetzbar sind. Die Umsetzung selbst muss verschiedene Abhängigkeiten berücksichtigen, weshalb die Maßnahmen zeitlich und inhaltlich aufeinander abzustimmen sind. Die Veränderungen betreffen zudem verschiedene Ebenen in der Prozess-, Daten- und Toollandschaft, die im Zusammenhang zu managen sind. Ohne Ressourcenbereitstellung, Priorisierung und Terminierung verlaufen die Maßnahmen häufig im Sande, weil die Schlüsselpersonen i.d.R. ohnehin stark beansprucht sind und sich mitunter auf dringliche Aufgaben in anderen Projekten und im Tagesgeschäft konzentrieren. Zwischenergebnisse sind mangels definierter Meilensteine kaum messbar. Eine gezielte und effiziente Einbeziehung der Prozessbeteiligten und eine laufende Kommunikation zum Maßnahmenfortschritt ist ohne Projektvorgehen selten durchzuhalten.

Letztendlich stagniert die Umsetzung ohne Projektsteuerung. Die

Seite 39 von 54

Motiviation der Beteiligten, die Akzeptanz der Betroffenen und das Vertrauen der Führungskräfte in den Veränderungsprozess lässt dann stetig nach.

! Hinweis Mit höherem Reifegrad des Prozesses nimmt die Fähigkeit des Prozessverantwortlichen zu, diesen kontinuierlich zu verbessern. Die Kontrolle und Optimierung des Prozesses ist eine Daueraufgabe, die hinsichtlich des Ressourcenbedarfs im Prozessmanagement stets zu berücksichtigen ist und je nach Prozessreife unterschiedlichen Aufwand nach sich zieht. Ob dann konkrete Optimierungsmaßnahmen projekthaft zu organisieren sind, hängt von ihrer Komplexität ab. Die Einführung oder das Reengineering eines Prozesses erfordern in jedem Fall Projektsteuerung.

Zudem bestätigten die befragten Bundesbehörden einhellig, dass die Abhängigkeiten zwischen den Prozessen und zwischen den Verfahren innerhalb der Prozesse nicht zu unterschätzen sind und dass auch deshalb eine Steuerung der Maßnahmen unverzicht-bar ist. Es wurde darauf hingewiesen, dass deshalb auch die Koordination der Teilpro-jekte und die Harmonisierung der Fachkonzepte für die Prozessgestaltung ein anfangs unterschätzter Aspekt ist.

! Hinweis Als sinnvoll erweist sich, neben den konkreten Prozesskonzepten ein Big Picture der Prozesslandschaft (Prozessarchitektur) zu pflegen, aus dem schnell die Abgrenzung und die Schnittstellen hervorgehen. Zu empfehlen ist auch, dass ein solches Prozessschaubild gleich zu Beginn entworfen und mit den Prozessen mitentwickelt wird. Die konkrete Ausprägung von erforderlichen Schnittstellen erfolgt überwiegend in der Prozessgestaltung. Wichtig ist, dass diese Anforderungen in die Teilprojekte zurückfließen, die Partnerprozesse entwickeln. Sonst laufen die Prozesskonzepte auseinander oder überlappen in den Abläufen und Verantwortungen.

5.4.3 Schwerpunkte und Umfang des Umsetzungsprojekts Mit ITIL wird stets die Umsetzung konkreter Prozesse im Rahmen eines genau abge-steckten Umfangs bzw. Schwerpunkts (Scope) empfohlen. Der Scope beeinflusst we-sentlich die Komplexität des Projekts und damit seine Dauer und die Umsetzungsrisiken. Der Scope kann also auch recht ungünstig gewählt werden, weil er zu weit oder zu eng gefasst wird. Bei den befragten Behörden hat es sich häufig als günstig erwiesen, den Scope zugleich in zweierlei Hinsicht zu beschränken:

1. Fokussierung auf konkrete Prozesse 2. Fokussierung auf konkrete Pilotservices

Beispiel In einer Behörde wurden zunächst 4 Pilotservices definiert. Diese wurden

nach verschiedenen Kriterien ausgewählt, so dass folgende Aspekte be-rücksichtigt wurden:

Seite 40 von 54

Bereitstellung einer kritischen Anwendung für ein internes Fachverfah-ren

Bereitstellung einer Anwendung, die auch von externen Kunden - also anderen Bundesbehörden – genutzt wird

Bereitstellung einer Anwendung für interne Verwaltungsabläufe mit Self Service für die Mitarbeiter der Behörde

! Hinweis Möglichst vor Beginn der Bestandsaufnahme – spätestens vor Beginn der

Umsetzungsplanung – sollte der Gestaltungs- und Geltungsbereich der einzuführenden Prozesse erarbeitet und mit dem Auftraggeber abgestimmt werden. Hierdruch wird der Fokus für die Erhebung und Analyse klarer gesetzt. Wer solche Umsetzungsprojekte bereits mehrfach begleitet hat, weiß, wieviel Aufwand hierdurch gespart und wie gezielt eine Bestandsaufnahme erfolgen kann. Gleichzeitig wird vermieden, dass Erwartungen an das ITIL-Projekt formuliert werden, die nicht Gegenstand der aktuellen Einführungsphasen sind. Schließlich wird man manchmal auch in dieser Phase auf Pfade gelenkt, die den Weg zum eigentlichen Ziel eher verlängern als beschleunigen. Hierbei soll aber auch darauf hingewiesen werden, dass der Scope kein Dogma ist. Wird während der Bestandsaufnahme festgestellt, dass dieser verlagert, eingeschränkt oder erweitert werden sollte, um wichtige Effekte zu erzielen die mit dem grundsätzlichen Optimierungsziel konform sind, dann sollte dies auch geschehen. Eine Änderung im Scope ist dann aber in jedem Fall ein bedeutsamer Projekt-Change, der entsprechend zu managen ist.

5.4.4 ITIL-Ausbildung Das Vorgehen in der ITIL-Ausbildung der Mitarbeiter war recht unterschiedlich. Besonders häufig wurde ein differenziertes Verfahren gewählt. Schlüsselpersonen in der Umsetzung – mitunter auch die Leitungsebene – nutzten zunächst standardisierte, ex-terne Ausbildungsangebote. In der Fläche erfolgte dann anschließend die Ausbildung intern im Rahmen eines Tutor-Verfahrens. Hier wurde also aus Praktikabilitäts- und Wirtschaftlichkeitsgründen ein zweistufiges Vorgehen gewählt, das sich aus Sicht der Behörden auch vollkommen bewährt hat. Schließlich ist die Ausbildung der beteiligten Mitarbeiter am konkreten Sollprozess meist effizienter und wirksamer als abstrakte ITIL-Schulungen. Mitunter wurde aber auch die Ausbildung aller IT-Mitarbeiter über Standardschulungen und deren Zertifizierung für sinnvoll erachtet.

Beispiel In einem Fall wurde der IT-Betrieb durch externe Mitarbeiter des Dienstleisters vor Ort unterstützt. Hier haben sich der Betriebsleiter der Behörde und der Betriebsleiter seitens des Dienstleisters einer Standard-ITIL-Ausbildung unterzogen und sich als Service Manager zertifizieren lassen. Das Training der Mitarbeiter verlief dann mit der Umsetzung aus eigener Kraft. Hier wurden im Projektverlauf die ITIL-Standards im Zusammenhang mit den Umsetzungsentscheidungen besprochen.

Seite 41 von 54

Beispiel In einem anderen Fall wurde ähnlich vorgegangen. Hier wurde betont, dass die Schulung der IT-Mitarbeiter in der Fläche sich an der konkreten Prozesspraxis der Behörde und nicht an den allgemeinen ITIL-Grundsätzen empfehlen sollte. Mit anderen Worten: Wer die Gestaltung der Prozesse steuert, der sollte die ITIL-Standards intensiv beherrschen. Wenn die IT-Mitarbeiter dann zu schulen sind, dann sollte diese Schulung die definierten Soll-Prozesse zum Gegenstand haben, in die diese Mitarbeiter konkret involviert sind oder deren Schnittstellen sie kennen müssen. Diese Schulungen erfolgen also eher im Zusammenhang mit der organisatorischen Einführung der Prozesse.

! Hinweis Eine Grundregel besteht darin, dass die betroffenen Mitarbeiter in den

Prozessen frühzeitig in die Gestaltung ihrer Abläufe einzubeziehen sind. Wieviel wissen über die Standards benötigen sie dann, um dieser Aufgabe auch gerecht werden zu können? Eine flächige ITIL-Zertifizierung der IT-Mitarbeiter ist selten notwendig und wirtschaftlich, wenn das benötigte Wissen intern vermittelt und geteilt wird. Dies ist aber zu organisieren. In der Konsequenz ist hier sinnvoll, dass die Schlüsselpersonen in der Konzeption und Umsetzung frühzeitig benannt und tatsächlich ausgebildet werden, sofern sie dieses Wissen nicht bereits nachweisen können. Der Wissenstransfer in die Fläche erfolgt dann bereits mit der gemeinsamen Entwicklung und Einführung der Soll-Prozesse. Dieses Ausildungskonzept sollte frühzeitig im Projektvorgehen formuliert werden.

! Hinweis Wenn es also um den Umfang der ITIL-Ausbildung geht, liegt die Wahrheit mitunter in der Mitte: Eine flächige Ausbildung würde die Umsetzung in größeren IT-Organisationen in die Länge ziehen und wäre sehr aufwändig. Langfristig ist für alle IT-Mitarbeiter im Support und Betrieb – insbesondere auch für deren Führungskräfte – eine ITIL-Grundausbildung sinnvoll. Alle Mitarbeiterinnen und Mitarbeiter in Rollen mit gestalterischer Verantwortung (z.B. Linienführungskräfte, Prozessverantwortliche, ITIL-Koordinatoren, …) sollten hierbei mittelfristig eine Standard-Ausbildung anstreben. Die zentralen, steuernden Rollen im IT-Service Management sollten dabei vor allem auf eine Ausbildung adäquat zum Service Manager fokussieren. Linienführungskräfte sollten verstärkt mit spezifischen Angeboten für das Management unterstützt werden. Die Prozessbeteiligten können zunächst intern trainiert werden. Es sollte zudem geprüft werden, ob nicht auch diese schrittweise nachträglich eine Grundausbildung entsprechend ITIL Foundation erhalten sollten, um die zugrundeliegenden Standards besser im Zusammenhang zu verstehen und so selbst aktiver in der Prozessverbesserung werden zu können. Ohnehin gewinnt diese Zusatzqualifikation im IT-Betrieb schnell an Bedeutung und ist damit auch immer häufiger verfügbar.

! Hinweis Die IT-Leitung der befragten Bundesbehörden hat tendenziell festgestellt, dass es an passenden Ausbildungsangeboten speziell für Führungskräfte in der IT mangelt. Die Standard-Angebote ITIL Foundation und ITIL Service Manager fokussieren sehr stark auf die fachlichen Prozessanforderungen und sind zeitintensiv. Wichtig wären für die Führungskräfte vor allem Angebote, die den sinnvollen und gezielten

Seite 42 von 54

Einsatz des ITIL-Instrumentariums in Verbindung mit einem Überblick über die konkreten Prozesse behandeln. Schließlich geht es hier darum, Chancen und konkrete Problemlösungsansätze zu erkennen, mögliche Benefits der Umsetzung richtig einschätzen zu können, Projektrisiken bewertbar zu machen und die Anforderungen an das Vorgehen in der Umsetzung zu verstehen.

! Hinweis Neben den Anforderungen an Ausbildungsangebote für die IT-Leitung wurde auch der Bedarf für spezifische fachliche Weiterbildungsangebote in konkreten Disziplinen des IT-Service Managements geäußert. Dies betraf z.B. Fragen rund um » »

die Implementation von Configuration Management die Einführung einer Problem-Datenbank

! Hinweis Was die Auswahl von Weiterbildungsangeboten für ITIL betrifft, wird hier explizit auf das Programm der BAKÖV innerhalb der Bundesbehörden hingewiesen. www.bakoev.bund.de Dieses liefert neben ITIL-Ausbildungen für die Mitarbeiterinnen und Mitar-beiter in der Bundesverwaltung auch das Simulationsspiel Apollo 13, in dem die Teilnehmer Praxissituationen in 4 Phasen trainieren.

5.4.5 Einheitliches Begriffsverständnis Als ein grundsätzliches Problem sehen alle befragten Bundesbehörden im Rückblick das einheitliche Verständnis der Begriffe im IT-Service Management. Dies betraf meh-rere Aspekte: »

»

»

Begriffe wie Störung, Problem, Fehler, Service, Call, Ticket, Leistung, etc. wurden in der Vergangenheit in unterschiedlicher Weise verwendet. Alle sahen die Notwendig-keit und auch die Chance, zu Beginn der Einführung zunächst ein einheitliches Beg-riffsverständnis zu schaffen und messen dem auch im Rückblick eine hohe Bedeu-tung bei. Dies senkt den Aufwand für zeitraubende Diskussionen und die Behand-lung der zahlreichen Missverständnisse. In einigen Fällen wurde hier eingeräumt, dass zuvor viel und lange aneinander vorbeigeredet wurde. Mit der Standardisierung der Begriffe gemäß ITIL wird aber ein neues Problem er-zeugt: Alle wesentlichen Begriffe sind englischsprachige Terminologie. Dies läuft mitunter den Bestrebungen in der Bundesverwaltung entgegen, einheitliche deutsche Begrifflichkeiten zu verwenden. Die Manager-Rollen in den ITIL-Empfehlungen führten in der Bundesverwaltung regelmäßig zu Diskussionen. Der Manager-Begriff wird in ITIL entweder für die Pro-zessverantwortung genutzt (im Sinne eines Prozess-Managers) oder aber für die Verantwortung für konkrete Bearbeitungsvorgänge (z.B. Verantwortlicher für einen kompletten Incident-Vorgang in der Störungsbearbeitung). In der öffentlichen Ver-waltung wird der Manager-Begriff enger gefasst. Wenn überhaupt, dann wird er i.d.R. für Rollen mit personellen Führungsaufgaben verwendet. Dies führte in einigen Be-hörden zu der Frage, ob diese Manager-Rollen eigentlich so benannt werden kön-nen. In einigen Fällen erzeugte dies auch Diskussionen, die bis zu Personalentwick-lungspfaden und Vergütungsfragen führten.

! Hinweis Wer keine gemeinsame Sprache findet, wird sich auch in der

Seite 43 von 54

Zusammenarbeit in gemeinsamen Prozesse schwer tun. Die Vereinheitlichung der zahlreichen Fachbegriffe im IT-Service Management ist ein wesentlicher Vorteil der ITIL-Standards. Dieser Nutzen sollte nicht unterschätzt werden. Dies gilt nicht nur für die interne Zusammenarbeit. Auch die Dienstleister und Werkzeuganbieter haben sich bislang nicht an standardisierte Begriffe gebunden gefühlt und das Begriffschaos oft für sich genutzt, um ihre Leistungen und Lösungen ansprechend zu verpacken. Diese Spielräume fallen nun weg, da die Kunden ein klares Verständnis von dem haben, was sie hinter diesen Schlagworten erwarten. Es spricht natürlich nichts dagegen, adäquate deutsche Begriffe zu wählen und diese dann konsequent zu verwenden; die Zuordnung zu den ITIL-Standardbegrifflichkeiten sollte aber klar fixiert sein.

5.4.6 Prozesseigentümer und Prozessverantwortlicher Wichtig erscheint, dass einzuführende Prozesse auch von der IT-Leitung gewollt und unterstützt werden. Sichtbar wird dies, wenn ein Prozess-Sponsor bzw. –Eigentümer festgelegt ist, der die Entwicklung des Prozesses treibt und die Ziele mit dem Prozess-verantwortlichen abstimmt. Hier gibt es in der konkreten Umsetzungspraxis der befragten Bundesbehörden alle Va-rianten: » » »

die Leitungsebene der IT nimmt diese Rolle gemeinschaftlich wahr ein konkreter Prozesseigentümer innerhalb der Leitungsebene ist benannt es gibt keine Trennung zwischen Prozessverantwortung und Prozesseigentümer

! Hinweis Wenn es einen Prozessverantwortlichen gibt, wer führt diesen dann? Wer

vereinbart mit ihm Prozessziele und wer unterstützt ihn in der Erreichung dieser Ziele? Die Prozessverantwortlichen für IT-Service Management Prozesse sind grundsätzlich in einer nicht simplen Situation. Sie sind verantwortlich für das Zusammenwirken aller IT-Mitarbeiter entlang der Linienorganisation innerhalb ihres eigenen Prozesses. Die Macht- und Entscheidungsstrukturen der Organisation definieren sich über die Linie. Welches Gewicht hat nun der Prozessverantwortliche, um aus den Suboptima dieser Strukturen in seinem Prozess ein Optimum für die gesamte IT-Organisation zu liefern? Wenn er die andere Seite dieser Matrixorganisation verantwortet, dann benötigt er konkrete Unterstützung und auch Führung. Wenn diese gemeinschaftlich durch das Leitungsteam der IT wahrgenommen wird, dann kommt dies in der Praxis meist einer nicht wirksamen Verantwortung gleich. Deshalb macht es Sinn, einen Prozesseigentümer (Process Owner) zu definieren, der in der oberen Leitungsebene der IT angesiedelt ist, der die konkreten Prozessziele mit dem Prozessverantwortlichen abstimmt, deren Erreichung kontrolliert und in Konfliktsituationen die Interessen der Gesamtorganisation in diesem Prozess wahrnimmt.

Seite 44 von 54

5.4.7 Rollendefinition Das Rollenverständnis in der IT-Organisation stellte tendenziell in den befragten Behör-den eine Herausforderung dar. Dies betrifft das Lösen von Stellen und Personen auf der einen Seite von Rollen und deren Funktionen auf der anderen Seite. Dies ist deshalb wesentlich, weil IT-Mitarbeiter stets in verschiedenen Prozessen kon-krete Aufgaben wahrnehmen, die in entsprechenden Rollen zu standardisieren sind. Damit übt jeder IT-Mitarbeiter unterschiedliche Rollen in der IT-Organisation aus. Mit-unter wechselt er im Prozess auch zwischen den Rollen, die er neben seiner funktiona-len Zuordnung in einer Organisationseinheit wahrnimmt. Wenn die Aufgaben, Befugnisse und Qualifikationsanforderungen an die Rollen formu-liert sind, liefert das auch Transparenz für die Mitarbeiter, was die Anforderungen an ihr persönliches Stellenprofil betrifft. Eine der wesentlichen Erfahrungen ist, dass gegenüber der Gestaltung von Abläufen zunächst zu wenig Aufmerksamkeit der Rollenstandardisierung gewidmet wird. Während die Abläufe die Aufgaben des Mitarbeiters im Prozess in ein recht enges Korsett binden, kann ein klares Rollenverständnis mitunter auch mit weniger Regulierung zu einer guten Prozessleistung führen. Gerade dann, wenn die vorgedachten Abläufe nicht geeignet sind, in besonderen Situation angemessen zu reagieren, ist es wichtig, die Rollenver-antwortung zu kennen, um dieser dann gerecht werden zu können. Kennen die Mitar-beiter ihre Verantwortung, füllen sie diese auch dann aus, wenn sie mangels geeigneter Workflows allein auf ihre Flexibilität und Erfahrung angewiesen sind. Gerade für kleinere IT-Organisationen ist dieser Gesichtspunkt angesichts der geringen Arbeitsteilung im Team meist noch wesentlicher als durchstrukturierte Abläufe. In größe-ren IT-Organisation dagegen nimmt der Bedarf für ein klares Rollenverständnis wie-derum zu, wenn Verantwortung und Mitwirkung in der Zusammenarbeit in Prozessen richtig verstanden werden soll. Ein weiterer Aspekt ist die Abbildung dieser Rollen auf die Stellenprofile und die Perso-nalentwicklungsprogramme sowie deren angemessene Einstufung mit Blick auf die Ver-gütungsstrukturen.

! Hinweis Der Rollendefinition und ihrer konkrete Spezifikation sollte in der Prozessentwicklung besondere Aufmerksamkeit gewidmet werden. Diese Erkenntnis ist nicht neu. Sie ist schon bekannt, seitdem es Methoden in der Geschäftsprozessentwicklung gibt. Dennoch werden diese Fragen immer wieder vernachlässigt. Mitunter sollten also Projektverantwortlichen in der ITIL-Umsetzung kritisch werden, wenn zu schnell Abläufe produziert werden, ohne die Rollenverantwortungen festzulegen. Auch die Modellierungs- und Dokumentationswerkzeuge lenken hier mitunter die Aufmerksamkeit einseitig auf die Gestaltung von Prozessabläufen.

5.4.8 Gestaltung und Dokumentation der Prozesse In mehreren Fällen wurde auf die notwendige Abgrenzung und Integration der Prozesse hingewiesen. So lieferten diese Zusammenhänge mitunter einen wirklichen Aha-Effekt für die beteiligten Mitarbeiter. Dass die festgelegten Prozesse für die Mitarbeiter in einer angemessenen Form zu dokumentieren sind, wurde in allen Fällen als selbstverständlich angesehen. Nur so

Seite 45 von 54

kann das strukturelle Prozesswissen festgehalten und effektiv transferiert werden. Zum anderen müssen die Festlegungen in den Prozessen auch für das Management und für die Prozessrevision nachvollziehbar sein. Hinsichtlich Angemessenheit sei auf die Hin-weise zur Dokumentation in der Bestandsaufnahme verwiesen.

! Hinweis Bevor die Gestaltung konkreter Prozesse erfolgt, sollten alle Beteiligten ein gemeinsames Verständnis vom Gesamtbild der Prozessorganisation (Big Picture, Prozess-Framework) besitzen. Dies schließt folgendes Verständnis ein: »

»

»

Welche Prozesse führen wir überhaupt ein? Was sind Ziel, Inhalt und grundsätzlicher Ablauf der einzelnen Prozesse? Über welche Schnittstellen wirken die Prozesse grundsätzlich zusammen?

Die anspruchsvolle Aufgabe besteht i.d.R. genau darin, die Prozesse so einzuführen, dass sie in die bestehende Landschaft passen, die Besonderheiten der Organisation (z.B. im Zusammenwirken mit bestehenden Prozessen) berücksichtigen und dennoch neue Verantwortungen und Best Practices wirksam machen, die zu einer spürbaren Verbesserung führen. Bevor konkrete Prozesse ausgestaltet werden, sollte ihre Abgrenzung und Einbettung im Prozessmodell klar verstanden worden sein. Sonst wird mitunter aneinander vorbei entwickelt, was die Beteiligten Zeit, Aufwand und Nerven kostet.

! Hinweis Definieren Sie von vorn herein die wesentlichen Dokumentationsstandards. Dies betrifft die wesentlichen Dokumente, die Bestandteil der Prozessdokumentaqtion sind, sowie deren Inhalt und Gliederung. Lassen Sie aber bei der Beschreibung der Verfahren mehr formalen Spielraum als bei der Definition der Policy und des Prozesskonzepts. Hier gilt: Je tiefer die Dokumentation in die Prozesse abtaucht, um so mehr Flexibilität wird zugelassen. Je grundsätzlicher die Aussagen in der Prozessbeschreibung sind, um so standardisierter sind die Dokumentationsanforderungen. Empfehlenswert sind zumindest folgende dokumentierte Ergebnisse: »

»

»

»

» »

Policy (Vision, Mission, Ziele, Regeln, Rahmenbedingungen im Prozess) Prozesskonzept (beschreibt das grundsätzliche Konzept des Prozesses und seine Einbettung in das Prozess-Framework) Rollen (beschreibt die Rollen und deren Verantwortung im Prozess, ggf. auch die Anforderungen an die Besetzung der Rollen) Prozeduren (beschreibt konkrete Teilprozesse bzw. Prozeduren im Prozess und kann - wo notwendig - bis auf Arbeitsanleitungen für konkrete Rollen heruntergebrochen werden) Metriken (setzt Ziele in konkrete Messgrößen um und definiert diese) Prozessplanung (beschreibt rollierend die aktuellen Anforderungen, die nächsten Umsetzungsziele und den Stufenplan für die Weiterentwicklung des Prozesses.

Seite 46 von 54

5.4.9 Einsatz von Beratern in der Umsetzung Die Wege waren hier in den Bundesbehörden recht unterschiedlich, wobei alle befragten Behörden gute Erfahrungen mit ihrem Vorgehen gemacht haben. »

»

»

Eine in allen Fällen gültige Aussage lautet: Die Etablierung der Prozesse kann nicht durch Berater sichergestellt werden. Die Prozesse müssen aus der Organisation heraus, von den beteiligten Mitarbeitern entwickelt werden. Eine zweite, überwiegend geäußerte Aussage lautet: Berater mit Umsetzungserfah-rung aus anderen Projekten sind ein wesentlicher Erfolgsfaktor für das Implementati-onsprojekt. Dies müssen nicht immer externe Berater sein. Es können auch interne Mitarbeiter sein, die bereits über entsprechende Erfahrungen verfügen. Die dritte, überwiegend geäußerte Aussage lautet: Die Aufgaben der Berater sollten genau abgesteckt und ihre Rolle sinnvoll definiert sein. Als wichtig erschienen hier vor allem

o die Unterstützung in der Initiierung und Planung des Vorhabens und der Maßnahmen auf Grundlage der Projekterfahrungen

o die persönliche Begleitung der Schlüsselpersonen im Projekt als Coach auf Grundlage ihrer Umsetzungserfahrungen und bekannter Risiken

o die Moderation der Konzeptions- und Entscheidungsprozesse auf Grund-lage ihrer unabhängigen, interessenneutralen Rolle

o die fachlichen Impulse für die sinnvolle Prozessgestaltung auf Grundlage bereits häufig bewährter Entscheidungen

Unterschiedliche Aussagen wurden hinsichtlich folgender Aspekte geäußert: 1. Wann sollten Berater involviert werden?

In einem Fall wurde die Erfahrung gemacht, dass es sinnvoll erscheint, der eige-nen Organisation eine Selbstfindungsphase zu ermöglichen, bevor externe Un-terstützung beschafft wird (siehe Beispiel).

2. Welche Berater sollten involviert werden? Überwiegend wurde hier auf hersteller- und produktneutrale Beratung gesetzt, was vor allem auf die Bereitstellung von Expertise in der Prozessentwicklung hin-ausläuft. Die Erwartungshaltung war hier, dass sich die Berater auf die Lösung der konkreten Problemstellungen unter Berücksichtigung der individuellen Rah-menbedingungen in der Behörde konzentrieren und Entscheidungen nicht vor dem Hintergrund der Produktpositionierung gelenkt werden. Gleichzeitig sollte mitunter die Evaluierung von Werkzeugen unterstützt werden, um eine langfristig trägfähige Toolstrategie sicherzustellen. In anderen Fällen wurde das Gegenteil befürwortet. Wo die Anforderungen weit-gehend mit bestehenden Standards zu erfüllen sind, wurde die Einbindung von Implementationspartnern für konkrete Produkte für sinnvoll erachtet, die die Pro-zessentscheidungen weitgehend auf Grundlage der Produktmerkmale lenken. Hier wurden die Prozesse also im Rahmen der Lösungsimplementation gestaltet.

Beispiel Im konkreten Fall wurden der Organisation für die Vorphase 6 Monate eingeräumt. Ohne diese Phase würde es den Verantwortlichen schwer

Seite 47 von 54

fallen, den konkreten Auftrag für die Beratung zu formulieren, den Beratern den erforderlichen Input zu liefern und den Erfolg der Beratungsleistungen zu steuern. Wenn die Organisation ihre Ziele und den Bedarf für Umsetzungsleistungen formulieren kann, dann würde der Beratereinsatz effizienter erfolgen. In anderen Fällen wurde die Erfahrung gemacht, dass möglichst frühzeitig Expertise in der Umsetzung solch spezifischer Managementdisziplinen einzubeziehen ist. Gerade in der Frühphase mit der bestehenden Unschärfe, was die Kenntnis der Situation und des Handlungsbedarfs sowie der Rahmenbedingungen und Ziele betrifft, erwies sich hier externe Unterstützung für die richtige Initialisierung des Vorhabens als sinnvoll.

! Hinweis Implementationspartner für die Toolunterstützung der Prozesse werden in

jedem Fall benötigt, sofern das Produkt-know-how in der Behörde nicht bereits vorhanden ist. Ob eine herstellerneutrale Prozessberatung sinnvoll ist, hängt wesentlich von zwei Faktoren ab: »

»

Stehen die strategischen Toolstandards zur Unterstützung der diversen IT-Service Management-Prozesse bereits fest? Besitzt der Implementationspartner die Fähigkeit, auch die über sein Werkzeug hinausgehenden Prozessanforderungen zu behandeln und den Veränderungsprozess in solchen Reorganisationsprojekten zu begleiten?

Deshalb muss diese Frage stets in der konkreten Situation beantwortet werden.

5.4.10 Einsatz von Werkzeugen im IT-Service Management Alle befragten Bundesbehörden waren sich darin einig, welch große Bedeutung der Ein-satz prozessunterstützender Werkzeuge für die Etablierung der Prozesse hat. Die Prozessetablierung war stets auch mit der Einführung neuer oder Anpassung bereits eingesetzter Werkzeuge verbunden. Fragen, die mit der Einführung und dem Einsatz von Tools im IT-Service Management zusammenhängen, wurden teilweise in den Befragungen angesprochen, der Schwer-punkt der Gespräche wurde aber zunächst bewusst auf Fragen rund um die organisato-rischen Herausforderungen der ITIL-Umsetzung gelegt. Wer sich mit dem Tooleinsatz beschäftigt, sollte aber folgende Aspekte im Blick behal-ten: »

»

»

Transparenz in der bestehenden Toollandschaft – vor allem Prozesswerkzeuge im Support sowie bestandsführende Werkzeuge für die Dokumentation von IT-Kompo-nenten Angestrebter Standardisierungs- und Integrationsgrad der Prozesswerkzeuge im Support- und Delivery-Management Strategie für den Tooleinsatz unter Berücksichtigung des notwendigen Integrationsgrades, der angemessenen Prozessunterstützung und der Tool- und Schnittstellen-Wirtschaftlichkeit

Seite 48 von 54

»

»

»

»

»

Zentrales oder dezentrales CMDB-Konzept in Abhängigkeit von den eingesetzten Change-Management-Umgebungen Integration von Auftragsmanagement, Änderungsmanagement und IT-Beschaffungs-abwicklung Integration Change-Management und CMDB mit betriebsnahen Werkzeugen (z.B. Softwareverteilung, Inventarisierung, Überwachung, User- und Berechtigungsver-waltung, etc.) Integration mit Werkzeugen der Kunden und Dienstleister zur Steuerung von Supportvorgängen und Aufträgen sowie zum Austausch von Konfigurationsdaten Einbettung von Werkzeugen für das Informations- und Wissensmanagement

Die Fragen rund um die Entwicklung der passenden Toolstrategie, sowie um die Aus-wahl und Einführung geeigneter Werkzeuge sind sicherlich vielfältig und würden den hier festgelegten Rahmen sprengen. Deshalb wird an dieser Stelle auf weitergehende Aussagen verzichtet.

5.5 Kontrolle In einigen Fällen, in denen die Prozessentwicklung bereits vor mehreren Jahren begann, wurde bereits ein sehr hoher Reifegrad erreicht. Hier rückte die laufende Kontrollierbar-keit und Verbesserung der Prozessqualität bereits in den Vordergrund. Was ist zu kontrollieren? Wenn die Prozesse entwickelt werden, um eine Verbesserung der Servicequalität und –Effizienz zu erzielen, dann muss der Prozessverantwortliche sicherstellen, dass dieses Ziel auch erreicht wird. Dies kann er nur, wenn er die Leistung seines Prozesses mess-bar ist. Dafür empfiehlt ITIL so genannte Leistungsindikatoren (KPI = Key Performance Indicators). Die Behörden, die hier bereits Erfahrung gesammelt haben, betonen zwei Aspekte:

1. Die Prozessqualität und –effizienz sollte möglichst über die gesamte Prozess-kette hinweg messbar gemacht werden.

2. Man sollte sich nicht auf die KPI in den Prozessen vollständig verlassen. Ein ganz anderer Aspekt ist die subjektive Wahrnehmung der Qualität bei den Anwendern und Kunden. Auch diese sollte messbar gemacht werden, um zu erkennen, ob das eigene Qualitätsmanagementsystem hinreichend geeignet und effizient ist, die Qualität kundengerecht sicherzustellen.

Seite 49 von 54

6 Erreichung der Ziele Auch wenn nicht immer alle Ziele sofort erreicht wurden, so können alle befragten Bun-desbehörden auf spürbare Effekte ihrer Maßnahmen zurückblicken. Zwei Beispiele sol-len das veranschaulichen:

Beispiel Die grundsätzlichen Ziele der Leitung wurden im konkreten Fall erfüllt. Der Service Desk wurde optimiert und in dieser Form auch von den Anwendern akzeptiert. Im Ergebnis steht dem Anwender der Zugang zur IT über eine konkrete Rufnummer zur Verfügung. Hier wurden im Service Desk auch standardisierte Betriebsaufgaben platziert – insbesondere Remote Management dezentraler Komponenten und die Softwareverteilung. Verbesserungsbedarf besteht noch

in der flächigen Nutzung des Service Desks. Daraus ergeben sich Aufgaben für die noch tiefere Verankerung der Schnittstelle in der Anwenderorganisation.

in der Toolfunktionalität zur verbesserten Prozessunterstützung in der Datenkonsolidierung im Configuration Management – bereitgestellte Daten sind teilweise unzureichend, müssen werden aber dennoch mit recht hohem Aufwand gepflegt

Verbesserung der Toolunterstützung für das Change Management – bessere Abbildung der konkreten Changeklassen und -kategorien

Beispiel Im Zusammenhang mit der Einführung des Service Desks, des Incident

Managements und reaktiven Problem Managements wurden folgende Ergebnisse erzielt: Vorgangsvolumen, Reaktions-, Durchlauf- und Bearbeitungszeiten der Störungen wurden messbar. Auch Aufwand und Bearbeitungsfluss wurden über die Toolunterstützung transparent, was Aussagen zur Prozessoptimierung möglich macht. Die Messpunkte (KPI) für die Prozessqualität wurden so definiert, dass diese die gesamte Prozesskette umfassen – von der Meldung bis zur wirksamen Behebung der Störungen. Z.B. ergab sich hieraus, dass die Spezialisten im Betrieb tatsächlich entlastet wurden, weil 73% der gemeldeten Störungen ohne Involiverung der Fachkräfte allein im Service Desk behoben werden können. Dies ist zugleich ein Kriterium für das Qualifikations- und Erfahrungsniveau im 1st-Level-Support. Auch die Störanfälligkeit konkreter Anwendungen, Produkte und Komponenten wurde messbar. Die Anzahl der in konkrete Störungsbehebungsvorgänge involvierten Personen wurde spürbar gesenkt. Auch andere Abläufe in der IT wurden durch die Einführung des Service Desks verbessert oder verschlankt. Dies reichte den Prozessverantwortlichen noch nicht, sie machten auch neben diesen objektiven, internen Kriterien die subjektive Wahrnehmung der Anwender messbar.

Seite 50 von 54

7 Weiterentwicklung der Maßnahmen Nachfolgend wird ein Ausblick auf die aktuellen und geplanten Maßnahmen zur Weiter-entwicklung der Prozesse zusammengefasst. Alle befragten Behörden setzen diesen eingeschlagenen Weg in der Einführung von IT-Service Management Prozessen fort. Da die Roadmaps behördenspezifisch sind, soll der Überblick anhand konkreter Bei-spiele dargestellt werden:

Beispiel In 2006 legte eine der befragten Behörden den Schwerpunkt auf die kunden- und anwendernahen Funktionen und Prozesse: Service Desk, Incident Management, Service Level Management. In 2007 wird nun hier der Schwerpunkt auf das Change und Configuration Management verlagert. Da bereits mit den Maßnahmen in 2006 festgestellt wurde, dass bereits grundsätzliche Praktiken im Configuration und Change Management für die anderen Prozesse benötigt werden, liefen bereits einige Maßnahmen hierzu als Unterstützungsprojekt in 2006 parallel. In 2008 werden dann die bestehenden Prozesse um das Release und Problem Management ergänzt. Geplant ist hier auch eine stärkere Kopplung zwischen dem IT-Service Desk und dem Fach-Helpdesk. ITIL bezeichnet diese IT-fernen Supportfunktionen als Business Operations Service Desk. Hier soll sichergestellt werden, dass zu Anfragen, die auch mit IT-Nutzung im Zusammenhang stehen – ein schneller Austausch zwischen beiden Service Desks erfolgen kann. Dies soll eine Kopplung der eingesetzten Tools einschließen.

Beispiel Die Einführung des Capacity, Service Level und Change Managements

erfolgt in einem Fall zunächst ohne entsprechende Toolunterstützung und aus der Perspektive des Systembetriebs heraus. Daraus resultieren die Ziele für die Weiterentwicklung: »

»

»

Die Prozesse sollen künftig in einem angemessenen Maße toolunterstützt werden, um die Effizienz und Akzeptanz bei den IT-Mitarbeitern zu verbessern. Daneben soll die Wirksamkeit der Prozesse auf die anwendernahen IT-Funktionen ausgedehnt werden. Mit der Servicedefinition soll eine serviceorientierte, verursacher- und verursachungsgerechte Kosten- und Leistungsrechnung implementiert werden.

Seite 51 von 54

8 Kontakte

8.1 Ansprechpartner der befragten Bundesbehörden Name, Vorname Behörde e-Mail

Pia Karger Bundesministerium des Innern Z6@bmi.bund.de

Herlitze, Rudolf Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit

rudolf.herlitze@bmu.bund.de

Leitungsstab ZIVIT Zentrum für Informationsverarbeitung und Informationstechnik

leitungsstab@zivit.de

Wagner, Jens Bundesanstalt für Wasserbau Jens.Wagner@baw.de

Bonk, Markus Bundesstelle für Informationstechnik

Markus.Bonk@bva.bund.de

8.2 Ansprechpartner der Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik (KBSt)

1. Petra Günther (Petra.Guenther@bmi.bund.de) 2. Jörg Schönebeck (Joerg.Schoenebeck@bmi.bund.de) 3. Dr. Thomas Bliß (Thomas.Bliss@bmi.bund.de)

Seite 52 von 54

9 Glossar Begriff Erklärung

Anwender ITIL definiert Anwender als Nutzer von IT-Services. Dies sind i.d.R. die Mitarbeiter des Kunden (siehe Kunde).

Assessment Verfahren bzw. Maßnahmen zur systematischen Bewertung eines Sachverhalts. Prozess-Assessments können insbesondere zur Be-wertung der Angemessenheit, Wirksamkeit oder Leistungsfähigkeit von Prozessen durchgeführt werden.

Best Practice Praktisch bewährte und wirtschaftliche Managementverfahren und Prozeduren

Change Management

ITIL-Prozess im Service Support Management für die Steuerung und Kontrolle von Änderungen in der IT

Compliance Fähigkeit einer Organisation, formale Anforderungen zu erfüllen, die aus Gesetzen, Verträgen, Richtlinien, Normen und sonstigen Rege-lungen resultieren

Configuration Management

ITIL-Prozess im Service Support Management für die Konfigurations-kontrolle und die Steuerung der Konfigurationsdatenqualität

ISO International Standards Organisation Internationale Organisation für Normung

Incident Management

ITIL-Prozess im Service Support Management für die Störungsbehe-bung

IT-Governance Framework

Rahmenwerk für die IT-Steuerung

ITIL

Information Technology Infrastructure Library Anerkannte Best Practice und Defacto-Standard für Gestaltung, Imp-lementierung und Management wesentlicher Steuerungsprozesse in der IT

IT-Service Bereitstellung eines oder mehrer IT-Systeme incl. Benötigter Leistun-gen der IT zur Unterstützung von Geschäftsprozessen.

ITSM Information Technology Service Management Zusammenfassung integrierter Managementdisziplinen zur Steuerung und Unterstützung von IT-Services

KPI Key Performance Indicator = Messgröße für die Leistung oder Qualität eines Prozesses; wird vom Prozessverantwortlichen überwacht, um die Erfüllung von Prozessanforderungen zu kontrollieren und Optimie-rungspotenziale zu erkennen.

Kunde ITIL definiert den Kunden als Auftraggeber für IT-Services. Dies kann die Leitung externer Organisationen oder interner wie z.B. der Fachab-teilungen sein. ITIL grenzt den Kunden vom Anwender (User) ab.

Seite 53 von 54

Seite 54 von 54

Begriff Erklärung

OGC Office of Government Commerce, Britische Regierungsbehörde und Urheber der ITIL Best Practices

Problem Management

ITIL-Prozess im Service Support Management für die Erkennung und Behebung von Problemen als unbekannte Störungsursachen

Scope Bereich, Schwerpunkt, Umfang der Umsetzung

Service Desk Funktion der IT-Organisation für die zentrale Anwenderschnittstelle

Service Level Zugesichertes Qualitätsniveau (Gesamtheit der Qualitätszusagen) ei-nes Services

Service Level Management

ITIL-Prozess im Service Delivery Management für die Definition und Spezifikation der IT-Services und Serviceeigenschaften sowie für die Überwachung der Servicequalität und Servicevereinbarungen

Service-spe-zifikation

Definition und durchgängige Beschreibung eines konkreten Services

Stakeholder Als Stakeholder werden Personen oder Gruppen verstanden, die als Anspruchsgruppen ein konkretes Interesse an einem Gegenstand ha-ben. Bezogen auf die ITIL-Umsetzung in der IT-Organisationen kön-nen das Kunden, IT-Anwender, IT-Mitarbeiter, Lieferanten, die IT-Lei-tung, die Arbeitnehmervertretung o.a. Interessengruppen sein. Sie zu kennen ist wichtig, um sie in angemessener Weise in den Verände-rungsprozess einzubinden.

Supplier Ma-nagement

ITIL-Prozess im Relationship Management (Beziehungsmanagement) für die Entwicklung und Steuerung von Dienstleisterbeziehungen durch die IT-Organisation

Quick win Erfolg, der kurzfristig und möglichst ohne erheblichen Mehraufwand erzielt werden kann

Tabelle 1: Glossar