Entwicklung und Anwendung einer Methodik zur Verfeinerung von ITIL® Prozessbeschreibungen am Beispiel des ITIL® Change Managements

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung

2 Problemstellung
2.1 Aufgabenstellung und Ziele
2.2 Abgrenzung
2.3 Gliederung und Vorgehensweise
2.4 Vorhandene Ansätze

3 Kontext der Arbeit
3.1 Begriffsdefinition IT Service und Prozess
3.2 IT Service Management
3.2.1 Was ist ITSM
3.2.2 Motivation für ITSM
3.2.3 Erfordernisse zur Einführung von ITSM in einer Organisation
3.2.4 Best Practices für ITSM
3.3 IT Infrastructure Library
3.3.1 Entstehungsgeschichte
3.3.2 Bedeutung
3.3.3 Grundstruktur
3.3.4 Kernprozesse für das Service Management der ITIL
- 3.3.4.1 Service Delivery
- 3.3.4.2 Service Support
3.3.5 Kritische Betrachtung
3.4 Zusammenfassung

4 Referenzmodell für Change Management nach ITIL
4.1 Begriffsdefinitionen
4.2 Prozessumgebung
4.3 Prozesskonzept
4.4 Modularisierung der Prozesskomponenten
4.4.1 RFC Erfassung und Filterung
4.4.2 RFC Klassifizierung
4.4.3 Change Planung
4.4.4 Koordination der Change Entwicklung, Erprobung und Implementierung
4.4.5 Change Nachbearbeitung
4.4.6 Dringende Changes
4.4.7 Standard Changes
4.5 Rollenmodell
4.6 Datenmodell
4.7 Zusammenfassung und Bewertung

5 Konzeptentwicklung
5.1 Begriffsdefinition ‚Business Process Diagram’
5.2 Anforderungen an das Verfeinerungsverfahren
5.2.1 Grundsätzliche Anforderungen
5.2.2 Anforderungen an die Methodik
5.2.3 Grundsätze der ordnungsgemäßen Modellierung
5.3 Strukturierung der Module
5.3.1 Motivation
5.3.2 Bestehende Ansätze
- 5.3.2.1 ARIS
- 5.3.2.2 PROMET
- 5.3.2.3 Strukturierung nach Gadatsch
5.3.3 Ansatz für die Prozessverfeinerung
5.4 Ordnungsrahmen für die Prozessverfeinerung
5.5 Verfeinerungsverfahren
5.5.1 Vorgehen
5.5.2 Variante A – Intuitiver Ansatz
- 5.5.2.1 Idee und Ansatz
- 5.5.2.2 Verfeinerungsstufen
- 5.5.2.3 Verfeinerungspattern
- 5.5.2.4 Management von Varianten
- 5.5.2.5 Komplexitätsmanagement
- 5.5.2.6 Modellkonsolidierung
- 5.5.2.7 Exemplarische Anwendung
- 5.5.2.8 Bewertung und Fazit
5.5.3 Variante B – Verfeinern durch inhaltliches Erweitern
- 5.5.3.1 Idee und Ansatz
- 5.5.3.2 Verfeinerungsstufen
- 5.5.3.3 Management von Varianten
- 5.5.3.4 Komplexitätsmanagement
- 5.5.3.5 Modellkonsolidierung
- 5.5.3.6 Exemplarische Anwendung
- 5.5.3.7 Bewertung und Fazit
5.6 Zusammenfassung

6 Konzeptumsetzung
6.1 RFC Erfassung und Filterung
6.1.1 Prozesssicht
6.1.2 Organisations- Schnittstellen- und Datensicht
6.2 RFC Klassifizierung
6.2.1 Prozesssicht
6.2.2 Organisations- Schnittstellen- und Datensicht
6.3 Change Planung
6.3.1 Prozesssicht
6.3.2 Organisations- Schnittstellen- und Datensicht
6.4 Koordinierung der Change Entwicklung, Erprobung und Implementierung
6.4.1 Prozesssicht
6.4.2 Organisations- Schnittstellen- und Datensicht
6.5 Change Nachbearbeitung
6.5.1 Prozesssicht
6.5.2 Organisations- Schnittstellen- und Datensicht
6.6 Dringende Changes
6.6.1 Prozesssicht
6.6.2 Organisations- Schnittstellen- und Datensicht
6.7 Standard Changes
6.7.1 Prozesssicht
6.7.2 Organisations- Schnittstellen- und Datensicht
6.8 Datenmodell für CM
6.9 Zusammenfassung

7 Bewertung der Umsetzung
7.1 Charakterisierung der technischen Umsetzung
7.2 Wurden die Ziele erreicht?
7.3 Beurteilung der Verfeinerungsergebnisse
7.4 Bewertung der Gabelungspunkte
7.5 Exemplarische Übersetzung von BPMN nach BPEL
7.6 Verbesserungspotenziale im verfeinerten BPD

8 Zusammenfassung und Ausblick
8.1 Zusammenfassung
8.2 Ausblick

A - BPMN Sprachkonstrukte

B - Abkürzungsverzeichnis

C - Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 2-1: Aufgabenstellung - Verfeinerung des Change Management Prozesses

Abbildung 2-2: Vorgehensmodell

Abbildung 2-3: itSMF Metamodell für ITIL [PrSc06]

Abbildung 3-1: Generisches ITSM Prozessmodell [Ogc05]

Abbildung 3-2: Prozesse und Abteilungen [Ogc05]

Abbildung 3-3: ‚Reifende’ ITSM Modelle [Cur05]

Abbildung 3-4: Generisches Modell für das ITSM [You00]

Abbildung 3-5: Abstrahierter Durchlauf eines beispielhaften Problembehebungszenarios des IT Service Managements

Abbildung 3-6: ITIL Grundstruktur [Pra05]

Abbildung 3-7: Beispiel für Interaktion der Service Support und Service Delivery Prozesse [Bre02]

Abbildung 4-1: Change, Release, Capacity und Configuration Management [Ogc05]

Abbildung 4-2: Release Management zwischen Change und Configuration Management [Mof06b]

Abbildung 4-3: CM im Spannungsfeld von Release, Incident und Problem Management [Its04]

Abbildung 4-4: Grober Ablauf des CM Prozesses [Its04]

Abbildung 4-5: BPMN Darstellung des Moduls ‚RFC Erfassung und Filterung’

Abbildung 4-6: BPMN Darstellung des Moduls ‚RFC Klassifizierung’

Abbildung 4-7: BPMN Darstellung des Moduls ‚Change Planung’

Abbildung 4-8: BPMN Darstellung des Moduls ‚Koordination und Change Entwicklung’

Abbildung 4-9: BPMN Darstellung des Moduls ‚Change Nachbearbeitung’

Abbildung 4-10: BPMN Darstellung des Moduls ‚Dringende Changes’

Abbildung 4-11: BPMN Darstellung des Moduls ‚Standard Changes’

Abbildung 4-12: Rollenmodell für CM

Abbildung 4-13: Ausgetauschte Daten im CM Prozess [Pra06]

Abbildung 4-14: Datenmodell für CM

Abbildung 5-1: ARIS Haus [Sche01]

Abbildung 5-2: PROMET - Ebenen und Dimensionen [Öst95]

Abbildung 5-3: Prozess- und Struktursichten nach Gadatsch [Gad02]

Abbildung 5-4: Beispiel für die integrierte Darstellung der Prozess-, Organisations-, Daten- und Schnittstellensicht in ein BPMN Modell

Abbildung 5-5: Variante A – Idee für das Verfeinerungsverfahren (Prozesssicht)

Abbildung 5-6: Beispielprozess zur Veranschaulichung von Verfeinerungspattern

Abbildung 5-7: (Pattern A) Aufspaltung einer Aktivität in zwei sequentielle Aktivitäten

Abbildung 5-8: (Pattern B) Aufspaltung einer Aktivität in zwei parallele Aktivitäten

Abbildung 5-9: (Pattern C) Aufspaltung einer Rolle mit Verschiebung einer Aktivität

Abbildung 5-10: Gabelungspunkte

Abbildung 5-11: Modul ‚RFC Erfassung und Filterung’ auf Stufe 0 gemäß Abbildung 4-5

Abbildung 5-12: Modul 'RFC Erfassung und Filterung' auf Stufe 1 nach Variante A

Abbildung 5-13: Modul ‚RFC Erfassung und Filterung’ auf Stufe 0 gemäß Abbildung 4-5

Abbildung 5-14: Modul 'RFC Erfassung und Filterung' auf Stufe 2 nach Variante B

Abbildung 6-1: generisches Modell des ITIL Change Management Prozesses

Abbildung 6-2: Integrierte Darstellung der Organisations- und Schnittstellensicht des Moduls ‚RFC Erfassung’

Abbildung 6-3: generisches Modell des ITIL Change Management Prozesses

Abbildung 6-4: Integrierte Darstellung der Organisations- und Schnittstellensicht des Moduls ‚RFC Klassifizierung’

Abbildung 6-5: generisches Modell des ITIL Change Management Prozesses

Abbildung 6-6: Verfeinerung des Moduls ‚RFC Klassifizierung’ (Teil 1/2)

Abbildung 6-7: Integrierte Darstellung der Organisations- und Schnittstellensicht des Moduls ‚Change Planung’

Abbildung 6-8: Verfeinerung des Moduls ‚Change Planung’ (Teil 1/3)

Abbildung 6-9: generisches Modell des ITIL Change Management Prozesses

Abbildung 6-10: Integrierte Darstellung der Organisations- und Schnittstellensicht des Moduls ‚Change Koordinierung’

Abbildung 6-11: Verfeinerung des Moduls ‚Change Koordinierung’ (Teil 1/4)

Abbildung 6-12: generisches Modell des ITIL Change Management Prozesses

Abbildung 6-13: Integrierte Darstellung der Organisations- und Schnittstellensicht des Moduls ‚Change Nachbearbeitung’

Abbildung 6-14: Verfeinerung des Moduls ‚Change Nachbearbeitung’

Abbildung 6-15: generisches Modell des ITIL Change Management Prozesses

Abbildung 6-16: Integrierte Darstellung der Organisations- und Schnittstellensicht des Moduls ‚Dringende Changes’

Abbildung 6-17: Verfeinerung des Moduls ‚Dringende Changes’ (Teil 1/5)

Abbildung 6-18: Verfeinerung des Moduls ‚Standard Changes’

Abbildung 6-19: Integrierte Darstellung der Organisations- und Schnittstellensicht des Moduls ‚Standard Changes’

Abbildung 6-20: UML Klassendiagramm für CM Datenmodell

Abbildung 6-21: Quantitative Zusammenfassung der Konzeptumsetzung

Abbildung 7-1: Ausschnitt aus verfeinertem Modell der 'Change Planung'

Tabellenverzeichnis

Tabelle 4-1: Erfassung - Input und Output

Tabelle 4-2: Vorschläge der ITIL für Prioritätsstufen eines RFCs

Tabelle 4-3: Beispiel der ITIL für RFC-Kategorien

Tabelle 4-4: Klassifizierung – Input und Output

Tabelle 4-5: Planung – Input und Output

Tabelle 4-6: Koordinierung - Input und Output

Tabelle 4-7: Nachbearbeitung – Input und Output

Tabelle 4-8: Dringende Changes – Input und Output

Tabelle 4-9: Legende für CM Datenmodell

Tabelle 6-1: RACI Diagramm für Modul 'RFC Erfassung’

Tabelle 6-2: Aktivitäten des Moduls ‚RFC Klassifizierung’, die durch Zweiteilung entstanden sind

Tabelle 6-3: Überarbeitete oder durch inhaltliche Erweiterung in das Modul ‚Klassifizierung’ integrierte Ereignisse

Tabelle 6-4: Überarbeitete oder durch inhaltliche Erweiterung in das Modul ‚Klassifizierung’ integrierte Aktivitäten

Tabelle 6-5: Gabelungspunkte des Moduls ‚RFC Klassifizierung’

Tabelle 6-6: RACI Diagramm für Modul 'RFC Klassifizierung’

Tabelle 6-7: Aktivitäten des Moduls ‚Change Planung’, die durch Zweiteilung entstanden sind

Tabelle 6-8: Überarbeitete oder durch inhaltliche Erweiterung in das Modul ‚Change Planung’ integrierte Ereignisse

Tabelle 6-9: Überarbeitete oder durch inhaltliche Erweiterung in das Modul ‚Change Planung’ integrierte Aktivitäten

Tabelle 6-10: Gabelungspunkte des Moduls ‚Change Planung’

Tabelle 6-11: mögliche Ausgestaltung des FSCs

Tabelle 6-12: mögliche Ausgestaltung eines Dokuments zur PSA

Tabelle 6-13: RACI Diagramm für Modul 'Change Planung’

Tabelle 6-14: Überarbeitete oder durch inhaltliche Erweiterung in das Modul ‚Change Koordinierung’ integrierte Ereignisse

Tabelle 6-15: Überarbeitete oder durch inhaltliche Erweiterung in das Modul ‚Change Koordinierung’ integrierte Aktivitäten

Tabelle 6-16: Gabelungspunkte des Moduls ‚Change Koordinierung’

Tabelle 6-17: Mögliche Gestaltung des Implementierungsplans

Tabelle 6-18: Mögliche Beschaffenheit des Kommunikationsplans

Tabelle 6-19: RACI Diagramm für Modul 'Change Koordinierung’

Tabelle 6-20: Aktivitäten des Moduls ‚Change Nachbearbeitung’, die durch Zweiteilung entstanden sind

Tabelle 6-21: Überarbeitete oder durch inhaltliche Erweiterung in das Modul ‚Change Nachbearbeitung’ integrierte Aktivitäten

Tabelle 6-22: Überarbeitete oder durch inhaltliche Erweiterung in das Modul ‚Change Nachbearbeitung’ integrierte Ereignisse

Tabelle 6-23: RACI Diagramm für Modul 'Change Nachbearbeitung’

Tabelle 6-24: Überarbeitete oder durch inhaltliche Erweiterung in das Modul ‚Dringende Changes’ integrierte Aktivitäten

Tabelle 6-25: Überarbeitete oder durch inhaltliche Erweiterung in das Modul ‚Dringliche Changes’ integrierte Ereignisse

Tabelle 6-26: RACI Diagramm für Modul 'Standard Changes’

Tabelle 6-27: Quantitative Zusammenfassung der Konzeptumsetzung

„Das Gold liegt in den Prozessen“

Dr. Jens Neumann, Mitglied des Vorstandes der Volkswagen AG von 1993 bis 2004

1 Einleitung

Die Geschäftswelt der heutigen Zeit wird von ausgeklügelten und raffinierten Computer­systemen getragen. Im Informationszeitalter und angesichts schnelllebiger Märkte, die sich im Antlitz von Globalisierungsprozessen kontinuierlich wandeln, ist jede moderne Unternehmung, die erfolgreich wirtschaften möchte, auf digitale Unterstützung angewiesen. Ein bewusster Verzicht auf Computertechnik ist praktisch nicht machbar.

Geschäftsprozesse aller Art werden über komplexe Rechensysteme modelliert, abgebildet und betrieben. Informationstechnologie (IT) unterstützt dabei meist nicht nur das Kerngeschäft eines Unternehmens, sondern kann durch den Einsatz neuartiger Technologien zum Türöffner für neue geschäftliche Chancen avancieren. Sie ist mittlerweile fast ausnahmslos als geschäfts­kritisch anzusehen und genießt somit in den Augen von Verantwortlichen einen wichtigen Stellenwert.

Die hohe IT Lastigkeit geschäftlicher Gefüge hat allerdings auch ihre Schattenseiten. Mit verstärktem IT Einsatz steigt beispielsweise die Abhängigkeit von der Verfügbarkeit von Systemen. Störungen an IT Services können zu Produktionsausfällen, Lieferverzögerungen, Fehlern in Abrechnungsvorgängen oder - im Extremfall - sogar zum Zusammenbruch der Geschäftstätigkeit von Unternehmen führen. Es ist deshalb nicht verwunderlich, dass enormer Aufwand betrieben wird, um solchen Szenarien entgegenzuwirken. Organisationen investieren in immer größerem Maße in ihre IT Infrastrukturen und erkennen zunehmend, dass derartige Ausgaben keine Kosten- sondern vielmehr wichtige Erfolgsfaktoren sind.

Dieser Trend suggeriert eine ausgezeichnete wirtschaftliche Lage der IT Branche. Doch der Markt ist umkämpft wie nie zuvor, denn auch Dienstleister müssen sich verstärkt vor konkurrierenden Anbietern behaupten. Sie sind gezwungen, ihren Kunden maximalen Service zu bieten und dabei selber betriebswirtschaftlich und gewinnorientiert zu operieren. Die Herausforderung dabei ist, sich von einem reinen Technologie-Lieferanten zu einer strategisch wichtigen Service-Organisation zu entwickeln, die dem Kunden messbare Beiträge zu dessen Wertschöpfung liefert. Das Wohl der Unternehmung des Kunden hängt also unmittelbar davon ab, dass IT im Rahmen eines Dienstes wohl überlegt, effizient und flexibel bereitgestellt wird.

Etablierte Herangehensweisen, Konzepte und Denkmuster für diese Anforderungen finden sich in der Theorie und den Vorgaben des IT Service Managements (ITSM). ITSM umfasst einen Satz an bewährten Maßnahmen und Methoden, die nötig sind, um die bestmögliche Unterstützung von Geschäftsprozessen durch IT zu erreichen. Durch die Methodiken des ITSM wird IT zur Planung, Koordination und Steuerung aller mit ihr im Zusammenhang stehenden Aktivitäten und Ressourcen in Form von Prozessen organisiert, und zu Überwachungs- und Kontrollzwecken durch Kennzahlen messbar gemacht. Zentrale Idee ist dabei, dass IT Organisationen als Dienstleister auftreten und danach streben, qualitativ hochwertige, kostengünstige und bewertbare IT Services anzubieten. Was zählt, ist der Gedanke einer ‚serviceorientierten’ Kundenbeziehung.

Einen konkreten Leitfaden mit Methoden zum IT Service Management stellt die sog. IT Infrastructure Library (ITIL) dar. Sie ist kein festgelegter Standard, sondern eine Sammlung von praktischen Vorgehensweisen, die einen Best Practice Ansatz verfolgen. Dabei werden Modelle und Organisationsformen, die sich in der Praxis bewährt haben, derart beschrieben, dass sie von jeder Organisation adaptierbar sind und somit auf deren eigene Bedürfnisse zugeschnitten werden können. ITIL bietet praktische Anleitungen zur Unterteilung der Funktionen wie auch zur Organisation der zuvor erwähnten Prozesse, die im Rahmen des serviceorientierten Betriebs einer IT Infrastruktur entstehen.

Der Lehrstuhl für Kommunikationssysteme und Systemprogrammierung der Ludwig-Maximilians-Universität München beschäftigt sich in Forschungsprojekten mit ITSM. Dabei wurden unter anderem am Markt verfügbare Workflowmanagement-Anwendungen evaluiert, die dazu dienen, IT Prozesse und Abläufe gemäß des ITSM zu unterstützen, wie zum Beispiel Ticketsysteme für Helpdeskbetriebe. Feststellung ist, dass derartige Tools aufgrund struktureller und konzeptioneller Mängel zurzeit fast ausschließlich als unzureichend zu bezeichnen sind. Folgende Punkte beschreiben häufige Missstände (vgl. [Leh05]):

­ Konformität zur ITIL oder zu ähnlichen ITSM Modellen, also striktes Agieren eines Tools nach den vorgegebenen Empfehlungen, ist oft nachträglich aufgestempelt und
eher selten per Design implementiert.
­ Applikationen sind häufig historisch gewachsen und gleichen mehr einem Fleckenteppich als einer Lösung aus einem Guss.
­ Tools sind in der Regel überdimensioniert, unübersichtlich, steif und monolithisch.
­ Vernetzung von Anwendungen unterschiedlicher Hersteller ist in der Praxis meist nicht realisierbar beziehungsweise exorbitant aufwendig.
­ Sie sind größtenteils teuer in der Anschaffung und nur durch hohen Aufwand an die Gegebenheiten einer IT Infrastruktur anpassbar.

Wie die aufgezählten Punkte verdeutlichen, mangelt es an Anwendungen, die gleichzeitig flexibel, standardisiert, preisgünstig und per Design konform zum ausgewählten ITSM Modell sind. Es besteht folglich Bedarf an durchdachteren Konzepten. Tools für das ITSM sollen offen und anpassbar sein, um Veränder­ungen an einer IT Infrastruktur als wie auch an den abzubildenden Geschäftsprozessen ohne Einschränkungen abbilden zu können. Zudem sollen sie sich durch einfache Wartbarkeit auszeichnen.

Im Rahmen dieser Diplomarbeit werden die Bemühungen zur Entwicklung neuartiger Toolkonzepte unterstützt. Dazu wird eine Methodik entwickelt und angewandt, anhand derer der generische ITIL ‚Change Management’ Prozess, der Vorgehensweisen zur Verwaltung von Änderungen an einer IT Infrastruktur definiert, verfeinert werden kann. Durch diese Prozess­verfeinerung entsteht ein konkretes, fein aufgelöstes und formalisiertes Modell des Change Managements, das mit hohem Detaillierungsgrad Zusammenhänge, Beziehungen und Abläufe des Prozesses darstellt. Ziel ist, eine vervollständigte, präzisierte, formalisierte und klar strukturierte Darstellung für den Prozess zu entwickeln. Das konstruierte Modell kann im Weiteren gegebenenfalls für die Entwicklung eines auf Web Services basierenden Workflowmanagement-Werkzeugs für ITIL Prozesse verwendet werden.

2 Problemstellung

Der Change Management (CM) Prozess, der wie eingangs erwähnt im Folgenden betrachtet wird, ist fundamentaler Bestandteil einer jeden ITSM Methodologie. Auch die ITIL, die nach Vorgabe als ITSM Leitfaden für das Vorhaben der Diplomarbeit zu verwenden ist, sieht ihn vor. Grundsätzliche Aufgabe ist nun, die ITIL Beschreibungen für den CM Prozess zu verfeinern. Dies würde, wie bereits motiviert, die Konzeption von neuen Workflowmanagement-Tools unterstützen. Darüber hinaus wären bessere Beurteilungen von konkreten ITIL Prozessimplemen­tierungen möglich, was wie folgt zu erklären ist: Angesichts von Unternehmens­um­strukturier­ungen wie beispiels­weise der aktuellen Fusion der Netzwerksparten von Nokia und Siemens sind Unternehmens­prozesse im Zuge von Synergieeffektbestrebungen oft neu auszurichten. Organisationen wünschen dabei etablierte Bench­markings, um sich bezogen auf ihre jeweiligen IT Prozesse systematisch vergleichen und so im stark konkurrierenden Markt positionieren zu können. Dies impliziert die Notwendigkeit für formale, ausführliche und gleichzeitig möglichst allgemeingültige ITSM Prozessbeschreibungen, anhand derer das gewünschte Benchmarking festgemacht werden kann. Über solch ein feingranulares, gemeinsames Modell für ITSM Prozesse, das über die generischen Vorgaben der ITIL hinausgeht, wäre die Grundlage für Vergleiche mit konkurrierenden Unternehmen gegeben.

Dieses Kapitel dient nun als Hinführung zum eigentlichen Vorhaben, indem zunächst detailliert auf die Aufgabenstellung sowie die Ziele der Arbeit eingegangen wird (Abschnitt 2.1). Daran anschließend folgt eine kurze Abgrenzung (Abschnitt 2.2) sowie die Vorstellung der Gliederung und grundsätzlichen Vorgehensweise (Abschnitt 2.3). Die Herausarbeitung und Bewertung vorhandener Ansätze rundet das Kapitel ab (Abschnitt 2.4).

2.1 Aufgabenstellung und Ziele

Ausgehend von der generischen Beschreibung des CM Prozesses, die in den Büchern der ITIL vorgegeben ist, sind in der Diplomarbeit Möglichkeiten einer Prozess­verfeinerung zu prüfen, um zu einer detailreicheren Darstellung zu gelangen. Dazu soll in zwei Schritten vorgegangen werden. In einer ersten konzeptionellen Planungsphase sind mögliche Verfeinerungs­konzepte zu entwickeln, woran anschließend in einer zweiten Phase die Verfeinerung nach dem entwickelten Konzept durchzuführen ist. Als Ergebnis entsteht ein ausführliches Business Process Diagram (BPD, vgl. Abschnitt 5.1), das zum einen den verfeinerten Prozess darstellt, und an dem zum anderen einfach, komfortabel und so genau wie möglich abgelesen werden kann, wie die einzelnen Elemente des CM Prozesses miteinander korrelieren.

Für das Vorhaben sind diverse technische Anforderungen umzusetzen, wie beispielsweise die grundlegende Entwicklung einer sinnvollen Formalisierung. Im Zuge dessen ist herauszufinden, ob sich die sogenannte Business Process Modeling Notation (BPMN, vgl. Abschnitt 4.4) als graphische Notation für das zu erstellende BPD eignet. Über die Business Process Execution Language (BPEL) bestünde somit die Möglichkeit, aus der BPMN Formalisierung des BPDs ein XML Dokument zu extrahieren, dessen Daten zur Entwicklung eines auf Web Services basierenden Workflow­management-Werkzeugs weiterverwendet werden könnten [Mnm06]. Erweist sich die BPMN als unbrauchbar, ist über Alternativen nachzudenken.

Die folgende Abbildung 2-1 verdeutlicht die Aufgaben­stellung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1: Aufgabenstellung - Verfeinerung des Change Management Prozesses

Ausgehend von der generischen Prozessbeschreibung des Change Managements nach ITIL (links im Bild) ist die Verfeinerung soweit durchzuführen (breite Linie), bis ein konkretes und maximal verfeinertes BPD entstanden ist (rechts). Die feinen Verästelungen veranschaulichen, dass Zwischenschritte der Verfeinerung trotz Anwendung ein und desselben Ver­feinerungs­konzepts unter­schied­lich ablaufen könnten, was zu verschieden beschaffenen BPDs führen würde. Eine einzige, eineindeutige Verfeinerung für das CM gibt es somit nicht, womit in dieser Arbeit eins der möglichen konkreten BPDs herausgearbeitet wird.

Folgende Ziele werden mit der Diplomarbeit verfolgt: Die zentrale Frage ist, ob eine umfassende und gleichzeitig sinnvolle Prozessverfeinerung überhaupt realisierbar ist. Vergleichbare Vorhaben mit ähnlicher Zielsetzung, die eine Antwort auf diese Frage liefern könnten, wurden bisher noch nicht unternommen (vgl. Abschnitt 2.4). Was aber gemacht werden kann, und mit dieser Arbeit auch angegangen wird, ist wie zuvor erwähnt ein Vorgehen für eine Prozessverfeinerung zu entwickeln und darauf aufbauend einen Verfeinerungsversuch zu starten, der das Vorgehen umsetzt. Alle Aktionen und Ansätze werden dabei detailliert aufgezeichnet, womit der ‚Weg’ zum eigentlichen Ziel wird. Dies dient auch dazu, um anderweitige, sich vom ITIL-CM unterscheidende Prozesse ähnlich verfeinern zu können.

Bereits genanntes Ziel der Arbeit ist, aus dem entwickelten Konzept für die Verfeinerung ein fein aufgelöstes und formalisiertes BPD zu erstellen. Dazu ist zum einen ein Konzept zu entwickeln, wie der Change Management Prozess am besten ‚aufgeknackt’, also in separate Blöcke unterteilt werden kann, und wie diese Blöcke in sich zu strukturieren sind. Das Verfeinerungsverfahren möge an den Blöcken ansetzen und das gesamte Vorhaben auf diese Weise gliedern und überschaubar halten.

Als weiteres Ziel ist herauszuarbeiten, welches Modellierungstool am besten für die grafische Veranschaulichung der Verfeinerung zu verwenden ist. Da der konkrete, verfeinerte Prozess entsprechend den Vorgaben und der Syntax der BPMN zu konstruieren ist, muss das Modellierungstool BPMN unterstützen. Nach Durchführung der Prozessverfeinerung ist zu beurteilen, ob die BPMN ihren Zweck zur graphischen Darstellung von Geschäftsprozessen erfüllt hat.

Darüber hinaus ist Ziel der Arbeit, das verfeinerte Modell des CM Prozesses zu bewerten. Was lässt sich am BPD ableiten und wie ist es zu charakterisieren? Zudem interessiert die Beschaffenheit von speziellen Ereignissen, den sogenannten Gabelungspunkten, die im Lauf der Verfeinerung passiert werden. An ihnen eröffnen sich mehrere Möglichkeiten zur weiteren Verfeinerung, wie in Abschnitt 5.5.2.4 ausführlich erläutert. Wie lässt sich die Menge aller Gabelungs­punkte des endgültigen BPD charakterisieren?

Während der Entwicklung des BPD bietet es sich im Weiteren an, dessen Entstehungsprozess aus verschiedenen Blickwinkeln und aus unterschiedlichen Ebenen zu betrachten. Zum einen interessiert die Dynamik der Verfeinerung: Es ist anzunehmen, dass der ITIL CM Prozess nicht homogen und gleichförmig verfeinerbar sein wird. So wird es Teilaspekte geben, die bereits nach wenigen Schritten ihren Endzustand erreichen werden, und solche, die mehrstufig konkretisierbar sind. Ziel ist, derartige Tendenzen herauszuarbeiten und zu beschreiben. Zum anderen wird untersucht, ob auf dem Weg von der generischen Prozessbeschreibung zum konkreten Modell sich wiederholende Muster zu erkennen sind. Existieren Komponenten des Prozesses, die sich immer nur auf eine einzige Art verfeinern lassen, also ohne die zuvor beschriebenen Gabelungspunkte? Oder gibt es solche, von denen aus zwar in unterschiedliche Richtungen weiter verfeinert werden kann, die dann allerdings, egal welcher Weg auch eingeschlagen wird, stets mehr oder weniger ähnlich sind? Beispiel wäre hier der sogenannte Request for Change (vgl. Abschnitt 4.2), der höchstwahrscheinlich für alle zu untersuchenden IT Organisationen annähernd gleich aufgebaut ist.

2.2 Abgrenzung

Das Thema dieser Diplomarbeit, die Verfeinerung eines generischen ITIL Prozesses, entspringt einem Bereich des ITSM, der in der Fachwelt gegenwärtig erhebliche Aufmerksamkeit genießt. Zahlreiche Beratungshäuser, Forschungseinrichtungen und anderweitige Organisationen versuchen mit großem Aufwand konkrete ‚Templates’, also vorlagenartige Schablonen, zu den ITIL Managementprozessen zu erstellen^[1]. Hintergrund dazu ist Folgender: Jedes Unternehmen, das die ITIL als Methodologie für das ITSM einführen möchte, bedarf eines konkreten Plans beziehungsweise eine greifbaren Vorlage, anhand derer die Einführung konkret umzusetzen ist. Da die ITIL Publikationen derartige Konstrukte nicht anbieten und sich lediglich im Rahmen abstrahierter Beschreibungen präsentieren, besteht erheblicher Bedarf an konkreten, detaillierten, leicht adaptierbaren und dennoch allgemeingültigen Prozessmodellen.

Diese Arbeit erhebt nicht den Anspruch, das verfeinerte Template für das ITIL CM erstellen zu wollen. Sie ist vielmehr als kleiner Schritt zu betrachten, der dazu beiträgt, die Thematik voranzutreiben, und anderen als Anregung für weitergehende Ausführungen zu dienen. Darüber hinaus wird nicht versucht, ein umfassendes theoretisches Modell zu erstellen, da dies den Umfang der Arbeit sprengen würde. Eine der Zielsetzungen ist wie beschrieben die Vorgaben der ITIL zu formalisieren, und darauf aufbauend einen Verfeinerungsversuch anzugehen.

Da die Vollständigkeit der Prozessverfeinerung nicht bewiesen werden kann, wird großer Wert auf die Darstellung des Verfahrens zur Verfeinerung gelegt (vgl. Kapitel 5). Das tatsächliche Verfeinern (vgl. Kapitel 6) ist dann als Beispiel für das Verfahren zu sehen.

Nachdem das Vorhaben mit seinen Anforderungen und Zielen motiviert und ausführlich vorgestellt wurde, erläutert der folgende Abschnitt das grundsätzliche Vorgehen. Dazu wird die Gliederung der Diplomarbeit vorgestellt.

2.3 Gliederung und Vorgehensweise

Das Vorgehen dieser Arbeit gliedert sich analog der Darstellung aus Abbildung 2-2. In einem einführenden dritten Kapitel werden die thematischen und begrifflichen Grundlagen für alle weiteren Ausführungen in Form eines Überblicks über das weitläufige Gebiet des ITSM und der ITIL vorgestellt (in Abbildung nicht enthalten).

Kapitel 4 fertigt nach den Vorgaben der OGC ein Referenzmodell für das CM an. Der ITIL Prozess wird dabei wesentlich ausführlicher als im einführenden Kapitel dargestellt. Um kohärente Komponenten zu gruppieren, wird der Prozess in funktional zusammengehörende Einheiten aufgebrochen, die als Module bezeichnet werden. Anhand dieser Strukturierung entsteht ein Gliederungs­schema, auf das im Weiteren referenziert werden kann. Aufgabe ist, die Menge aller Aktivitäten, Schnittstellen zu anderen Prozessen und der Prozess-Input und -Output der einzelnen Module herauszuarbeiten und zu modellieren. Jedes Modul wird durch eine graphische Darstellung in BPMN formalisiert. Zum Abschluss des Kapitels wird das Zusammen­­spiel der Rollen des Prozesses graphisch visualisiert, ebenso wie der Fluss beteiligter Informationen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2: Vorgehensmodell

Aufsetzend auf das Referenzmodell wird im fünften Kapitel das Konzept für die Prozessverfeinerung entwickelt. Nach einer Anforderungsanalyse folgt die Ausarbeitung eines Konzepts zur Strukturierung der Module. Darauf hin werden in einem ‚Verfahrenfindungsprozess’ konkrete Ansätze zur Prozessverfeinerung vorgestellt. Sie werden auf Effektivität geprüft, mitprotokolliert und redigiert, so dass als Ergebnis ein Ansatz für die konkrete Verfeinerung in Kapitel 6 zur Verfügung steht.

Dieses sechste Kapitel stellt den Kern der Diplomarbeit dar. Hier wird aufbauend auf den Vorarbeiten der vorausgehenden Kapitel die erarbeitete Methodik der Verfeinerung angewandt und das detaillierte BPD zum ITIL CM erstellt. Das Vorgehen dazu orientiert sich erneut am Gliederungsschema, das im vierten Kapitel eingeführt wurde. Die Module werden einzeln betrachtet und die jeweiligen Verfeinerungsergebnisse in strukturierter Weise aufbereitet und zusammengefasst.

Im vorletzten, siebten Kapitel wird die Umsetzung des Konzeptes bewertet. Wie im Abschnitt 2.1 skizziert wird der Versuch unternommen, dass BSP zu charakteri­sieren. Dabei werden unter anderem die Ergebnisse der Verfeinerung beurteilt und Aussagen über die Gabelungspunkte getroffen.

Die Ausführungen werden in Kapitel 8 schließlich zusammengefasst und anhand eines Ausblicks abgerundet. Die vier letztgenannten Kapitel enthalten die Schwerpunkte der Eigen­entwick­­lungen dieser Diplomarbeit.

2.4 Vorhandene Ansätze

Im Zuge der Literaturrecherche zeigt sich deutlich, dass im Bereich des Business Process Modeling erhebliche wissenschaftliche Forschung im Gang ist. BP Modeling wird dazu verwendet, sowohl Ist-Zustände sowie zukünftige Beschaffenheiten von Geschäftsprozessen zu beschreiben, was somit das Feld des ITSM tangiert (vgl. Abschnitt 3.2). Um ein Beispiel für die zahlreichen Aktivitäten zu nennen, sei die „Third Interna­tional Conference on Business Process Management“ [Bpm05] erwähnt, die vergangenes Jahr in Nancy, Frankreich abgehalten wurde. Auf der Veranstaltung wurden mehr als 40 Veröffentlichungen vorgestellt und diskutiert. Konkrete, detaillierte Modelle zu ITSM Prozessen befinden sich jedoch nicht unter den Publikationen. Darüber hinaus konnten während der Recherche zu dieser Arbeit auch aus anderweitigen, dem BPM nahe stehenden Quellen keine derartigen Modelle aufgedeckt werden.

Kein verfeinertes, aber dennoch wesentlich umfassender als in den generischen ITIL Beschreibungen dargelegtes Modell offeriert die ‚Pulinco GmbH’ [Pul06]. Ihr „ITIL Referenz­modell“ präsentiert sich als interaktive Webseite, die eine Menge scheinbar endlos verzweigter Verknüpfungen, Tabellen, Spalten und Illustrationen enthält. Der Detaillierungsgrad des Modells hebt sich in gewisser Weise von den ITIL Vorgaben ab, da es die Theorie um zahlreiche weiterführende Gedanken und Aspekte erweitert. Daneben erhebt das Modell zu recht den Anspruch, durchgängig formalisiert zu sein, schafft es allerdings nicht, die der Thematik gebührende Strukturierung, Übersicht und vor allem zusammenhängende Visualisierung zu bieten.

Ein weiteres Modell für ITIL Prozesse ist im Hause ‚IDS Scheer’ zu finden [IDS06]. Es manifestiert sich als Sammlung graphischer Darstellungen in Form ereignisgesteuerter Prozessketten (EPK). Die Visualisierungen sind durchwegs einfach gehalten und werden mit nur wenigen textuellen Anmerkungen erläutert. Sie sind in zahlreiche modularisierte Einheiten aufgegliedert, denen es ein wenig an Strukturierung mangelt. Dabei fällt es schwer, den Gesamtüberblick zu behalten. Das Modell bietet einen Detaillierungsgrad, der nicht über den der ITIL hinausgeht, wohl aber alle Komponenten und Aspekte der ITIL Prozesse geschlossen erfasst.

Auch die Firma Microsoft stellt ein Rahmenwerk für das ITSM bereit, und zwar das Microsoft Operations Framework (MOF) [Mof06a]. Dieses Modell, das auf der ITIL basiert und als Microsoft-Erweiterung zu betrachten ist, liefert anhand zahlreicher graphischer Veranschaulichungen mehr Informationen als die klassischen ITIL Publikationen. Die einzelnen Prozesse sind ausführlicher als bei der ITIL aufbereitet. Bezüglich Formalisierung und stilistischer Exaktheit sind die Publikationen denen der ITIL mehr oder weniger gleichzusetzen.

Ein vielversprechendes ‚Referenzmodell’ wird derzeit vom itSMF (IT Service Management Forum, siehe Abschnitt 3.3.1) entwickelt. Eine Arbeitsgruppe arbeitet daran, ein umfassendes Metamodell für die ITIL zu konstruieren, das entgegen den anbieterspezifischen Modellen von beispielsweise Scheer und Pulinco den Anspruch erhebt, eine standardisierte Konkretisierung der ITIL Inhalte zu sein. Das itSMF unterstellt, dass jede kommerzielle ITIL Verfeinerung mehr oder weniger einen eigenen ‚ITIL Dialekt’ kreiert. Ziel ist, anhand des standardisierten Metamodells keinen weiteren Dialekt zu schaffen. Ausgehend von einem ‚Kernmetamodell’ werden mehrere Konkretisierungsebenen, also Verfeinerungsstufen definiert. Dadurch soll ein „klar definiertes, stufenweises Vorgehen beim Ableiten ausführbarer Prozesse aus der generischen ITIL Prozessbeschreibung ermöglicht [werden]“ [PrSc06]. Abbildung 2-3 visualisiert die Idee.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3: itSMF Metamodell für ITIL [PrSc06]

Das Konzept der Diplomarbeit versucht keinen weiteren ITIL Dialekt zu entwickeln, sondern eine Konkretisierungsmethode vorzulegen, die eng an den OGC Vorgaben ausgerichtet und so allgemein­gültig wie möglich ist.

Abschießend ist anzumerken, dass jede Unternehmung, die die ITIL Methodologie produktiv lebt, die einzelnen Prozesse für sich konkret implementiert und somit weiter verfeinert haben muss. Da Prozessabläufe sensible Geschäftsdaten darstellen, sind diese konkreten ITIL Prozessimplementierungen in der Regel jedoch nicht frei zugänglich.

Das nächste Kapitel führt nun in das thematische Umfeld der Arbeit ein.

3 Kontext der Arbeit

In diesem Kapitel wird das thematische Umfeld der Diplomarbeit, das IT Service Management, näher vorgestellt. Dabei werden die wichtigsten Begrifflichkeiten definiert und erläutert, um dem Leser eine kompakte terminologische Grundlage anzubieten. Anschließend folgt eine Einführung in die ITIL als prozessorientierter Leitfaden und gegenwärtiger de facto Standard für das ITSM. Bevor auf das ITSM eingegangen wird zunächst eine Erklärung der Begriffe ‚IT Service’ und ‚Prozess’.

3.1 Begriffsdefinition IT Service und Prozess

Fundament des IT Service Managements ist der IT Service. Darunter versteht Sommer eine Dienstleistung, die von einem IT Anbieter für einen Kunden erbracht wird. Sie unterstützt Geschäftsprozesse und setzt sich aus einem integrierten Verbund von Aktivitäten, Technologien und Personen zusammen. Bereitstellung durch den Anbieter und Inanspruchnahme durch den Dienstnehmer finden häufig gleichzeitig statt, wobei der Dienstnehmer oft an der Bereitstellung und Verbesserung direkt und maßgeblich beteiligt ist [Som04].

Garschhammer et al. erweitern diese Definition und sehen einen IT Service als Menge von Interaktionen der Rollen User, Kunde und IT Diensterbringer. Zusätzlich wird ein IT Service durch die jeweilige Beziehung einer Rolle zu dem Service spezifiziert, was ihn letztlich erst genauer definiert [Gar01].

Der Fortlauf dieser Arbeit stützt sich auf die Begriffsbestimmung von Lewis [Lew99]:

„A Service is a function that the enterprise network provides for the business. [It might be seen as] an abstraction over and above the enterprise network [and] a phenomenon that arises in virtue of the structure and operation of the network ^[2] “ ([Lew99], S. 36).

Zur inhaltlichen Definition und qualitativen Bewertung eines IT Services ist es zwingend notwendig, sogenannte Service Level Agreements (SLA) zu formulieren. Diesen expliziten Dienstvereinbarungen obliegt die Aufgabe, Eckwerte eines IT Services zu beschreiben, die für den Dienstnehmer als wie auch für den Diensterbringer verständlich, messbar und entsprechend den Unternehmensanforderungen festgemacht sind. Anhand von in SLAs definierten Messkriterien wird es also ermöglicht, einen IT Service zu beurteilen [Ogc01]. Weitere bewährte Methodik zur Qualitätssicherung für IT Services beschreibt Deming mit seinem ‚Quality Circle’. Er fordert, dass jeder IT Service in der kreisförmigen Abfolge aus Planungsphase (Plan), Implementierungsphase (Do), Überarbeitungsphase (Check) und Anpassungsphase (Act) abläuft. Auf diese Art kann eine kontinuierliche Steigerung der Qualität erreicht werden [Ogc05].

Wie später noch gezeigt wird, ist ITSM eine Disziplin, die IT ausschließlich durch das Zusammenwirken integrierter ‚ Prozesse’ organisiert. Ein Prozess ist dabei als „Satz von in Wechselbeziehungen stehenden Mitteln und Tätigkeiten [zu verstehen,] die Eingaben in Ergebnisse umgestalten“ (vgl. DIN EN ISO 8402, 1995-08, Ziffer 1.2). Zu den Mitteln zählen Personal als auch Finanzen, Anlagen, Einrichtungen, Techniken und Methoden. Eine näher an die IT und somit an das ITSM zugeschnittene Definition bezeichnet einen Prozess als die „Gesamtheit von in Wechselbeziehungen stehenden Abläufen, Vorgängen und Tätigkeiten, durch welche […] Informationen transportiert oder umgeformt werden“ ([Dgq04], S. 14). Die Prozesssausführung unterliegt dabei gewissen Prozessbedingungen und wird kontinuierlich überwacht. Abbildung 3-1 veranschaulicht den Zusammenhang.

Betont sei, dass es von äußerster Wichtigkeit ist, sich für jede Implementierung eines ITSM­ Prozesses stets das eigentliche Ziel, nämlich die Unterstützung der Geschäftsabläufe des Kunden, vor Augen zu halten [ZaKu05]. Dies wird in der Praxis gerne über­sehen, was dazu führt, dass das Business an die IT angeglichen wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-1: Generisches ITSM Prozessmodell [Ogc05]

Zusätzlich ist für das Verständnis des Prozess-Begriffes nach ITSM erwähnenswert, den Zusammenhang zu Organisationsstrukturen, wie sie fast überall in Unternehmungen vorzufinden sind, aufzuzeigen. Prozesse sind in der Regel so organisiert, dass sie Aktivitäten verschiedener, unabhängiger Abteilungen erfordern. Das bedeutet, dass abteilungsübergreifender Input beigesteuert werden muss, um sie erfolgreich ausführen zu können. Umseitige Abbildung 3-2 veran­schaulicht diese Eigenschaft anhand eines exemplarischen Beispiels.

Ein fiktiver ‚Entstörungsprozess’, der beim Service Desk in Form eines Incidents ‚beginnt’, erfordert an diversen Stationen innerhalb der Beispiel-Organisation gezielte Aktivitäten, die durch die blauen Punkte dargestellt sind. So wird er zum einen an den Serverbetrieb und an das Netzwerkmanagement weitergeleitet, in einem weiteren Schritt dann and die Entwicklungsabteilung, die Leitung der Entwicklung und auch an das Organisationsteam. Schluss­endlich kehrt er nach weiteren Aktivitäten des Netzwerkmanagements an das Service Desk zurück. Prozesse sind somit filigran verästelte Abläufe, die intelligentes Management erfordern.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-2: Prozesse und Abteilungen [Ogc05]

Nun zu der Frage, was sich konkret hinter ITSM verbirgt.

3.2 IT Service Management

3.2.1 Was ist ITSM

Wie bisher beschrieben ist IT heutzutage nicht mehr als Sammlung loser Komponenten zu verstehen, sondern vielmehr als kooperativer Verbund vernetzter Systeme [Han99]. Es gilt, wohldefinierte Dienste und Anwendungen bereitzustellen, die an den Zielen einer Unternehmung ausgerichtet sind. Um dies zu erreichen, ist es notwendig, IT Services durchdacht zu steuern und zu verwalten. Dabei gilt es, die Kontrolle beziehungsweise Steuerung über die IT Services dauerhaft aufrechtzuerhalten, damit sie erfolgreich betrieben und weiterentwickelt werden können [Som04]. Diese Sichtweise verfolgt das IT Service Management. Der Begriff ITSM wird fast immer dazu verwendet, Managementmethoden für IT Infrastrukturen, die sich an integrierten Prozessen orientieren, zu beschreiben. Folgende, erste Definition ist weitläufig akzeptiert:

„ITSM ist eine Sammlung von Prozessen, die kooperierend die Qualität von IT Services garantieren, entsprechend den ‚Service Levels’, denen der Kunden zugestimmt hat. ITSM ist Management­bereichen überlagert, wie zum Beispiel dem System-Management, Netzwerk-Management oder der Systementwicklung, aber auch vielen Prozessbereichen wie Change Management, Asset Management und Problem Management“ ([You00], S. 2).

Eine andere Definition findet sich in auf dem IT-Portal Bitpipe.com. Hier wird ITSM als Top-Down Annäherung an das IT Management bezeichnet, die durch das ‚Business’ und nicht durch die Technik getrieben wird. Sie spricht speziell den strategischen Geschäftswert an, der durch die IT Organisation anhand ihrer Services generiert wird [Bit06].

Young versteht ITSM als Philosophie, die das Betreiben und Verwalten von IT Ressourcen beziehungsweise IT Prozessen als Dienstleistungsgeschäft betrachtet. Grundlage sind bewährte Aspekte aus Prozesskonstruktions-, Integrations- und Managementtechniken, so dass wettbewerbsfähige und profit-orientierte Praktiken für das Anbieten von IT basierten Produkten und Dienstleistungen etabliert werden können. Vorraussetzung für den Erfolg der Philosophie sind besonnene Kunden, die sich dieses Ansatzes bewusst sind, explizit definierte Services und Erwartungen an Performance, Fähigkeiten im Marketing und der Verwaltung von Finanzen und die Konzipierung von durchdachten, integrierten Prozessen, die nicht nur reaktiv sondern proaktiv sind [You00].

In Abbildung 3-3 ist nach Curtis demonstriert, welchen ‚Impact’ eine nach ITSM organisierte IT haben kann [Cur05]. Die Darstellung veranschaulicht, wie der Qualitätsgrad eines angebotenen IT Service mit zugrunde liegenden Konzepten zusammenhängt. Je mehr Anforderungen des ITSM umgesetzt werden, desto höher steigt auch die Qualität des angebotenen IT Service, wie an den Beschreibungen der Level 0 bis Level 4 zu erkennen: Bedient man sich beispielsweise lediglich der Unterstützung durch ein Workflowmanagement-Tool ohne weitere Prozesse und IT Management Konzepte, so wird der offerierte IT Service höchstwahrscheinlich durch Chaos bestimmt (Level 0). Organisiert man Services allerdings in Form des ‚Service Delivery Process Engineering’, indem beispielsweise Trends analysiert und Versuche unter­nommen werden, Probleme vorherzusagen, so kann man von einem ‚proaktiven’ Dienst sprechen (Level 2). Ziel von ITSM ist, wie schon zuvor erwähnt, einen IT Service ‚as a Business’ anzubieten (Level 4), der eine Unternehmung als strategischer Partner unterstützt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-3: ‚Reifende’ ITSM Modelle [Cur05]

Ein ähnliches, jedoch wissenschaftlich fundierteres ‚Reifegradmodell’ zur Beurteilung der Qualität von ITSM Implementierungen wurde an der Vrije Universität in Amsterdam entwickelt [NiVl99]: Das sogenannte IT Service Capability Maturity Model (ITS-CMM) bietet IT Dienstleistern zum einen die Möglichkeit, ihre Fähigkeiten bei der Bereitstellung von IT Services zu bewerten und stellt zum anderen umfangreiche Anleitungen bereit, wie Qualität bei IT Services verbessert werden kann.

Abbildung 3-4 stellt nach Young [You00] ein generisches Modell für das ITSM dar, dem viele in der Literatur zu findende Modelle sehr ähnlich sind, wie beispielsweise das ITSM Reference Model von Hewlett Packard [HP06]. Configuration und Change Management, die eng miteinander verwoben sind und somit gemeinsam aufgeführt werden, fungieren als zentrale Komponenten, um die sich die anderen Prozesse reihen. Dies resultiert aus der primären Zielsetzung von ITSM, Stabilität in Produktivumgebungen aufrechtzuerhalten, während zahlreiche, komplexe Änderungen (Changes) durchgeführt werden. Prozesse des Bereichs ‚Operations’ befassen sich mit alltäglichen Problemen an der Infrastruktur. ‚Service Development and Deployment’ - Prozesse agieren als Koordinatoren, Qualitätsüberwacher und Kontrollinstanzen über den Einsatz selbst gestrickter beziehungsweise gekaufter Applikationen. ‚Service Planning’ ist der Bereich, in dem alle Service Anforderungen des Kunden identifiziert, geplant und gemanagt werden. Dies umfasst typischerweise die Entwicklung und das Management von SLAs und Service-Management Verträgen. Die Prozesse des ‚IT/Business Alignment’ Bereichs behandeln strategische Verpflichtungen und administrative Aspekte des Betriebs einer IT Service Unternehmung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-4: Generisches Modell für das ITSM [You00]

Nach der kurzen Einführung zu ITSM nun eine Motivation für das Betreiben von IT Services nach den Praktiken des ITSM.

3.2.2 Motivation für ITSM

Wird IT als loses Gefüge isolierter, autarker und dezentral organisierter Organisationszellen betrachtet, so ist es ausgesprochen schwierig wenn nicht unmöglich, Services mit messbarem Quality of Service (QoS, zu übersetzen als ‚Dienstgüte’) anbieten zu können. Die offerierten Dienste der IT Organisation würden nicht als organisierte Einheit auftreten, über keine zentralen Managementfunktionalitäten verfügen und sich so in undurchsichtigen Zusammenhängen verlieren. Typische und allseits bekannte Probleme bei klassisch, also nicht nach ITSM organisierten IT Organisationen sind zum Beispiel [Som04] [Com06a]:

­ Betriebsunterbrechende Änderungen an Systemen
­ Unzureichende Service Level Agreements
­ Mangelnde Kontrolle über die IT Infrastruktur
­ Keine Messkriterien für generelle Verbesserungen
­ Nicht bekannte Service-Kosten
­ Nicht identifizierte und somit unerreichbare IT Komponenten

In einer nach ITSM verwalteten Umgebung würden die genannten Probleme nicht beziehungsweise nur sehr selten auftreten.

Am besten lässt sich die Relevanz und Bedeutung von ITSM anhand eines konkreten, aus der Praxis stammenden Workflows verdeutlichen. Im folgenden Beispiel, das [Com06a] entnommen wurde, wird ein einfaches aber typisches Störungserkennungs- und Problem­behebungsszenario für eine IT Applikation durchlaufen. Was würde passieren, falls kein ITSM mit wohlstrukturierten, integrierten Prozessen etabliert wäre?^[3]

Die Störung eines Systems, etwa der Ausfall eines Systemdienstes, wird im Monitoring durch einen Agenten erkannt und eine Nachricht (Event) über den Event-Manager an das Incident Management weitergeleitet (siehe Abbildung 3-5 auf der nächsten Seite). Dort kommt sie als Incident Eintrag in der Service Desk Software an. Der Bearbeiter des Tickets stellt fest, dass die Störung bereits mehrfach aufgetreten ist und informiert zur eigenständigen Ursachenforschung das Problem-Management. Das Problem-Management zieht zur Diagnose weitere Daten über andere Systeme aus dem Management-Data-Warehouse heran und entscheidet schließlich, einen Change Request auf allen Systemen gleichen Typs vorzunehmen, um den Fehler zu beheben. In diesem Beispiel geht es darum, zur Fehlerbehebung einen Patch für das Betriebssystem einzuspielen. Im Change-Management wird die Änderung auf ihre Machbarkeit hin geprüft. Dabei wird festgestellt, dass aus anderen Gründen bereits einige Systeme mit dem Patch versorgt wurden. Zudem wird erkannt, dass es auf einem System eine Unverträglichkeit einer Anwendung mit dem geplanten Patch gibt, dieses System jedoch von dem Problem bislang nicht betroffen war. Der Change wird nun für die restlichen, mit dem Patch kompatiblen Systeme über einen Eintrag der geplanten Änderung in die CMDB veranlasst. Er wird an das Release Management weitergeleitet, das die Änderung vornimmt. Der neue Zustand der Systemkonfiguration wird vom Discovery gescannt und in der CMDB hinterlegt. Das Configuration-Management verifiziert im Rahmen eines Abgleichs den Ist- und Sollzustand und meldet dem Change-Management den Vollzug der Änderung, der Change wird geschlossen, und damit kann auch der Incident geschlossen werden.

In einem dezentralen Umfeld mit nicht strukturierter, also isolierter Überwachung und getrenntem Patch Management wäre das Szenario unter Umständen mit negativen Auswirkungen auf den Betrieb und wesentlich ineffizienter abgelaufen. Zudem gäbe es in der Regel dort keine Protokollierung der aufgetretenen Fehler, und somit würde es an Daten über die Häufigkeit der Störungen mangeln. Das Service Desk würde außerdem die Ursache der Störung nicht herausfinden können, sofern kein zentrales Problem-Management etabliert wäre. Schlimmstenfalls wäre es dazu gekommen, dass die Störung über einen langen Zeitraum hinweg aufgetreten wäre, ohne dass man nach einer nachhaltigen Lösung für ihre Beseitigung gesucht hätte. Früher oder später hätte man beschlossen, den Patch vorsorglich auf allen Systemen einzuspielen. Falls keine CMDB existieren würde, wäre es aufwändig gewesen, festzustellen, wo der Patch bereits installiert wurde. Die Unverträglichkeit mit der Anwendung hätte man nicht entdeckt, was womöglich zu Ausfällen der Anwendung geführt hätte. Es wird klar, dass es aufgrund fehlender integrierter Prozesse schlichtweg keine Garantie für eine effiziente und erfolgreiche Lösung des Problems gegeben hätte. Durch den Einsatz von ITSM Methoden und Techniken wird gewährleistet, dass das eben beschriebene Szenario nicht eintritt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-5: Abstrahierter Durchlauf eines beispielhaften Problembehebungszenarios des IT Service Managements

Der folgende Abschnitt stellt einige Aspekte zur konkreten Etablierung von ITSM in einem Unternehmen vor.

3.2.3 Erfordernisse zur Einführung von ITSM in einer Organisation

Es erfordert bestimmte Kompetenzen, um ITSM mit all seinen Anforderungen in einem Unternehmen einzuführen. Profunde Kenntnisse aus den Bereichen Serviceorientierung, Planung, Organisation und Betriebswirtschaft werden benötigt. Wichtig ist, dass sich der Fokus aller Beteiligten weg von der Technologie und den damit verbundenen Produkten hin zur Erbringung von Services bewegt. Hauptaugenmerk liegt nämlich nicht mehr auf dem Dienst an sich, also beispielsweise der isolierten Betrachtung eines Server Dienstes, sondern auf den Ergebnissen und Auswirkungen von dessen Bereitstellung. Im Rahmen einer ‚serviceorientierten’ Kundenbeziehung hat der Dienstleister als strategischer Partner aufzutreten. Dazu ist nötig, dass Mitarbeiter des Diensterbringers Fähigkeiten wie kunden- und leistungsorientiertes Verhalten, Verhandlungs­geschick, Risikobewusstsein als auch wirtschaftliches und strategisches Arbeiten entwickeln. Ebenso müssen Kunden vom Nutzen des ITSM überzeugt sein und wissen, dass ITSM die von ihnen genutzten IT Services verbessert und somit zu einem wichtigen Erfolgsfaktor der gesamten Unternehmung wird. Wichtig ist, dass die eingeführten Prozesse konsequent und dauerhaft eingehalten werden. Nur dann kann die Servicequalität verbessert werden und zu einer optimalen Unterstützung des Kunden führen [Som04].

3.2.4 Best Practices für ITSM

ITSM wird in einem Unternehmen in der Regel nicht auf der zuvor beschrieben generischen Ebene eingeführt. Man bedient sich stattdessen eines greifbaren Leitfadens, der die Grundkonzepte des ITSM anhand sogenannter Best Practices konkre­tisiert. Eine ‚Best Practice’ ist zu definieren als eine in der Praxis erprobte und bewährte ‚optimale Vorgehensweise’, die einen bestmöglichen Ansatz spezifiziert und zu qualitativ hochwertigen Ergebnissen führt [Bro02]. Zu Best Practices für ITSM gehören nach [Olb02] unter anderem:

­ Control Objectives for Information and Related Technology (Cobit) [Isa06]
­ BiOOlogic [Bio06]
­ Microsoft Operations Framework (MOF) [Mof06a]
­ Information Technologie Infrastructure Library (ITIL) [Ogc06b]

Die ITIL, der am weitesten verbreitete und gegenwärtige de facto Standard-Leitfaden für das ITSM (vlg. Abschnitt 3.3.2) wird nun im nächsten Abschnitt detailliert vorgestellt.

3.3 IT Infrastructure Library

Nach einigen Worten zur Entstehungsgeschichte der ITIL wird in diesem Abschnitt Ihre Bedeutung exemplarisch hervorgehoben. Anschließend werden die einzelnen Publikationen, die die ITIL bilden, genauer vorgestellt. Dabei wird im Speziellen auf die Kernprozesse für das Service Management der ITIL eingegangen, zu denen auch der Change Management Prozess, der Fokus dieser Diplomarbeit, gehört. Der Abschnitt wird durch eine kritische Betrachtung abgerundet.

3.3.1 Entstehungsgeschichte

Die britische Central Computer and Telecommunications Agency (CCTA), die vor einiger Zeit in das Office of Government Commerce (OGC) integriert wurde, publiziert seit dem Ende der 80er Jahre unter dem Label ITIL einen ausführlichen Leitfaden für das ITSM. Grund für die Entwicklung des Leitfadens war das Fehlen von Prozessstandards, die allen britischen Regierungseinrichtungen zum Management ihrer komplexen IT Strukturen zur Verfügung stehen sollten. Ziel war dabei wie zuvor beschrieben konkrete Anleitungen zu offerieren, nach denen Informationstechnologie effizient und kostengünstig entsprechend der Denkweise des ITSM organisiert werden kann [BrMi02].

Da die Anforderungen einer Regierungseinrichtung nicht zwangsläufig denen der marktwirtschaftlichen Geschäftswelt entsprechen, hat die OGC Arbeitsbeziehungen zu zahlreichen nichtstaatlichen Unternehmen, Organisationen und Gruppen etabliert, um die ITIL zu erproben und zu modifizieren. Hieraus entstand das IT Service Management Forum (itSMF) als gemeinnützige Stiftung. Durch diese Verbindung zu einer Anwenderorganisation wird gewährleistet, dass die ITIL ein dynamisches und sich kontinuierlich weiterentwickelndes Gefüge bleibt, das stets bemüht ist, neuste Erkenntnisse aus der Praxis aufzugreifen [Bre06].

3.3.2 Bedeutung

ITIL wird als der de-facto Standard für das ITSM in Europa gesehen. Sie wurde als Basis für den ersten formalen britischen ITSM Standard verwendet, und fungierte Ende letzten Jahres als Grundlage für den neuen ISO/IEC Standard 20000. Ebenso bedienen sich das Standardqualitätssystem ISO/IEC 9000 und auch das IT-Grundschutzhandbuch des Bundesamts für Sicherheit in der Informationstechnik (BSI) dieser Best Practice Sammlung [ZaKu05]. In den letzten Jahren hat die ITIL auch in Nordamerika und Kanada signifikante Bedeutung erlangt. Zwar ist es noch etwas verfrüht vorherzusagen, ob sie sich weltweit etablieren wird, doch die Bemühungen der zahlreichen Tool-Hersteller, Beratungshäuser und international ausgerichteten Unternehmen weisen in diese Richtung [BrMi02].

Bedeutend ist neben dem die Tatsache, dass sich eine IT Unternehmung mittels ITIL schnell und einfach eine wohldefinierte Ausgangslage für das ITSM schaffen kann. Die Kosten zur Beschaffung der ITIL Bücher sind relativ gering,^[4] was zunächst niedrige Auswirkungen auf das IT Budget einer Unternehmung hat und recht schnell zu ersten Ergebnissen führen kann. Allerdings ist es damit nicht getan, denn die umfassende Entwicklung, Einführung und das kontinuierliche Ausüben des ITSM bedarf erheblicher Mittel.

Auch ITIL Zertifizierung hat sich mittlerweile zu einem bedeutungsvollen Aspekt entwickelt. IT Dienstleister, die Ihre Services strikt gemäß der ITIL betreiben, können sich dies beispielsweise anhand einer Zertifizierung durch das holländische Exameninstitut voor Informatica (EXIN) oder das britische Information Systems Examination Board (ISEB) bestätigen lassen [Exi06] [Ise06]. Das Zertifikat garantiert Qualität, was dem Kunden die Dienstleisterauswahl erleichtern kann.

Weitere interessante Informationsquelle für Fragen zur Bedeutung der ITIL ist eine Studie der Firma Detecon, die im Jahre 2004 „Trends und Perspektiven der ITIL in Deutschland“ untersucht hat [Det04]. Sie kommt zu dem Schluss, dass das ITSM bei überwiegender Mehrheit der befragten Unternehmen noch mit Mängeln behaftet ist. Große Organisationen, die über umfangreiche IT Abteilungen verfügen, haben sich bereits weitgehend entsprechend der Empfeh­lungen der ITIL organisiert. Dennoch werden IT Prozesse nur selten vollständig nach den ITIL Vorgaben gemanaged. Die korrekte Ausführung der standardisierten Prozesse durch Mitarbeiter bereitet den meisten Unternehmen noch Probleme. Weiteres Ergebnis der Studie ist, dass die Nutzung des ITIL Konzeptes vor allem bei großen IT Organisationen zu einer Verbesserung des ITSM führt. Bei kleinen Unternehmen ist dem in der Regel nicht so. Um speziell ihnen bei der Verbesserung des ITSM bessere Unterstützung bieten zu können, wäre die Entwicklung einer abgespeckten und auf die besonderen Bedürfnisse von Kleinunternehmen angepassten ITIL Version hilfreich.

Ähnliche Befunde liefern Umfragen der International Network Services GmbH aus März 2006 [INS06] und der FH Aalen aus dem Jahre 2004 [Aal04]. Bei beiden wurde im Kern ebenfalls herausgefunden, dass immer mehr und mehr Organisationen ein Bewusstsein für die ITIL entwickeln, sie also zunehmend an Signifikanz gewinnt.

Auch ein Research Paper von Gartner aus dem Jahr 2005 entwickelt analoge Ergebnisse [CuCo05]. Die Autoren stellen anhand ihrer Umfragen ebenso fest, dass die ITIL als ITSM Leitfaden steigende Marktanteile verbuchen kann. Nichts desto trotz hat eine nicht unbeachtlicher Teil anderweitige ITSM Modelle übernommen, wie beispielsweise Cobit (‚Control Objectives for Information and Related Technology’, internationales Modell von Kontrollzielen, speziell für IT Prozesse) oder Six Sigma (Methode des Qualitätsmanagement, um möglichst fehlerfreie Prozesse erreichen zu können), da diese spezielle Komponenten bereitstellen, die der ITIL fehlen. Es lässt sich allerdings auch beobachten, dass ITIL oft in Kombination mit anderen ITSM Modellen eingesetzt wird. Unternehmen konstruieren sich somit ihr eigenes ITSM Derivat. Gartner behauptet nebendem, dass die Mehrheit der IT Organisationen ITIL nicht als das Ende des ITSM Weges sehen. Sie sind vielmehr der Meinung, dass verbesserte, weiterentwickelte Konzepte aufkommen werden. Abschließend wird festgestellt, dass eine Einführung der ITIL nicht zwangsläufig automatisch verbesserte IT Services garantiert. Eine Umstrukturierung zur Etablierung der ITIL stellt einen erheblichen Eingriff in eine Organisation dar, der immer noch allzu gerne unterschätzt wird.

Weitergehende Befunde und Zahlen zur Verbreitung der ITIL lassen sich in der Arbeit von Sewera finden. Dort wird zum Beispiel aufgeführt, dass „nach neueren Befragungen […] zwei Dritteln der deutschen Unternehmungen ITIL bekannt“ ([Sew05], S. 42) ist, und mehr als ein Drittel ITIL-Anwendungen im produktiven Einsatz hat. Die am häufigsten etablierten ITIL Prozesse sind Change und Security Management als wie die Funktion Service Desk.

Nun zu der Frage, woraus sich der ITIL Leitfaden konkret zusammensetzt.

3.3.3 Grundstruktur

Die ITIL Bibliothek umfasst insgesamt folgende acht Bände, die jeweils einzelnen Managementbereichen entsprechen [Ogc06c]:

­ Service Support
­ Service Delivery
­ Planning to Implement Service Management
­ ICT Infrastructure Management
­ Application Management
­ Software Asset Management
­ Security Management
­ The Business Perspective

Die Werke Service Support und Service Delivery präsentieren Best Practices für das effektive und effiziente IT Service Management und werden als Kern der ITIL bezeichnet [Ogc00a] [Ogc01]. Auf sie wird im Weitern genauer eingegangen. Planning to Implement Service Management beschäftigt sich konkret mit der Erst-Implementierung von ITIL in einer Organisation. Dabei wird unter anderem behandelt, wo und wann zur ITIL Einführung angesetzt werden sollte, welche Umgestaltungen innerhalb einer Organisation vonnöten sind, welche Veränderungen der Unternehmenskultur einhergehen müssen und welche Implikationen die Einführung auf Projekt- und Programmplanung hat [Ogc02a]. Der Band ICT Infrastructure Management stellt Vorgehensweisen zur Strategieentwicklung für die Etablierung von IT Infrastrukturen bereit [Ogc02b]. In der Publikation Application Management wird eine Reihe von Methoden angeboten, mit deren Hilfe die Erstellung, Einführung und Verwaltung von Applikationen nach der Idee der ITIL abgewickelt werden kann. Es handelt sich um ein ‚Lifecycle Management’ für Anwendungssysteme, zu betrachten als Kombination aus Betreiber- und Betreuungsdienstleistungen für den gesamten Lebenszyklus [Ogc02c]. Software Asset Management beschäftigt sich mit der Infrastruktur und den Prozessen, die notwendig sind, um den Lebenszyklus von Software Assets zu steuern und zu verwalten [Ogc03]. Das Buch Security Management bietet ‚beste Vorgehensweisen’ für alle sicherheitsrelevanten Gesichtspunkte des ITSM und ist aus diesem Grund mit allen anderen ITIL Prozessen eng verwoben [Ogc00b]. Das letzte Werk The Business Perspective beschreibt die Beziehungen der IT zu Ihren Kunden. Es präsentiert Konzepte, anhand derer IT Organisationen die angebotenen Services verbessern können, um den Geschäftszielen ihrer jeweiligen Dienstnehmer besser gerecht zu werden [Ogc04].

Zur besseren Veranschaulichung ist die Struktur der ITIL in Abbildung 3-6 zusammenfassend dargestellt. Nicht enthalten ist der Band Software Asset Management, der eng an das Application Management anzugliedern wäre.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-6: ITIL Grundstruktur [Pra05]

Nachdem die grundlegende Beschaffenheit der ITIL aufgezeigt wurde, folgt im Weiteren ein tieferer Blick auf die Kernprozesse.

3.3.4 Kernprozesse für das Service Management der ITIL

Das Service Management ist als Herzstück der ITIL zu betrachten. Es wird wie erwähnt aus den Büchern Service Delivery und Service Support gebildet, die jeweils fünf Prozessbeschreibungen enthalten. Zusätzlich umfasst das Service Management das sogenannte Service Desk, das während des Regelbetriebes als einziger Kontaktpunkt einer IT Organisation zu deren Kunden fungiert. Das Service Desk ist kein Prozess, sondern eine Funktion, die mehrere Prozesse bedient [Its04]. So übernimmt es beispielsweise oft den First-Level-Support des Incident Manage­ments.

Zunächst ein genauerer Blick auf Service Delivery.

3.3.4.1 Service Delivery

Der Bereich Service Delivery beschäftigt sich mit der taktischen Planung und Steuerung aller IT Service Leistungen. Ihm sind folgende Prozesse zugeordnet [Its04]:

Service Level Management (SLM)

Das SLM arbeitet an der Erhaltung und allmählichen Verbesserung der auf die geschäftlichen Aktivitäten des Kunden ausgerichteten IT Services. Zu diesem Zweck sind Vereinbarungen zur Leistungen der IT Organisation zu treffen, die anschließend kontinuierlich überwacht und dokumentiert werden.

Financial Management for IT Services

Das Financial Management für IT Services sorgt dafür, dass der Betrieb aller angebotenen IT Services innerhalb eines wirtschaftlich vertretbaren Rahmens abläuft. Zentrales Element des Managementbereichs ist somit die Berechnung und Überwachung aller Kosten. Falls Anpassungen innerhalb der gemanagten IT Infrastruktur nötig werden, wird im Financial Management vor einer Autorisierung zwischen Kosten und Nutzung und somit zwischen Preis und Leistung abgewogen. Weitere Aufgabe ist, das Thema ‚Charging’ zu organisieren, also wie sich Kosten an Kunden weiterverrechnen lassen.

Capacity Management

Aufgabe des Capacity Managements ist die Optimierung des Einsatzes von IT Ressourcen. Wie der Name schon verrät sind Kapazitäten zu planen und zu organisieren. Darunter fallen das Management von Ressourcen, deren Optimierung, das Management der Leistung von Ressourcen und der Bereich der Anwendungsdimensionierung. Wichtig ist, dass vorausschauend geplant wird, um stets die vereinbarten Service Levels erreichen zu können.

IT Service Continuity Management

Der Bereich Service Continuity Management hat zur Aufgabe, Planungen für den Katastrophenfall in Form von Kontinuitätsmaßnahmen bereitzustellen. Ihm obliegt es, alle nötigen Maßnahmen einzuleiten, um IT Services, die dem Kunden durch SLAs garantiert werden, im Falle von unvorhergesehenen, schwerwiegenden Vorfällen aufrechtzuerhalten beziehungsweise schnellstmöglich wieder herzustellen. Dabei sind alle technischen, finanziellen und organisatorischen Kontinuitätsmaßnahmen bereichsübergreifend zu planen und abzustimmen.

Availability Management

Dem Availability Management obliegt es, die mit dem Kunden im SLA vereinbarte Verfügbarkeit der IT Services sicherzustellen. Darunter fallen unter anderem das Management von Wartungsfenstern und die Ergreifung von Maßnahmen zur Minimierung der Folgen von Störungen.

3.3.4.2 Service Support

Der Bereich Service Support ist entgegen der Zielsetzung der Service Delivery Prozesse auf das Management des alltäglichen Betriebs eines IT Services ausgerichtet. Er befasst sich mit Dienstleistungen, die erforderlich sind, um Kunden ausreichende IT Unterstützung zu allen aktiven Geschäftsabläufen zu geben.

Service Support ist in fünf Managementbereiche und eine Funktion unterteilt:

Incident Management

Das Incident Management hat den Zweck, dem Anwender einen gestörten beziehungsweise ausgefallenen Service so schnell wie möglich wieder zur Verfügung zu stellen. Die Beseitigung der Ursache ist dabei zweitrangig. Bereits eine Störungsumgehung zählt als Beseitigung der Störung. Um dies zu gewährleisten, ist das Service Desk (siehe nächster Punkt) dem Incident Management meistens direkt angegliedert. Somit werden Zwischenfälle (Incidents) gleich in erster Instanz erfasst, wobei die Qualität der dokumentierten Informationen zu einer Störung von eklatanter Wichtigkeit ist, da sie unmittelbaren Einfluss auf die Effektivität des Incident Managements und der anderen Prozesse (wie zum Beispiel der des Problem Managements) hat.

Service Desk

Wie beschrieben ist das Service Desk kein Prozess im ITIL-Sinne sondern vielmehr eine unabhängige organisatorische Einheit. Es übernimmt die Funktion des einzigen Ansprechpartners des Kunden beim Service Provider. Wiederholend lässt sich sagen, dass die zentrale Aufgabe des Service Desks in der Erfassung, Bearbeitung und Überwachung von Vorfällen aller Art liegt.

Problem Management

Das Problem Management unterstützt das Incident Management, indem bei schwerwiegenden oder häufig auftretenden Störungen deren Ursachen analysiert werden. Zusätzlich wird daran gearbeitet, strukturellen Schwierigkeiten in einer IT Infrastruktur zu begegnen. So können kontrollierte Strategien zur Störungs- und Ursachenbeseitigung entwickelt werden. Dazu gilt es, in Zusammenarbeit mit dem Service Desk und anderen Managementbereichen den Fehlerbeseitigungsprozess zu koordinieren. Neben dem versucht das Problem Management, die IT Infrastruktur proaktiv und vorgreifend auf Schwachstellen zu untersuchen, um die Anzahl von Fehlern vorab bereits reduzieren zu können.

Configuration Management

Das Configuration Management hat die Aufgabe, andere Managementbereiche durch die Bereitstellung eines möglichst detaillierten Modells der IT Infrastruktur zu unterstützen. Alle IT Assets werden dazu in einer sogenannten Configuration Management Data Base (CMDB) erfasst und beschrieben. Dabei werden nicht nur Vermögenswerte bilanztechnisch erfasst, sondern auch Informationen zum Standort, Abhängigkeiten von anderweitigen Komponenten und Spezifikationen von Applikationen. Die Tiefe der Beschreibung gründet sich aus dem Informationsbedarf anderer Managementbereiche. Ein Beispiel zur Nutzung der CMDB wäre der Vergleich der Konfigurationen eines Pools an Rechnern, an denen überall derselbe Fehler auftritt. Asset-Informationen aus der CMDB könnten dem Problem Management bei der Ursachensuche behilflich sein. Zusätzliche Aufgabe des Configuration Managements ist die Dokumentation aller Statusänderungen an einer Infrastruktur.

Change Management

Änderungen (Changes) sind allgegenwärtiger und normaler Bestandteil einer jeden Unternehmung. Auf Veränderungen im geschäftlichen Umfeld muss reagiert werden, wovon zwangsläufig auch die IT Infrastruktur betroffen ist. Mögliche Gründe für Änderungen sind:

­ Anforderungen aus dem Incident- und Problem Management
­ Tausch oder Upgrades von Systemkomponenten
­ Änderungen in den Geschäftsprozessen beim Kunden
­ Veränderte oder neue Gesetzgebungen
­ Einführung neuer Produkte oder Dienstleistungen

Laut ITIL gilt es, notwendige Änderungen stets durch das Change Management zu erfassen. Änderungen müssen geplant, genehmigt und umgesetzt werden. Zudem muss die Umsetzung überprüft werden. Dadurch soll der Änderungsprozess kontrolliert und die Auswirkungen auf den produktiven Betrieb minimiert werden. Ab Kapitel 4 wird erheblich detaillierter auf das Change Management eingegangen.

Release Management

Um sicherzustellen, dass nur kompatible und möglichst einheitliche Soft- und Hardware im Produktionsbetrieb eingesetzt wird, muss deren Installation und Wartung kontrolliert und autorisiert werden. Das Release Management testet und genehmigt Soft- und Hardware, um das funktionierende Zusammenspiel mit allen anderen eingesetzten Configuration Items (CI, Komponente der IT Infrastruktur, die zur Erbringung eines Services benötigt wird, und die in der CMDB erfasst ist) zu gewährleisten. Die Wahrscheinlichkeit der Einführung fehlerhafter beziehungsweise nicht kompatibler Komponenten wird durch diese Qualitätssicherung gesenkt. Neben der beschriebenen Steuerung von Soft- und Hardware-Rollouts obliegt dem Release Management, Anwender und Servicemitarbeiter beispielsweise durch die Organisation von Schulungen rechtzeitig auf Änderungen vorzubereiten. Durch die Zusammenarbeit mit dem Configuration Management wird im Weiteren die Dokumentation zur Infrastruktur zeitnah aktualisiert.

Um die Service Support und Service Delivery Prozesse greifbarer zu visualisieren, wird in umseitiger Abbildung 3-7 in Anlehnung an Brenner dargestellt, wie die Interaktion der Prozesse beispielhaft während des Lebenszyklus eines Incidents von statten gehen könnte [Bre02].

Zum Abschluss dieses Abschnitts sei darauf hingewiesen, dass die Kernprozesse der ITIL nur rudimentär angerissen wurden. Die Verknüpfungen der einzelnen Bereiche und deren Umsetzung würden den Rahmen einer Kurzdarstellung sprengen und sind daher unberücksichtigt geblieben. Für vertiefende Informationen zu den anderweitigen, lediglich kurz erwähnten ITIL Publikationen sei auf einschlägige Literatur verwiesen.

Im Rahmen dieser Einführung folgen nun exemplarisch einige kritische Aspekte.

3.3.5 Kritische Betrachtung

Wie jede Theorie birgt auch die ITIL nachteilige Aspekte. Großer Vorwurf, der ihr gemacht werden kann, ist die Tatsache dass Weiterentwicklungen weder systematisch organisiert noch gezielt finanziert werden. Weder das OGC als Rechteinhaber der ITIL noch das itSMF verfügen über einen umfassend entwickelten Business Plan, so dass die Best Practices weiterhin mehr oder wenig ‚zufällig’ und ohne Road-Map vorangetrieben werden. Es ist anzunehmen, dass die ITIL Publikationen somit immer den aktuellsten Erfordernissen und Geschäftsmethoden produktiver Szenarien hinterherhinken werden [BrMi02].

Zu bemängeln ist an der ITIL außerdem die Tatsache, dass sie als Modell für das ITSM zu generisch bleibt. Mit ihrer bibliotheksartigen Struktur, deren Bände mit Richtlinien und Empfehlungen gefüllt sind, ermöglicht sie, ein eigenes Implementierungskonzept für das ITSM zu finden. Dazu stehen in der Publikation ‚Planning to Implement Service Management’ Anlei­tun-­

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-7: Beispiel für Interaktion der Service Support und Service Delivery Prozesse [Bre02]

g­en bereit. „Für die [konkrete] technische Umsetzung des Servicemanagements liefert es hingegen kaum Unterstützung“ [ZaKu05].

Anderer kritischer Aspekt gründet sich im Thema ‚Tool-Zertifizierung’. Obwohl mittlerweile viele Anbieter von Workflowmanagement-Applikationen ihre Produkte als ‚ITIL-konform’ anpreisen, existieren für die Tool-Unterstützung kaum allgemein etablierte Konzepte und Zertifizierungs­richtlinien. Häufig werden Tools postum als ITIL-konform deklariert, oder pro­prietäre, nicht-offen gelegte Beurteilungen wie beispielsweise von ‚Pink Elephant’ [Pin06] eingekauft. Ursachen dafür sind beim OGC zu suchen, das als Inhaber der ITIL Urheberrechte gegenwärtig kein anerkanntes Gütesiegel für ITIL Managementsoftware vergibt [Ogc06a]. Ein Umdenken würde den Tool-Markt konsolidieren und die Toolauswahl erheblich transparenter machen.

Neben dem ist festzustellen, dass die Beschreibungen der ITIL unterschiedlich strukturiert sind [Pro03], ein klares Gesamtmodell vermissen lassen [Han99] und erhebliche Lücken aufweisen. Bei der Interaktion von verschiedenen ITIL Prozessen ist beispielsweise oft nicht klar definiert, ob die Prozesse über echte Prozessschnittstellen verfügen, oder lediglich Informationen austauschen. Die wenigen Workflow-Skizzen, die die textuellen ITIL Prozess­beschreibungen erläutern, enthalten zur Veranschaulichung von Interaktionen stets Pfeile gleicher Art. Kriterien zur Entscheidung, ob es sich um eine Schnittstelle oder um eine auszutauschende Information handelt, werden auch im Text nicht angegeben [PrSc06]. Ein weiteres Beispiel für Lücken in den ITIL Beschreibungen findet sich im Zusammenhang mit an Prozessen beteiligten Rollen. Diese werden in der ITIL zwar einzeln genannt und oft auch erklärt, aber nicht in eine zusammenfassende Darstellung in Form von Übersichten gebracht (vgl. Abschnitt 4.5). Ebenso verhält es sich mit der Beschreibung von im Laufe von Prozessen auszutauschenden Informationen. Diese werden zwar angeführt, allerdings wird nicht spezi­fi­ziert, wie sie sich konkret zusammenzusetzen haben (vgl. Abschnitt 4.6).

Aus den Lücken der ITIL ergeben sich weitere Probleme. Da die Prozesse oft nur unvollständig spezifiziert sind und keine konkreten, standardisierten und gleichzeitig umfassenden Modelle für die Einführung der ITIL vorliegen, interpretieren und vervollständigen ITIL Berater, IT Professionals und Anbieter von Workflowmanagement-Lösungen die ITIL Vorgaben auf ihre Art [Buh05]. Auf diese Weise entstehen inkompatible ITIL Erweiterungen, die nicht vergleichbar sind.

Letzter Gesichtspunkt, den man bei der ITIL vergeblich sucht, ist eine durchgängige Formalisierung der angebotenen Prozessbeschreibungen [Pro03]. Um dem entgegenzuwirken, wird das im Rahmen der Prozessverfeinerung dieser Diplomarbeit erstellte Business Process Diagramm wie angekündigt formal in BPMN modelliert.

3.4 Zusammenfassung

Im diesem Kapitel wurde der Leser in Form einer kurzen Einführung an das weitläufige Feld des IT Service Managements herangeführt. Nach einigen Begriffsdefinitionen und Erläuterungen zum ITSM folgte eine Einführung zur ITIL, dem gegenwärtig etabliertesten Leitfaden für das ITSM. Die einzelnen Managementprozesse der ‚Core Titles’ wurden dabei rudimentär vorgestellt. Der Leser sollte nun in der Lage sein, die Diplomarbeit in ihren thematischen Rahmen einzuordnen.

Im nächsten Kapitel wird der ITIL Change Management Prozess erneut aufgegriffen und erheblich detaillierter betrachtet.

4 Referenzmodell für Change Management nach ITIL

Im Folgenden wird ein Referenzmodell für das ITIL Change Management (CM) erstellt. Der Prozess wird dabei erneut aufgegriffen und vertiefend betrachtet, so dass er gemäß seiner Spezifizierung in der ITIL umfassend und in sich geschlossen aufbereitet ist. Dazu wird zunächst der Begriff ‚Referenzmodell’ definiert, um deutlich zu machen, wie er im Kontext der Arbeit zu verstehen ist (Abschnitt 4.1). Nach einer Einordnung des Begriffes ‚Change’ folgen Erläuterungen zur Umgebung des CM Prozesses. Aufgabe ist, ihn in das Gesamtfeld aller ITIL Prozesse einzuordnen (Abschnitt 4.2). Daraufhin wird das grundlegende Konzept des Prozesses vorgestellt, wobei die Prozessbestandteile und der grobe Prozessablauf beleuchtet werden (Abschnitt 4.3). Wichtigster Teil dieses Kapitels ist der anschließende Abschnitt zur Modularisierung kohärenter Prozesskomponenten. Ziel ist, den Prozessablauf nach ITIL in funktional zusammen­gehörende Ein­heiten aufzuteilen, diese detailliert zu beschreiben und das entstehende Modell mittels BPMN zu formalisieren (Abschnitt 4.4). Danach wird dargelegt, wie die Rollen des Prozesses zueinander in Beziehung stehen (Abschnitt 4.5), und auch der Fluss von Informationen zusammenhängend erläutert (Abschnitt 4.6). Das Kapitel wird mit einer knappen Zusammenfassung und einer Bewertung der BPMN abgeschlossen (Abschnitt 4.7).

4.1 Begriffsdefinitionen

Referenzmodelle sind Konstrukte, die im Kontext der Modellierung von Geschäftsprozessen allgegenwärtig sind. Ein Standard-Referenzmodell lässt sich dabei nicht spezifizieren, je nach Anforderung existieren unterschiedliche Typen. So nennen beispielsweise Fettke, Loos und Zwickler in ihrer Abhandlung ‚Business Process Reference Models’ allein 30 unterschiedliche Modelle [FeZw05]. Weitere Beispiele wären Scheer und sein ‚Referenzmodell für industrielle Geschäftsprozesse’ [Sche97] oder Becker und Schütte mit dem ‚Handels-H Referenzmodell’ [BeSc04]. Bei allen Darlegungen ist festzustellen, dass die Bezeichnung ‚Referenzmodell’ eine Formulierung ist, die oft verwendet aber nur selten anhand einer klaren Definition abgegrenzt wird [Har94]. Für diese Diplomarbeit sei sie deshalb wie folgt abgesteckt. Das hier erstellte Referenzmodell des ITIL Change Managements ist als „initial conceptual approach“ [Tho05] (zu übersetzen als ‚erster konzeptioneller Denkansatz’) zu verstehen, also als generischer Referenzpunkt für die Entwicklung weiterführender, spezifischerer Modelle. Es soll keinen ausführ­baren Charakter haben, sondern so gut es geht mit Abstraktheit aufwarten. Zweck des hier erarbeiteten Referenzmodells ist, als formalisierte Ausgangslage oder sogenannte ‚Stufe 0’ für das im Fortgang der Arbeit zu entwickelnde verfeinerte CM Modell zu fungieren.

Im bisherigen Verlauf der Arbeit wurde CM bereits mit einführenden Worten kurz vorgestellt. Dabei ist jedoch noch nicht genauer auf die Bedeutung des Begriffs ‚Change’ eingegangen worden. Grundsätzlich ist ein Change, zu übersetzen als Veränderung, Eingriff oder Wandel, ein Vorgang, der etwas zum ‚Anderen’ transformiert.^[5] Das Andere kann dabei etwas Neuartiges oder auch Vorhergehendes, zuvor Abgelöstes sein. Im Kontext unternehmerischer Organisationsentwicklung bedeutet ‚Change’, den Wandel von Unterneh­mungen zu organisieren. Der sogenannte ‚Organisational Change’ entspringt dabei eher einer betriebwirtschaftlichen Domäne, meist ohne Berücksichtigung technischer Implementierungen [CaGr04]. Umgestaltungen geschäftlicher Abläufe sind nötig, um bei ständig neuen wirtschaftlichen Herausforderungen auf Marktumgestaltungen und zunehmende Konkurrenz reagieren zu können. Weitere Gründe für organisatorische Veränderungen sind laut Scheer beispielsweise [SeAb03]:

­ Neue oder sich wandelnde Kunden, Zulieferer oder andere Marktteilnehmer
­ Neue oder veränderte Marktangebote (Produkte, Dienstleistungen, Informationen usw.)
­ Fusionen und Übernahmen
­ Veränderte rechtliche Rahmenbedingungen
­ Verfügbarkeit neuer Technologien
­ Outsourcing bestimmter Aktivitäten
­ Neue Geschäftsmodelle

Es gebietet sich also, auf Bewegungen am Markt aus organisatorischen Gesichtspunkten kontrolliert reagieren zu können. Eine Befragung des Magazins ‚Computerwoche’, nach der 65 Prozent von 765 befragten CEOs in den nächsten zwei Jahren ihre Unternehmen radikal verändern möchten, verdeutlicht dies [Com06b].

Im Bereich des ITSM betrachtet man den Change konkreter. Hier steht der Begriff für die effektive und kostengünstige Implementierung autorisierter Änderungen an einer IT Infrastruktur, sodass die durch Änderungen verursachten Störungen auf ein Minimum reduziert werden [Pra06]. Das MOF beispielsweise definiert einen Change als Vorgang, der eine beliebige IT Komponente in eine IT Umgebung einbringt, was die Funktionalität von IT Service Levels oder der gesamten IT Umgebung beziehungsweise deren Komponenten berühren kann^[6] [Mof06b]. Der zum Change zugehörige CM Prozess hat sicherzustellen, „dass [dazu] standardisierte Methoden und Verfahren verwendet werden“ [Its04]. Folgende Zielsetzungen sollen mit ITIL CM erreicht werden [Ogc05]:

­ Lieferung stabilerer und hochwertigerer IT Services
­ Risikominimierung bei durchzuführenden Änderungen
­ Reduzierung der negativen Einflüsse von Änderungen auf die Qualität der IT Services
­ Selteneres Rückgängigmachen von Änderungen
­ Effektive und effiziente Rückfallpläne, falls eine Änderung misslingt
­ Bessere Abschätzung der Kosten für vorgeschlagene und geplante Änderungen

Werden die Vorgaben der ITIL konsequent umgesetzt, ist folgender Nutzen durch ITIL CM zu erwarten [Pra05]: Alle Anwender des Kunden werden Steigerungen in ihrer Produktivität beobachten können, da IT Dienste stabiler laufen. Neben dem arbeiten auch Mitarbeiter des IT Dienstleisters produktiver und unterbrechungsfreier, da Changes ausschließlich koordiniert gehandhabt werden. Außerdem wird es möglich sein, eine hohe Anzahl von Änderungen sicher und ohne Destabilisierung der Infrastruktur durchzuführen. Weiterer Nutzen liegt in der Möglichkeit, an zentraler Stelle Informationen zu durchgeführten Changes erfassen zu können, was die Beurteilung von Problembereichen erlaubt.

Damit Changes nach ITIL wunschgemäß funktionieren, ist es wichtig, Standardänderungen zu definieren, so dass einfache, überschaubare Aktionen unbürokratisch auf unkomplizierte und schnelle Weise ausgeführt werden können. Andernfalls wäre wegen des immensen organisatorischen Aufwandes Widerstand innerhalb der IT Organisation zu erwarten. Neben dem ist es essentiell, eng mit dem Configuration Management zusammenzuarbeiten, das in Kapitel zwei kurz vorgestellt wurde. Alle Änderungen sind sauber zu erfassen und zu dokumentieren, was anhand der CMDB des Configuration Managements zu geschehen hat. Auf diese Weise steht allen anderen Managementprozessen stets ein aktueller Ist-Zustand der Infrastruktur zur Verfügung [Ogc00a].

Der nächste Abschnitt beschreibt laut [Ogc05], wie CM in den Rahmen der ITIL Managementbereiche einzuordnen ist. Dabei werden explizit nicht die interne Struktur sowie weder Input und Output der Aktivitäten des Prozesses beleuchtet (siehe Abschnitt 4.3), sondern lediglich die Beziehungen zu den übrigen Kernprozessen, also Prozess-Schnittstellen, vorgestellt.

4.2 Prozessumgebung

CM interagiert sowohl mit Service Support als auch mit Service Delivery Prozessen. Das Incident Management hat die Möglichkeit, einen sogenannten Request for Change (RFC, siehe nächster Abschnitt) an das Change Management zu stellen. Dasselbe gilt für das Problem Management, das mit einem RFC eine Problemlösung beschreibt, deren Umsetzung es seitens des CM zu prüfen und gegebenenfalls durchzuführen gilt. Problemlösungen können allerdings neue Probleme verursachen. Im Zuge der Implementierung einer Änderung durch das CM ist es somit vonnöten, das Incident und Problem Management informiert zu halten, um etwaige neue Fehler, die dem Change innewohnen könnten, rasch aufzuspüren und beheben zu können. Eine besondere Beziehung besteht zwischen CM und Release Management. Änderungen an einer Infrastruktur ergeben sich zwangsläufig bei der Entwicklung und Verteilung von neuer Soft- und Hardware. Wird angedacht, solche Änderungen in Form von Releases in eine Infrastruktur zu integrieren, so übernimmt das Release Management dabei die ausführende und überwachende Rolle, nicht das CM. Das Service Level Management bemisst im Falle von Changes mit weitreichenden Auswirkungen, hohem Risiko und erheblichem Zeitaufwand potentielle Ausfälle und bestimmt somit mögliche Auswirkungen auf den Dienstnehmer. Es wird dazu vom CM über umfangreiche anstehende Änderungen informiert, und kann somit Feedback vom Dienstnehmer einholen. Im Availability Management werden Changes angestoßen, die die Verfügbarkeit der IT Services verbessern sollen. Darüber hinaus liefert dieser Prozess Input zu Auswirkungen von Changes, da durch Veränderungen mitunter die Verfügbarkeit von IT Services tangiert werden kann. Das Capacity Management benötigt Aktivitäten des CM, um Erweiterungen an Systemkapazitäten integrieren lassen zu können. Zusätzlich werden Auswirkungen von umgesetzten Änderungen auf Kapazitäten untersucht und überwacht. Da Changes den Continuity Plan, den das Continuity Management bereithält, hinfällig werden lassen können, indem Notfallkonzepte nicht mehr ausführbar sind, ist eine enge Zusammenarbeit zwischen CM und Continuity Management zwingend erforderlich. Es gilt, vorbeugende Maßnahmen und Lösungspläne zur Gewährleistung der Beständigkeit aller Dienste vorgefertigt verfügbar zu haben. Der Zusammenhang des CM zum Configuration Manage­ment wurde im vorhergehenden Abschnitt bereits erwähnt.

Abbildung 4-1 veranschaulicht nach [Ogc05] stark abstrahiert den Zusammenhang zwischen Change, Release, Capacity und Configuration Management.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-1: Change, Release, Capacity und Configuration Management [Ogc05]

Zum besseren Verständnis der Abbildung ist nachfolgende Darstellung 4-2 aus dem Microsoft Operations Framework [Mof06b] erwähnenswert, wohlwissend, dass im MOF nur ITIL verwandte Konzepte behandelt werden. Das Release Management ist hier zwischen Change und Configuration Management angeordnet. Es beginnt also im CM und kann als dessen Subprozess angesehen werden. Die Abbildung soll die enge Verbindung zwischen den beiden Bereichen verdeutlichen und untermauern, inwiefern das Release Management dem CM zuträgt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-2: Release Management zwischen Change und Configuration Management [Mof06b]

Einen Versuch zur Einordnung des CM Prozesses in das Spannungsfeld aus Release, Incident und Problem Management legt die dem itSMF entnommene Abbildung 4-3 in Anlehnung an Demings Quality Circle [Its04] (vgl. Abschnitt 3.2) dar. Die Abfolge aus Change Planung durch das Change Management (Plan), dessen Umsetzung durch das Release Management (Do), Evaluierung durch Feedback aus dem Betrieb durch das Incident Management (Check) und Anpassung nach Evaluierung durch das Problem Management (Act) beschreibt einen möglichen Lebenszyklus eines Changes. Anzumerken ist, dass ‚Check’ in der Regel nicht nur vom Incident Management durchgeführt wird, sondern beispielsweise ebenso auch vom Change Management. Generell gilt, dass die geklammerten Begriffe mehr oder weniger allen aufgeführten Bereichen zugeordnet werden können, die Darstellung also nicht eineindeutig ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-3: CM im Spannungsfeld von Release, Incident und Problem Management [Its04]

Im Zuge der Beschreibung der Schnittstellen von CM sei abschließend darauf hingewiesen, dass anhand des Informationsmodell des CM Prozesses, das im Abschnitt 4.6 vorgestellt wird, der Überblick über Interaktionen des Prozesses mit seinem Umfeld weiterführend geschärft wird.

Der nächste Abschnitt stellt nun das grundlegende Konzept für das ITIL CM vor, indem die primären Prozessbestandteile und der grobe Prozessablauf erörtert werden.

4.3 Prozesskonzept

CM nach ITIL konstituiert sich nach [Ogc00a] aus folgenden Bestandteilen: Zentrales Element ist der bereits erwähnte RFC. Er fungiert als organisatorisches Medium, anhand dessen Änderungs- und Verbesserungsvorschläge als wie auch Korrekturen von vorhergehenden Änderungen an das CM herangetragen werden. Es gibt zahlreiche Ursachen, weshalb ein RFC formuliert werden kann, und auch unterschiedliche Initiatoren. Beispiele wären, dass sich der physische Ort einer Hardwarekomponente ändern soll, weil ein Benutzer umziehen möchte, oder vom Problem Management eine Lösung zu einem existierenden Problem erarbeitet werden konnte. Darüber hinaus beschreiben RFCs nicht nur Änderungen an physischen Komponenten. So könnten neben Hard- und Software auch taktische Pläne Betrachtungsgegenstand sein.

Der sogenannte Change Manager organisiert die Aktivitäten des CM Prozesses. Er ist dafür verantwortlich, eingehende RFCs zu filtern, zu klassifizieren und zu akzeptieren. Zusätzlich obliegt ihm die Prozess-Planung, -Koordinierung und -Nachbearbeitung und das Einholen der für die Durchführung von Changes nötigen Autorisierung(en).

Das Change Advisory Board (CAB), zu übersetzen als ‚Änderungs-Beitrat’, ist eine Zusammenkunft unterschiedlicher Personen, die allesamt mit dem zu erbringenden IT Service in Verbindung stehen. Das CAB wird zu festen Terminen einberufen, um schwerwiegende Änderungen zu beurteilen. Je nach Anforderung kann es unterschiedlich zusammengesetzt sein. Typischerweise nehmen der Change Manager (als Vorsitzender), der Service Level Manager, Vertreter aus dem Incident-, Problem-, und Release Management, Vertreter des Kunden und etwaiger Subunternehmer sowie Finanzexperten als wie auch IT Spezialisten teil. Für dringende Fälle sieht die ITIL ein Emergency Committee (EC) vor, um wichtige Entscheidungen schneller als im Rahmen des CAB’s treffen zu können. Ergebnisse der beiden Beiräte werden als sogenannte CAB minutes and actions veröffentlicht und sind für jeden Angehörigen der IT Organisation frei zugänglich. An dieser Stelle sei kurz angemerkt, dass alle Rollen des CM Prozesses im nächsten Abschnitt gesammelt vorgestellt werden, gefolgt von einer gesamtheitlichen Aufbereitung in Kapitel 4.5.

Weiterer Bestandteil von CM ist der sogenannte Critical Outage Plan. Dieser Notfallplan beschreibt, was zu tun ist, falls eine Change-Implementierung fehlschlägt. Wichtig ist, dass das Anfertigen von Ausweichplänen frühzeitig organisiert und eng mit allen Aktivitäten der Change-Planung koordiniert wird.

Der grobe Ablauf des CM Prozesses ist in Abbildung 4-4 nach [Its04] abstrahiert modelliert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-4: Grober Ablauf des CM Prozesses [Its04]

Ein RFC erreicht aus beliebiger Quelle das CM. Dort werden die folgenden Subprozesse durchlaufen: Der RFC wird in einem ersten Schritt erfasst und, sofern alle Vorraussetzungen zur Annahme erfüllt sind, akzeptiert. Es folgt die Klassifizierung nach Kategorie und Priorität, wobei entschieden wird, ob Aktivitäten für einen dringlichen Änderungsantrag anzustoßen sind. Handelte es sich um ein ‚normales’ Changevorhaben, so wird im nächsten Schritt die Umsetzung des Changes geplant. Es gilt, Auswirkungen und benötigte Ressourcen abzuschätzen. Daran anschließend ist nach Autorisierung die tatsächliche Implementierung des Changes zu koordinieren, gefolgt von einer abschließenden, rückwirkenden Evaluation. Alle Aktivitäten übermitteln Daten und Informationen, die die Infrastruktur betreffen, an das Configuration Management, wo der zentrale Datensatz der CMDB aktualisiert wird.

Nachdem das Umfeld sowie das grundsätzliche Konzept von ITIL CM vorgestellt wurde, widmet sich der nächste Abschnitt der detaillierten Darlegung des Prozessablaufes, indem funktional zusammengehörende Prozesskomponenten genauer betrachtet werden.

4.4 Modularisierung der Prozesskomponenten

Um die Prozessverfeinerung angehen zu können, ist es notwendig, eine Ausgangsbeschreibung des CM-Ablaufes zur Verfügung zu haben. Die ‚Stufe 0’ der Verfeinerung ist sozusagen zu erarbeiten. Sie muss dermaßen beschaffen sein, dass ein ‚Ausgangsgrad’ an Formalisierung erreicht wird, an dem alle weiteren Schritte der Konkretisierung ansetzen können. Dieser Abschnitt trägt dem Rechnung. Die einzelnen Aktivitäten beziehungsweise Subprozesses des CM werden modularisiert, ausführlich beschrieben und graphisch formalisiert. Dazu folgen nun zunächst einige konzeptionelle Gesichtspunkte.

Die nun folgende Stufe 0 der Verfeinerung ist hinsichtlich Strukturierung und behandelten Aspekten strikt an die Vorgaben der ITIL CM Prozess­­beschreibung ausgerichtet (siehe [Ogc00a]). Die Darstellung der Prozessaktivitäten erfolgt inhaltlich somit so generisch wie möglich, und wird dieselben Inkonsistenzen und Lücken wie die Beschreibungen der ITIL aufweisen (vgl. Abschnitt 3.3.5 und 4.7). Die Abweichung zur ITIL ist allerdings der Initialgrad an Formalisierung, der anhand graphischer Modellierungen erreicht wird. Für die einzelnen Module werden, soweit in der ITIL spezifiziert, alle Aktivitäten, Schnittstellen (vgl. Abschnitt 4.2) zu anderen Prozessen, Prozess-Input und -Output als wie auch Rollen zusammengetragen und modelliert (Abschnitte 4.4.1 bis 4.4.7). Dabei werden die Module bewusst nicht in Sichten untergliedert, da dies Bestandteil von Kapitel 5 ist. Der Zusammenhang aller interagierenden Rollen, die während der Modularisierung aufgezählt werden, und auch die Verknüpfung der Informationseinheiten, die im Ablauf des Prozesses ausgetauscht werden, werden daran anschließend herausgearbeitet und anhand graphischer Modelle visualisiert (Abschnitte 4.5 und 4.6).

Als Sprache zur Modellierung der Module wird wie bereits erwähnt die BPMN verwendet. Wie ihrer Bezeichnung zu entnehmen ist, dient sie dem Erstellen von ‚Business Process Diagrams’. Sie basiert auf Flussdiagramm-Konzepten, zugeschnitten auf die Konstruktion graphischer Modelle für Abläufe von Geschäftsvorgängen [OwRa03]. BPMN ist eine generische Notation, die von allen Involvierten leicht zu verstehen ist – vom Geschäfts­­analysten, der Prozess­konzepte erstellt, dem Entwickler, der die Abbildung eines Prozesses auf Technologien verantwortet, oder dem Betriebswirt, der Prozesse lenkt und ü­­berwacht [Spa06b]. Besonderheit der BPMN ist die in den ersten Kapiteln erwähnte Fähigkeit, einen modellierten Prozess mittels BPEL in ein XML Dokument überführen zu können. Dies ist insofern hervorhebenswert, da dadurch der Schritt von der Prozessmodellierung zur Umsetzung der Modelle anhand von Managementapplikationen erheblich vereinfacht wird. Formalisierte Daten des Modells können zur Applikationsentwicklung standardisiert übernommen werden. Dies ist nicht selbstverständlich, denn oft ist zu beobachten, dass von Analysten erstellte Prozessmodelle lediglich als Anforderungsdokumente herangezogen werden, nicht jedoch als konstituierender Input für Toolspezifikationen dienen.

Eine Einführung zur BPMN, in der grundlegenden Konzepte und das Begriffssystem der Notation vorgestellt werden, findet sich im Anhang. Auch Abschnitt 4.7 beschreibt im Rahmen eines kurzen Fazits weitere Aspekte der Notation.

Für die konkrete Modellierung der Module des CM Prozesses im Rahmen der Diplomarbeit wurden einige Modellierungstools begutachtet. Beispielhaft seien der Process Modeler Plugin für Microsoft Visio von Itp-Commerce [Itp06], der BPMN Modeler von Ilog [Ilo06], oder der Power Designer von Sybase [Syb06] genannt. Aus Gründen der Usability ist entschieden worden, alle Modelle anhand des Business Process Visual Architect von Visual Paradigm [Vis06] in der Version 1.1 zu erstellen. Diese Lösung unterstützt Business Process Modeling ausschließlich nach BPMN und zeichnet sich durch ein äußerst komfortables Interaktionskonzept aus.

Nun zur konkreten Darlegung der einzelnen Module.

4.4.1 RFC Erfassung und Filterung

Entsprechend Abbildung 4-4 aus Absatz 4.3 ist das Erfassen von RFCs als erste Teilaktivität des CM Prozesses zu betrachten.

Der Subprozess beginnt mit dem Eintreffen eines neuen RFCs beim CM. Alle Angehörigen einer IT Organisation sind ermächtigt, RFCs einzureichen. Um zu erreichen, dass breite Unterstützung der Anwenderschaft gegeben ist, empfiehlt die ITIL für die RFC Einbringung Autorisierung eines Vorgesetzen vorauszusetzen. Ist diese vorhanden, so ist im Rahmen einer Filterung zu prüfen, ob der RFC unnötig, ein Duplikat eines bereits bestehenden RFCs oder von Haus aus gar nicht durchführbar ist. Dadurch hat entweder die Abweisung des RFCs zu erfolgen, wobei dem Antragsteller eine Begründung zukommen zu lassen ist, oder die ordnungsgemäße Akzeptierung und weitergehende Bearbeitung des RFCs. Für einen akzeptierten RFC wird ein sogenannter Change Record (CR)^[7] angelegt, der als Container zur Beschreibung aller ab nun im Zusammenhang mit dem RFC folgenden CM Aktivitäten fungiert. Darüber hinaus werden alle Aktionen des CM stets in ein sogenanntes Change Log proto­kolliert.

Das Modul ‚RFC Erfassung und Filterung’ unterhält Verbindungen zum Incident, Problem, Service Level und Capacity Management, die allesamt RFCs einreichen können. Zudem existiert eine Schnittstelle zum Configuration Management, wo alle wichtigen Aktionen des CM dokumentiert werden. Der Input und Output des Moduls ist in folgender Tabelle aufgelistet:

Tabelle 4-1: Erfassung - Input und Output

Abbildung in dieser Leseprobe nicht enthalten

Rollen, die bei der Erfassung und Filterung interagieren, sind CM, Configuration Management und der Antragsteller des RFCs. In Abbildung 4-5 ist die Abfolge der Aktivitäten des Moduls in BPMN dargestellt. Für die drei beteiligten Rollen wurden sogenannte ‚Swimlanes’ eingerichtet, zwischen denen anhand ausgetauschter Nach­richten kommuniziert wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-5: BPMN Darstellung des Moduls ‚RFC Erfassung und Filterung’

Nach dem Annehmen und Erfassen hat die Klassifizierung des RFCs zu erfolgen.

4.4.2 RFC Klassifizierung

Die Aktivitäten der RFC Klassifizierung sehen vor, den RFC mit einer Priorität zu versehen und ihn zu kategorisieren. Die Priorität eines RFCs beschreibt die Wichtigkeit der beantragten Änderung. Sie ergibt sich aus der Dringlichkeit der Änderung und - sofern ein Problem die Ursache für den RFC ist - aus den Auswirkungen des unbehobenen zugrundeliegenden Problems [Its04]. Es liegt in der Verantwortung des CM, eine Priorität zuzuweisen. Dazu schlägt die ITIL vor, sich auch mit dem Antragsteller und eventuell sogar dem CAB auszutauschen. Folgende Priorisierungsstufen werden in der ITIL vorgeschlagen ([Ogc00a], Abschnitt 8.5.3):

Tabelle 4-2: Vorschläge der ITIL für Prioritätsstufen eines RFCs

Abbildung in dieser Leseprobe nicht enthalten

Ist die Priorität festgesetzt, so ist spezifiziert, ob der RFC dringend behandelt werden muss. Falls dem so ist, gilt es, gesonderte Aktivitäten anzustoßen, wie unter Absatz 4.4.6 beschrieben. Ein nicht dringlicher RFCs ist in die Menge aller RFCs, die gerade bearbeitet werden, entsprechend seiner Priorität einzuordnen. Neben dem sind mögliche Auswirkungen seiner Umsetzung auf das Business und den IT Betrieb abzuwiegen, als wie benötigte Ressourcen für die Implementierung zu diskutierten. Anhand dieser Informationen gilt es, den bewerteten und mit Priorität versehenen RFC zu kategorisieren. Dazu empfiehlt die ITIL folgende Einstufungen [Its04]:

Tabelle 4-3: Beispiel der ITIL für RFC-Kategorien

Abbildung in dieser Leseprobe nicht enthalten

Für jede IT Organisation ist zu erwarten, dass die große Mehrheit aller RFCs lediglich geringfügige Folgen haben. Zu erwähnen sei an dieser Stelle, dass die ITIL die Begriffe ‚RFC’ und ‚Change’ nicht klar voneinander abgrenzt, beziehungsweise nicht spezifiziert, ab wann ein RFC als Change zu betrachten ist. Hier sei definiert, dass ein akzeptierter (und somit wie festgelegt mit einem ‚Change Record’ ausgestatteter) RFC, der priorisiert und kategorisiert ist, als Change bezeichnet wird. Dies impliziert nicht automatisch die ‚Autorisierung’, also die Freigabe zur Durch­führung des Changes (siehe Abschnitt 4.4.3).

Für einen Change mit geringfügigen Folgen ist anschließend an die Kategorisierung zu prüfen, ob er durch eine Standardprozedur umgesetzt werden kann. Simple Vorgänge wie beispiels­weise ein Hardwareupgrade sind laut ITIL vorzudefinieren und vorzuautorisieren und somit ohne erneute CM Freigabe umsetzbar (siehe Abschnitt 4.4.7). Für Changes mit erheblichen Folgen empfiehlt die ITIL, Mitglieder des CAB um Feedback zu bitten oder gar eine CAB Sitzung zur Absteckung des weiteren Vorgehens einzuberufen. Für Changes mit weitreichenden Folgen ist letzteres obligatorisch.

In dem eben betrachteten zweiten Modul interagieren die Rollen CM, CAB/EC und auch der Antragsteller des RFCs. Es ist lediglich eine Schnittstelle zum Configuration Management gegeben. Den Input und Output des Moduls stellt Tabelle 4-4 zusammen:

Tabelle 4-4: Klassifizierung – Input und Output

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-6 visualisiert die Abfolge der Aktivitäten des Moduls.

An das Klassifizieren eines akzeptierten RFC reiht sich die Planung dessen konkreter Umsetzung, wie im nächsten Abschnitt beschrieben.

4.4.3 Change Planung

Das Modul ‚Planung’ lässt sich in vier Phasen unterteilen. In einem ersten Schritt werden die möglichen Auswirkungen des Changes bewertet. Es gilt abzuschätzen, welche negativen Gesichtspunkte auf die Unternehmung des Kunden abfärben könnten: Werden die IT Infrastruktur und IT Services, Kapazitäten und Performance als wie auch Zuverlässigkeit und Ausfallsicherheit der IT Systeme beeinträchtigt? Müssen Notfallpläne und Sicherheitskonzepte überarbeitet werden? Werden anderweitige, nicht-IT Infrastrukturen durch den Change tangiert? Außerdem ist zu bemessen, was geschehen würde, falls der Change nicht implementiert werden würde. Nicht unerheblich ist nebendem die Bewertung jedes geplanten Changes im Rahmen des bereits festgelegten Forward Schedule of Change (FSC) und der Projected Service Availability (PSA), der geplanten Systemverfügbarkeit. Die ITIL spezifiziert allerdings auch, dass Vorgänge existieren, die nicht unbedingt vorab bezüglich ihrer Auswirkungen beurteilt werden müssen, wie beispielsweise ein einfacher Hardwaretausch. Hierbei würde es sich um den bereits erwähnten Standard-Change handeln, für den es genügt, nach Abschluss eine kurze Information an das CM zu übermitteln. Software-Änderungen empfiehlt die ITIL stets anhand eines vollständig durchlaufenen Changes abzuwickeln, bei dem alle möglichen Auswirkungen bedacht wurden.

In einer zweiten Phase wird anschließend der Ressourcenbedarf für das Implementieren des Changes ermittelt. Hierunter sind IT- und Geschäftsressourcen zu verstehen, also die bereitgestellt Kosten, Mitarbeiter sowie Zeit- und Materialaufwendungen. Ist dies weitgehend erfolgt, so

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-6: BPMN Darstellung des Moduls ‚RFC Klassifizierung’

wird erwartet, dass jeder Beteiligte der Change Planung (CM, CAB/EC Mitglied, durch das CM/CAB/EC nominierte Dritte) anhand der Ergebnisse der Ressourcen- und Auswirkungsbemessung sowie der zu erwartenden Verbesserung durch Implementierung des Changes mitteilt, ob er den Change befürwortet.

Die dritte Phase des Moduls beschreibt das Autorisieren und Freigeben eines Changes. Jede Änderung sollte prinzipiell vor Implementierung durch das CM genehmigt werden. Dies bewirkt, dass eigenmächtigen, vom CM unbemerkten Manipulationen an der IT Infrastruktur entgegengewirkt werden kann. Das CM kann seine Befugnisse allerdings auch delegieren, wie beispielsweise bei einfachen Standard-Changes. Für nicht-Standard-Changes sieht die ITIL mehrere Autorisierungsebenen vor, die ein Change entsprechend seiner Bedeutung durchlaufen sollte. Im sogenannten ‚Financial Approval’ wird entschieden, ob sich der Change im Budget beziehungsweise innerhalb eines erlaubten finanziellen Rahmens bewegt. Kosten sind oft ein Autorisierungskriterium. Das ‚Technical Approval’ beurteilt, ob der geplante Change mit den vom Financial Approval freigegebenen Mitteln technisch umgesetzt werden kann. Das ‚Business Approval’ prüft, ob der Change seitens des Kunden genehmigt ist. Grundsätzlich liegt die finale Autorisierungskompetenz für Changes immer beim CM. Bei Änderungen mit höchster Priorität und weitreichenden Folgen wird sich das CM jedoch immer mit dem IT Management kurzschließen, wo im Einklang mit dem Kunden Entscheidungen für das weitere Vorgehen getroffen werden.

Der letzte, vierte Schritt beschreibt die zeitliche Planung genehmigter Changes. Der theoretische Idealfall wäre, alle Changes sequentiell auszuführen. Dies ist in der Realität jedoch nicht machbar, da oft Abhängigkeiten zwischen Changes und auch anderweitigen Gegebenheiten existieren. Neue Hardware könnte zum Beispiel angepasste Treiber und auch neue Dokumentation für den Endbenutzer erfordern. Die ITIL empfiehlt aus diesem Grund das Konzept der sogenannten Releases. Ein Release ist in der Regel ein Soft- oder Hardwarepaket, das mehrere einzelne Changes beinhaltet, nach außen jedoch als singulärer Change erscheint. Um Beeinträchtigungen durch die Implementierung von Changes so minimal wie möglich zu halten, empfiehlt es sich, so viele Changes wie möglich in ein Release zu packen. Es ist leicht erkennbar, dass aus dem Releasekonzept eine sehr enge Verzahnung zwischen Change- und Release Management resultiert. Zur zeitlichen Planung genehmigter Changes gibt die ITIL im Weiteren vor, einen zuvor genannten FSC zu veröffentlichen. Dieses Dokument enthält Einzelheiten zu allen Changes, die zur Implementierung freigegeben wurden, unter anderem auch zu welchen Releases ein jeweiliger Change gegebenenfalls gehört. Der FSC ist auch insofern bedeutungsvoll, da es für Organisationseinheiten und Fachabteilungen überaus wichtig ist, Daten über anstehende Änderungen für die eigenen Planungen zur Verfügung zu haben. Generell möge der FSC einen genauen, detaillierten Plan für eine kurzfristige Zeitspanne präsentieren und mittelfristige Änderungen zumindest recht wage beschreiben. Er sollte an alle Personen und organisatorische Einheiten ausgegeben werden, für die Informationen über anstehende Changes von Interesse sein könnten, wie zum Beispiel die anderweitigen ITIL Prozesse. Außerhalb des ITSM sollten Inhalte des FSC über das Service Desk, das Service Level Management oder Customer Relationship Bereiche kommuniziert werden.

Zum Abschluss dieses Moduls hebt die ITIL hervor, dass es von eklatanter Wichtigkeit für alle CM Bestrebungen ist, das Ziel von Änderungen, nämlich die Unterstützung beziehungsweise Verbes­serung des Business des Kunden, stets nie aus den Augen zu verlieren. Außerdem wird angemerkt, dass das Planungs-Modul iterativ sein kann. Es wäre möglich, dass Teilaktivitäten wie das ‚Financial Approval’ nochmals durchzuführen sind, falls sich geschäftliche Rahmenbedingungen des Kunden ändern.

Nach der Beschreibung der vier Phasen des Planungs-Moduls nun ein Blick auf die beteiligten Rollen. Wie eben vorgestellt interagieren neben dem CM, CAB/EC und Configuration Management diesmal zusätzlich das Release-, Financial-, Security-, IT Service Continuity-, Capacity- und Service Level Management. Diese Liste beschreibt auch die Schnittstellen des Moduls zu anderen ITIL Prozessen. Den Input und Output der Change Planungsphase stellt Tabelle 4-5 zusammen.

[...]

---

^[1] Diese Angaben gründen sich auf Gespräche mit ITIL Beratern sowie Mitarbeitern des Lehrstuhls für Kommunikationssysteme und Systemprogrammierung des Instituts für Informatik der Ludwig-Maximilians-Universität München

^[2] Zu übersetzen mit: „Ein Service ist eine Funktion, die der Unternehmung vom Unternehmensnetz bereitgestellt wird. Er kann als Abstraktion des Unternehmensnetzes und als Phänomen gesehen werden, das aus dem Wirken der Struktur und des Betriebes des Netzes entsteht.“

^[3] Vorweggenommene Begriffe aus dem ITIL Themenfeld werden in Abschnitt 3.3 ausführlich erläutert.

^[4] Das Buch ‚ITIL Service Support’ bei Amazon.com für 138,50 $ (23.05.2006)

^[5] Zu erwähnen ist an dieser Stelle der philosophisch angehauchte Artikel zum ‚Change’ unter http://en.wikipedia.org/wiki/Change – obwohl bekannt ist, dass die freie Enzyklopädie Wikipedia nur nicht-statischen Inhalt anbietet, der sich jederzeit ändern kann.

^[6] Im Original: „Change: Any new IT component deliberately introduced to the IT environment that may affect an IT service level or otherwise affect the functioning of the environment or one of its components.“

^[7] Die ITIL nennt den Begriff ‚Change Record’, spezifiziert aber keine klaren Regeln zu dessen Verwendung. Hier wird nun interpretiert, dass zu jedem akzeptierten Change ein Datensatz in Form eines Change Records erstellt wird.