Die Bachelorarbeit können Sie hier downloaden - Patrick Pauen

Status quo der Einführung ITIL-basierter Standardprozesse im 

Mittelstand und in mittelständischen Unternehmen sowie 

Entwurf eines Vorgehensmodells unter besonderer 

Berücksichtigung des Incident und Problem Managements 

Bachelorarbeit 

vorgelegt von 

Patrick Pauen 

aus Mönchengladbach 

geboren am: 13.08.1984 

Matrikel-Nr.: 696282 

Hochschule Niederrhein 

Fachbereich Wirtschaftwissenschaften 

Studiengang Bachelor in Information Systems 

Sommersemester 2010 

1. Prüfer: Prof. Dr. Georg Wilking 

2. Prüfer: Prof. Dr. Dietmar Abts

Inhaltsverzeichnis I 

Inhaltsverzeichnis 

Abkürzungsverzeichnis ............................................................................... IV 

Abbildungsverzeichnis ................................................................................ VI 

Tabellenverzeichnis .................................................................................... VII 

1 Einleitung ............................................................................................... 1 

1.1. Zielsetzung der Arbeit .................................................................................................... 2 

1.2. Aufbau der Arbeit .......................................................................................................... 2 

2 Grundlagen - Begriffe und Definitionen ................................................ 3 

2.1. Prozess ........................................................................................................................... 3 

2.2. Funktion ......................................................................................................................... 4 

2.3. Rolle ............................................................................................................................... 4 

2.3.1. Prozess-Owner ....................................................................................................... 4 

2.3.2. Prozess-Manager .................................................................................................... 4 

2.3.3. Prozess-Mitarbeiter ................................................................................................ 5 

2.4. Key Performance Indikatoren ........................................................................................ 5 

2.5. IT-Service ....................................................................................................................... 5 

2.6. IT-Service Management ................................................................................................. 5 

2.7. Mittelstand ..................................................................................................................... 5 

3 IT Infrastructure Library im Überblick .................................................. 7 

3.1. Geschichte ...................................................................................................................... 7 

3.2. ITIL V3 .......................................................................................................................... 8 

3.3. IT Service Lifecylce ....................................................................................................... 8 

3.3.1. Service Strategy ..................................................................................................... 9 

3.3.2. Service Design ....................................................................................................... 9 

3.3.3. Service Transition .................................................................................................. 9 

3.3.4. Service Operation ................................................................................................... 9 

3.3.5. Continual Service Improvement........................................................................... 10 

3.3.6. Complementary Set .............................................................................................. 10 

4 ITIL-basierte Prozesse im Detail ......................................................... 11 

4.1. Incident Management ................................................................................................... 11 

4.1.1. Begriffe ................................................................................................................ 11 

4.1.2. Prinzipien ............................................................................................................. 13 

4.1.3. Rollen ................................................................................................................... 14 

4.1.4. Prozessablauf des Incident Managements ............................................................ 16 

4.1.5. Methoden und Tools ............................................................................................ 20 

4.2. Problem Management .................................................................................................. 20 

4.2.1. Begriffe ................................................................................................................ 21 

4.2.2. Prinzipien ............................................................................................................. 22 

4.2.3. Rollen ................................................................................................................... 22 

4.2.4. Methoden und Tools ............................................................................................ 23

Inhaltsverzeichnis II 

4.2.5. Prozessablauf des Problem Managements ........................................................... 24 

5 Erhebung der Daten .............................................................................. 28 

5.1. Untersuchungsgegenstand ............................................................................................ 28 

5.2. Erhebungsmethode ....................................................................................................... 28 

5.3. Zielgruppe der Erhebung .............................................................................................. 30 

5.4. Konzeption des Fragebogens ....................................................................................... 30 

5.5. Auswahl der Umfrageteilnehmer ................................................................................. 33 

5.5.1. Wikipedia ............................................................................................................. 33 

5.5.2. Firmendatenbanken der Industrie und Handelskammern ..................................... 34 

5.5.3. Ermitteln der E-Mail-Adresse .............................................................................. 34 

6 Status quo von ITIL .............................................................................. 36 

6.1. Umfrageergebnis .......................................................................................................... 36 

6.1.1. Größe und Branchen der teilnehmenden Unternehmen ....................................... 36 

6.1.2. Status quo von ITIL ............................................................................................. 37 

6.1.3. Gründe für die Nutzung bzw. den Verzicht von ITIL .......................................... 38 

6.1.4. Verbreitung der ITIL-basierten Prozesse und Funktionen ................................... 40 

6.1.5. Bedarf an ITIL-basierten Prozessen und Funktionen ........................................... 41 

6.1.6. Verwendete ITIL-Version .................................................................................... 42 

6.1.7. Probleme bei der Einführung des Incident Managements.................................... 43 

6.1.8. Probleme bei der Einführung des Problem Managements ................................... 44 

6.1.9. Einfluss von ITIL auf die Prozesse ...................................................................... 45 

6.1.10. Diskussion der Ergebnisse ................................................................................... 49 

6.2. Experteninterview ........................................................................................................ 51 

6.2.1. Ursache für den Verzicht auf ITIL-basierte Standardprozesse ............................ 51 

6.2.2. Gründe für den Einsatz von ITIL-basierten Standardprozessen .......................... 51 

6.2.3. Erfolgsfaktoren für eine erfolgreiche Umsetzung von ITIL V3 ........................... 51 

6.2.4. Einfluss der aktuellen Wirtschaftskrise ................................................................ 52 

6.2.5. Zukünftige Entwicklung in KMU ........................................................................ 52 

7 Probleme bei der Einführung ............................................................... 53 

7.1. Probleme ...................................................................................................................... 53 

7.1.1. Fehlende Akzeptanz bei den Mitarbeitern ........................................................... 53 

7.1.2. Mangelnde Unterstützung durch das Management .............................................. 53 

7.1.3. Schlechte Terminplanung ..................................................................................... 53 

7.1.4. Fehlendes Know-How der IT-Mitarbeiter ............................................................ 54 

7.1.5. Fehlende technische Unterstützung durch effektive Hilfsmittel .......................... 54 

7.1.6. Unzureichende Tool-Unterstützung ..................................................................... 54 

7.1.7. Overhead während der Implementierungsphase .................................................. 54 

7.1.8. Ungenaue Trennung zwischen Incident und Problem Management .................... 54 

7.1.9. Durchdringung des Prozesses dauert länger als geplant ...................................... 55 

7.1.10. Kommunikationsprobleme ................................................................................... 55 

7.1.11. Unsaubere Abbildung von Prozessen im Tool ..................................................... 55 

7.1.12. Unzureichendes Training der betroffenen IT-Mitarbeiter .................................... 55 

7.1.13. Fehlende Ressourcen für Projektunterstützung .................................................... 55 

7.1.14. Falsche Priorisierung von Incidents ..................................................................... 55 

7.2. Fallbeispiele ................................................................................................................. 56 

7.2.1. Hessische Zentrale für Datenverarbeitung (HZD) ............................................... 56 

7.2.2. Führender deutscher DSL-Netzbetreiber für den Massenmarkt ........................... 56

Inhaltsverzeichnis III 

8 Vorgehensmodell.................................................................................. 58 

8.1. Initialisierung ............................................................................................................... 60 

8.1.1. Name des Projektes festlegen ............................................................................... 60 

8.1.2. Auswahl der Projektbeteiligten ............................................................................ 60 

8.1.3. Kick-off Veranstaltung durchführen .................................................................... 61 

8.1.4. Schulung der Projektmitglieder ............................................................................ 61 

8.1.5. Grobe Terminplanung .......................................................................................... 62 

8.1.6. Einbinden des Betriebs- bzw. Personalrats in den Planungsprozess .................... 62 

8.2. Zieldefinition ................................................................................................................ 63 

8.2.1. Zielworkshop veranstalten ................................................................................... 63 

8.2.2. Ziele dokumentieren ............................................................................................. 64 

8.2.3. Genehmigung der Ziele ........................................................................................ 64 

8.3. Analyse ......................................................................................................................... 64 

8.3.1. Ist-Analyse durchführen ....................................................................................... 64 

8.3.2. Erste Auswertung der Ergebnisse und Rückfrage ................................................ 66 

8.3.3. Handlungsfelder identifizieren und Handlungsempfehlungen ableiten ............... 66 

8.3.4. Anpassen der Terminplanung .............................................................................. 67 

8.3.5. Informationsveranstaltung für die IT-Mitarbeiter ................................................ 67 

8.4. Design .......................................................................................................................... 67 

8.4.1. Prozess-Workshop................................................................................................ 68 

8.4.2. Toolauswahl durchführen ..................................................................................... 73 

8.4.3. Prozessschulung durchführen ............................................................................... 74 

8.5. Durchführung der Implementierung ............................................................................ 74 

8.5.1. Projektmarketing betreiben .................................................................................. 74 

8.5.2. Tools einführen .................................................................................................... 75 

8.5.3. Anpassung der Tools ............................................................................................ 75 

8.5.4. Tool-Schulung ...................................................................................................... 75 

8.5.5. Erstellen von Arbeitsanweisungen ....................................................................... 75 

8.5.6. Erfahrungen dokumentieren und Verbesserungspotenziale identifizieren ........... 76 

8.6. Evaluierung und Weiterentwicklung ............................................................................ 76 

8.6.1. Review der Implementierung ............................................................................... 76 

8.6.2. Kontinuierlichen Verbesserungsprozess definieren und initiieren ....................... 77 

8.7. Abschluss ..................................................................................................................... 78 

9 Fazit ...................................................................................................... 79 

Quellenverzeichnis ................................................................................... VIII 

Eidesstattliche Erklärung ........................................................................... XII

Abkürzungsverzeichnis IV 

Abkürzungsverzeichnis 

Abb. Abbildung 

Abs. Absatz 

BSI British Standards Institution 

bzw. beziehungsweise 

Ca. circa 

CAB Change Advisory Board 

CCTA Central Computer and Telecommunications Agency 

CI Configuration Item 

CMDB Configuration Management Database 

CMS Configuration Management System 

DSL Digital Subscriber Line 

E-Mail Electronic Mail 

EC Emergency Committee 

EDV Elektronische Datenverarbeitung 

e. V. eingetragener Verein 

ggf. gegebenenfalls 

GITIMM Government Information Technology Infrastructure 

Management Method 

GmbH Gesellschaft mit beschränkter Haftung 

Hrsg. Herausgeber 

HZD Hessische Zentrale für Datenverarbeitung 

IfM Institut für Mittelstandsforschung 

IHK Industrie- und Handelskammer 

IT Informationstechnologie 

ITIL Information Technology Infrastructure Library 

ITSM IT Service Management 

itSMF IT Service Management Forum 

KMU Kleine und mittlere Unternehmen 

KPI Key Performance Indicator 

Mio. Millionen 

MoSCoW Must - Should - Could - Won't 

Nr. Nummer 

OGC Office of Government Commerce

Abkürzungsverzeichnis V 

OLA Operational Level Agreement 

PDCA Plan - Do - Check - Act 

RACI Responsible - Accountable - Consulted - Informed 

RfC Request for Change 

SLA Service Level Agreement 

SMART Spezifisch - Messbar - Akzeptiert - Realistisch - Terminierbar 

SWOT Strengths - Weaknesses - Opportunities - Threats 

Tab. Tabelle 

TMG Telemediengesetz 

UC Underpinning Contract 

u. U. unter Umständen 

vgl. vergleiche 

V3 Version 3 

VABI Verantwortlich - Ausführend - Beteiligt - Informiert 

z. B. zum Beispiel

Abbildungsverzeichnis VI 

Abbildungsverzeichnis 

Abb. 1: Aufbau der Arbeit ............................................................................................................ 2 

Abb. 2: Generisches Prozessmodell .............................................................................................. 3 

Abb. 3: ITIL V3 .......................................................................................................................... 10 

Abb. 4: Incident Model für sicherheitsrelevante Incidents ......................................................... 13 

Abb. 5: Incident Model für performancerelevante Incidents ...................................................... 13 

Abb. 6: Incident Management Prozess ........................................................................................ 16 

Abb. 7: Problem Management Prozess ....................................................................................... 24 

Abb. 8 - Anzahl der Mitarbeiter der befragten Unternehmen ..................................................... 36 

Abb. 9 - Branchen der befragten Unternehmen .......................................................................... 37 

Abb. 10 - Prozentuale Verteilung der ITIL-Nutzer ..................................................................... 37 

Abb. 11 - Ursachen für den Verzicht auf ITIL-basierte Standardprozesse ................................. 38 

Abb. 12 - Ursachen für die Nutzung von ITIL-basierten Standardprozessen ............................. 39 

Abb. 13 - Verbreitung der ITIL-basierten Prozesse und Funktionen .......................................... 41 

Abb. 14 - Noch einzuführende Prozesse und Funktionen ........................................................... 42 

Abb. 15 - Verwendete ITIL Version ........................................................................................... 43 

Abb. 16 - Anteil der Befragten mit Problemen bei der Einführung des Incident Managements 43 

Abb. 17 - Probleme bei der Einführung des Incident Managements .......................................... 44 

Abb. 18 - Anteil der Befragten mit Problemen bei der Einführung des Incident Managements 44 

Abb. 19 - Probleme bei der Einführung des Problem Managements .......................................... 45 

Abb. 20 - Vorgehensmodell ........................................................................................................ 59 

Abb. 21 - Beispielhafte Darstellung einer SWOT-Matrix .......................................................... 66 

Abb. 22 - Prozesshandbuch ......................................................................................................... 73 

Abb. 23 - PDCA-Zyklus ............................................................................................................. 77

Tabellenverzeichnis VII 

Tabellenverzeichnis 

Tab. 1 - KMU Definition des IfM Bonn ....................................................................................... 6 

Tab. 2 - Priorisierungssystematik ................................................................................................ 18 

Tab. 3 - Vor- und Nachteile der Erhebungsmethoden ................................................................ 29 

Tab. 4 - Fragebogen: 1. Block - Größe und Branche .................................................................. 31 

Tab. 5 - Fragebogen: 2. Block - Status quo von ITIL ................................................................ 31 

Tab. 6 - Fragebogen: 3. Block - Gründe für die Nutzung bzw. den Verzicht ............................. 31 

Tab. 7- Fragebogen: 4. Block: Verbreitung der ITIL-basierten Prozesse und Funktionen ......... 31 

Tab. 8 - Fragebogen: 5. Block: Bedarf an ITIL-basierten Prozessen und Funktionen ................ 32 

Tab. 9 - Fragebogen: 6. Block: Verwendete ITIL-Version ......................................................... 32 

Tab. 10 - Fragebogen: 7. Block - Probleme bei der Einführung des Incident Managements ..... 32 

Tab. 11 - Fragebogen: 8. Block - Probleme bei der Einführung des Problem Managements ..... 32 

Tab. 12 - Fragebogen: 9. Block Einfluss von ITIL auf die Prozesse .......................................... 33 

Tab. 13 - Zusammenhang zwischen Anzahl IT-Mitarbeiter und Nutzung von ITIL .................. 39 

Tab. 14 - Zusammenhang zwischen Anzahl EDV-Anwender und Nutzung von ITIL ............... 40 

Tab. 15 - Einfluss von ITIL auf die Benutzerfreundlichkeit der Prozesse ................................. 46 

Tab. 16 - Einfluss von ITIL auf die Effizienz der Prozesse ........................................................ 46 

Tab. 17 - Einfluss von ITIL auf die IT-Sicherheit im Unternehmen ......................................... 46 

Tab. 18 - Einfluss von ITIL auf die Prozessqualität im Unternehmen ....................................... 47 

Tab. 19 - Einfluss von ITIL auf die Transparenz der Prozesse .................................................. 47 

Tab. 20 - Einfluss von ITIL auf die Wirtschaftlichkeit der Prozesse .......................................... 48 

Tab. 21 - Einfluss von ITIL auf die Qualität des Sourcing ......................................................... 48 

Tab. 22 - Einfluss von ITIL auf die Reaktionszeit der IT ........................................................... 48 

Tab. 23 - Einfluss von ITIL auf die Stukturierung des IT-Betriebes .......................................... 49 

Tab. 24 - Einfluss von ITIL auf die Flexiblität der Prozesse ...................................................... 49 

Tab. 25 - RACI-Tabelle für das Incident Management .............................................................. 70 

Tab. 26 - Rollenbeschreibungen ................................................................................................. 70 

Tab. 27 - KPIs für das Incident und das Problem Management ................................................. 71 

Tab. 28 - Template für Verbesserungsvorschläge ....................................................................... 76

Einleitung 1 

1 Einleitung 

Die Rahmenbedingungen wirtschaftlichen Handelns werden schon seit einigen Jahren durch 

einen permanenten Wandel beeinflusst. Globalisierung und der daraus entstehende größere 

Konkurrenzdruck, sowie stetig wachsende Kundenerwartungen haben in den letzten Jahren zu 

einer steigenden Abhängigkeit der Unternehmen von der IT geführt. Somit hängt der Erfolg 

eines Unternehmens wesentlich von der Leistungsfähigkeit seiner IT-Architektur ab. Für eine 

Vielzahl von Unternehmen sind deren eingesetzte IT-Systeme unentbehrlich geworden, da sie 

tiefgreifend in die Abwicklung von Geschäftsprozessen eingebunden sind. Die IT-Systeme un- 

terstützten dabei oftmals die betrieblichen Abläufe und liefern Daten, die als Entscheidungs- 

grundlage dienen. Angesichts dieser Entwicklung hängt der Unternehmenserfolg maßgeblich 

von der Optimierung der einzelnen IT Prozesse ab um die Kosten zu senken, das Qualitätsni- 

veau zu verbessern und somit einen langfristigen Unternehmenserfolg gewährleisten zu können. 

Eine flexible Gestaltung der Geschäftsmodelle sowie der Unternehmensstrategien ist unver- 

meidbar um sich an die Bedingungen der dynamischen Märkte anpassen zu können. Aus diesem 

Grund ist es notwendig, dass Unternehmen ihre organisatorischen Strukturen, vor allem aber 

ihre Prozesse und Abläufe an die neuen Anforderungen anpassen. In dieser sich ständig wan- 

delnden Unternehmenslandschaft wird von IT-Abteilungen eine ständige Flexibilität sowie kur- 

ze Reaktionszeiten erwartet. Die unmittelbare Bereitstellung von kundenspezifischen qualitativ 

hochwertiger IT-Services müssen trotz immer fortwährenden Kürzungen der IT-Budgets prob- 

lemlos bereitgestellt werden. 

Gerade mittelständische Unternehmen sind aufgrund ihres geringen Eigenkapitals, sowie der 

wenigen menschlichen Ressourcen maßgeblich von ihren Prozessen abhängig. 1 Folglich ist eine 

Optimierung der Geschäftsprozesse besonders wichtig. 

Mit ITIL steht eine Sammlung fachlich-methodischer Good-Practices zur Verfügung, die auf die 

Optimierung von Prozessen abzielt und somit zum Erreichen der gesetzten Ziele beisteuern 

kann. 

1 Vgl. Nienstermann, M.: Service Management-Lösungen für KMU, Saarbrücken 2007, S.16.

Einleitung 2 

1.1. Zielsetzung der Arbeit 

Die Zielsetzung dieser Arbeit ist die Ermittlung des Status quo von ITIL in mittelständischen 

Unternehmen und Unternehmen mittlerer Größe sowie die Erarbeitung eines optimierten Vor- 

gehensmodells, mit dessen Hilfe das Incident und das Problem Management im Unternehmen 

implementiert werden kann. 

1.2. Aufbau der Arbeit 

Die vorliegende Bachelorarbeit gliedert sich inhaltlich in drei wesentliche Abschnitte. Der erste 

Abschnitt beschreibt den Hintergrund und die Zielsetzung dieser Arbeit und wird in Kapitel 1 

erläutert. Im zweiten Abschnitt werden die theoretischen Grundlagen dieser Arbeit beschrieben. 

Im Rahmen dessen werden die notwendigen allgemeinen Grundlagen für das Verständnis von 

ITIL (Kapitel 2) vorgestellt. Basierend auf diesen Grundlagen wird im dritten Kapitel das ITIL 

Framework vorgestellt. Die beiden Prozesse Incident und Problem Management werden im 

vierten Kapitel präsentiert. Dabei werden die für das Verständnis der Prozesse notwendigen 

Begriffe, Aktivitäten, Rollen, Schnittstellen und Ziele detailliert beschrieben. Der dritte Ab- 

schnitt und gleichzeitig Schwerpunkt dieser Arbeit beschreibt das Vorgehen bei der Erhebung 

der Daten (Kapitel 5), das Ergebnis der Umfrage (Kapitel 6) und die typischen Probleme, die 

bei der Einführung von Incident und Problem Management (Kapitel 7) auftreten können. Auf 

Basis dieser Informationen werden anschließend Lösungsvorschläge erarbeitet, die in das Vor- 

gehensmodell einfließen und in Kapitel 8 vorgestellt werden. 

1. Abschnitt: Motivation 

2. Abschnitt: Theorie 

3. Abschnitt: Praktische Umsetzung 

Abb. 1: Aufbau der Arbeit 

Kapitel 1: Einleitung 

Kapitel 2: Grundlagen - Begriffe und Definitionen 

Kapitel 3: IT Infrastructure Library im Überblick 

Kapitel 4: ITIL-basierte Prozesse im Detail 

Incident- und Problem Management 

Kapitel 5: Erhebung der Daten 

Kapitel 6: Status quo von ITIL 

Kapitel 7: Probleme bei der Einführung 

Kapitel 8: Vorgehensmodell

Grundlagen - Begriffe und Definitionen 3 

2 Grundlagen - Begriffe und Definitionen 

Das zweite Kapitel beschreibt Begriffe und Definitionen, die als Grundlage für die nachfolgen- 

den Ausführungen dienen. 

2.1. Prozess 

Ein Prozess ist eine chronologische Abfolge aller Schritte, die zum Erreichen eines festgelegten 

Ziels erforderlich sind. 2 Aus diesem Grund ist eine klare Zielvorgabe zwingend notwendig, um 

eine zielorientierte Veränderung zu ermöglichen. Voraussetzung für eine zielorientierte Verän- 

derung ist ein definierter Input, der mit Hilfe der Aktivitäten des Prozesses in einen definierten 

Output umgewandelt wird. 3 Dieser Vorgang wird als generischer Prozess bezeichnet. Für das 

Ergebnis eines Prozesses gilt, dass es einzeln identifizierbar und messbar sein muss. Darüber 

hinaus verfügt jeder Prozess über ein auslösendes Ereignis, ist zeitlich unbegrenzt, beliebig oft 

reproduzierbar und hat einen Kunden, der auf das Prozessergebnis angewiesen ist. 4 

Abb. 2: Generisches Prozessmodell 5 

Beispiel: 

Ein Prozess ist z. B. das Incident Management. 

2 vgl. Olbrich, A.: ITIL kompakt und verständlich, 4. Auflage, Wiesbaden 2008, S. 9. 

3 Vgl. Ebel, N.: ITIL® V3 Basis-Zertifizierung, 1. Auflage, München 2008, S. 45. 


5 Entnommen aus: Office of Government Commerce: Service Operation, London 2007, S. 15.


2.2. Funktion 

Eine Funktion ist eine unabhängige spezialisierte Organisationseinheit, die mit Hilfe von eige- 

nen Werkzeugen und Methoden das Ausführen bestimmter Tätigkeiten ermöglicht und die Ver- 

antwortung für die Erbringung des Ergebnisses trägt. 6 In der Regel werden für eine Funktion 

Aufgaben, Entscheidungskompetenzen und Verantwortlichkeiten festgelegt, die eine effektive 

Funktionsausübung ermöglichen. 

Beispiel: 

Eine Funktion ist z. B. der Service Desk. Der Service Desk dient den Anwendern als zentrale 

Anlaufstelle und informiert die Anwender gegebenenfalls über Veränderungen an der IT- 

Infrastruktur. 

2.3. Rolle 

Eine Rolle wird in einem Prozess definiert und dient der Zuweisung von Verantwortlichkeiten, 

Aktivitäten, Kompetenzen und kann von einer oder mehreren Personen wahrgenommen werden, 

wobei mehrere Rollen auch von ein und derselben Person ausgeübt werden können. 7 

Die wichtigsten Rollen sind: 

� Prozess-Owner 8 

� Prozess-Manager 

� Prozess-Mitarbeiter 

2.3.1. Prozess-Owner 

Der Prozess-Owner trägt die Verantwortung für die Definition, die Dokumentation und die 

Zielerreichung des Prozesses. Darüber hinaus ist er verantwortlich für die Definition der Kenn- 

zahlen. 9 

2.3.2. Prozess-Manager 

Der Prozess-Manager ist verantwortlich für die Überwachung und Einhaltung der Prozessquali- 

tät auf Basis der definierten Ziele, die Steuerung der Prozessaktivitäten und die Koordination 

der Schnittstellen. 10 

6 

Vgl. Olbrich, A.: ITIL kompakt und verständlich, 4. Auflage, Wiesbaden 2008, S. 160. 

7 

Vgl. Kempter, A.: Rollen in ITIL V3, 2010, http://wiki.de.it-processmaps.com/index.php/Rollen_in_ITIL_V3, 

11.03.2010. 

8 

In der Literatur wird auch von Prozess-Besitzer gesprochen. 

9 

Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.159. 

10 

Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.160.


2.3.3. Prozess-Mitarbeiter 

Der Prozess-Mitarbeiter sorgt für die operative Ausführung der Aktivitäten des Prozesses und 

eskaliert im Problemfall an den Prozess-Manager. 11 

2.4. Key Performance Indikatoren 

Ein Key Performance Indikator (KPI) ist eine Messgröße mit der man die Qualität eines Prozes- 

ses, eines IT-Service oder einer Aktivität messen kann. Innerhalb der IT können zahlreiche 

Messungen durchgeführt werden, jedoch werden nur die wichtigsten Messgrößen als KPIs defi- 

niert. 

2.5. IT-Service 

Ein IT-Service ist ein Nutzeneffekt, den ein IT-Service-Provider 12 für einen Kunden oder meh- 

rere Kunden durch die Kombination von Personen, Prozessen und Technologien erbringt. 13 

Beispiel: 

Vergabe einer E-Mailadresse an einen Kunden. 

2.6. IT-Service Management 

IT-Service Management ist die Ausrichtung der IT an die aktuellen und zukünftigen Anforde- 

rungen des Unternehmens und seiner Kunden durch die Steuerung der Qualität und Quantität 

der IT-Services. Das IT-Service Management umfasst Prozesse und Verfahren, die eine zielge- 

richtete, kundenfreundliche und kundenoptimierte Planung, Steuerung, Erbringung und Kontrol- 

le der IT Services ermöglicht, um den Kunden ein Höchstmaß an IT-Servicequalität zu bieten 

und eine Senkung aller anfallenden Kosten für die verschiedenen Servicetätigkeiten zu verwirk- 

lichen. 14 Aus diesem Grund sollten im Rahmen des IT-Service Management Begriffe normiert, 

Arbeitsabläufe standardisiert und Prozesse transparent gestaltet werden. 

2.7. Mittelstand 

Das Institut für Mittelstandsforschung Bonn definiert Unternehmen, die bis zu neun Mitarbeiter 

beschäftigen oder weniger als 1 Mio. € Jahresumsatz erwirtschaften als kleine Unternehmen. 

Unternehmen mit 10 bis 499 Beschäftigten respektive einem Jahresumsatz von 1 Mio. € bis 

11 Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.160. 

12 Ein IT-Service-Provider ist ein Dienstleister, der seinen Kunden einen IT-Service anbietet. 

13 Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 172. 

14 Vgl. ITIL.org: ITIL.org - Service Management, 

http://www.itil.org/de/vomkennen/itil/ueberblick/servicemanagement.php, 09.02.2010.


unter 50 Mio. € werden als mittlere Unternehmen definiert. Unternehmen die 500 und mehr 

Beschäftigte bzw. einen Umsatz von 50 Mio. € und mehr erwirtschaften werden als Großunter- 

nehmen bezeichnet. 15 

Tab. 1 - KMU Definition des IfM Bonn 16 

Unternehmensgröße Zahl der Beschäftigten Umsatz € / Jahr 

klein bis 9 bis unter 1 Millionen 

mittel 10 bis 499 1 bis unter 50 Millionen 

Mittelstand (KMU) zusammen bis 499 bis unter 50 Millionen 

groß 500 und mehr 50 Millionen und mehr 

15 

Vgl. Bundesministerium für Wirtschaft und Technologie (Hrsg.): Der Mittelstand der Bundesrepublik Deutschland, 

Berlin 2007, S 9. 

16 

In Anlehnung an: Institut für Mittelstandsforschung Bonn (Hrsg.): IfM Bonn Institut für Mittelstandsforschung 

Bonn, http://www.ifm-bonn.org/index.php?id=89, 09.02.2010.

IT Infrastructure Library im Überblick 7 

3 IT Infrastructure Library im Überblick 

ITIL steht für Information Technology Infrastructure Library und ist ein Good-Practice- 

Leitfaden, der aus der Praxis gewonnene Erkenntnisse, Modelle und Architekturen beschreibt, 

die als Richtlinie für den systematischen Aufbau und Betrieb einer abgestimmten professionel- 

len IT-Servicestruktur verwendet werden können. 17 Der Fokus von ITIL liegt dabei vordergrün- 

dig auf der stetigen und dauerhaften Verbesserung der Qualität der erbrachten IT-Services. ITIL 

liefert allerdings keine detaillierte Anleitung wie die Implementierung von ITIL erfolgen sollte, 

sondern beschreibt stattdessen was zu tun ist. Im Zuge dessen werden die abzubildenden Pro- 

zesse, Rollen, und Aufgaben vorgestellt, jedoch nicht wie diese im Einzelfall umzusetzen sind. 18 

Eine konkrete Umsetzung von ITIL erfolgt durch eine Anpassung der Inhalte an die individuel- 

len Bedürfnisse des einführenden Unternehmens, um einen bestmöglichen Erfolg zu gewährleis- 

ten. Dank der langjährigen Praxiserfahrung bietet ITIL eine hohe Zuverlässigkeit und hat sich 

mittlerweile als international anerkannter De-Facto Standard etabliert. 19 

3.1. Geschichte 

Seinen Ursprung hatte ITIL Mitte der 80er Jahre. Die damalige britische Regierung unter der 

Federführung der britischen Premierministerin Margaret Thatcher, beauftrage die „Central 

Computer and Telecommunications Agency” (CCTA) mit einer Studie. Diese hatte das Ziel, 

die Geschäftsprozesse der IT der britischen Regierungsstellen zu analysieren, zu beschreiben 

und Mittel und Wege zu finden, die stetig steigenden IT-Kosten der britischen Behörden in den 

Griff zu bekommen. 20 Im Rahmen dieser Studie wurde eine umfangreiche Befragung und Ist- 

Aufnahme in repräsentativen IT Dienstleistungsunternehmen, Rechenzentren, sowie bei Kunden 

und Lieferanten durchgeführt. 

Das Ergebnis dieser Befragung wurde im Jahr 1988 unter dem Namen „Government Informati- 

on Technology Infrastructure Management Method” (GITIMM) als Leitlinie für den IT-Betrieb 

englischer Behörden veröffentlicht. GITIMM wurde für eine Mehrzahl an Unternehmen aber 

erst interessant, nachdem die behördlich geprägten Prozesse an die Bedürfnisse der Industrie 

angepasst wurden. 21 Im Zuge dieser Anpassung wurde der Leitfaden überarbeitet und nament- 

lich an die neuen Gegebenheiten angepasst, bevor im Jahr 1989 mit dem „Service Level Mana- 


18 Vgl. Olbrich, A.: ITIL kompakt und verständlich, 4. Auflage, Wiesbaden 2008, S. 1 . 

19 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 12. 

20 Vgl. Schiefer, H.; Schitter, E.: Prozesse optimieren mit ITIL ® , 2. Auflage ,Wiesbaden 2008, S. 3. 

21 Vgl. Ebel, N.: ITIL® V3 Basis-Zertifizierung, 1. Auflage, München 2008, S. 56.


gement“ das erste Buch des ITIL Frameworks veröffentlicht wurde. Auch die im April 2001 

erfolgte Eingliederung der CCTA in das Office of Government Commerce (OGC) hatte keinen 

negativen Einfluss auf die Weiterentwicklung des ITIL Frameworks, denn die OGC arbeitet 

auch heute noch in Zusammenarbeit mit zahlreichen Management Instituten und Foren an der 

stetigen Verbesserung des ITIL Frameworks. 22 

Im Juni 2007 publizierte das OGC mit der dritten Version der IT Infrastructure Library eine 

neue, überarbeitete Version, deren auffälligste Änderung die Etablierung einer neuen Struktur 

war. Diese Struktur umfasst die folgenden drei Bereiche: 

� ITIL Core 

� ITIL Complementary Guidance 

� ITIL Web Support Services 

3.2. ITIL V3 

Die neue ITIL V3 beschreibt die Rolle der IT nicht länger aus der operativen Sicht, sondern in 

erster Linie als IT-Service-Provider und Enabler für seine Kunden. Den Fokus legt ITIL V3 auf 

die Bereitstellung der IT-Services und das dafür notwendige IT-Service Management. Auf diese 

Weise kann die IT flexibel reagieren, um den wechselnden Anforderungen der Kunden zu ge- 

nügen. Aus diesem Grund wurde der ITIL Service Lifecycle entwickelt. 

3.3. IT Service Lifecylce 

Der ITIL Service Lifecycle besteht aus insgesamt fünf Phasen, die jeweils in einer eigenen 

Kernpublikation beschrieben werden. Bei den fünf Kernpublikationen handelt es sich um: 

� Service Strategy 

� Service Design 

� Service Transition 

� Service Operation 

� Continual Service Improvement 

Ergänzt werden die fünf Kernpublikationen durch das Buch The official introduction to the ITIL 

Service Lifecycle. 

22 Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 1.


3.3.1. Service Strategy 

Die ITIL Kernpublikation Service Strategy fokussiert die strategische Einordnung von IT- 

Services und liefert eine Beschreibung, wie das IT-Service Management gestaltet, entworfen 

und implementiert werden kann. 23 

3.3.2. Service Design 

Die ITIL Kernpublikation Service Design liefert eine Zusammenfassung der Prozesse, die für 

eine Entwicklung und Gestaltung von Services und Service Management Prozessen eine we- 

sentliche Rolle spielen. 24 Die folgenden Stichpunkte 25 beschreiben die inhaltlichen Schwerpunk- 

te der ITIL-Publikation Service Design: 

� Service Catalogue Management 

� Service Level Management 

� Capacity Management 

� Availability Management 

� IT Continuity Management 

� IT Security Management 

� Supplier Management 

3.3.3. Service Transition 

Das ITIL Buch Service Transition beschreibt Prozesse und Verfahren, mit deren Hilfe sowohl 

neue als auch angepasste IT-Services im operativen IT-Betrieb implementiert werden können. 26 

Die Kernthemen 27 dieser Publikation sind: 

� Transition Planning 

� Change Management 

� Service Asset & Configuration Management 

� Release Management 

3.3.4. Service Operation 

Die ITIL Publikation Service Operation beschreibt Prozesse und Methoden, die eine optimierte 

Bereitstellung von IT Services sowie einen optimierten Support ermöglichen. 28 

Die inhaltlichen Schwerpunkte 29 bilden: 

23 ® 

Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL V3, 1. Auflage, Hannover 2008, S. 3. 

24 ® 


25 ® 

Böttcher, R.: IT-Servicemanagement mit ITIL V3, 1. Auflage, Hannover 2008, S. 3. 

26 ® 


27 ® 

Böttcher, R.: IT-Servicemanagement mit ITIL V3, 1. Auflage, Hannover 2008, S. 3. 

28 ® 

Vgl. Buchsein, R.; Victor, F.; Günther, H.; Machmeier, V.: IT-Management mit ITIL V3, 2. Auflage, Wiesbaden 

2008, S. 37. 

29 ® 

Böttcher, R.: IT-Servicemanagement mit ITIL V3, 1. Auflage, Hannover 2008, S. 3.


� Event Management 

� Incident Management 

� Request Fulfilment 

� Problem Management 

� Access Management 

3.3.5. Continual Service Improvement 

Das Continual Service Improvement befasst sich mit der kontinuierlichen und systematischen 

Qualitätsverbesserung von IT-Services durch die Integration bewährter Prinzipen, Verfahren 

und Methoden des Capability Improvements sowie des Qualitäts und Change Managements. 30 

3.3.6. Complementary Set 

Komplettiert wird die ITIL V3 Publikation durch das umfangreiche Complementary Set, das 

sich aus den Themengebieten „Speciality Topics, Knowledge & Skills, Governance Methodes, 

Standard Alignment, Case Studies, Templates, Executive Introductions, Study Aids, 

Qualifications, Quick Wins und Scalability‟ 31 zusammensetzt. 

Abb. 3: ITIL V3 32 

In Abbildung 3 wird der Zusammenhang der einzelnen Phasen dargestellt. Im Kern des IT- 

Service Lifecycle befindet sich die Service Strategy, die die Achse des IT-Service Lifecycle 

bildet. Die Phasen Service Design, Service Operation und Service Transition sind kreisförmig 

um die Strategien angeordnet. Das Continual Service Improvement umfasst die vier Phasen und 

veranschaulicht auf diese Weise die kontinuierliche Verbesserung über alle Phasen hinweg. 


31 Olbrich, A.: ITIL kompakt und Verständlich, 4. Auflage, Wiesbaden 2008, S.144. 

32 Entnommen aus: Ebel, N.: ITIL v3® Basis-Zertifizierung, 1. Auflage, München 2008, S. 32.

ITIL-basierte Prozesse im Detail 11 

4 ITIL-basierte Prozesse im Detail 

Im vierten Kapitel werden das Incident und Problem Management sowie der Service Desk de- 

tailliert vorgestellt. 

4.1. Incident Management 

Das Incident Management ist ein Prozess mit der Zielsetzung, anfallende Incidents 33 

schnellstmöglich zu beheben um die Funktionalität des IT-Betriebes wiederherzustellen und 

mögliche negative Auswirkungen auf betroffene Geschäftsprozesse abzuwenden. 34 

4.1.1. Begriffe 

Zum besseren Verständnis werden im Folgenden einige Begriffe vorgestellt, die für das Ver- 

ständnis des Incident Managements notwendig sind. 

Configuration Item (CI) 

Configuration Items sind alle, für die Bereitstellung eines IT-Services notwendigen Komponen- 

ten. Die dazugehörigen Informationen werden in einem Configuration Management System 

(CMS) erfasst und mit Hilfe des Configuration Management verwaltet. 35 

Beispiel: 

Ein Configuration Item ist z. B. ein Monitor. 

Incident 

Ein Incident ist „ein Ereignis, das nicht zum standardmäßigen Betrieb eines Service gehört und 

das tatsächlich oder potenziell eine Unterbrechung oder Minderung der Service-Qualität verur- 

sacht." 36 Aber auch ausgefallene CIs, deren Ausfall keine direkte Auswirkung auf den Kunden 

hat, werden als Incidents bezeichnet. 

Beispiel: 

Der Ausfall einer Festplatte, die sich im Raid-5 Cluster befindet. Dieser Ausfall hat keine di- 

rekte Auswirkung, da der Cluster auch ohne die ausgefallene Festplatte funktioniert. Trotzdem 

handelt es sich um einen Incident. 

33 

In der Literatur wird häufig auch der Begriff Störung verwendet. 

34 

Vgl. Böttcher, R. IT-Servicemanagement mit ITIL® V3, 1. Auflage, Hannover 2008, S. 133. 

35 ® 

Vgl. Buchsein, R.; Victor, F.; Günther, H.; Machmeier, V.: IT-Management mit ITIL V3, 2. Auflage, Wiesbaden 

2008, S. 354. 

36 

Office of Government Commerce: Service Operation, London 2007, S. 86.


Service Desk 

Der Service Desk ist eine zentrale Anlaufstelle, an die sich die Kunden wenden können, wenn 

Unterstützungsbedarf besteht. 37 Dabei fungiert der Service Desk als Schnittstelle zwischen den 

Kunden und den IT-Mitarbeitern. 38 

Service Level Agreement (SLA) 

Ein Service Level Agreement ist eine Vereinbarung zwischen einem IT-Service-Provider und 

einem Kunden hinsichtlich der zu leistenden IT-Services. 39 

Operational Level Agreement (OLA) 

Ein OLA ist eine „Vereinbarung zwischen einem IT-Service-Provider und einem anderen Teil 

derselben Organisation. Ein OLA unterstützt die Bereitstellung von IT-Services durch den IT- 

Service-Provider für den Kunden. Das OLA definiert die zu liefernden Waren oder Services und 

die Verantwortlichkeiten der beiden Parteien.‟ 40 

Underpinning Contract (UC) 

Ein Underpinning Contract ist „ein Vertrag zwischen einem IT-Service-Provider und einer 

Drittpartei. Die Drittpartei stellt Waren oder Services zur Verfügung, die die Bereitstellung 

eines IT-Service für einen Kunden unterstützen. Der Underpinning Contract definiert Ziele und 

Verantwortlichkeiten, um die in einem SLA vereinbarten Service-Level-Ziele zu erreichen.‟ 41 

Service Request 

Ein Service Request ist die Anfrage eines Anwenders nach Informationen, Beratung, einem 

Standard-Change oder nach Zugriff auf einen IT- Service. 42 

Beispiel: 

Ein Service-Request ist z. B. die Anfrage eines Anwenders beim Service Desk mit der Bitte das 

Passwort eines Benutzer-Accounts zurückzusetzen. 

Workaround 

Ein Workaround ist eine Übergangslösung, die zur Reduzierung der Auswirkung eines Incident 

beiträgt und solange genutzt wird, bis eine endgültige Lösung zur Beseitigung des Incident zur 

Verfügung steht. 43 



39 Vgl. Nienstermann, M.: Service Management-Lösungen für KMU, Saarbrücken 2007, S.60. 

40 Office of Government Commerce: Service Operation, London 2007, S. 381. 


42 Vgl. Böttcher, R. IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 134. 

43 Vgl. Buchsein, R.; Victor, F.; Günther, H.; Machmeier, V.: IT-Management mit ITIL ® V3, 2. Auflage, Wiesbaden 

2008, S. 368.


4.1.2. Prinzipien 

Zeitvorgaben 

Basierend auf den vereinbarten SLA sollte für die Bearbeitung der unterschiedlichen Phasen der 

Incident-Abwicklung eine bestimmte Zeit definiert werden, die zur Bearbeitung des Incident zur 

Verfügung steht. Diese Zeit sollte als festgelegtes Ziel in den OLA oder Underpinning 

Contracts festgehalten werden und als Zielvorgabe dienen. Für eine einheitliche Einhaltung der 

Zeitvorgaben ist es wichtig, dass alle betroffenen Support-Gruppen über diese Zeitvorgaben 

informiert werden. 44 

Incident Modell 

Um das Incident Management effektiver zu gestalten, sollten im Vorfeld Incident Modelle defi- 

niert werden. Incident Modelle ermöglichen eine effektivere Bearbeitung von erneut auftreten- 

den Incidents. Diese können durch den bereits vorher festgelegten Ablauf innerhalb des vorge- 

gebenen Zeitrahmens gehandhabt werden. Auf diese Weise werden Incidents, die eine spezielle 

Behandlung erfordern, zielgerichtet an den zuständigen Prozess weitergeleitet. 45 

Beispiel: Sicherheitsrelevante Incidents 

Für sicherheitsrelevante Incidents könnte gelten, dass alle benötigten Informationen automati- 

siert an das Security Management weitergeleitet werden. 

Annahme und 

Dokumentation 

Abb. 4: Incident Model für sicherheitsrelevante Incidents 

Beispiel: Performancerelevante Incidents 

Für performancerelevante Incidents könnte gelten, dass sie automatisch an das Capacity Mana- 

gement weitergeleitet werden. 

Annahmen und 

Dokumentation 

Prüfung 

Prüfung 

Abb. 5: Incident Model für performancerelevante Incidents 

44 Vgl. Office of Government Commerce: Service Operation, London 2007, S. 54. 


Weiterleitung an 

Security 

Management 

Weiterleitung an 

das Capacity 

Management


Major Incidents 

Major Incidents sind kritische Störungen, die einen besonders großen Einfluss auf die Ge- 

schäftsprozesse des Unternehmens haben und somit besondere Maßnahmen für eine sofortige 

Servicewiederherstellung erfordern. Bedingt durch die besondere Relevanz des Major Incidents 

gelten oftmals wesentlich kürzere Bearbeitungszeiten und es muss eine höhere Dringlichkeit 

verwendet werden. Für eine effektive Abwicklung sollte eine Definition des Major Incidents 

vereinbart und auf das Gesamtsystem der Incident-Priorisierung abgestimmt werden. 46 

4.1.3. Rollen 

Im Rahmen des Incident Managements sollten die folgenden Rollen festgelegt werden: 

Incident Manager 

Der Incident Manager ist für die effektive Durchführung des Incident Managements verantwort- 

lich. 47 Zu seinen Hauptaufgaben gehört die Implementierung und kontinuierliche Verbesserung 

des Incident Managements, sowie die Planung der notwendigen Ressourcen. Aber auch die 

Kommunikation mit den anderen Prozess-Managern und die Erstellung von Managementberich- 

ten gehört zu seinen Aufgaben. 

1st Level Support 

Der 1st Level Support ist die „erste Prozessstufe im Incident Management‟ 48 und im Falle einer 

eingehenden Störungsmeldung der erste Ansprechpartner für den Kunden. Im Zuge dessen 

kümmert sich der 1st Level Support um die sofortige Behebung von einfachen Incidents. 49 

Wenn der Incident an dieser Stelle nicht mit angemessenem Aufwand behoben werden kann, 

kommt es zur Eskalation zum 2nd Level Support. 

2nd Level Support 

Der 2nd Level Support „ist die zweite Prozessstufe im Incident Management‟ 50 und übernimmt 

die Störungsmeldungen vom 1st Level Support. Im 2nd Level Support sind Spezialisten tätig, 

die sich um die Behebung des Incident kümmern. Wenn dies nicht möglich ist wird bei Bedarf 

die Unterstützung des 3rd Level Support angefordert. Falls ein Problem die Ursache für den 

Incident ist, so wird der Incident an das Problem Management übergeben. 51 


47 Vgl. Kempter, A.: Rollen in ITIL V3, 2010, http://wiki.de.it-processmaps.com/index.php/Rollen_in_ITIL_V3, 

11.03.2010. 

48 Schiefer, H.; Schitter, E.: Prozesse optimieren mit ITIL ® , 2. Auflage ,Wiesbaden 2008, S. 274. 


50 Schiefer, H.; Schitter, E.: Prozesse optimieren mit ITIL ® , 2. Auflage ,Wiesbaden 2008, S. 274. 

51 Vgl. Kempter, A.: Rollen in ITIL V3, 2010, http://wiki.de.it-processmaps.com/index.php/Rollen_in_ITIL_V3, 

11.03.2010.


3rd Level Support 

Beim 3rd Level Support handelt es sich üblicherweise um die Hersteller von Hardware- oder 

Softwareprodukten, die zur schnellstmöglichen Behebung des Incident kontaktiert werden. 52 

Major Incident Team 

Das Major Incident Team ist ein dynamisch gegründetes Team bestehend aus IT-Managern und 

IT-Spezialisten, die unter der Leitung des Incident Managers die Erarbeitung einer Lösung für 

die Behebung des Major Incidents anstreben. 53 

52 


11.03.2010. 

53 


11.03.2010.


4.1.4. Prozessablauf des Incident Managements 

Management 

Eskalation 

Über Event 

Management 

Major Incident 

Verfahren 

Ja 

HierarchiHierarchischescheEskalation 

Eskalation erfor- 

erforderlich? 

derlich ? 

Abb. 6: Incident Management Prozess 54 

Über Weboberfläche Anruf eines Anwenders 

Ja 

Nein 

Ja 

Incident Identifizierung 

Incident Erfassung 

Incident Kategorisierung 

Service Request? 

Incident Priorisierung 

Major Incident? 

Erstdiagnose 

Funktionale 

Eskalation 

erforderlich ? 

Untersuchung und 

Diagnose 

Lösung und 

Wiederherstellung 

Incident Abschluss 

Nein 

54 Entnommen aus: Office of Covernment Commerce: Service Operation, London 2007, S.56. 

Ende 

Nein 

Nein 

Ja 

Ja 

E-Mail eines techni- 

schen Mitarbeiters 

An Request 

Fulfilment 

Funktionale Eskalation 

2/3 Level


Der Incident Management Prozess umfasst die folgenden Aktivitäten: 

Identifikation von Incidents 

Ein Incident kann nicht behoben werden, bevor dieser nicht erkannt wird. Aus diesem Grund 

empfiehlt ITIL die Überwachung aller wichtigen IT Komponenten um Incidents frühzeitig zu 

erkennen und diesen durch den Anstoß des Incident Management Prozesses frühzeitig entge- 

genzuwirken. Im Idealfall sollte die Behebung des Incident bereits erfolgt sein, bevor der Inci- 

dent sich negativ auf die Kunden und deren Arbeitsleistung auswirkt. 55 

Incident-Erfassung 

Ein Ziel des Incident Managements ist eine zügige Störungsbehebung. Voraussetzung für eine 

zügige Störungsbehebung ist eine zentrale Störungsannahmestelle, an die sich die Anwender im 

Falle eines Incident wenden können. Die Aufgabe dieser Störungsannahmestelle ist die Koordi- 

nation der einzelnen Incidents. ITIL empfiehlt in solchen Fällen einen Service Desk zu etablie- 

ren. 56 Dieser Service Desk ist die zentrale Anlaufstelle (Single Point of Contact) für alle Stö- 

rungsmeldungen. Um eine maximale Erreichbarkeit dieser Störungsannahmestelle gewährleis- 

ten zu können, sollten zunächst zentrale Rufnummern, Faxnummern und E-Mail-Postfächer 

eingerichtet und den Anwendern mitgeteilt werden. Auf diese Weise soll ein unkoordiniertes 

Fragen nach Hilfestellung in der IT verhindert werden. Stattdessen können sich die Anwender 

im Falle eines auftretenden Incident an den Service Desk wenden, der alle auftretenden Inci- 

dents erfasst. 

Incident-Kategorisierung 

Die Kategorisierung ist das Zuordnen des Incident zu einer fachlichen Gruppe wie z. B. Netz- 

werk, Peripherie oder Software. Grundlage der Kategorisierung ist eine eigens entwickelte ein- 

heitliche Kategorisierungssystematik. Sowohl die Kategorisierungssystematik als auch die Ka- 

tegorisierungstiefe sollte dabei individuell an die Gegebenheiten des Unternehmens angepasst 

werden. Mit Hilfe dieser Kategorisierung können anfallende Incidents einfacher den verantwort- 

lichen IT-Mitarbeitern zugeordnet und Service Requests erkannt werden. Durch die Nutzung der 

Kategorisierungssystematik können fälschlicherweise als Incident erfasste Service Requests als 

solche identifiziert und an das Request Fulfilment weitergeleitet werden. 57 

55 Vgl. Office of Government Commerce: Service Operation, London 2007, S.55. 


57 Vgl. Office of Government Commerce: Service Operation, London 2007, S.57.


Incident-Priorisierung 

Nach der Klassifizierung erfolgt die Incident-Priorisierung bei der die beiden Faktoren Dring- 

lichkeit und Auswirkung mit Hilfe einer Priorisierungssystematik bewertet werden. 58 Die Nut- 

zung einer Priorisierungssystematik, wie sie beispielhaft in Tabelle 1 dargestellt wird, ist aber 

nur dann effektiv, wenn sie einheitlich von allen Mitarbeitern des Service Desk angewendet 

wird. 

Tab. 2 - Priorisierungssystematik 59 

Erste Diagnose 

Nach der Priorisierung muss eine erste Diagnose des Incident erfolgen. Dabei versucht der Ser- 

vice Desk-Mitarbeiter alle Symptome, sowie die Ursachen des Incident durch gezielte Fragen zu 

identifizieren und ermittelt welche Korrekturmaßnahmen für die Lösung des Incident erforder- 

lich sind. 60 Als Hilfsmittel werden in dieser Phase üblicherweise Diagnoseskripte und Known 

Error Datenbanken genutzt. 61 Im Idealfall erfolgt eine prompte Lösung des Incident durch den 

Service-Desk Mitarbeiter. Wenn dies nicht der Fall ist, dann erfolgt die Eskalation des Incident. 

Incident-Eskalation 

Auswirkung 

Hoch Mittel Niedrig 

Dringlichkeit Hoch 1 2 3 

Mittel 2 3 2 

Niedrig 3 4 5 

Für den Fall, dass es den Service Desk-Mitarbeitern nicht gelingt die Störung direkt zu beseiti- 

gen, ist eine funktionale Eskalation zum besser qualifizierten 2nd Level Support notwendig. 

Wenn die Störungsbeseitigung nicht in einem bestimmten Zeitraum erfolgt, muss es zu einer 

erneuten Eskalation kommen. Eine Eskalation ist eine Aktivität, die das Einholen zusätzlicher 

Ressourcen umfasst und immer dann notwendig ist, wenn der Service Desk einen Incident nicht 

selber lösen kann und die Erreichung von Service Level-Zielen gefährdet ist. 62 Ziel der Eskala- 

tionsprozedur ist die Verhinderung bzw. Minimierung von materiellen und immateriellen Schä- 

den, sowie die Unterstützung einer schnellen Störungsbehebung. 

Generell werden zwei Eskalationstypen unterschieden: 

Priorität Beschreibung Lösungsdauer 

1 kritisch < 1 Stunden 

2 hoch < 6 Stunden 

3 moderat < 24 Stunden 

4 niedrig < 48 Stunden 

5 Planung geplant 


59 Entnommen aus: Office of Government Commerce: Service Operation, 2007, S. 58. 



62 van Bon, J.; de Jong, A.; Kolthof, A.; Pieper, M.; Tjassing, R.; van der Veen, A.; Verheijen, T.: IT Service Management 

basierend auf ITIL V3 – Das Taschenbuch, 3. Auflage, Zaltbommel 2008, S.146.


� Funktionale Eskalation: 

Die Weiterleitung eines Incident, Problems, Request oder Change von einem Support Le- 

vel zum nächsten Support Level wird als funktionale Eskalation bezeichnet. Eine funktio- 

nale Eskalation wird dann notwendig, wenn eine Support-Einheit nicht mehr in der Lage ist 

zur Problemlösung beizutragen oder die festgelegte Zeit für die Lösung des Incident abge- 

laufen ist. 63 

� Hierarchische Eskalation: 

Die hierarchische Eskalation ist das Informieren oder Einbeziehen höherer Management- 

Ebenen zur Einleitung weiterer Maßnahmen. Die hierarchische Eskalation innerhalb eines 

Prozesses erfolgt normalerweise zunächst über den Prozess-Manager und den Prozess- 

Owner und wird angestoßen, wenn die funktionale Eskalation nicht den gewünschten Er- 

folg bringt. 64 

Untersuchung und Diagnose 

Nach der Eskalation erfolgt die Untersuchung und Diagnose des Incident. Im Rahmen der Un- 

tersuchung werden oftmals die folgenden Aktivitäten 65 durchgeführt: 

� Identifikation der Ursache oder der Informationen, die die Anwender benötigen 

� Die chronologische Reihenfolge der Events verstehen 

� Die Auswirkung des Incident bestätigen 

� Events, die den Incident verursacht haben könnten identifizieren 

� Suchabfragen nach ähnlichen bzw. gleichen Vorkommnissen in bereits vorhandenen 

Incident- oder Problem Records. Als alternative Quellen für die Suche können auch 

Known Error Datenbanken oder Wissensdatenbanken von Herstellern genutzt wer- 

den 

Oftmals lassen sich auf diese Weise bereits einige Incidents beheben, ohne das eine Eskalation 

notwendig ist. 

Lösung und Wiederherstellung 

Auf Basis der Untersuchungsergebnisse und der Diagnose können Maßnahmen umgesetzt wer- 

den, die der Störungsbehebung bzw. der Wiederherstellung des Services dienen. Alle umgesetz- 

ten Aktivitäten und relevanten Informationen müssen dabei im Incident Record protokolliert 

und ständig aktualisiert werden. Wenn eine Lösung gefunden wird, dann müssen im Anschluss 



65 Vgl. Office of Government Commerce: Service Operation, London 2007, S. 59 f.


daran Tests durchgeführt werden, mit deren Hilfe sichergestellt werden soll, dass die erarbeitete 

Lösung erfolgreich war und der Service für den bzw. die Anwender wiederhergestellt ist. 66 

Incident-Abschluss 

Mit dem Schließen des Störungstickets erfolgt der Abschluss des Störungslebenszyklus. Der 

Abschluss eines Störungstickets kann allerdings erst nach einer Prüfung durch den verantwort- 

lichen Service Desk-Mitarbeiter erfolgen. Dieser hat zu prüfen, ob die Störung vollständig und 

zur vollen Zufriedenheit des Anwenders gelöst wurde. 67 Des Weiteren ist zu prüfen, ob sich die 

anfangs festgelegte Störungskategorie als richtig erwiesen hat oder ob eine nachträgliche An- 

passung der Störungskategorie von Nöten ist. Darüber hinaus sind die noch ausstehenden De- 

tails für die Incident-Dokumentation einzuholen und die Wahrscheinlichkeit für ein erneutes 

Auftreten des Incident zu bestimmen. Wenn ein erneutes Auftreten wahrscheinlich ist, dann 

muss mit Hilfe des Problem Managements ein Problem Record erstellt werden, damit eine Ini- 

tiierung von präventiven Maßnahmen erfolgen kann. Zu guter Letzt erfolgt noch der formale 

Abschluss des Incident. 

4.1.5. Methoden und Tools 

Für die effektive Umsetzung des Incident Managements sollte das folgende Tool genutzt wer- 

den: 

Incident Management Tools 

Im Zuge des Incident Managements sollte ein Incident Management Tool verwendet werden, 

welches über eine Historie verfügt und die Informationen über die Incidents und die Probleme 

speichert. Darüber hinaus sollt das Tool eine Kategorisierung von Incidents ermöglichen, die 

Informationen über die umgesetzten Maßnahmen dokumentieren können und über Diagnose- 

skripte verfügen. 68 Diese Funktionalität wird üblicherweise von sogenannten Ticketing-Tools 

bereitgestellt. 

4.2. Problem Management 

„Das Problem Management ist der Prozess, der für das Management des Lebenszyklus aller 

Probleme zuständig ist.“ 69 

66 Vlg. Office of Government Commerce: Service Operation, London 2007, S. 61. 



69 Office of Government Commerce: Service Operation, London 2007, S. 67.


„Wichtigstes Ziel des Problem Managements ist es, Probleme und daraus resultierende Inci- 

dents zu verhindern, das wiederholte Auftreten von Incidents auszuschließen und die Auswir- 

kungen von nicht vermeidbaren Incidents zu minimieren.“ 70 

Das Problem Management liefert eine Beschreibung aller Aktivitäten, die zur Diagnose der 

zugrunde liegenden Ursache von Incidents und zur Lösung der entsprechenden Probleme not- 

wendig sind. Das Problem Management hat darüber hinaus die Aufgabe sicherzustellen, dass 

die gefundenen Lösungen mit Hilfe von geeigneten Steuerungsverfahren implementiert wer- 

den. 71 Eine weitere Aufgabe des Problem Managements ist die Verwaltung der zur Verfügung 

stehenden Informationen zu den einzelnen Problemen und deren dazugehörigen Lösungen und 

Workarounds. 72 

Der Mehrwert, der durch den Einsatz des Problem Managements entsteht, kann sehr groß sein, 

denn das Problem Management arbeitet eng mit dem Incident und Change Management zu- 

sammen, um die Verfügbarkeit und Qualität von IT-Services zu verbessern. Die Informationen, 

die bei der Lösung von Incidents anfallen, werden erfasst und später genutzt um dauerhafte 

Lösungen zu identifizieren, mit denen sich die Anzahl, sowie die Lösungszeiten der anfallenden 

Incidents reduzieren lassen. Auf diese Weise werden Ausfallzeiten und Unterbrechungen von 

relevanten Systemen reduziert. Weitere Vorteile sind eine verbesserte Verfügbarkeit der IT- 

Services sowie eine verbesserte Produktivität der Mitarbeiter. 73 

4.2.1. Begriffe 

Im Folgenden werden zahlreiche Begriffe vorgestellt, die für das Verständnis des Problem Ma- 

nagement Prozesses notwendig sind. 

Was ist ein Problem? 

„Ein Problem ist die unbekannte Ursache eines oder mehrerer Incidents.‟ 74 

Was ist ein Known Error? 

Ein Known Error ist ein Problem, dessen Ursache identifiziert und für den ein Workaround 

gefunden und festgelegt wurde. Der Known Error wird in der Known Error Datenbank gespei- 

chert und auf diese Weise den Service Desk-Mitarbeitern zur Verfügung gestellt. Dadurch kön- 




73 Vgl. Office of Government Commerce: ITIL Service Operation, S. 68. 

74 Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 154.


nen die Service Desk-Mitarbeiter in der Known Error Datenbank nach bekannten Problemen 

und deren Lösungen suchen. 75 

4.2.2. Prinzipien 

Problemmodelle 

Oftmals treten Probleme einmalig auf und müssen aus diesem Grund auch individuell behandelt 

werden. Es ist aber auch möglich, dass Incidents aufgrund nicht behandelter oder zugrunde 

liegender Probleme erneut auftreten, beispielsweise wenn die Kosten für die dauerhafte Lösung 

zu hoch sind und aus diesem Grund die kostenaufwendige Lösung nicht umgesetzt wird. 76 

Um eine schnellere Diagnose zu ermöglichen sollte deshalb nicht nur ein Known Error Record 

in der Known Error Datenbank erfasst werden, sondern auch ein Problemmodell erstellt werden. 

Dies ermöglicht eine vereinfachte Behandlung von Problemen. Das Problemmodell ist ver- 

gleichbar mit dem in Kapitel 4.1.2. genannten Incident-Modell und ermöglicht das Festlegen 

einer chronologischen Reihenfolge von Schritten, die die Abwicklung des Prozesses vereinfa- 

chen. Darüber hinaus werden die Zuständigkeit sowie der zur Verfügung stehende Zeitrahmen 

für die auszuführenden Aktionen festgelegt. Dies alles ermöglicht eine vereinfachte und be- 

schleunigte Behandlung von erneut auftretenden Problemen. 77 

4.2.3. Rollen 

Problem Manager 

Der Problem Manager ist für das Problem Management verantwortlich und kümmert sich um 

die Koordination der gesamten Problem Management Aktivitäten. Die weiteren Aufgaben 78 des 

Problem Managers sind: 

� Management Reporting 

� Pflege der Known Error Database 

� Formaler Abschluss der Problem Records 

� Verbindung zu externen Partnern in Bezug auf die Lösung von Problemen 

� Zusammenstellung der Problem Solving Groups 

Problem Solving Goups 

Problem Solving Groups werden abhängig vom jeweiligen Problem zusammengestellt. 79 Die 

Zusammenstellung übernimmt der Problem Manager. 80 Üblicherweise bestehen Problem 




78 Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 156. 


80 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 156.


Solving Groups aus Spezialisten, die sich um die Diagnose und Lösungssuche kümmern. Dabei 

kann es sich sowohl um interne, als auch um externe Spezialisten handeln. 81 

4.2.4. Methoden und Tools 

Für die effektive Umsetzung des Problem Managements empfiehlt ITIL die Nutzung von ver- 

schiedenen Tools, die im Folgenden vorgestellt werden: 

CMS 

Das Configuration Management System, kurz CMS, unterstützt die IT-Mitarbeiter beim Mana- 

gement der IT-Infrastruktur und liefert detaillierte Informationen zu den Komponenten der IT- 

Infrastruktur. Aus diesem Grund ist das CMS eine wertvolle Quelle für die Diagnose von Prob- 

lemen und unterstützt die IT-Mitarbeiter bei der Bewertung der Auswirkungen von Proble- 

men. 82 

Known Error Datenbank 

Die Known Error Datenbank ist ein wichtiges Hilfsmittel, welches dazu genutzt wird, die früher 

gewonnenen Erkenntnisse über Incidents und Probleme und deren Lösungen zu dokumentieren. 

Auf diese Weise wird eine schnellere Diagnose und Lösung bei einem erneuten Auftreten er- 

möglicht. 83 In der Known Error Datenbank werden detaillierte Informationen über die Symp- 

tome, Workarounds und Lösungsmaßnahmen gespeichert, die beim erneuten Auftreten des 

Fehlers abgerufen und genutzt werden können. 84 


82 Office of Government Commerce: ITIL Service Operation, S. 75. 


84 Office of Government Commerce: ITIL Service Operation, S. 75.


4.2.5. Prozessablauf des Problem Managements 

Service 

Desk 

Change 

Management 

Event Management 

Abb. 7: Problem Management Prozess 85 

Ja 

Incident 

Management 

Problemerkennung 

Problemerfassung 

Kategorisierung 

Priorisierung 

Untersuchung und 

Diagnose 

Workaround? 

Change erforderlich 

? 

Nein 

85 Entnommen aus: Office of Covernment Commerce: Service Operation, London 2007, S.69. 

Nein 

Known Error Record 

erstellen 

Lösung 

Abschluss 

Schwerwiegendes 

Problem ? 

Ende 

Proactive 

Problem 

Managemet 

CMS 

Supplier oder 

Auftragnehmer 

Known 

Error 

Datenbank 

Review nach 

schwerwiegenden 

Problemen


Beim Problem Management werden zwei verschiedene Arten 86 des Problem Managements un- 

terschieden: 

� Reaktives Problem Management - Das reaktive Problem Management umfasst die 

Erkennung von Problemen und Known Errors durch die Analyse von Incidents, wenn 

diese bereits aufgetreten sind. 87 

� Proaktives Problem Management - Das proaktive Problem Management umfasst die 

regelmäßige Analyse von Incidents und die fortwährende Analyse der IT-Infrastruktur 88 

und wird zwar in der Phase der Service Operation initiiert, gehört aber in der Regel zum 

Continual Service Improvement. 89 

Problemerkennung 

Die Problemerkennung kann auf verschiedene Weisen erfolgen. Beispielsweise kann ein Prob- 

lem auf Basis der folgenden Stichpunkte 90 erkannt werden: 

� Die Erfahrung der Service Desk Mitarbeiter ist eine Möglichkeit um Probleme zu er- 

kennen. Demnach sollte ein Problem Record auch dann erfasst werden, wenn der Ser- 

vice Desk Mitarbeiter einen Incident beheben, jedoch nicht die Ursache eindeutig be- 

stimmen kann und aufgrund seiner Erfahrung die Vermutung hegt, dass ein Problem 

dem Incident zugrunde liegt. 

� Die nächste Möglichkeit ist die nachgelagerte Analyse eines Incident durch den techni- 

schen Support. Wenn der technische Support aufgrund der Analyse zu der Erkenntnis 

kommt, dass ein Problem vorliegt, dann sollte ebenfalls ein Problem Record eröffnet 

werden. 

� Die Automatische Erkennung von Problemen durch den Einsatz von Event/Alarm-Tools 

ist eine weitere Möglichkeit. 

Problemerfassung 

Im Zuge der Problemerfassung müssen alle relevanten Problemdetails erfasst werden. Wichtig 

ist darauf zu achten, dass ein Querverweis zu dem vorhandenen Incident angelegt wird, der den 

eigentlichen Problem Record verursacht hat. Darüber hinaus ist darauf zu achten, dass alle 

wichtigen Details des Incident Record in den Problem Record kopiert werden. Der Inhalt der zu 

kopierenden Informationen variiert und ist abhängig von dem aufgetretenen Problem. Häufig 

werden aber die folgenden Informationen 91 erneut dokumentiert: 

� Anwenderdetails 

� Servicedetails 


87 Vgl. Olbrich, A.: ITIL kompakt und verständlich, 4. Auflage, Wiesbaden 2008, S. 42. 

88 Vgl. Olbrich, A.: ITIL kompakt und verständlich, 4. Auflage, Wiesbaden 2008, S. 42. 





� Gerätedetails 

� Erfassungsdatum 

� Details der Priorisierung und Kategorisierung 

� Beschreibung des Incident 

� Beschreibung der Details der diagnostischen und umgesetzten Wiederherstellungsmaß- 

nahmen 

Problemkategorisierung 

Die Problemkategorisierung gestaltet sich analog zum Incident Management (siehe Kapitel 

4.1.4.). Im Zuge dessen ist darauf zu achten, dass die gleiche Systematik sowohl beim Incident 

als auch beim Problem Management verwendet wird. 92 

Problempriorisierung 

Die Problempriorisierung muss ebenso wie die Problemkategorisierung analog zum Incident 

Management erfolgen (siehe. Kapitel 4.1.4.) und zusätzlich den Schweregrad des Problems 

berücksichtigen. Der Schweregrad verdeutlicht, wie weitreichend ein Problem die zugrundlie- 

gende Infrastruktur beeinflusst. 

Problemuntersuchung und –diagnose 

Um die Ursache für ein Problem zu identifizieren muss zunächst eine Untersuchung des Prob- 

lems stattfinden. Dabei hängt sowohl der Umfang, als auch der Durchführungszeitraum maß- 

geblich von der Auswirkung, dem Schweregrad und der Dringlichkeit des Problems ab. 93 Durch 

den Einsatz von hilfreichen Techniken wie z. B. der Schlüsselwortsuche in der Known Error 

Datenbank oder der Auswertung der CMDB 94 können die Probleme effektiv untersucht wer- 

den. 95 

Workarounds 

Oftmals besteht die Möglichkeit einen Workaround für Incidents zu finden, die durch ein Prob- 

lem verursacht wurden. Workarounds sind aber nur temporäre Lösungen. Daher sollte an einer 

dauerhaften Lösung gearbeitet werden, sofern es vom Aufwand noch angemessen ist. 

Erstellen eines Known Error Record 

Nach Beendigung der Diagnose muss ein Known Error Record in der Known Error Datenbank 

erstellt werden. 96 



94 Die CMDB ist eine Datenbank, die der Verwaltung von CIs dient. 




Problemlösung 

Sobald eine passende Lösung zur Behebung des Problems gefunden wurde, muss zunächst si- 

chergestellt werden, dass die erarbeitete Lösung keine dauerhaften Schwierigkeiten verursacht. 

Für den Fall, dass Änderungen an der Funktionalität notwendig sind, muss ein Request for 

Change (RfC) 97 erstellt und genehmigt werden, um die Lösung einsetzen zu können. Wenn es 

sich um ein schwerwiegendes Problem handelt, dass sich negativ auf die unternehmerische Tä- 

tigkeit auswirkt, ist eine umgehende Einberufung einer Dringlichkeitssitzung des Change Advi- 

sory Board / Emergency Committee (CAB /EC) notwendig, um sofortige Maßnahmen für den 

Notfall-RfC initiieren zu können. 98 

Wenn es sich um einen normalen RfC handelt, sollte die erarbeitete Lösung zunächst den Chan- 

ge Management Prozess durchlaufen. Dies hat zur Folge, dass die erarbeitete Lösung erst dann 

eingesetzt wird, wenn der Change genehmigt und für die Umsetzung freigegeben wurde. Soll- 

ten bis zur Umsetzung des Changes erneut Probleme oder Incidents auftreten, so sollte für deren 

Behebung die Known Error Database genutzt werden, um eine schnelle Lösung sicherzustel- 

len. 99 

Problemabschluss 

Nachdem der Change umgesetzt wurde, der Review erfolgreich war und die Lösung im Einsatz 

ist, muss zu guter Letzt der Problem Record sowie die verbliebenen offenen Incident Records 

formal abgeschlossen werden. 100 

Review nach schwerwiegenden Problemen 

Nach dem Auftreten und Beheben eines schwerwiegenden Problems ist ein Review durchzufüh- 

ren, um Rückschlüsse aus dem schwerwiegenden Problem zu ziehen und die wichtigsten Er- 

kenntnisse für die Zukunft zu nutzen. Im Fokus der Betrachtung stehen dabei in erster Linie das 

Verhalten der Mitarbeiter, Verbesserungspotenziale beim Vorgehen der Mitarbeiter und die 

Identifikation von Maßnahmen mit deren Hilfe das künftige Auftreten von schwerwiegenden 

Problemen vermieden werden kann. 101 

97 Ein RfC ist ein formaler Antrag zur Durchführung eins Change. 




101 Vgl. Office of Government Commerce: ITIL Service Operation, S. 73.

Erhebung der Daten 28 

5 Erhebung der Daten 

Im fünften Kapitel werden der Untersuchungsgegenstand, die Erhebungsmethode, die Zielgrup- 

pe der Befragung, das Konzept des Fragebogens und die Auswahl der Umfrageteilnehmer be- 

schrieben. 

5.1. Untersuchungsgegenstand 

Gegenstand der Untersuchung ist die Ermittlung des Status quo von ITIL in mittelständischen 

Unternehmen und Unternehmen mittlerer Größe. Im Mittelpunkt der Untersuchung stehen die 

ITIL-basierten Prozesse und Funktionen, die in den befragten Unternehmen zum Einsatz kom- 

men und jene, die in Zukunft noch implementiert werden sollen. Im Zuge der Untersuchung soll 

ermittelt werden, welche ITIL-Version in den befragten Unternehmen genutzt wird. Außerdem 

soll untersucht werden, aus welchen Gründen ITIL verwendet bzw. nicht verwendet wird. Da- 

rüber hinaus sollen die verschiedenen Probleme, die die Befragten bei der Einführung des Inci- 

dent und Problem Managements hatten, ermittelt werden. Für diese Probleme sind Lösungsvor- 

schläge zu erarbeiten, die in das zu entwerfende Vorgehensmodell einfließen sollen und mit 

dessen Hilfe die Prozesse erfolgreich implementiert werden können. 

5.2. Erhebungsmethode 

Die Erhebung der benötigten Informationen kann mit Hilfe der folgenden vier Methoden erfol- 

gen: 

� mündliche Befragung 

� telefonische Befragung 

� schriftliche Befragung 

� Onlineumfrage 

Die Vor- und Nachteile der vier Erhebungsmethoden werden in der folgenden Tabelle vorge- 

stellt:


Tab. 3 - Vor- und Nachteile der Erhebungsmethoden 

Vorteile Nachteile 

Mündliche Befragung • Interviewer kann sich an die Be- 

fragungssituation anpassen 102 

• Fragen können erklärt werden 

• Höhere Rücklaufquote 

Telefonische Befragung • Geringe Kosten 

• Allokalität 

Schriftliche Befragung • Allokalität 

• Interviewer kann sich an die Be- 

fragungssituation anpassen 104 

• Fragen können erklärt werden 

• Relativ geringe Kosten 105 

• Flexible Zeiteinteilung bei der 

Beantwortung der Fragen 106 

• Fragebogen kann jederzeit beant- 

wortet werden 

• Höhere Erreichbarkeit der Aus- 

kunftsperson 107 

• Visuelle Darstellung von Zusam- 

menhängen möglich 

Onlineumfrage • Allokalität 

• Flexible Zeiteinteilung bei der 

Beantwortung der Fragen 

• Automatische Durchführung und 

Auswertung 108 

• Keine Erfassungsfehler 

• Visuelle Darstellung von Zusam- 

menhängen möglich 

• Hohe Reisekosten 103 

• Zeitintensive Reisen sind oftmals notwendig 

• Visuelle Darstellung von Zusammenhängen 

nicht möglich 

• Visuelle Darstellung von Zusammenhängen 

nicht möglich 

• Geringe Antwortquote 

• Die notwendige manuelle Erfassung ist 

arbeitsaufwendig, risikobehaftet und zeit- 

aufwendig 

• Unklare Fragestellungen können nicht 

erklärt werden 

• Unklare Fragestellungen können nicht 

erklärt werden 

Die wichtigsten Faktoren bei der Wahl der Erhebungsmethode sind die anfallenden Kosten und 

die zur Verfügung stehende Zeit, denn für die Durchführung der Erhebung steht nur ein gerin- 

ges Budget, sowie ein kurzer Zeitrahmen zur Verfügung. Aufgrund dieser ökonomischen und 

zeitlichen Gesichtspunkte fällt die Wahl der Erhebungsmethode auf die Onlineumfrage. 

102 Vgl. Rossig, W. E.; Prätsch, J.: Wissenschaftliche Arbeiten, 7. Auflage, Hamburg 2008, S. 76. 

103 Vgl. Mayer, H. O.: Interview und schriftliche Befragung, 4. Auflage, München 2008, S.100. 





108 Vgl. Rossig, W. E.; Prätsch, J.: Wissenschaftliche Arbeiten, 7. Auflage, Hamburg 2008, S. 77.


5.3. Zielgruppe der Erhebung 

In Absprache mit Prof. Dr. Wilking werden mittelständische Unternehmen und Unternehmen 

mittlerer Größe als Zielgruppe für die Umfrage festgelegt. Als Unternehmen mittlerer Größe 

definiert Prof. Dr. Wilking alle Unternehmen, die mehr Arbeitnehmer als ein mittelständisches 

Unternehmen beschäftigen, aber nicht mehr als 2000 Arbeitnehmer beschäftigen . Aufgrund der 

umfassenden Kenntnisse über die eigene IT-Abteilung werden die Verantwortlichen der IT- 

Abteilung als Zielperson für die Umfrage ausgewählt. 

Als Grundlage für die Identifikation des Mittelstands wird die Einteilung des Institut für Mittel- 

standforschung Bonn genutzt. (siehe Kapitel 2.7.1.). Das Institut für Mittelstandsforschung 

Bonn definiert die Anzahl der Mitarbeiter und den Umsatz der Unternehmen, als die wichtigsten 

Kriterien zur Abgrenzung der Unternehmensgröße. Im Rahmen der Datenerhebung wird mit der 

Anzahl der Mitarbeiter nur eines der beiden Kriterien für die Klassifizierung der Unterneh- 

mensgröße verwendet, da die Frage nach dem Umsatz des Unternehmens u.U. mögliche Adres- 

saten von einer Teilnahme absehen lassen könnte. 

5.4. Konzeption des Fragebogens 

Die Konzeption des Fragebogens sieht eine Befragungsdauer von 6 - 9 Minuten vor, wobei die 

Befragungsdauer und die Anzahl der gestellten Fragen stark vom Antwortverhalten der Umfra- 

geteilnehmer abhängen. 

Das für die Umfrage verwendete System der Onlineumfrage.com GmbH 109 arbeitet mit Sprün- 

gen, die es ermöglichen auf das Antwortverhalten der Umfrageteilnehmer zu reagieren. Auf 

diese Weise kann sichergestellt werden, dass den Teilnehmern der Umfrage nur sinnvolle Fra- 

gen gestellt werden. 

Insgesamt besteht der Fragebogen aus neunzehn Fragen. Thematisch können die Fragen in die 

folgenden neun Frageblöcke unterteilt werden: 

� 1. Block: Größe und Branchen der teilnehmenden Unternehmen 

� 2. Block: Status quo von ITIL 

� 3. Block: Gründe für die Nutzung bzw. den Verzicht 

� 4. Block: Verbreitung der ITIL-basierten Prozesse und Funktionen 

� 5. Block: Bedarf an ITIL-basierten Prozessen und Funktionen 

109 Siehe: www.onlineumfragen.com.


� 6. Block: Verwendete ITIL-Version 

� 7. Block: Probleme bei der Einführung des Incident Managements 

� 8. Block: Probleme bei der Einführung des Problem Managements 

� 9. Block: Einfluss von ITIL auf die Prozesse 

Der erste Block umfasst allgemeine Fragen zur Anzahl der Mitarbeiter und der Branche des 

befragten Unternehmens. Dabei dient die Frage nach der Mitarbeiterzahl nicht nur der Kategori- 

sierung der Umfrageteilnehmer, sondern zielt auch darauf ab, die nicht zur Zielgruppe gehören- 

den Unternehmen herauszufiltern und an das Ende der Umfrage zu leiten. 

Tab. 4 - Fragebogen: 1. Block - Größe und Branche 

1. Block : Größe und Branche 

Wie viele Mitarbeiter sind in Ihrem Unternehmen beschäftigt? 

In welcher Branche ist Ihr Unternehmen hauptsächlich tätig? 

Im zweiten Block wird ermittelt, ob ITIL in den befragten Unternehmen zum Einsatz kommt. 

Tab. 5 - Fragebogen: 2. Block - Status quo von ITIL 

Wird ITIL in Ihrem Unternehmen verwendet? 

2. Block : Status quo von ITIL 

Im dritten Themengebiet werden die Gründe für die Nutzung bzw. den Verzicht auf ITIL ermit- 

telt. Im Rahmen dessen wird untersucht, ob es einen Zusammenhang zwischen der Anzahl der 

IT-Mitarbeiter bzw. EDV-Anwender und der ITIL-Nutzung gibt. 

Tab. 6 - Fragebogen: 3. Block - Gründe für die Nutzung bzw. den Verzicht 

3. Block : Gründe für die Nutzung bzw. den Verzicht 

Warum wird ITIL in Ihrem Unternehmen nicht eingesetzt? 

Welche Ziele verfolgen Sie mit der Nutzung von ITIL? 

Wie viele Mitarbeiter sind in der IT tätig? 

Wie viele EDV - Anwender/innen gibt es in Ihrem Unternehmen? 

Das Ziel des vierten Themenkomplexes ist, zu ermitteln welche ITIL-basierten Prozesse und 

Funktionen in den Unternehmen verwendet werden. 

Tab. 7- Fragebogen: 4. Block: Verbreitung der ITIL-basierten Prozesse und Funktionen 

4. Block : Verbreitung der ITIL-basierten Prozesse und Funktionen 

Welche ITIL-basierten Standardprozesse und Funktionen haben Sie in Ihrem Unternehmen umgesetzt? 

Im fünften Block wird ermittelt, welche ITIL-basierten Prozesse und Funktionen in den Unter- 

nehmen noch eingeführt werden sollen.


Tab. 8 - Fragebogen: 5. Block: Bedarf an ITIL-basierten Prozessen und Funktionen 

5. Block : Bedarf an ITIL-basierten Prozessen und Funktionen 

Welche ITIL-basierten Standardprozesse und Funktionen planen Sie neben den bereits vorhandenen 

Prozessen und Funktionen noch einzuführen? 

Gegenstand des sechsten Themenkomplexes ist die in den Unternehmen verwendete ITIL- 

Version. 

Tab. 9 - Fragebogen: 6. Block: Verwendete ITIL-Version 

6. Block : Verwendete ITIL-Version 

Haben Sie ihre Prozesse nach ITIL Version 3 ausgerichtet? 

Gegenstand des siebten Themengebiets sind die Probleme, die bei der Einführung des Incident 

Managements aufgetreten sind. 

Tab. 10 - Fragebogen: 7. Block - Probleme bei der Einführung des Incident Managements 

7. Block : Probleme bei der Einführung des Incident Managements 

Gab es Probleme bei der Einführung des Incident Managements? 

Welche Probleme gab es bei der Einführung des Incident Managements? 

Das Ziel des achten Blocks ist die Ermittlung der Probleme, die bei der Einführung des Problem 

Managements in den befragten Unternehmen aufgetreten sind. 

Tab. 11 - Fragebogen: 8. Block - Probleme bei der Einführung des Problem Managements 

8. Block : Probleme bei der Einführung des Problem Managements 

Gab es Probleme bei der Einführung des Problem Managements? 

Welche Probleme gab es bei der Einführung des Problem Managements? 

Im neunten und letzten Themenkomplex sollen die Probanden die unternehmenseigenen Prozes- 

se anhand der in Tabelle 12 dargestellten Kriterien bewerten. Ziel ist es herauszufinden, ob die 

Verwendung von ITIL-basierten Prozessen und Funktionen einen positiven Einfluss auf die 

Prozesse hat. Im Zuge dessen erfolgt einer Unterteilung nach Probanden, die ITIL nutzen bzw. 

nicht nutzen.


Tab. 12 - Fragebogen: 9. Block Einfluss von ITIL auf die Prozesse 

Bitte bewerten Sie: 

9. Block : Einfluss von ITIL auf die Prozesse 

� die Benutzerfreundlichkeit Ihrer IT-Prozesse 

� die Effizienz Ihrer Prozesse 

� die IT-Sicherheit in Ihrem Unternehmen 

� die Prozessqualität in Ihrem Unternehmen 

� die Transparenz Ihrer Prozesse 

� die Wirtschaftlichkeit Ihrer Prozesse 

� das Sourcing in Ihrem Unternehmen 

� die Reaktionszeit Ihrer IT auf anfallende Störungen und Probleme 

� die Strukturierung Ihres IT-Betriebes 

� die Flexibilität Ihrer Prozesse 

5.5. Auswahl der Umfrageteilnehmer 

Um Teilnehmer aus der passenden Zielgruppe für die Onlineumfrage zu gewinnen ist es zu- 

nächst notwendig mittelständische Unternehmen und Unternehmen mittlerer Größe anhand der 

Mitarbeiterzahl zu identifizieren. Als Informationsquellen werden Wikipedia und die Firmenda- 

tenbanken der verschiedenen IHKs verwendet. 

5.5.1. Wikipedia 

Wikipedia ermöglicht Wirtschaftsunternehmen ein eigenes Firmenprofil mit Informationen über 

Produkte, Geschichte, Markt- und Mitarbeiterzahlen zu erstellen und auf Wikipedia zu veröf- 

fentlichen. Dafür muss das Unternehmen mindestens eines der folgenden Kriterien 110 erfüllen: 

Das Unternehmen 

� hat mindestens 1000 Vollzeitmitarbeiter oder 

� verfügt über mindestens 20 Zweigniederlassungen / Produktionsstandorte / Filialen ( 

keine Verkaufsbüros oder Handelsniederlassungen) oder 

� wird an einer deutschen Börse im regulierten Markt oder in einem gleichwertigen Börsensegment 

im Ausland gehandelt oder 

� hat eine marktbeherrschende Stellung oder innovative Vorreiterrolle bei einer relevanten 

Produktgruppe oder Dienstleistung oder 

� kann einen Jahresumsatz von mehr als 100 Millionen € vorweisen oder 

� hat eines der Kriterien historisch erfüllt. 

110 Vgl. Wikipedia : Wikipedia:Relevanzkriterien, 

http://de.wikipedia.org/wiki/Wikipedia:Relevanzkriterien#Wirtschaftsunternehmen, 25.03.2010


Zahlreiche Unternehmen haben die Möglichkeit genutzt und ihr eigenes Unternehmensprofil auf 

Wikipedia veröffentlicht. Diese Unternehmensprofile werden einzelnen Kategorien zugeordnet 

(z. B. „Unternehmen nach Stadt‟ 111 ). Mit Hilfe dieser Kategorisierung ist es möglich einen 

Überblick über Unternehmensprofile der gleichen Gattung zu bekommen und die verschiedenen 

Unternehmensprofile aufzurufen. Auf diese Weise kann mit Hilfe der Mitarbeiterzahl geprüft 

werden, ob ein Unternehmen zur Zielgruppe gehört. Kritisch anzumerken ist, dass die auf Wiki- 

pedia gelisteten Informationen nicht immer auf dem aktuellsten Stand sind. Folglich kann eine 

hundertprozentige Sicherheit, dass die Unternehmen zur Zielgruppe gehören, nicht gewährleis- 

tet werden. Aus diesem Grund muss während der Befragung eine erneute Überprüfung der An- 

zahl der Mitarbeiter erfolgen. 

5.5.2. Firmendatenbanken der Industrie und Handelskammern 

Als zweite Quelle für die Suche nach geeigneten Umfrageteilnehmern werden die Firmendaten- 

banken der Industrie und Handelskammern von Baden Württemberg 112 , Bayern 113 und Sach- 

sen 114 genutzt. Diese ermöglichen eine Suche nach Firmen anhand von ausgewählten Kriterien 

wie Branche, Rechtsform, Betriebsgrößenklasse oder Postleitzahl. Das für die Identifikation der 

potenziellen Umfrageteilnehmer relevante Kriterium ist die Betriebsgrößenklasse. Bei der Suche 

ist die Anzahl der angezeigten Unternehmen auf 20 begrenzt und erfolgt in Form einer zufälli- 

gen Auswahl. Aufgrund der Begrenzung wird der Suchvorgang mehrmals durchgeführt und die 

Daten werden in einer Liste gesammelt. Durch den mehrmals durchgeführten Suchvorgang ent- 

stehen beim Sammeln der Daten doppelte Einträge, die zu einem späteren Zeitpunkt wieder 

entfernt werden. 

5.5.3. Ermitteln der E-Mail-Adresse 

Um den IT-Verantwortlichen der ausgewählten Unternehmen von der Onlineumfrage in Kennt- 

nis setzen zu können, wird zunächst mit Hilfe der Suchmaschine Google 115 nach der Homepage 

des jeweiligen Unternehmens gesucht, wenn der Link zur Homepage nicht bereits in der Fir- 

mendatenbank oder im Unternehmensprofil angegeben ist. 

Nach Aufruf der Homepage der Unternehmen wird anschließend das Impressum des jeweiligen 

Unternehmens besucht, denn gemäß § 5 Abs. 1 Nr. 2 TMG sind Angaben, „die eine schnelle 

elektronische Kontaktaufnahme und unmittelbare Kommunikation ... ermöglichen, einschließ- 

lich der Adresse der elektronischen Post‟ 116 , im Impressum anzugeben. Diese E-Mailadresse 

111 

Siehe http://de.wikipedia.org/wiki/Kategorie:Unternehmen_%28M%C3%B6nchengladbach%29. Bei der ausgewählten 

Stadt handelt es sich um Mönchengladbach. 

112 

Siehe: www.bw-firmen.ihk.de 

113 

Siehe: www.firmen-in-bayern.de 

114 

Siehe: www.firmen-in-sachsen.de 

115 

Siehe: www.google.de 

116 

Bundesministerium der Justiz: TMG - Einzelnorm, http://www.gesetze-im-internet.de/tmg/__5.html, 27.03.2010.


ermöglicht eine erste Kontaktaufnahme mit den Unternehmen und wird anschließend in einer 

Liste gesammelt. Danach wird eine E-Mail verfasst, in der die Empfänger über die Umfrage 

informiert und um eine Weiterleitung an den IT-Verantwortlichen des jeweiligen Unternehmens 

gebeten wird.

Status quo von ITIL 36 

6 Status quo von ITIL 

Kapitel sechs beschreibt die Ergebnisse der durchgeführten Umfrage und des Experteninter- 

views mit Steven Handgräntinger. 

6.1. Umfrageergebnis 

Von den insgesamt 700 kontaktierten IT-Leitern haben 58 an der Umfrage teilgenommen und 

mindestens eine Frage beantwortet. Die daraus resultierende Antwortquote von 8,28 % ist rela- 

tiv gering. 

6.1.1. Größe und Branchen der teilnehmenden Unternehmen 

Die Mitarbeiterzahl der befragten Unternehmen verteilt sich folgendermaßen: 

1 - 9 Mitarbeiter 







Die Verteilung der teilnehmenden Unternehmen auf die folgenden Branchen sieht folgenderma- 

ßen aus: 

In welcher Branche ist Ihr Unternehmen hauptsächlich tätig? 

Abb. 9 - Branchen der befragten Unternehmen 

Wie in Abbildung 9 dargestellt, ist die IT-Branche mit 34 % am stärksten vertreten. Die Fahr- 

zeugbau und Zuliefererbranche ist mit 10% und die Elektrotechnikbranche mit 8 % vertreten. 

6 % der teilnehmenden Unternehmen sind im Maschinen- und Anlagenbau tätig. 12 % der Be- 

fragten sind in sonstigen Branchen aktiv. Die verbleibenden Branchen sind mit je 2 - 4 % sehr 

gleichmäßig verteilt. 

6.1.2. Status quo von ITIL 

Im Folgenden wird die prozentuale Verteilung der befragten Unternehmen dargestellt, die ITIL 

nutzen: 

Wird ITIL in Ihrem Unternehmen genutzt? 

ja 

50% 

Abb. 10 - Prozentuale Verteilung der ITIL-Nutzer 

nein 

37,5 % 

Weiß nicht / 

Keine Angabe 

12,5%


Die durchgeführte Umfrage hat ergeben, dass 50 % der befragten mittelständischen Unterneh- 

men und Unternehmen mittlerer Größe ITIL nutzen. Dem gegenüber stehen 37,5 % der Unter- 

nehmen, die ITIL nicht einsetzen. Die verbleibenden 12,5 % der Befragten wollten oder konnten 

die Frage nicht beantworten. 

6.1.3. Gründe für die Nutzung bzw. den Verzicht von ITIL 

Abbildung 11 verdeutlicht die Ursachen, warum die befragten Unternehmen auf die Einführung 

von ITIL-basierte Standardprozesse und Funktionen verzichten. Die Gründe dafür sind: 

Warum wird ITIL in Ihrem Unternehmen nicht eingesetzt? 

Abb. 11 - Ursachen für den Verzicht auf ITIL-basierte Standardprozesse 

Die häufigste Ursache, warum ITIL in den befragten Unternehmen nicht zum Einsatz kommt 

ist der Aufwand, der mit der Einführung von ITIL verbunden ist. Mit 29,41 % sind alternative 

Frameworks, die in den befragten Unternehmen zum Einsatz kommen, der zweithäufigst ge- 

nannte Grund. 17,65 % der befragten Unternehmen, die ITIL nicht nutzen versprechen sich 

durch die Verwendung von ITIL keine Vorteile. Je 5,88 % der Umfrageteilnehmer geben die zu 

hohen Einführungskosten, den Widerstand der Mitarbeiter, die fehlende Reife von ITIL sowie 

die noch laufende Prüfung von ITIL als Ursache für die Nichtberücksichtigung an. 

In Abbildung 12 werden die Ziele dargestellt, die die ITIL-nutzenden Unternehmen mit dem 

Einsatz von ITIL verfolgen. 

Eine ITIL Einführug wäre zu aufwendig 

Andere alternative Frameworks werden bereits verwendet 

ITIL umfasst keine detailierten Empfehlungen 

keine Vorteile durch den Einsatz von ITIL 

Einführung wird noch geprüft 

ITIL befindet sich noch in der Entwicklungsphase 

Widerstand bei den Mitarbeitern 

Einführungskosten sind zu hoch 

Weiß nicht / keine Angabe 

5,88% 

5,88% 

5,88% 

5,88% 

5,88% 

17,65% 

23,53% 

29,41% 

41,18% 

0,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00% 35,00% 40,00% 45,00%


Welche Ziele verfolgen Sie mit der Nutzung von ITIL? 

Effizienz erhöhen 

Qualität der Prozesse verbessern 

Professionalisierung der IT 

Kundenzufriedenheit erhöhen 

Transparenz der IT Prozesse 

Strukturierung des IT-Betriebs verbessern 

Schnellere Reaktionszeiten erreichen 

Störanfälligkeit minimieren 

Kosten senken 

Verbesserung der IT Sicherheit 

ITIL-Zertifizierung ermöglichen 

Sonstiges 

Abb. 12 - Ursachen für die Nutzung von ITIL-basierten Standardprozessen 

Abbildung 12 verdeutlicht die Ziele, die mit der Nutzung von ITIL verfolgt werden. Demnach 

sind die wichtigsten Ziele die Erhöhung der Effizienz, die Verbesserung der Prozessqualität 

sowie die Professionalisierung der IT. Rund 2 /3 der Befragten (68,18 %) möchten die Kundenzu- 

friedenheit erhöhen. Weitere Ziele sind die Transparenz der IT-Prozesse und die verbesserte 

Strukturierung des IT-Betriebes. 

Um den Zusammenhang zwischen der Anzahl der IT-Mitarbeiter und der ITIL-Nutzung darzu- 

stellen wurde die folgende Tabelle erstellt: 

4,55% 

27,27% 

40,91% 

36,36% 

45,45% 

45,45% 

68,18% 

63,64% 

63,64% 

77,27% 

0,00% 10,00% 20,00% 30,00% 40,00% 50,00% 60,00% 70,00% 80,00% 90,00% 

Tab. 13 - Zusammenhang zwischen Anzahl IT-Mitarbeiter und Nutzung von ITIL 

IT-Mitarbeiter 

Wie viele Mitarbeiter sind in der IT tätig? 

ITIL Einsatz ? 

Ja Nein 

Gesamt 

1 - 10 21,43 % 78,57 % 100,00 % 

11 - 25 71,43% 28,57 % 100,00 % 

26 - 50 33,33 % 66,67 % 100,00 % 

51 - 100 80,00 % 20,00 % 100,00 % 

101 - 200 100,00 % 0,00 % 100,00 % 

201 - 500 85,71 % 14,29 % 100,00 % 

501 - 1000 100,00 % 0,00 % 100,00 % 

86,36% 

86,36%


Tabelle 13 verdeutlicht, dass ein stark signifikanter Zusammenhang zwischen der ITIL-Nutzung 

und der Größe der IT-Abteilung herrscht. Je Größer die IT-Abteilung ist, umso größer ist die 

Wahrscheinlichkeit, dass ITIL genutzt wird. 

Tabelle 14 verdeutlicht den Zusammenhang zwischen der Anzahl der EDV-Anwender/innen 

und der Nutzung von ITIL: 

Tab. 14 - Zusammenhang zwischen Anzahl EDV-Anwender und Nutzung von ITIL 

EDV - Anwen- 

der/innen 

Wie viele EDV-Anwender / innen gibt es in Ihrem Unternehmen? 

ITIL-Nutzung 

Ja Nein 

Tabelle 14 illustriert, dass ab einer Anzahl von mehr als 500 EDV-Anwendern vermehrt ITIL 

zum Einsatz kommt. Eine Ausnahme sind die Unternehmen mit 1001 - 2000 EDV-Anwendern, 

bei denen die ITIL-Nutzung bzw. Nichtnutzung jeweils 50 % ausmacht. 

6.1.4. Verbreitung der ITIL-basierten Prozesse und Funktionen 

Die folgende Darstellung bildet die prozentuale Verteilung der ITIL-basierten Prozesse und 

Funktionen ab, die in den befragten Unternehmen zum Einsatz kommen: 

Gesamt 

1 - 50 50,00 % 50,00 % 100,00 % 

51 - 100 50,00 % 50,00 % 100,00 % 

101 - 200 42,86 % 57,14 % 100,00 % 

201 - 500 50 % 50 % 100,00 % 

501 - 1000 85,71 % 14,29 % 100,00 % 

1001 - 2000 50 % 50,00 % 100,00 % 

< 2000 100,00 % 0,00 % 100,00 %


Welche ITIL-basierten Standardprozesse und Funktionen haben Sie in Ihrem Unternehmen 

umgesetzt? 

Abb. 13 - Verbreitung der ITIL-basierten Prozesse und Funktionen 

Besonders weit verbreitet sind der Service Desk, das Incident, das Change und das Problem 

Management. Dabei fällt auf, dass es sich um ITIL-basierte Prozesse und Funktionen aus der 

Kernpublikation Service Operation handelt, die den operativen Betrieb der IT fokussiert. Das 

Service Level Management als Schnittstelle zum Kunden ist als Planungsprozess am weitesten 

verbreitet. 

Service Desk 

Incident Management 

Change Management 

Problem Management 

Service Level Management 

Information Security … 

Service Reporting 

Monitoring and Control 

IT Service Continuity … 

Availability Management 

IT Operations 

Release and Deployment … 

Request Fulfillment 

Knowledge Management 

Service Asset and … 

Supplier Management 

Capacity Management 

Service Portfolio Management 

Service Catalogue Management 

Financial Management 

Continual Service Improvement 

Access Management 


Service Validation and Testing 

Transition Planning and Support 

Demand Management 

Evaluation 

9,52% 

9,52% 

0,00% 

23,81% 

23,81% 

19,05% 

19,05% 

19,05% 

19,05% 

33,33% 

33,33% 

33,33% 

28,57% 

28,57% 

28,57% 

6.1.5. Bedarf an ITIL-basierten Prozessen und Funktionen 

Abbildung 14 stellt die geplanten Prozesse und Funktionen dar, die in den befragten Unterneh- 

men noch implementiert werden sollen: 

42,86% 

38,10% 

52,38% 

47,62% 

47,62% 

47,62% 

47,62% 

71,43% 

66,67% 

85,71% 

80,95% 

80,95% 

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%


Welche ITIL-basierten Standardprozesse und Funktionen planen Sie neben den bereits vor- 

Service Asset and Configuration … 

Weiß nicht / Keine Angaben 

Service Reporting 

CSI Improvement Process 

Capacity Management 

Service Catalogue Management 

Transition Planning and Support 

Change Management 

Service Level Management 

Information Security Management 

Monitoring and Control 

IT Service Continuity Management 

Availability Management 

Knowledge Management 

Access Management 


Service Validation and Testing 

keine 

Financial Management 

Demand Management 

Evaluation 

Service Desk 

Incident Management 

Problem Management 

IT Operations 

Release and Deployment … 

Request Fulfillment 

Supplier Management 

Service Portfolio Management 

handenen Prozessen und Funktionen noch einzuführen? 

Abb. 14 - Noch einzuführende Prozesse und Funktionen 

Der größte Nachholbedarf besteht beim Service Asset und Configuration Management, sowie 

beim Service Reporting und Continual Service Improvement. Generell fällt auf, dass kein bzw. 

nur ein geringer Bedarf an operativen Prozessen wie dem Incident und dem Problem Manage- 

ment vorhanden ist. Stattdessen stehen Planungs- und Implementierungsprozesse wie das Ser- 

vice Asset und Configuration Management oder das Transition Planning und Support im Fokus. 

6.1.6. Verwendete ITIL-Version 

Abbildung 15 beschreibt die verschiedenen ITIL-Versionen, die in den befragten Unternehmen 

zum Einsatz kommen. 

0,00% 

0,00% 

0,00% 

0,00% 

0,00% 

0,00% 

0,00% 

0,00% 

5,26% 

5,26% 

5,26% 

5,26% 

10,53% 

10,53% 

10,53% 

10,53% 

10,53% 

10,53% 

10,53% 

10,53% 

10,53% 

10,53% 

15,79% 

15,79% 

15,79% 

21,05% 

21,05% 

26,32% 

31,58% 

0,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00% 35,00%


27,27% 

9,09% 4,55% 

9,09% 

Abb. 15 - Verwendete ITIL Version 

Haben Sie ihre Prozesse nach ITIL V3 ausgerichtet? 

18,18% 

31,82% 

Abbildung 15 verdeutlicht, dass die Hälfte der befragten ITIL-Nutzer ihre Prozesse vollständig 

oder zumindest teilweise nach ITIL V3 ausgerichtet haben. Rund 9 % der Befragten planen 

noch den Umstieg auf ITIL V3. Auffällig ist, dass mehr als 1 /4 der befragten ITIL-Nutzer noch 

unentschlossen sind, ob auf ITIL V3 umgestiegen werden soll. 

6.1.7. Probleme bei der Einführung des Incident Managements 

In Abbildung 16 wird der prozentuale Anteil der Umfrageteilnehmer dargestellt, die bei der 

Einführung des Incident Management Probleme hatten. 

Abb. 16 - Anteil der Befragten mit Problemen bei der Einführung des Incident Managements 

Wie aus Abbildung 16 ersichtlich wird, hatten rund 53% der Umfrageteilnehmer, die das Inci- 

dent in ihrem Unternehmen implementiert haben, Probleme bei der Einführung. 

Ja 

Ja, aber nur einen Teil unserer Prozesse 

Nein, wir arbeiten noch mit ITIL Version 2, planen aber 

den Umstieg auf ITIL Version 3 

Nein, wir arbeiten noch mit ITIL Version 2 und sind 

noch unentschlossen, ob wir auf ITIL Version 3 

umsteigen sollen 

Nein, wir arbeiten noch mit ITIL Version 2 und planen 

keinen Umstieg 

Weiß nicht / Keine Angabe 

Gab es Probleme bei der Einführung des Incident Managements? 

Nein 

47,06 % 

Ja 

52,94 %


Welche Probleme gab es bei der Einführung des Incident Managements? 

Abb. 17 - Probleme bei der Einführung des Incident Managements 

Mehr als 1 /3 der Befragten hatte Schwierigkeiten mit der fehlenden Akzeptanz der Mitarbeiter. 

Etwa 18 % der Teilnehmer fehlte die technische Unterstützung durch effektive Hilfsmittel. Ca. 

11 % der Umfrageteilnehmer hatten Probleme mit dem Overhead während der Implementie- 

rungsphase, dem fehlenden Know-How der Mitarbeiter und der länger dauernden Durchdrin- 

gung des Prozesses. 

Fehlende Akzeptanz der Mitarbeiter 

Fehlende technische Unterstützung durch effektive Hilfsmittel 

Overhead während der Implementierungsphase 

Fehlendes Know-How der Mitarbeiter 

Durchdringung des Prozesses dauert länger als geplannt 

Kommunikationsprobleme 

Unzureichende Tool-Unterstützung 

Unsaubere Abbildung von Prozessen im Tool 

Unzureichendes Training der betroffenen Mitarbeiter 

Schlechte Zeitplanung 

Mangelnde Unterstützung durch die Vorgesetzten 

Fehlende Ressourcen für Projektunterstützung 

0,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00% 35,00% 40,00% 

6.1.8. Probleme bei der Einführung des Problem Managements 

Abbildung 18 verdeutlicht den prozentualen Anteil der Umfrageteilnehmer, die das Problem 

Management in Ihrem Unternehmen etabliert haben und Probleme bei der Einführung hatten. 

Gab es Probleme bei der Einführung des Problem Managements? 

Nein 

52,94 % 

Abb. 18 - Anteil der Befragten mit Problemen bei der Einführung des Incident Managements 

5,88% 

5,88% 

5,88% 

5,88% 

5,88% 

5,88% 

5,88% 

11,76% 

11,76% 

11,76% 

Ja 

47,06 % 

17,65% 

35,29%


Ca. 47 % der Umfrageteilnehmer hatten Probleme bei der Einführung des Problem Manage- 

ments. Abbildung 19 illustriert die Probleme, die im Zuge der Einführung des Problem Mana- 

gements aufgetreten sind. 

Welche Probleme gab es bei der Einführung des Problem Managements? 

Fehlende Akzeptanz der Mitarbeiter 

Fehlende technische Unterstützung durch effektive 

Hilfsmittel 

Fehlendes Know-How der Mitarbeiter 

Ungenaue Trennung zwischen Incident und Problem 

Management 

Fehlende Projektressourcen 

Overhead während der Implementierungsphase 

Schlechte Zeitplanung 

Mangelnde Unterstützung durch die Vorgesetzten 

Abb. 19 - Probleme bei der Einführung des Problem Managements 

Fast 1 /4 der Unternehmen, die das Problem Management implementiert haben, hatten Probleme 

mit der fehlenden Akzeptanz der Mitarbeiter oder bemängelten die fehlende technische Unter- 

stützung durch effektive Hilfsmittel. Rund 18 % der Umfrageteilnehmer hatten Probleme durch 

das fehlende Know-How der Mitarbeiter. Die restlichen Probleme wie die fehlenden Projektres- 

sourcen, der Overhead während der Implementierungsphase, die mangelnde Unterstützung 

durch die Vorgesetzten, die schlechte Zeitplanung sowie die ungenaue Trennung zwischen Inci- 

dent und Problem Management, sind jeweils mit rund 6% vertreten. 

6.1.9. Einfluss von ITIL auf die Prozesse 

Abschließend wurden die Umfrageteilnehmer nach ihrer subjektiven Meinung zur Benutzer- 

freundlichkeit, Wirtschaftlichkeit und Flexibilität ihrer Prozesse befragt. Außerdem wurde die 

IT-Sicherheit und das Sourcing des Unternehmens sowie die Reaktionszeit der IT auf anfallende 

Störungen von den Befragten bewertet. Die Ergebnisse wurden in Relation zur ITIL-Nutzung 

gesetzt um den Einfluss von ITIL zu ermitteln. 

5,88% 

5,88% 

5,88% 

5,88% 

5,88% 

17,65% 

23,53% 

23,53% 

0,00% 5,00% 10,00% 15,00% 20,00% 25,00% 

Tabelle 15 verdeutlicht den Einfluss von ITIL auf die Benutzerfreundlichkeit der Prozesse.


Tab. 15 - Einfluss von ITIL auf die Benutzerfreundlichkeit der Prozesse 

ITIL-Einsatz 

Insgesamt hat die Nutzung von ITIL einen geringen negativen Einfluss auf die Benutzerfreund- 

lichkeit der Prozesse. Rund 2 /3 der befragten Unternehmen, die auf die Verwendung von ITIL 

verzichten, halten die Benutzerfreundlichkeit der eigenen Prozesse für gut. Im Gegensatz dazu 

halten 55 % der befragten ITIL-Nutzer ihre eigenen Prozesse für gut oder sehr gut. 

Die Auswirkung der Nutzung von ITIL auf die Effizienz der Prozesse wird in Tabelle 16 darge- 

stellt. 

Tab. 16 - Einfluss von ITIL auf die Effizienz der Prozesse 

ITIL-Einsatz 

Bewertung 

Benutzerfreundlichkeit der Prozesse 

Sehr gut Gut Genügend Ungenügend 

Gemäß Tabelle 16 hat der Einsatz von ITIL nur einen geringen Einfluss auf die Effizienz der 

Prozesse. 95 % der Unternehmen, die ITIL anwenden, empfinden die Effizienz der eigenen 

Prozesse als mindestens genügend. Die restlichen 5 % konnten die Effizienz der Prozesse nicht 

beurteilen. 93,33 % der Unternehmen, die ITIL nicht nutzen, befinden die eigenen Prozesse für 

wenigstens genügend. Einzige Ausnahme sind die 6,67 % der Befragten, die ITIL nicht nutzen 

und die eigenen Prozesse als ineffizient einschätzen. 

Setzt man die Meinung der Umfrageteilnehmer zur IT-Sicherheit des Unternehmens in Relation 

zur ITIL-Nutzung, so ergibt sich folgende Tabelle: 

Tab. 17 - Einfluss von ITIL auf die IT-Sicherheit im Unternehmen 

ITIL-Einsatz 

Kann ich nicht 

beurteilen 

Summe 

Ja 5 % 50 % 35 % 5 % 5 % 100 % 

Nein - 66,67 % 26,67 % 6,67 % - 100 % 

Bewertung 

Effizienz der Prozesse 



beurteilen 

Summe 

Ja 5 % 50 % 40 % - 5 % 100 % 

Nein 6,67 % 53,33 % 33,33 % 6,67 % - 100 % 

Bewertung 

IT-Sicherheit im Unternehmen 



beurteilen 

Summe 

Ja 25 % 40 % 25 % 5 % 5 % 100 % 

Nein 20 % 40 % 40 % - - 100 %


Tabelle 17 illustriert, dass der Einsatz von ITIL in den Unternehmen zu keiner wesentlichen 

Verbesserung der IT-Sicherheit geführt hat, obwohl immerhin mehr als 50 % der befragten 

ITIL-Nutzer das Information Security Management als Prozess eingeführt haben. (siehe Kapitel 

6.1.4.) 

Tabelle 18 verdeutlicht die Qualität der Prozesse in Abhängigkeit zur ITIL-Nutzung in den be- 

fragten Unternehmen. 

Tab. 18 - Einfluss von ITIL auf die Prozessqualität im Unternehmen 

ITIL-Einsatz 

Die Analyse der Kennzahlen in Tabelle 18 ergibt, dass die Nutzung von ITIL einen negativen 

Einfluss auf die Qualität der Prozesse hat. Demnach befinden zwar 80 % der ITIL-Nutzer die 

eigene Prozessqualität für gut, sehr gut oder wenigstens genügend. Aber immerhin 15 % halten 

die eigene Prozessqualität für ungenügend. Rund 93 % der Befragten, die ITIL nicht einsetzen, 

bewerten die eigene Prozessqualität mit gut oder genügend. Die restlichen rund 7 % halten die 

Prozessqualität für ungenügend. 

Der Einfluss von ITIL auf die Transparenz der Prozesse wird in Tabelle 19 dargestellt. 

Tab. 19 - Einfluss von ITIL auf die Transparenz der Prozesse 

ITIL-Einsatz 

Bewertung 

Gemäß Tabelle 19 hat ITIL einen geringen positiven Einfluss auf die Transparenz der Prozesse, 

denn 85 % der befragten ITIL-Nutzer bewerten die Transparenz mit mindestens genügend wo- 

hingegen nur 80 % der Befragten, die ITIL nicht nutzen, die Transparenz der eigenen Prozesse 

mit mindestens genügend bewerten. 

Prozessqualität im Unternehmen 



beurteilen 

Summe 

Ja 10 % 40 % 30 % 15 % 5 % 100 % 

Nein - 46,67 % 46,67 % 6,67 % - 100 % 

Bewertung 

Transparenz der Prozesse 



beurteilen 

Summe 

Ja 10 % 25 % 50 % 10 % 5 % 100 % 

Nein - 46,67 % 33,33 % 20 % - 100 % 

Tabelle 20 stellt die Wirtschaftlichkeit der Prozesse in Abhängigkeit zur ITIL-Nutzung dar.


Tab. 20 - Einfluss von ITIL auf die Wirtschaftlichkeit der Prozesse 

ITIL-Einsatz 

Tabelle 20 verdeutlicht, dass ITIL sich negativ auf die Wirtschaftlichkeit der Prozesse auswirkt. 

Etwa 30 % der befragten Unternehmen, die ITIL verwenden, befinden die Wirtschaftlichkeit der 

Prozesse als sehr gut oder gut wohingegen 46,67 % der Unternehmen, die ITIL nicht verwen- 

den, die Wirtschaftlichkeit mit gut bewerten. 

Tabelle 21 illustriert den Einfluss von ITIL auf die Qualität des Sourcing. 

Tab. 21 - Einfluss von ITIL auf die Qualität des Sourcing 

ITIL-Einsatz 

Anhand von Tabelle 21 wird deutlich, dass der Einsatz von ITIL einen positiven Einfluss auf 

das Sourcing des Unternehmens hat. Besonders auffällig ist, dass mehr als 1 /4 der befragten Un- 

ternehmen , die ITIL nicht nutzen, das Sourcing des Unternehmens nicht beurteilen können. 

Tabelle 22 verdeutlicht die Reaktionszeit der IT auf anfallende Störungen in Abhängigkeit zur 

ITIL-Nutzung: 

Tab. 22 - Einfluss von ITIL auf die Reaktionszeit der IT 

ITIL-Einsatz 

Tabelle 22 illustriert, dass die Verwendung von ITIL einen positiven Einfluss auf die Reakti- 

onszeit der IT hat. 

Bewertung 

Wirtschaftlichkeit der Prozesse 

Sehr 

gut 

Gut Genügend Ungenügend 


beurteilen 

Summe 

Ja 5% 25 % 50 % 15 % 5 % 100 % 

Nein - 46,67 % 40,00 % 13,33 % - 100 % 

Bewertung 

Das Sourcing im Unternehmen 

Sehr 

gut 



beurteilen 

Summe 

Ja 5% 35 % 55 % - 5 % 100 % 

Nein - 33,33 % 40,00 % - 26,67 % 100 % 

Die Reaktionszeit der IT auf anfallende Störungen 

Bewertung 

Sehr 

gut 



beurteilen 

Summe 

Ja 15% 70 % 10 % - 5 % 100 % 

Nein 13,33 % 60,00 % 26,67% - - 100 %


Die Strukturierung des IT-Betriebes in Relation zur Verwendung von ITIL wird in der folgen- 

den Tabelle dargestellt: 

Tab. 23 - Einfluss von ITIL auf die Stukturierung des IT-Betriebes 

ITIL-Einsatz 

Aus Tabelle 23 geht hervor, dass die Nutzung von ITIL einen positiven Einfluss auf die Struk- 

turierung des IT-Betriebes hat. Mit 65% bewerten eine Mehrzahl der Unternehmen, die ITIL in 

ihrem Unternehmen einsetzen, die Strukturierung des IT-Betriebes mit gut oder sehr gut, wo- 

hingegen nur 53,33% der Unternehmen, die für ITIL keine Verwendung haben, die Strukturie- 

rung des eigenen IT-Betriebes mit gut oder sehr gut bewerten. 

Tabelle 24 illustriert die Flexibilität der Prozesse in Relation zur ITIL-Verwendung: 

Tab. 24 - Einfluss von ITIL auf die Flexiblität der Prozesse 

ITIL-Einsatz 

Die Verwendung von ITIL hat einen negativen Einfluss auf die Flexibilität der Prozesse. Nur 

55% der befragten ITIL-Nutzer bewerten die Flexibilität ihrer Prozesse mit gut oder sehr gut, 

wohingegen 66,67 % der befragten Unternehmen, die ITIL nicht verwenden, die Flexibilität der 

eigenen Prozesse mit gut oder sogar sehr gut bewerten. 

6.1.10. Diskussion der Ergebnisse 

Die Ergebnisse der Studie zeigen, dass sich ITIL in der Hälfte der mittelständischen Unterneh- 

men und Unternehmen mittlerer Größe etabliert hat. Nichts desto trotz konnten oder wollten 

12,5 % der Umfrageteilnehmer keine Antwort darauf geben, ob ITIL in ihrem Unternehmen 

verwendet wird. Dies könnte an der Unwissenheit der Teilnehmer gelegen haben, die ITIL nicht 

kannten. 

Bewertung 

Die Strukturierung des IT-Betriebes 

Sehr 

gut 

Ja 10 % 55 % 

Nein 

Bewertung 

13,33 % 


40,00 % 

30 % 

46,67 % 

Die Flexibilität der Prozesse 


- 

- 


beurteilen 

5 % 

- 


beurteilen 

Summe 

100 % 

100 % 

Summe 

Ja 10 % 45 % 30 % 10 % 5 % 100 % 

Nein 20,00 % 46,67 % 33,33 % - - 100 %


Im Rahmen der Studie wurden auch die Ziele identifiziert, die die ITIL-Nutzer durch die Ver- 

wendung von ITIL erreichen wollen. Die häufigsten genannten Ziele sind die Verbesserung der 

Prozessqualität und die Steigerung der Effizienz. Weitere wichtige Ziele sind die Professionali- 

sierung der IT, die Erhöhung der Kundenzufriedenheit und die Transparenz der Prozesse. Es 

gibt auch Gründe die gegen die Nutzung von ITIL sprechen. Demnach sind der Aufwand, der 

mit der Einführung verbunden ist und die alternativ verwendeten Frameworks die Hauptgründe 

warum ITIL in manchen Unternehmen nicht eingeführt wurde. 

Im Zuge der Studie wurden auch die ITIL-basierten Prozesse und Funktionen identifiziert, die 

in den Unternehmen am häufigsten verwendet werden und die in Zukunft noch implementiert 

werden sollen. Primär werden mit dem Service Desk sowie dem Change, dem Problem und dem 

Incident Management, operative Prozesse und Funktionen des ITIL-Frameworks in den Unter- 

nehmen verwendet. Nachholbedarf besteht dagegen bei den Planungs- und Implementierungs- 

prozessen. Dabei sticht vor allem das Service Asset und Configuration Management heraus, das 

fast 1 /3 der befragten ITIL-Nutzer noch einführen möchte. 

Im Rahmen der Umfrage wurde auch ermittelt, welche ITIL Version in den Unternehmen zum 

Einsatz kommt. Die Umfrage hat ergeben, dass sich ITIL V3 noch nicht vollständig durchge- 

setzt hat. Zwar verwenden immerhin die Hälfte aller befragten ITIL-Nutzer ITIL V3 und weite- 

re 9% wollen ihre Prozesse nach ITIL V3 ausrichten, nichts desto trotz sehen viele Unterneh- 

men bisher noch nicht die Notwendigkeit ihre Prozesse nach der neuesten Version auszurichten. 

Im Rahmen der Untersuchung wurde auch der Einfluss von ITIL auf die Prozesse ermittelt. 

Demnach hat die ITIL-Nutzung keinen positiven Einfluss auf die Benutzerfreundlichkeit, die 

Wirtschaftlichkeit, die Flexibilität und die Effizienz der Prozesse. Positiv hat sich dagegen die 

ITIL-Nutzung auf die Transparenz der Prozesse, die Qualität des Sourcing, die Reaktionszeit 

der IT und die Strukturierung des IT-Betriebes ausgewirkt. 

Meiner Meinung nach kann ITIL einen positiven Einfluss auf die Qualität der Prozesse haben, 

solange die Prozesse nicht zu komplex gestaltet werden. Gerade mittelständische Unternehmen 

zeichnen sich durch enge Kundenbeziehungen, flache Hierarchien, kürzere Informationswege 

und eine hohe Flexibilität aus. 117 Eine Anpassung bzw. Optimierung der Prozesse ist aber mit 

der Bindung von zusätzlichem Personal verbunden, was in Einzelfällen zu zusätzlichen Perso- 

nalengpässen führen kann und sich negativ auf die Qualität der Prozesse auswirken kann. 

117 Vgl. Recklies, D.: Kleine und mittlere Unternehmen – Unternehmensgröße als Chance oder Handicap?, 

http://www.themanagement.de/Ressources/kmu.htm, 13.02.2010.


6.2. Experteninterview 

Steven Handgräntinger, Vorstandsvorsitzender des itSMF e.V. Deutschland, stellt sich für ein 

Interview zur Verfügung. Im Folgenden bekommen Sie einen Überblick über die Gründe wa- 

rum nach Meinung von Herrn Handgräntinger Unternehmen auf die Einführung von ITIL- 

basierten Standardprozessen in Unternehmen verzichten und warum diese möglicherweise doch 

eingeführt werden sollten. Darüber hinaus werden die wesentlichen Erfolgsfaktoren für eine 

erfolgreiche Umsetzung von ITIL V3 in Unternehmen etwas genauer beleuchtet und die Frage 

geklärt, ob die aktuelle Wirtschaftskrise nach Meinung von Herrn Handgräntinger einen Ein- 

fluss auf die Einführung von ITIL-basierten Prozessen in Unternehmen hat und wie er die zu- 

künftige Entwicklung von ITIL in KMU einschätzt. 

6.2.1. Ursache für den Verzicht auf ITIL-basierte Standardprozesse 

Die Einführung von ITIL-basierten Prozessen erfordert oftmals eine Einführung, die eine Bin- 

dung von internen und ggf. externen Ressourcen zur Folge hat. Darüber hinaus ist der entstan- 

dene Mehrwert, der durch Investitionen in Prozesse entsteht oftmals weniger greifbar, als der 

Mehrwert, der beispielsweise durch eine Hardwareinvestition entsteht. Ein weiterer Grund 

weswegen mittelständische Unternehmen eventuell von einer Einführung absehen ist das bisher 

nicht erkannte Potenzial von IT-Services. 118 

6.2.2. Gründe für den Einsatz von ITIL-basierten Standardprozessen 

„ITSM-Prozesse sind robuste Basisprozesse, die ein Unternehmen in die Lage versetzen, Stan- 

dardisierung und Automatisierung der IT voranzutreiben.‟ 119 Durch die Umsetzung ergeben 

sich zusätzliche Einsparpotenziale und somit ein Mehrwert für das Unternehmen. 120 

6.2.3. Erfolgsfaktoren für eine erfolgreiche Umsetzung von ITIL V3 

Die wesentlichen Erfolgsfaktoren für eine erfolgreiche Umsetzung von ITIL V3 ist nach Mei- 

nung von Herrn Handgräntinger die Konzentration auf die Service Strategie. 121 Anschließend 

gilt es zu klären, wie viel IT das Business benötigt und wie die IT den Geschäftswertbeitrag 

steigern kann. 122 Von diesem Standpunkt aus gilt es anschließend die einzelnen Basisprozesse 

zu priorisieren. 123 

118 vgl. Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009. 

119 Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009. 




123 vgl. Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.


6.2.4. Einfluss der aktuellen Wirtschaftskrise 

Gerade in wirtschaftlich schlechten Zeiten wie der aktuellen Wirtschaftskrise ermöglichen die 

standardisierten Basisprozesse die Automatisierung und Standardisierung voranzutreiben und 

Einsparpotenziale zu realisieren. Dabei ist es aber wichtig nicht nur die einzelnen IT-Kosten zu 

analysieren, sondern auch indirekten Kosten , die durch Qualität der IT beim Endanwender ent- 

steht, zu berücksichtigen. Nach Meinung von Herrn Handgräntinger wird die Wirtschaftskrise 

Unternehmen zwingen weiter zu automatisieren. 124 „Dies ist nur durch robuste Prozesse mög- 

lich.‟ 125 

6.2.5. Zukünftige Entwicklung in KMU 

Beobachtungen von Herrn Handgräntinger haben ergeben, dass immer mehr ITSM-Lösungen 

von KMU eingesetzt werden. Ca. 30 % der Mitglieder des itSMF zählt zu den KMU und auf 

dem Kongress des itSMF sind „bis zu 25 % KMU als Besucher‟. Diese Zahlen unterstreichen 

das Interesse der KMU, zeigen aber auch dass es noch ein weiter Weg ist. 126 


125 Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009. 

126 vgl. Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.

Probleme bei der Einführung 53 

7 Probleme bei der Einführung 

Gegenstand des siebten Kapitels sind die typischen Probleme, die im Rahmen der Einführung 

von Incident und Problem Management auftreten können. Im Zuge dessen werden die Proble- 

me, die im Rahmen der Umfrage ermittelt wurden genauer vorgestellt und die Fallbeispiele von 

zwei Unternehmen präsentiert, die ebenfalls Probleme bei der Prozesseinführung hatten. 

7.1. Probleme 

Im Folgenden werden zunächst die im Rahmen der Umfrage ermittelten Probleme genauer be- 

schrieben. 

7.1.1. Fehlende Akzeptanz bei den Mitarbeitern 

Ein wichtiger Erfolgsfaktor für eine erfolgreiche Implementierung von neuen Prozessen ist die 

Akzeptanz der Mitarbeiter. 127 Die Einführung von ITIL-basierten Prozessen, wie die des Inci- 

dent und des Problem Managements erfordert ein Umdenken der IT-Mitarbeiter und geht mit 

der Veränderung der gewohnten Arbeitsweise der IT-Mitarbeiter einher. Fehlende Akzeptanz 

kann dazu führen, „dass historisch gewachsene Verfahren gelebt werden‟ 128 und somit der neue 

Prozess nicht umgesetzt wird. 

7.1.2. Mangelnde Unterstützung durch das Management 

Ein häufiges Problem bei der Einführung von ITIL-basierten Prozessen ist die fehlende Unter- 

stützung durch das Management, obwohl diese ursprünglich zugesichert wurde. Der Alltag sieht 

jedoch oftmals anders aus, denn nicht jeder Mitarbeiter aus dem Management ist davon begeis- 

tert, dass zukünftig ein Prozess vorschreibt mit welcher Priorität z. B. ein Incident bearbeitet 

wird. 129 

7.1.3. Schlechte Terminplanung 

Umfangreiche Projekte wie z. B. eine Prozesseinführung benötigen eine Terminplanung die 

definiert, zu welchem Zeitpunkt welche Aktivität durchgeführt werden muss. Eine schlechte 

Terminplanung kann dazu führen, dass die notwendigen Ressourcen nicht zur Verfügung stehen 

und es zu unnötigen Verzögerungen bei der Prozesseinführung kommt. 

127 Vgl. Schmidt, R.; Dohle , H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 85. 

128 Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.63. 

129 Vgl. Schmidt, R.; Dohle , H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 85.


7.1.4. Fehlendes Know-How der IT-Mitarbeiter 

Für eine effektive Umsetzung eines Prozesses ist es wichtig, dass die Mitarbeiter über das not- 

wendige Know-How verfügen, um die einzelnen Aktivitäten bewerkstelligen zu können. Wenn 

die Mitarbeiter nicht über das notwendige Fachwissen verfügen, kann dies dazu führen, dass 

die Aktivitäten falsch oder gar nicht umgesetzt werden. 

7.1.5. Fehlende technische Unterstützung durch effektive Hilfsmittel 

Die Arbeitsabläufe in Prozessen werden oftmals durch den Einsatz von effektiven Hilfsmitteln 

(Tools) unterstützt und auch vereinfacht. ITIL empfiehlt beispielsweise für das Problem Mana- 

gement eine Known-Error Datenbank zu implementieren, um die Informationen über die Symp- 

tome, Workarounds und Lösungsmaßnahmen zu speichern, die beim abermaligen Auftreten des 

Fehlers aufgerufen und genutzt werden können 130 . Wenn aber genau diese Hilfsmittel fehlen, 

dann können die Prozesse nicht effektiv umgesetzt werden. 

7.1.6. Unzureichende Tool-Unterstützung 

Wie bereits in Kapitel 7.1.5 erklärt wurde, ist der Einsatz von effektiven Hilfsmitteln ein wich- 

tiger Erfolgsfaktor für die erfolgreiche Umsetzung des Prozesses. Wenn diese Tools nicht über 

die erforderliche Funktionalität verfügen, können sie somit nicht zum Erfolg des Projektes bei- 

tragen. 

7.1.7. Overhead während der Implementierungsphase 

Die Einführung von Prozessen kann ein umfangreiches Unterfangen sein, das eine Menge Per- 

sonal in Anspruch nimmt. Gerade in der Implementierungsphase werden viele Mitarbeiter benö- 

tigt, die die notwendigen Schritte für die Implementierung umsetzen. Wenn dieses Personal 

nicht extern beschafft wird, sondern aus dem eigenen Unternehmen kommt, kann dieses nur 

eingeschränkt oder gar nicht den täglichen Aufgaben nachgehen. Oftmals wird gerade aber ge- 

nau dies von den Mitarbeitern verlangt. Sie müssen ihrer täglichen Arbeit nachgehen und 

gleichzeitig bei der Implementierung der Prozesse helfen. Dies bedeutet zusätzliche Arbeit und 

in der Regel auch Overhead für die betroffenen Mitarbeiter. 131 

7.1.8. Ungenaue Trennung zwischen Incident und Problem Management 

Das Incident und das Problem Management sind zwei unterschiedliche Prozesse mit konkurrie- 

renden Zielen. Das Ziel des Incident Managements ist die schnellstmögliche Behebung von 

anfallenden Incidents. Das Ziel des Problem Managements ist die Senkung der Störungsanfäl- 

ligkeit und die nachhaltige Erhöhung der Servicequalität. Eine schnellstmögliche Behebung 


131 Vgl. Ellermann, H.: Münchener Rück: >> ITIL ist einfach


eines anfallenden Incident ist aber nicht möglich, wenn zunächst eine umfassende Analyse 

durchgeführt werden muss, um die mögliche Ursache für den Incident zu identifizieren. Eine 

ungenaue Trennung zwischen den beiden Prozessen hätte zur Folge, dass die Prozesse eventuell 

nicht optimal umgesetzt und somit die Ziele des Prozesses nicht erreicht werden. 

7.1.9. Durchdringung des Prozesses dauert länger als geplant 

Ein weiteres Problem kann entstehen, wenn die Durchdringung von Prozessen länger als geplant 

dauert. Auf diese Weise werden die Prozesse nicht effektiv umgesetzt mit der Folge, dass die 

eigentlichen Vorteile der Prozesse nicht genutzt werden. 

7.1.10. Kommunikationsprobleme 

Die Kommunikation ist ein wichtiger Erfolgsfaktor für die erfolgreiche Umsetzung des Projek- 

tes. Ohne eine gut funktionierende Kommunikation zwischen den Projektbeteiligten ist es mög- 

lich, dass Missverständnisse entstehen, die letztendlich zu Fehlleistungen führen und oftmals 

mit hohem Aufwand wieder behoben werden müssen. 

7.1.11. Unsaubere Abbildung von Prozessen im Tool 

Die unsaubere Abbildung von Prozessen im Tool kann dazu führen, dass die Prozesse nicht wie 

ursprünglich geplant umgesetzt werden und Fehlleistungen entstehen, da bestimmte Faktoren 

nicht berücksichtigt werden. 

7.1.12. Unzureichendes Training der betroffenen IT-Mitarbeiter 

Die Schulung der IT-Mitarbeiter ist ein wichtiger Erfolgsfaktor für eine effektive Umsetzung 

der Prozesse. Wenn die IT-Mitarbeiter aber nur unzureichend bzw. gar nicht geschult werden, 

kann dies zur Folge haben, dass den Mitarbeitern das notwendige Fachwissen für die Umset- 

zung der Prozesse fehlt und diese nicht oder nur unzureichend umgesetzt werden können. 

7.1.13. Fehlende Ressourcen für Projektunterstützung 

Der Erfolg eines Projektes hängt maßgeblich von der Bereitstellung der notwendigen Ressour- 

cen ab. Wenn die erforderlichen Ressourcen, wie z. B. die Mitarbeiter nicht zur Verfügung ste- 

hen, kann das Projekt auch nicht erfolgreich umgesetzt werden. Folglich sind fehlende Ressour- 

cen ein großes Problem während der Prozesseinführung des Incident und Problem Manage- 

ments. 

7.1.14. Falsche Priorisierung von Incidents 

Eine wichtige Aufgabe der Mitarbeiter des Service Desk ist die Priorisierung von Incidents. 

Eine falsche Einschätzung der Service Desk Mitarbeiter kann beispielsweise dazu führen, dass 

zunächst weniger wichtige Incidents bearbeitet werden.


7.2. Fallbeispiele 

Nachfolgend werden mit der Hessischen Zentrale für Datenverarbeitung und einem Telekom- 

munikationsunternehmen zwei Fallbeispiele vorgestellt, die das Incident oder das Problem Ma- 

nagement in Ihrem Unternehmen eingeführt haben und Probleme bei der Einführung hatten. 

7.2.1. Hessische Zentrale für Datenverarbeitung (HZD) 

Die Hessische Zentrale für Datenverarbeitung, kurz HZD, ist IT-Dienstleister für die hessische 

Landesverwaltung mit Standorten in Wiesbaden und Hünfeld. 132 Insgesamt sind bei der HZD 

rund 750 Mitarbeiter beschäftigt, die im Jahr 2008 einen Umsatz von 177 Mio. € erwirtschafte- 

ten. 133 Im Jahr 2003 wurde mit der Einführung von IT-Servicemanagement in der HZD gestar- 

tet, in dessen Rahmen das Change Management als erster Prozess implementiert wurde. 134 An- 

schließend wurde das bis dahin umgesetzte Störungsmanagement, welches vergleichbar mit 

dem Incident Management ist, neu designt und an ITIL angelehnt. 135 

Im Laufe der Einführung der ITIL-Prozesse hatten die Projektmitarbeiter mit einem prozess- 

übergreifenden Problem zu kämpfen. Durch das Mitbestimmungsrecht der Personalvertretung 

bei der Einführung von Prozessen musste zunächst Überzeugungsarbeit geleistet werden , um 

überhaupt die Prozesse einführen zu dürfen. 136 

7.2.2. Führender deutscher DSL-Netzbetreiber für den Massenmarkt 

Die Unternehmensberatungsgesellschaft Putz&Partner wurde von dem führenden deutschen 

DSL-Netzbetreiber mit einem Projekt beauftragt, dass das Ziel hatte „zwischen dem Incident 

und dem Problem Management effektive Strukturen und Prozesse zu schaffen und zu etablieren, 

um die Kundenzufriedenheit zu erhöhen.‟ 137 

Bereits vor dem eigentlichen Projektstart hatten die Projektbeteiligten mit einem Problem zu 

kämpfen, der Skepsis der Mitarbeiter. 138 Durch zahlreiche zuvor gescheiterte Projekte, die alle 

das Ziel hatten, die beiden Bereiche in einen End-to-End-Prozess zu verbinden, war die Skepsis 

132 

Vgl. Sachs, F.: Hessische Zentrale für Datenverarbeitung, www.hzd.de, 23.03.2010. 

133 

Alberts, S.: HZD ITSM-Fachforum 30.09.09, http://www.itsm-consulting.de/files/HZD%20ITSM- 

Fachforum%2030.09.09.pdf, 22.03.2010. 

134 

Alberts, S.: HZD ITSM-Fachforum 30.09.09, http://www.itsm-consulting.de/files/HZD%20ITSM- 

Fachforum%2030.09.09.pdf, 22.03.2010. 

135 

Vgl. itSMF e.V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S. 221. 

136 

Vgl. Alberts, S.: Subject: AW: Frage wegen der Einführung von ITIL-Prozessen bei der HZD, susanne.alberts@hzd.hessen.de 

, 23.03.2010. 

137 

Nickelsen, J.: Putz & Partner Unternehmensberatung AG: Incident und Problem Management, 

http://www.putzundpartner.de/fallstudien/telekommunikation/incident-und-problem-management.html, 26.03.2010. 

138 

vgl. Nickelsen, J.: Putz & Partner Unternehmensberatung AG: Incident und Problem Management, 

http://www.putzundpartner.de/fallstudien/telekommunikation/incident-und-problem-management.html, 26.03.2010.


bei den Mitarbeitern groß. Aus diesem Grund musste die vorherrschende Skepsis der Mitarbei- 

ter in Bezug auf dieses neuerliche Projekt zunächst überwunden werden. 139 

139 vgl. Nickelsen, J.: Putz & Partner Unternehmensberatung AG: Incident und Problem Management, 

http://www.putzundpartner.de/fallstudien/telekommunikation/incident-und-problem-management.html, 26.03.2010.

Vorgehensmodell 58 

8 Vorgehensmodell 

Ein Vorgehensmodell ist ein als Modell abgebildeter Prozess, welcher ein Problem lösen soll. 140 

Vorgehensmodelle tragen zur strukturierten Vorgehensweise bei und ermöglichen auf diese 

Weise ein abgestimmtes und optimiertes Vorgehen der Beteiligten. 141 In der Regel werden Vor- 

gehensmodelle als Projekt organisiert, können aber u. U. auch als Organisationsform umgesetzt 

werden. 142 

Im Zusammenhang mit IT-Projekten, wie dieser Bachelorarbeit, sind Vorgehensmodelle die 

Präzisierung eines Phasenmodells durch die Beschreibung der auszuführenden Tätigkeiten und 

dessen Ergebnisse. In diesem Kapitel wird ein Vorgehensmodell vorgestellt, welches basierend 

auf den in Kapitel 7 genannten Problemen ein reibungsloses Vorgehen für die Einführung von 

Incident und Problem Management ermöglichen soll. 

Das Incident und Problem Management sind zwei unterschiedliche Prozesse. In der Praxis ge- 

hören das Incident und Problem Management aber unmittelbar zusammen. Aus diesem Grund 

erfolgt ihre Einführung idealerweise zeitgleich. Diese Notwendigkeit resultiert aus der Tatsache, 

dass beim häufigen Auftreten gleichartiger Incidents in der Regel ein Problem die Ursache ist. 

Um dieses Problem aus der Welt zu schaffen ist das Problem Management gefordert dem nach- 

zugehen und mit Hilfe von eigenen Prozessabläufen das identifizierte Problem zu analysieren 

und letztendlich zu beheben. Aus diesem Grund macht eine zeitlich versetzte Einführung des 

Incident und Problem Managements keinen Sinn und sollte stattdessen zeitgleich erfolgen. 143 

Die Einführung von ITIL-basierten Prozessen ist ein umfangreiches Unterfangen. Aus diesem 

Grund sollte die Einführung von ITIL-basierten Prozessen in Form eines Projektes erfolgen, um 

den oftmals sehr weitreichenden Änderungen und dem Einfluss auf die Organisation gerecht zu 

werden. 144 

Um den iterativen Charakter der Projektdurchführung widerzuspiegeln ist das Vorgehensmodell 

in insgesamt sieben Phasen aufgeteilt. Jede einzelne Phase ist in einzelne Teilaufgaben geglie- 

dert, die für die Zielerreichung der jeweiligen Phase umgesetzt werden sollten. 

140 Vgl. Heinrich, L. J.; Stelzer, D.: Informationsmanagement, 9. Auflage, München 2009, S. 404. 

141 Vgl. Steinweg, C.: Projektkompass Softwareentwicklung, 4. Auflage, Braunschweig/Wiesbaden 2002, S.2. 

142 Vgl. Heinrich, L. J.; Stelzer, D.: Informationsmanagement, 9. Auflage, München 2009, S. 404. 

143 Vgl. Lienemann, G.: ITIL - Change Management, 1. Auflage, Hannover 2006, S. 46. 

144 Vgl. Kittel, M.; Koerting, T. J.; Schött, D.: Kompendium für ITIL V3 Projekte, 2. Auflage, Norderstedt 2009, 

S. 175.


Abb. 20 - Vorgehensmodell


8.1. Initialisierung 

Die erste Phase des Vorgehensmodells ist die Initialisierungs-Phase. In dieser Phase werden die 

notwendigen Vorbereitungsmaßnahmen für die erfolgreiche Einführung des Incident und Prob- 

lem Managements durchgeführt. Die Vorbereitungsmaßnahmen sind oftmals zeitaufwendig. 

Aus diesem Grund sollte unbedingt ausreichend Zeit für die Umsetzung der Vorbereitungsmaß- 

nahmen eingeplant werden. 

Die wichtigsten Aktivitäten in dieser Phase sind: 

� Name des Projektes festlegen 

� Auswahl der Projektbeteiligten 

� Kick-off Veranstaltung durchführen 

� Schulung der Projektteilnehmer 

� Grobe Terminplanung durchführen 

� Einbinden des Betriebs- bzw. Personalrats 

8.1.1. Name des Projektes festlegen 

Der erste Schritt der Initialisierungs-Phase ist die Festlegung des Projektnamens. Dieser ist ein 

Marketinginstrument um das Projekt und die damit verbundenen Änderungen unternehmensin- 

tern bekannt zu machen. Gleichzeitig kann der Projektname ein wichtiger Erfolgsfaktor für die 

Akzeptanz des Projektes sein. Um dies zu erreichen muss der Projektname jedoch überlegt aus- 

gewählt werden. Bei der Wahl des Projektnamen sollte darauf geachtet werden, dass der Name 

des Projektes inspirierend, einprägsam und aussagekräftig ist. 145 

8.1.2. Auswahl der Projektbeteiligten 

Der nächste Schritt ist die Auswahl der Projektmitglieder. Die Auswahl der Projektmitglieder ist 

ein wichtiger Erfolgsfaktor für die erfolgreiche Umsetzung des Projektes, denn nur wenn die 

Mitarbeiter über das notwendige Know-How und genügend Zeit verfügen, können sie auch zum 

Erfolg des Projektes beitragen. Folglich ist es unabdingbar, dass eine adäquate Besetzung des 

Projektteams für die Umsetzung des Projektes gewählt wird. Im Zuge dessen sollten bereits im 

Vorfeld des Projektes die verschiedenen Rollen der Projektmitglieder besetzt werden. 146 Die 

wichtigsten Rollen 147 sind: 

� Auftraggeber 

� Projektleiter 148 

� Lenkungsausschuss 149 




148 Der Projektleiter trägt die Verantwortung für die Steuerung des Projektes.


� Projektteam 150 

8.1.3. Kick-off Veranstaltung durchführen 

Nach der Auswahl der Projektbeteiligten sollte eine Kick-off Veranstaltung stattfinden. Inner- 

halb dieser Veranstaltung haben die Projektbeteiligten die Möglichkeit sich gegenseitig kennen- 

zulernen. Aus diesem Grund sollten alle Projektbeteiligten an dieser Veranstaltung teilnehmen. 

Die Veranstaltung dient aber nicht nur dem Kennenlernen der einzelnen Projektbeteiligten, son- 

dern es werden auch wichtige Themen wie die Projektziele, die Rollen der Projektbeteiligten, 

die generelle Vorgehensweise im Projekt sowie die Auswirkungen des Projektes vorgestellt. 151 

8.1.4. Schulung der Projektmitglieder 

Im nächsten Schritt der Initialisierungs-Phase sollten die Mitglieder des Projektes über die 

Grundlagen, Anwendungsmöglichkeiten, Chancen, aber auch die Risiken von ITIL informiert 

werden. An dieser Stelle bietet sich die Durchführung von ITIL-Schulungen an, mit deren Hilfe 

die beteiligten Projektmitglieder entsprechend geschult werden können. 152 Im Zuge dieser Schu- 

lung ist es ratsam den Schulungsteilnehmern die wichtigsten Begriffe des IT-Service Manage- 

ment zu vermitteln um auf diese Weise für einen einheitlichen Sprachgebrauch zu sorgen. Da- 

rüber hinaus gibt es die Möglichkeit, dass die Projektteilnehmer an einer ITIL®-Foundation- 

Schulung teilnehmen können. 153 Im Rahmen der ITIL®-Foundation-Schulung gibt es die Mög- 

lichkeit die Teilnehmer gezielt in dem Prozess zu schulen, in dem sie zukünftig eine Rolle ein- 

nehmen sollen. 154 

Wie in Kapitel 7.1.1. beschrieben haben Mitarbeiter oftmals Angst vor Veränderungen. Dies ist 

insofern nicht verwunderlich, als dass die Veränderungen der bisherigen Prozesse einen direkten 

Eingriff in die bisherige Arbeitsweise der betroffenen Mitarbeiter darstellen. Genau diese Angst 

kann den Projektmitarbeitern im Zuge der ITIL-Schulung genommen werden. Um dies zu errei- 

chen müssen die Projektmitarbeiter über die geplanten Änderungen sowie die möglichen Risi- 

ken des Projektes informiert und auf die Relevanz für das Unternehmen hingewiesen werden. 

Es ist nicht ausreichend die IT-Mitarbeiter anzuweisen einen Prozess umzusetzen. Stattdessen 

ist es wesentlich sinnvoller mit Hilfe einer einleuchtenden Argumentation die IT-Mitarbeiter 

von der Bedeutung des Prozesses zu überzeugen. 

149 Der Lenkungsausschuss setzt sich aus dem Projektleiter, dem Auftraggeber des Projektes und bei Bedarf auch 

internen oder externen Berater zusammen. 

150 Das Projektteam setzt sich aus den Mitarbeitern des Projektes zusammen, die sich um die Umsetzung der Aktivitä- 

ten des Projektes kümmern. 

151 Vgl. Kittel, M.; Koerting, T. J.; Schött, D.: Kompendium für ITIL V3 Projekte, 2. Auflage, Norderstedt 2009, S. 

182. 

152 Vgl. itSMF e. V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S.131. 



232.


Für die Durchführung der Schulung bietet es sich an auf das Wissen eines externen Beraters 

zurückzugreifen. Der Einsatz eines Beraters bietet in der Regel den Vorteil, dass dieser sowohl 

über das Know-How, als auch die notwendige Erfahrung für die Durchführung der Schulung 

verfügt. Inhaltlich sollten im Rahmen der ITIL-Schulung die wesentlichen Aspekte 155 des Inci- 

dent und des Problem Managements vorgestellt werden: 

� Ziele des Incident und des Problem Managements 

� Input, Aktivitäten und Output der Prozesse 

� Incident-Management-Owner, Problem-Management-Owner 

� KPIs für das Incident und das Problem Management 

8.1.5. Grobe Terminplanung 

Bereits in der Initialisierungs-Phase sollte eine grobe Terminplanung erfolgen, um den Zeitrah- 

men des Projektes grob abstecken zu können. 156 Die Termine sollten nur grob geplant werden, 

da zu diesem Zeitpunkt noch keine detaillierte Planung mit allen umzusetzenden Aktivitäten 

vorhanden ist. Eine beliebte Vorgehensweise um die Zieltermine des Projektes grob abschätzen 

zu können ist die Nutzung von Erfahrungswerten. Diese Variante bietet sich gerade dann an, 

wenn erfahrene externe Berater an der Umsetzung des Projektes mitwirken. 

8.1.6. Einbinden des Betriebs- bzw. Personalrats in den Planungsprozess 

Betriebs- bzw. Personalräte haben oftmals in Unternehmen bzw. Behörden einen großen Ein- 

fluss. Wie in Kapitel 7.2.1. beschrieben, kann dies mitunter dazu führen , dass die Umsetzung 

von Projekten verhindert bzw. verzögert wird. Um dies zu verhindern sollte der Betriebs- bzw. 

Personalrat, sofern dieser vorhanden ist, frühzeitig in die Planung mit eingebunden werden. 157 

Dadurch wird sichergestellt, dass sich das Projekt nicht unnötig verzögert. 158 Um die Mitarbei- 

tervertreter von der besonderen Relevanz des Projektes zu überzeugen ist es oftmals sinnvoll, 

dass der Betriebs- bzw. Personalrat durch die Unternehmensführung über die Einführung der 

Prozesse informiert wird. Auf diese Weise wird die besondere Bedeutung der Prozesse noch- 

mals hervorgehoben. 

Im Zuge der Einführung von ITIL-basierten Prozessen werden in der Regel KPIs zur Überwa- 

chung der Prozessqualität festgelegt. Häufig wird genau diese Maßnahme mit der Überwachung 

der IT-Mitarbeiter gleichgesetzt. Deshalb ist es besonders wichtig, dass dem Betriebs- bzw. 



157 Vgl. Buchsein, R.: IT-Management mit ITIV V3, 1. Auflage, Wiesbaden 2007, S. 227. 

158 Vogel, M.: Mitbestimmung bei IT-Systemen: Achtung: Betriebsrat!, 

http://www.cio.de/karriere/805409/index2.html, Abruf am 02.05.2010.


Personalrat verdeutlicht wird, dass es bei Festlegung der KPIs um die Verbesserung der Ser- 

vicequalität geht und nicht um die Überwachung der IT-Mitarbeiter. 159 

Oftmals sind die Betriebs- bzw. Personalräte besonders kritisch, wenn sie in der Vergangenheit 

mit ähnlich gearteten Projekten schlechte Erfahrungen gemacht haben. Aus diesem Grund ist 

ein schrittweiser Vertrauensaufbau ein wichtiges Kriterium um die Betriebsräte von der Pro- 

zesseinführung zu überzeugen. In der Regel können besonders kritische Betriebs- bzw. Perso- 

nalräte durch das frühzeitige Einbinden in das Projekt und eine offene Kommunikation besser 

überzeugt werden. 160 Darüber hinaus besteht die Möglichkeit, dass die Festlegung der erhobe- 

nen Kennzahlen in Absprache mit dem Betriebs- bzw. Personalrat erfolgt. 161 Auf diese Weise 

wird sichergestellt, dass der Betriebs- bzw. Personalrat zufriedengestellt wird und der Einfüh- 

rung der Prozesse zustimmt. 

8.2. Zieldefinition 

Die zweite Phase des Vorgehensmodells beschäftigt sich mit der Zieldefinition des Projektes. 

Ein wichtiger Schritt für die erfolgreiche Durchführung des Projektes ist die Festlegung von 

messbaren Zielen, auf die die Projektmitglieder hinarbeiten können. Im Zuge dessen sollte die 

folgenden Aktivitäten durchgeführt werden: 

� Zielworkshop veranstalten 

� Ziele dokumentieren 

� Ziele genehmigen lassen 

8.2.1. Zielworkshop veranstalten 

Für die Festlegung der Ziele bietet es sich an einen Zielworkshop zu veranstalten, in dem die 

Ziele des Projektes definiert werden. 162 Bei der Wahl der Teilnehmer des Workshops sollte da- 

rauf geachtet werden, dass repräsentative Vertreter ausgewählt werden, die die Interessen der 

jeweiligen Interessengruppe vertreten. Insbesondere sollte unbedingt der Auftraggeber des Pro- 

jektes an dem Zielworkshop teilnehmen. 

Im Zuge des Zielworkshops sollte zunächst ein Brainstorming veranstaltet werden. Das Brain- 

storming ist eine Kreativitätstechnik mit dessen Hilfe die Teilnehmer des Zielworkshops ihre 

Erwartungen an das Incident und das Problem Management äußern und beispielsweise auf einer 

159 itSMF e. V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S.138. 

160 Vgl. Zielke, F.; Schinkel, A.-W.; Oldag, J.; Weber, G.: ITIL überzeugend einführen , 1. Auflage, Düsseldorf 

2010,S.62 f. 

161 Vgl. Buchsein, R.: IT-Management mit ITIV V3, 1. Auflage, Wiesbaden 2007, S. 228. 



Metaplanwand sammeln können. Bei der Zielformulierung ist darauf zu achten, dass das festge- 

legte Ziel SMART ist. In diesem Kontext steht SMART 163 für: 

� Spezifisch 

� Messbar 

� Akzeptiert 

� Realistisch 

� Terminierbar 

Anschließend sollten die gesammelten Ziele sinnvoll geordnet und gegebenenfalls zusammen- 

gefasst werden. 164 Die verschiedenen Ziele haben zum Teil unterschiedliche Bedeutungen. Aus 

diesem Grund sollte als nächster Schritt eine Gewichtung und Priorisierung der Ziele erfolgen. 

8.2.2. Ziele dokumentieren 

Nach der Gewichtung und Priorisierung der Ziele sollte das Ergebnis des Zielworkshops in ei- 

nem Zielkatalog dokumentiert werden. 165 Dieser Zielkatalog dient als Grundlage für die spätere 

Identifikation der Handlungsfelder und der Ableitung der Handlungsempfehlungen. 

8.2.3. Genehmigung der Ziele 

Nach der Dokumentation der Ziele muss der fertige Zielkatalog dem Auftraggeber vorgelegt 

und die definierten Ziele genehmigt werden. Die Genehmigung wird natürlich vereinfacht, 

wenn der Auftraggeber wie in Kapitel 8.2.1 empfohlen am Zielworkshop teilnimmt und bereits 

während des Zielworkshops seine Bedenken hinsichtlich bestimmter Ziele äußern kann. 

8.3. Analyse 

In der nächsten Phase, der sogenannten Analyse-Phase wird in erster Linie der aktuelle Zustand 

der IT ermittelt. Die wichtigsten Aktivitäten in der Analyse-Phase sind: 

� Ist-Analyse durchführen 

� Erste Auswertung der Ergebnisse und Rückfrage mit den Befragten 

� Handlungsfelder identifizieren und Handlungsempfehlungen ableiten 

� Anpassen der Terminplanung 

� Informationsveranstaltung für die IT-Mitarbeiter durchführen 

8.3.1. Ist-Analyse durchführen 

Der nächste Schritt der Analyse-Phase ist die Durchführung einer Ist-Analyse. Das Ziel der Ist- 

Analyse ist die Identifikation der bereits bestehenden Prozesse und Verfahren. 166 Um dies zu 

163 itSMF e. V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S.114. 

164 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 284 f. 

165 vgl. itSMF e. V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S.118.


erreichen sollten die bereits existierenden Prozessbeschreibungen, Tooldokumentationen, Ar- 

beitsanweisungen und Schnittstellenbeschreibungen gesichtet werden. 167 

Oftmals ist die Sichtung der vorhandenen Dokumentation alleine nicht ausreichend, da diese 

keine Schlüsse darauf zulässt, ob die auf dem Papier beschriebenen Prozesse auch in der Praxis 

umgesetzt werden. 168 Aus diesem Grund ist es ratsam die betroffenen Mitarbeiter direkt zu be- 

fragen. Abhängig von der Anzahl der IT-Mitarbeiter kann dies ein umfangreiches Unterfangen 

werden. Deshalb muss im Einzelfall entschieden werden, ob die Befragung der Mitarbeiter in 

Form von Einzelinterviews oder Gruppeninterviews stattfinden sollte. 169 

6-W-Methode 

Für die Interviews bietet sich die Nutzung der 6-W-Methode an. Bei dieser Methode werden 

den Befragten sechs Basisfragen 170 gestellt: 

� Wer - Die Frage nach dem „Wer‟ klärt welche Person für den Prozess verantwortlich 

ist und die Aufgaben des Prozesses umsetzt. Darüber hinaus sollte im Zuge dessen ge- 

fragt werden, welche Person alternativ die Aufgaben übernehmen könnte. 

� Was - Die Frage nach dem „Was‟ dient der Identifikation der Aktivitäten des Prozes- 

ses. Das Ergebnis dieser Frage sollte in einem Aktivitätsdiagramm illustriert werden. 171 

� Wo - Mit der Frage nach dem „Wo‟ fliest der räumliche Aspekt in die Betrachtung mit 

ein. 

� Wann - Die Frage nach dem „Wann‟ berücksichtigt den zeitlichen Aspekt der Pro- 

zessbetrachtung und hinterfragt z. B. Reaktionszeiten auf Störungsmeldungen. 

� Warum - Nach der Frage nach dem Wann sollte mit der Frage nach dem „Warum‟ der 

Grund für den Einsatz der Prozessbeteiligten geklärt werden. 

� Wie - Nachdem geklärt ist, warum die Prozessbeteiligten tätig werden, ist zu klären wie 

die Prozessbeteiligten vorgehen. Im Rahmen dessen ist zu prüfen wie die eingesetzten 

Tools genutzt und konfiguriert werden. 

SWOT-Analyse 

Nach der Durchführung des Interviews ist es sinnvoll die Ergebnisse mit Hilfe der SWOT- 

Analyse zu analysieren. SWOT 172 steht für: 

� Strengths (Stärken) 


167 Vgl. itSMF e.V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S. 90. 



170 Vgl. itSMF e.V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S. 98 f. 

171 Vgl. itSMF e.V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S. 98. 



� Weaknesses (Schwächen) 

� Opportunites (Chancen) 

� Threats (Gefahren) 

Die SWOT-Analyse ist ein geeignetes Hilfsmittel für die Aufarbeitung der Analyseergebnisse 

und ermöglicht eine transparente Gegenüberstellung der Analyseergebnisse nach Stärken und 

Schwächen sowie nach Chancen und Bedrohungen. Für die Analyse der Ergebnisse des IST- 

Zustandes ist es sinnvoll die SWOT-Analyse in zwei unterschiedliche Ebenen einzuteilen. Die 

erste Ebene berücksichtigt die Stärken und Schwächen der vorhandenen Prozesse, die zweite 

Ebene wird genutzt um die Chancen und Risiken der IT-Organisation zu beurteilen. 173 Für die 

Darstellung der Ergebnisse eignet sich besonders die Verwendung einer SWOT-Matrix, wie sie 

beispielhaft in Abbildung 20 dargestellt wird. 

Abb. 21 - Beispielhafte Darstellung einer SWOT-Matrix 

8.3.2. Erste Auswertung der Ergebnisse und Rückfrage 

Nach der Durchführung der SWOT-Analyse sollte nochmals eine Rücksprache mit den Umfra- 

geteilnehmern erfolgen. Im Zuge dessen sollten die ersten Ergebnisse mit den Befragten kon- 

struktiv diskutiert und anschließend verifiziert werden. Um eine Beschönigung der tatsächlichen 

Situation zu vermeiden, sollten gerade zu diesem Zeitpunkt kritische Stimmen besonders sorg- 

sam berücksichtigt werden. 174 

8.3.3. Handlungsfelder identifizieren und Handlungsempfehlungen ableiten 

Auf Basis der Ergebnisse der SWOT-Analyse und den festgelegten Zielen müssen als nächstes 

die Handlungsfelder identifiziert und die notwendigen Handlungsempfehlungen für die Imple- 



189. 

Stärken 

Service Desk ist eingerichtet. 

Tickettool ist eingerichtet. 

Chancen 

Die Mitarbeiter sind motiviert und bereit 

das bisherige Vorgehen zu verändern. 

Ein Teil der IT-Mitarbeiter haben bereits 

Erfahrungen mit ITIL gemacht. 

Die Anwender sind an einem verbesserten 

IT-Service interessiert. 

Schwächen 

Die Schnittstellen zu anderen 

Fachbereichen sind unbekannt. 

Das Tickettool wird nicht immer verwendet. 

Risiken 

Es gibt keine Verfahren für Major Incidents. 

Es gibt keine Task Force. 

Die Anwender sind wegen den häufigen 

Verzögerungen bei der Störungsbehebung 

verärgert.


mentierung des Incident und des Problem Managements abgeleitet werden. 175 Um die Nachvoll- 

ziehbarkeit der Handlungsempfehlungen zu gewährleisten sollten die Handlungsempfehlungen 

in einem Maßnahmenkatalog dokumentiert werden. 176 Im Zuge dessen sollten die Aktivität, das 

Ziel, das erwartete Ergebnis, der Aufwand und gegebenenfalls Voraussetzungen dokumentiert 

werden. 177 

8.3.4. Anpassen der Terminplanung 

Nach der Erstellung des Maßnahmenkatalogs sind alle für den Projekterfolg notwendigen Akti- 

vitäten bekannt. Aus diesem Grund kann als nächster Schritt die zuvor durchgeführte Grobpla- 

nung der Termine angepasst und detailliert werden. Im Zuge dessen müssen die Termine kon- 

kretisiert, die Aktivitäten beschrieben und die Verantwortlichen für die einzelnen Aktivitäten 

festgelegt und informiert werden. 178 

8.3.5. Informationsveranstaltung für die IT-Mitarbeiter 

Am Ende der Analyse-Phase sollte der Lenkungsausschuss im Rahmen einer Informationsver- 

anstaltung die IT-Mitarbeiter über das Projekt informieren. Im Rahmen dessen sollten die IT- 

Mitarbeiter über die Projektbeteiligten, die Projektplanung, die Inhalte und die Konsequenzen 

des Projektes informiert werden und auf die anstehenden ITIL-Schulungen aufmerksam ge- 

macht werden. 179 Bei der Durchführung der Informationsveranstaltung ist es sinnvoll das Mana- 

gement in die Veranstaltung einzubinden, um die Bedeutung des Projektes hervorzuheben und 

die IT-Mitarbeiter auf diese Weise von der Relevanz der Projektes zu überzeugen. Dies kann 

sich positiv auf die Akzeptanz der Mitarbeiter auswirken. (siehe Kapitel 7.1.1.) 

8.4. Design 

In der Design-Phase wird das Vorgehen für die Implementierung festgelegt. Grundlage für die 

Gestaltung des Incident und des Problem Managements sind die Ergebnisse der Analyse-Phase. 

Die wichtigsten Aktivitäten in der Design-Phase sind: 

� Durchführung eines Prozess-Workshops 

o Prozesse definieren 

o Schnittstellen festlegen 

o KPIs festlegen 

o Definition der Rollen 


176 Vgl. itSMF e. V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S.134. 




196.


o Kriterien für die Toolauswahl ableiten 

o Dokumentation der Ergebnisse 

� Toolauswahl durchführen 

� Prozessschulung durchführen 

8.4.1. Prozess-Workshop 

Nachdem die Ausgangssituation, die Ziele und die Maßnahmen für die Umsetzung geklärt sind 

müssen als nächstes die neuen Prozesse entwickelt und an die Anforderungen des Unterneh- 

mens angepasst werden. Um das Incident und Problem Management zu gestalten ist es sinnvoll 

einen Prozess-Workshop zu veranstalten, in dessen Rahmen die Prozesse an die individuellen 

Bedürfnisse des Unternehmens angepasst und neu gestaltet werden. Die Hauptaufgabe der 

Workshop-Teilnehmer ist die Gestaltung des Incident und des Problem Managements sowie die 

Definition der Schnittstellen, der KPIs, der Rollen und die Ableitung der Kriterien für die Tool- 

auswahl. Eine weitere wichtige Aufgabe ist die Dokumentation der Ergebnisse. 180 

Im Vorfeld sollte aber zunächst geklärt werden, ob das Incident und das Problem Management 

in zwei einzelnen Prozess-Workshops gestaltet werden soll oder ob ein gemeinsamer Prozess- 

Workshop für die Gestaltung beider Prozesse sinnvoll ist. Für die Abhaltung eines einzelnen 

Workshops, in dem beide Prozesse gestaltet werden spricht die Tatsache, dass beide Prozesse 

stark voneinander abhängig sind und sich gegenseitig beeinflussen. Andererseits sollte darauf 

geachtet werden, dass nicht zu viele Personen an dem Prozess-Workshop teilnehmen, um eine 

optimale Zusammenarbeit zu gewährleisten. Folglich sollte im Einzelfall entschieden werden ob 

ein oder zwei Prozess-Workshops veranstaltet werden sollen. 

Generell ist es ratsam im Rahmen des Prozess-Workshops auf die Erfahrung der IT-Mitarbeiter 

zurückzugreifen und diese in die Gestaltung des neuen Prozesses aktiv einzubinden. 181 Auf die- 

se Weise kann die Akzeptanz für die geplanten Veränderungen und die Motivation für die Um- 

setzung erheblich gesteigert werden. 182 

Das Teilnehmerfeld für den Prozess-Workshop für die Gestaltung des Incident und Problem 

Managements kann sich z. B. aus den folgenden Teilnehmern zusammensetzen: 

� Problem Manager, Incident Manager 

� Leiter des Service Desk 

� Mitarbeiter des Service Desk 

� Vertreter des 2nd Level Support 





� Known-Error-Datenbank-Verantwortlicher , CMS-Verantwortlicher, Ticketing-Tool- 

Verantwortlicher 

Im Zuge des Prozess-Workshops werden die Prozesse, die Rollen, die Schnittstellen und die 

KPIs definiert bevor das Ergebnis noch dokumentiert wird. 

Definition der Prozesse 

Die Gestaltung eines Prozesses erfolgt auf Basis des generischen Prozessmodells. Demnach hat 

ein Prozess einen definierten Input, der mit Hilfe der Aktivitäten des Prozesses in einen defi- 

nierten Output umgewandelt wird. (siehe Kapitel 2.1.) Folglich müssen bei der Gestaltung des 

Prozesses der Input, der Output und die Aktivitäten des Prozesses festgelegt werden, wobei die 

Festlegung des Outputs auf Basis der vorher definierten Ziele erfolgt. 183 Das Ergebnis der Pro- 

zessdefinition sollte anschließend in einer Prozessbeschreibung dokumentiert werden. 

Definition der Rollen 

Der nächste Schritt ist die Definition der Rollen, die für die Umsetzung des Prozesses benötigt 

werden. Die Beschreibung der einzelnen Rollen sollte in sogenannten Rollenbeschreibungen 

festgehalten werden. Die Rollenbeschreibung enthält Informationen zu den folgenden Stich- 

punkten 184 : 

� Aufgaben 

� Verantwortung 

� Kompetenzen 

Um die Verantwortlichkeiten der einzelnen Aktivitäten des einzuführenden Prozesses zu doku- 

mentieren ist der Einsatz des RACI-Modells 185 sinnvoll. Das RACI-Modell ist ein Hilfsmittel 

zur Analyse und Darstellung von Verantwortlichkeiten. 186 Der Name des RACI Modells leitet 

sich von den Anfangsbuchstaben der folgenden englischen Begriffe 187 ab: 

� Responsible - benennt die für die Durchführung der Tätigkeit zuständige Person oder 

Gruppe 

� Accountable - beschreibt die für die Aktivität verantwortliche Person 

� Consulted - definiert die Person oder Gruppe, deren Rat eingeholt wird 

� Informed - beschreibt die Person oder Gruppe, die über den Verlauf bzw. das Ergebnis 

der Tätigkeit informiert wird 

Für das Incident Management sieht das RACI-Modell z. B. folgendermaßen aus: 

183 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 303 f. 


185 Das RACI-Modell wird in der deutschen Literatur teilweise auch als VABI-Modell bezeichnet. 


187 Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.175.


Tab. 25 - RACI-Tabelle für das Incident Management 188 

Aktivität Verantwortlich 

Störung anlegen und 

klassifizieren 

(Responsible) 

Ausführend 

(Accountable) 

Teamleiter Service-Desk- 

Mitarbeiter 

Bearbeitung der Störung Teamleiter Service-Desk- 

Ticketabschluss und 

anschließendes Informie- 

ren des Anwenders über 

die Erledigung 

Eintragen der Lösungen 

in die Lösungsdatenbank 

Pflege der Lösungsda- 

tenbank 

2 nd Level Support für 

Standardsoftware 


Fachapplikationen 


Hardware 

Mitarbeiter, 

2 nd -Level-Mitarbeiter 

Teamleiter Service-Desk- 

Qualitätssicherung 

im Service Desk 

Qualitätssicherung 

im Service Desk 

Service-Desk- 

Mitarbeiter 

Service-Desk- 

Mitarbeiter 

Service-Desk- 

Mitarbeiter 

3 rd Level Support Service-Desk- 

Reports über das Incident 

Management erstellen 

Mitarbeiter 

Mitarbeiter 

Service-Desk- 

Mitarbeiter, 

2 nd -Level-Mitarbeiter 

Qualitätssicherung im 

Service Desk 

Dispatcher im 2 nd -Level 

für Standardsoftware 


für Hardware 


für Dienstleister 

Entwickler, 

externe Dienstleiter 

Incident Manager Qualitätssicherung im 

Service Desk 

Beteiligt 

(Consulted) 

Externe 

Dienstleister 

Teamleiter im 

Service Desk 

Informiert 

(Informed) 

Prozess-Owner 

des Incident 

Managements 

Wichtige Rollen, die beispielsweise für die jeweiligen Prozesse festgelegt werden sollten sind: 

Tab. 26 - Rollenbeschreibungen 

Incident Management Problem Management 

Prozess-Owner des Incident Managements Prozess-Owner des Problem Managements 

Incident Manager Problem Manager 

1st Level Support 

2nd Level Support 

Gerade mittelständische Unternehmen haben nicht unbedingt die notwendigen Ressourcen um 

bestimmte Rollen mit einer Vollzeitstelle zu besetzen. Aus diesem Grund kann es sinnvoll sein, 

dass eine Person mehrere Rollen besetzt. 

188 In Anlehnung an: Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 99.


Definition der Schnittstellen 

„Damit die definierten Prozesse untereinander agieren können, müssen die Schnittstellen zum 

Austausch von Triggern, Daten und Informationen zwischen den Prozessen definiert wer- 

den‟. 189 Die Ergebnisse sollte anschließend in einer Schnittstellenbeschreibung für die jeweilige 

Schnittstelle festgehalten werden. 

Definition der KPIs 

Der nächste Schritt ist die Definition der zu messenden KPIs, mit deren Hilfe die Prozessquali- 

tät des Incident und Problem Management gemessen werden kann. 190 Bei Auswahl der KPIs ist 

es sinnvoll auf die Erfahrung der Mitarbeiter zu setzen und diese bei der Auswahl der KPIs ein- 

zubinden. Oftmals ist das Messen von KPIs ein umfangreiches Unterfangen, aus diesem Grund 

ist bei der Wahl der KPIs darauf zu achten, dass die KPIs sinnvoll ausgewählt werden. Es sollte 

nicht das primäre Ziel sein möglichst viele KPIs festzulegen, stattdessen sollten nur KPIs aus- 

gewählt werden, die für die Prozessoptimierung hilfreich und notwendig sind. Deshalb sollten 

die ausgewählten KPIs SMART (Spezifisch, Messbar, Akzeptiert, Realistisch, Terminierbar) 

sein. Bei der Auswahl der KPIs ist außerdem darauf zu achten, dass der Betriebsrat frühzeitig in 

die Auswahl eingebunden wird um weitere Konflikte und die damit verbundenen Verzögerun- 

gen zu vermeiden. Mögliche Beispiele wie die zu messenden KPIs aussehen könnten werden in 

der nachfolgenden Tabelle 25 dargestellt. 

Tab. 27 - KPIs für das Incident und das Problem Management 

Für das Incident Management Für das Problem Management 

� Anzahl der Incidents 191 

� Erstlösungsrat der Incidents 192 

� Durchschnittliche Wiederherstellungszeit aller Inci- 

dents 193 

� Durchschnittliche Wiederherstellungszeit pro Prioritäts- 

stufe 194 

� Durchschnittliche Wiederherstellungszeit pro Kategorie 

� Anzahl der Incidents nach Status 

� Anzahl der Incidents, die anfänglich falsch klassifiziert 

wurden 195 

� Anzahl der falsch weitergeleiteten Incidents 196 

� Anzahl der Probleme 197 

� Durchschnittliche Zeit bis zur Problem- 

identifizierung 

� Durchschnittliche Anzahl von Incidents 

bis das Problem identifiziert wird 

� Durchschnittliche Problemlösungszeit 

� Verhältnis reaktiver zu proaktiver Prob- 

lem-Tickets 198 


190 Vgl. Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 136. 

191 Kempter, A.: ITIL-Kennzahlen Service Operation - Servicebetrieb - IT Process Wiki , http://wiki.de.itprocessmaps.com/index.php/ITIL-Kennzahlen_Service_Operation_-_Servicebetrieb, 

02.06.2010. 


193 Vgl. Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 136 


195 Vgl. Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 136 

196 Vgl. Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 136.


Ableiten der Toolkriterien 

Der nächste Schritt ist das Festlegen der Anforderungen für die Toolauswahl. Im Zuge dessen 

müssen zunächst die Anforderungen an die Tools definiert und auf Basis der Aktivitäten des 

Prozesses identifiziert werden. 199 Anschließend sollte die Bedeutung der Anforderungen auf 

Basis des MoSCoW-Prinzip bewertet werden. MoSCoW 200 steht in diesem Kontext für: 

� M - MUST have this 

� S - SHOULD have this if at all possible 

� C - COULD have this if doesn't affect anything else 

� W - WON'T have this time but WOULD like in the future 

Alle Kriterien, die mit „MUST‟ bewertet werden sind die sogenannten Ausschlusskriterien. 

Diese müssen erfüllt werden, ansonsten werden die Tools, die diese Kriterien nicht erfüllen 

nicht weiter beim Auswahlverfahren berücksichtigt. Alle Anforderungen, die mit „SHOULD‟ 

bewertet werden sind „wichtig für die effektive und effiziente Prozessdurchführung und sollten 

nach Möglichkeit vorhanden sein.‟ 201 „COULD‟-Anforderungen sind für das Auswahlverfahren 

von geringer Bedeutung und können, müssen aber nicht, erfüllt werden. Die mit „WON'T‟ be- 

werteten Anforderungen sind zum aktuellen Zeitpunkt nicht notwendig, werden aber in Zukunft 

noch benötigt. 202 

Durch die Identifikation und die anschließende Bewertung der Anforderungen wird sicherge- 

stellt, dass das später ausgewählte Tool alle erforderlichen Funktionalitäten bereitstellt und so- 

mit keine Probleme wegen unzureichender Tool-Unterstützung auftreten (siehe. Kapitel 7.1.6.). 

Nachdem die Anforderungen identifiziert und mit Hilfe des MoSCoW-Prinzip bewertet wur- 

den, sollten die Anforderungen in einem Anforderungskatalog dokumentiert werden. 203 

Dokumentation der Ergebnisse 

Eine der Hauptaufgaben im Rahmen des Prozess-Workshops ist die Dokumentation der erarbei- 

teten Ergebnisse. Für die Umsetzung der Dokumentation ist es sinnvoll ein sogenanntes Pro- 

zesshandbuch zu erstellen. 204 In dem Prozesshandbuch können die erarbeiteten Prozess-, Rol- 

len- und Schnittstellenbeschreibungen übersichtlich dokumentiert werden. Auf diese Weise 

197 Kempter, A.: ITIL-Kennzahlen Service Operation - Servicebetrieb - IT Process Wiki http://wiki.de.itprocessmaps.com/index.php/ITIL-Kennzahlen_Service_Operation_-_Servicebetrieb, 

Abruf am 02.06.2010. 

198 Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 168. 


200 Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.315. 

201 Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.315. 

202 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.315. 


204 Vgl. Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 94 ff.


wird sichergestellt, dass alle notwendigen Informationen nachvollziehbar zur Verfügung gestellt 

werden können. 

Abb. 22 - Prozesshandbuch 205 

8.4.2. Toolauswahl durchführen 

Im Rahmen der Toolauswahl sollte zunächst festgelegt werden, wie viele Softwareanbieter ma- 

ximal in die engere Auswahl kommen. 206 Anschließend sollten Auswahlkriterien definiert wer- 

den mit deren Hilfe die potenziellen Anbieter identifiziert werden können. Mögliche Auswahl- 

kriterien 207 sind z. B.: 

� Zertifizierungen (ISO, ITIL-Konformität) 

� Branchenkenntnis 

� Empfehlungen / Referenzprojekte 

� Marktpräsenz (Marktführerschaft) 

Der nächste Schritt ist Durchführung einer Recherche um die am Markt befindlichen potenziel- 

len Anbieter nach den vorher festgelegten Kriterien zu identifizieren. Im Anschluss sollte ein 

Lastenheft erstellt und an die die geeignetsten Anbieter versendet werden, um ein Angebot von 

diesen zu erhalten. Anschließend sollte eine Bewertungsmatrix erstellt werden, mit deren Hilfe 

die verschiedenen Angebote verglichen werden können. Die drei Anbieter mit der besten Be- 

wertung sollten zu einer abschließenden Präsentation eingeladen werden, bei der das Tool von 

den Anbietern vorgestellt werden kann. 208 Nach der Präsentation sollten die Ergebnisse disku- 

205 Entnommen aus: Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 95. 



208 Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.198.


tiert und eine abschließende Bewertung durchgeführt werden. Auf Basis dieser Bewertung er- 

folgt endgültige Entscheidung. 

8.4.3. Prozessschulung durchführen 

Der nächste Schritt ist die Durchführung einer Prozessschulung. Die im Rahmen der Prozess- 

schulung vermittelten Inhalte sollten auf den im Prozess-Workshop geplanten Soll-Prozess be- 

ruhen. Darüber hinaus sollten den IT-Mitarbeitern ein Überblick über das ITIL-Framework ver- 

schafft und die Vorteile von ITIL hervorgehen werden. Des Weiteren sollte nicht nur die neuen 

Prozesse vorgestellt, sondern auch die wesentlichen Abweichung vom bisherigen Vorgehen 

hervorgehoben werden. 

Das Incident und das Problem Management sind zwei unterschiedliche Prozesse, nichts desto 

trotz fällt es den IT-Mitarbeitern oftmals schwer beide Prozesse voneinander zu trennen. (siehe 

Kapitel 7.1.8.). Aus diesem Grund sollten nach der Vorstellung der verschiedenen Aspekte der 

jeweiligen Prozesse die unterschiedlichen Ziele und Vorgehensweisen nochmals hervorgehoben 

werden. Ziel ist es auf diese Weise den Unterschied zwischen den beiden Prozessen zu verdeut- 

lichen. 

8.5. Durchführung der Implementierung 

Nach der Durchführung des Prozess-Workshops und der anschließenden Dokumentation der 

Ergebnisse müssen nun das Incident und das Problem Management im Unternehmen etabliert 

werden. Zuvor werden aber noch die Anwender bzw. Kunden über die Änderungen informiert 

und ein Termin mitgeteilt, ab dem die neuen Prozesse umgesetzt und auch angewandt wer- 

den. 209 Die wichtigsten Aktivitäten in der Implementierungsphase sind: 

� Projektmarketing betreiben 

� Einführung der Tools 

� Anpassen der Tools 

� Erstellen der Arbeitsanweisungen 

8.5.1. Projektmarketing betreiben 

Um die Mitarbeiter über die neuen Prozesse zu informieren sollte Projektmarketing betrieben 

werden. 210 Das Projektmarketing umfasst „alle Aktiviten, die der Erhöhung des Bekanntheits- 

grads und der Imageverbesserung eines Projektes dienen‟. 211 Das Ziel des Projektmarketings ist 

die Anwender bzw. Kunden von der Relevanz des Projektes zu überzeugen. Aus diesem Grund 

209 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.317 ff. 


211 Patzak, G.; Rattay, G.: Projektmanagement, 4., wesentlich überarbeitete Auflage, Wien 2004, S. 146.


sollte eine Informationsveranstaltung stattfinden, in der die Anwender bzw. Kunden von den 

neuen Prozessen und den damit verbundenen Änderungen informiert werden. Durch die Infor- 

mationsveranstaltung wird die Bedeutung der Prozesse nochmals hervorgehoben und somit die 

Akzeptanz bei den Mitarbeitern gefördert. Auf diese Weise kann der fehlenden Akzeptanz der 

IT-Mitarbeiter entgegengewirkt werden. (siehe. Kapitel 7.1.1.) 

8.5.2. Tools einführen 

Nach dem das Management die Beschaffung des Tools genehmigt hat, kann mit der Einführung 

des Tools angefangen werden. 212 

8.5.3. Anpassung der Tools 

Nach der der Implementierung der Tools müssen die Tools an die Anforderungen angepasst 

werden, damit im Prozessworkshop festgelegten Aktivitäten korrekt umgesetzt werden können. 

Beispielsweise könnten bei einem Ticketing-Tool die verschiedenen Kategorisierungsmöglich- 

keiten an die Anforderungen des Unternehmens angepasst werden. 

8.5.4. Tool-Schulung 

Nach der Einführung und Anpassung der Tools sollte der Schulungsbedarf der IT-Mitarbeiter 

ermittelt werden. Anschließend sollte eine Tool-Schulung mit allen Mitarbeitern veranstaltet 

werden, die noch geschult werden müssen.. Im Rahmen dessen sollten den Schulungsteilneh- 

mern das notwendige Know-How für den Umgang mit den neuen Tools vermittelt werden. Auf 

diese Weise wird sichergestellt, dass die Mitarbeiter mit den Tools umgehen und die Aktivitäten 

des Prozesses umsetzen können. Dadurch wird vermieden, dass die Mitarbeiter aufgrund von 

fehlendem Know-How die Tools falsch einsetzen (siehe 7.1.4.). 

8.5.5. Erstellen von Arbeitsanweisungen 

Die Aktivitäten der Prozesse wurden bereits im Rahmen des Prozess-Workshops festgelegt. Um 

aber eine einheitliche Vorgehensweise bei der Durchführung der Aktivitäten zu garantieren 

sollten sogenannte Arbeitsanweisungen erstellt werden, in denen die Aktivitäten detailliert be- 

schrieben werden. Im Zuge dessen sollte darauf geachtet werden, dass die Arbeitsanweisungen 

übertragbar gestaltet werden, um diese auch für vorübergehendes Personal verständlich zu ge- 

stalten. 213 Nach der Erstellung der Arbeitsanweisungen sollten diese im Prozesshandbuch do- 

kumentiert werden. 




8.5.6. Erfahrungen dokumentieren und Verbesserungspotenziale identifi- 

zieren 

Während der gesamten Implementierungsphase sollten die Mitglieder des Projektes ihre eigenen 

Erfahrungen dokumentieren, damit diese als Grundlage für spätere Verbesserungsmaßnahmen 

genutzt werden können. Darüber hinaus ist es oftmals sinnvoll, die Rückmeldungen der Pro- 

jektmitglieder sofort zu verarbeiten und bereits in der Implementierungsphase als Änderungs- 

maßnahme einfließen zu lassen. Auf diese Weise wird nicht nur der Prozess praxisorientierter 

gestaltet, sondern auch die Akzeptanz bei den Mitarbeitern gefördert. 214 

Tab. 28 - Template für Verbesserungsvorschläge 215 

Name 

Betroffene Aktivität im Prozess 

Festgestellter Vorfall und/oder gewonnene In- 

formation 

Auswirkung auf den Betrieb 

Vorgeschlagene Verbesserungsmaßnahmen 

Verbesserungsvorschlag 

8.6. Evaluierung und Weiterentwicklung 

Die Evaluierung und Weiterentwicklungs-Phase dient in erster Linie der Identifikation von Ver- 

besserungspotenzial, sowohl für die Prozesse als auch für das Vorgehen bei der Implementie- 

rung. Deshalb wird ein Review-Workshop durchgeführt, in dessen Rahmen die folgenden Akti- 

vitäten umgesetzt werden: 

� Review der Implementierung 216 

� Kontinuierlichen Verbesserungsprozess definieren und initiieren 217 

8.6.1. Review der Implementierung 

Die erste Aktivität des Review-Workshops ist die Durchführung eines Reviews. Das Review 

dient der Nachbetrachtung der abgeschlossenen Implementierung, um aus den daraus gewonnen 

Erkenntnissen für zukünftige Einführungsprojekte zu lernen. Um dies zu erreichen werden die 

214 

Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.320. 

215 

In Anlehnung an: Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, 

S.321. 

216 

Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.321. 

217 

Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.321.


vorher definierten Ziele mit dem tatsächlichen IST-Zustand der Prozesse anhand der vorher 

definierten Kennzahlen verglichen. 218 Während der Implementierungsphase haben die Projekt- 

mitglieder die Aufgabe ihre eigenen Erfahrungen zu dokumentieren. Das daraus resultierende 

Feedback muss während der Review-Phase ausgewertet und die vorgeschlagenen Verbesse- 

rungsmaßnahmen auf Machbarkeit und Auswirkung geprüft werden. Für den Fall, dass bei den 

implementierten Prozessen noch Anpassungsbedarf besteht, müssen Handlungsempfehlungen 

aus dem Feedback der Projektmitglieder abgeleitet werden. 219 

8.6.2. Kontinuierlichen Verbesserungsprozess definieren und initiieren 

Um die freigegebenen Handlungsempfehlungen umsetzen zu können ist es notwendig einen 

Aktivitätenplan zu erstellen. 220 Der Aktivitätenplan beschreibt die umzusetzenden Aktivitäten 

und ordnet diesen Aktivitäten einen festen Termin, einen Verantwortlichen sowie die benötigten 

Ressourcen zu. 

Das eigentliche Ziel dieses Vorhabens ist die kontinuierliche Verbesserung der eingeführten 

Prozesse. Um das Verbesserungspotenzial sukzessive ausschöpfen zu können sollte ein Kreis- 

lauf etabliert werden, der sich am Deming Cycle orientiert. Das von Edward Deming entwickel- 

te Modell wird auch als PDCA-Zyklus bezeichnet und setzt sich aus den folgenden vier Pha- 

sen 221 zusammen: 

� Plan - In der Plan-Phase werden die neuen Maßnahmen zur Qualitätsverbesserung geplant. 

� Do - In der Do-Phase erfolgt die Umsetzung der geplanten Maßnahmen. 

� Check - In der Check-Phase wird der Erfolg der Maßnahmen gemessen. 

� Act - In der Act-Phase werden die Abweichungen vom eigentlichen Ziel erkannt und 

Korrekturmaßnahmen durch einen erneuten Durchlauf des PDCA-Zyklus initiiert 

Abb. 23 - PDCA-Zyklus 222 



220 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.321 f. 


222 In Anlehnung an: Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 154.


Mit jedem Durchlauf des PDCA-Zyklus wird die Qualität des Prozesses schrittweise verbes- 

sert. 223 

8.7. Abschluss 

Abschließend sollte der Projekterfolg im Rahmen einer Abschlussfeier mit den Projektmitarbei- 

tern und den Mitarbeitern des Problem- und Incident Managements zelebriert werden, um die 

Projekteinführung angemessen abzuschließen. 224 



Fazit 79 

9 Fazit 

Im Rahmen der vorliegenden Bachelorarbeit wurde der Status quo von ITIL in mittelständi- 

schen Unternehmen und Unternehmen mittlerer Größe ermittelt und die typischen Probleme 

identifiziert, die bei der Einführung des Incident und Problem Management in den befragten 

Unternehmen auftraten. Basierend auf diesen Informationen wurde ein optimiertes Vorgehens- 

modell entworfen, mit dessen Hilfe die beiden Prozesse eingeführt werden können. 

Für diese Studie wurden 700 Unternehmen kontaktiert von denen 58 an der Erhebung teilge- 

nommen haben. Das Ergebnis dieser Studie zeigt, dass sich ITIL noch nicht vollständig in den 

mittelständischen Unternehmen und Unternehmen mittlerer Größe durchgesetzt hat. Demnach 

nutzen lediglich 50 % der befragen Unternehmen ITIL. Die Ursachen für den Verzicht sind 

vielseitig, einerseits greifen zahlreiche Unternehmen auf die Möglichkeit zurück alternative 

Frameworks zu verwenden, andererseits ist die Einführung von ITIL oftmals mit viel Aufwand 

verbunden. Die im Rahmen der Bachelorarbeit durchgeführte Studie zeigt, dass eine direkte 

Interdependenz zwischen der ITIL-Nutzung und den IT-Mitarbeitern herrscht. Je größer die 

Anzahl der IT-Mitarbeiter ist, desto häufiger kommt ITIL zum Einsatz. Die Einführung von 

ITIL-basierten Prozessen und Funktionen ist ein umfangreiches Unterfangen, welches mit der 

Bindung von zusätzlichem Personal verbunden ist. Aus diesem Grund verzichten gerade Unter- 

nehmen mit wenigen IT-Mitarbeitern auf eine Einführung von ITIL. 

Ferner zeigen die Ergebnisse der vorliegenden Studie, dass gerade operative Prozesse und Funk- 

tionen, wie der Service Desk, das Incident und das Problem Management vermehrt in den Un- 

ternehmen zum Einsatz kommt. Prozesse wie das Demand Management oder Transition und 

Support kommen dagegen selten zum Einsatz. Nachholbedarf besteht in erster Linie bei den 

Planungs- und Implementierungsprozessen, wie dem Service Asset und Configuration Mana- 

gement oder dem Transition Planung und Support. 

Die Einführung von ITIL-basierten Prozessen ist oftmals mit Problemen verbunden. Rund 50 % 

der Unternehmen die entweder das Incident oder das Problem Management eingeführt haben, 

hatten Probleme bei der Einführung. Im Rahmen dessen hatte die Unternehmen in erster Linie 

mit der fehlenden Akzeptanz der Mitarbeiter, der fehlenden technischen Unterstützung durch 

effektive Hilfsmittel, sowie dem fehlenden Know-How der Mitarbeiter zu kämpfen. Das im 

Rahmen dieser Bachelorarbeit entworfene Vorgehensmodell kann mittelständischen Unterneh-

Fazit 80 

men und Unternehmen mittlerer Größe die Möglichkeit bieten, Probleme zu vermeiden und das 

Incident- und das Problem Management effektiv einzuführen.

Quellenverzeichnis VIII 

Quellenverzeichnis 

Literatur 

Beims, M.: IT-Service Management in der Praxis mit ITIL® 3 - Zielfindung, Methoden, Reali- 

sierung, 2. Auflage, München 2010. 

Böttcher, R.: IT-Servicemanagement mit ITIL ® V3 – Einführung Zusammenfassung und Über- 

sicht der elementaren Empfehlungen, 1. Auflage, Hannover 2008. 

Buchsein, R.; Victor, F.; Günther, H.; Machmeier, V.: IT- Management mit ITIL ® V3 – Stra- 

tegien, Kennzahlen, Umsetzung, 2. Auflage, Wiesbaden 2008. 

Buhl, U.: ITIL Praxisbuch – Beispiele und Tipps für die erfolgreiche Prozessoptimierung, 2. 

Auflage, Heidelberg 2008. 

Ebel, N.: ITIL® V3 Basis-Zertifizierung - Grundlagenwissen und Zertifizierungsvorbereitung 

für die ITIL® Foundation-Prüfung, 1. Auflage, München 2008. 

Heinrich, L. J.; Stelzer, D.: Informationsmanagement – Grundlagen Aufgaben, Methoden, 

München 2009. 

itSMF e. V. (Hrsg.): ITIL in der Öffentlichen Verwaltung - Planung, Einführung und Steuerung 

von IT-Service-Prozessen, 1. Auflage, Düsseldorf 2007. 

Kittel, M.; Koerting, T. J.; Schött, D.: Kompendium für ITIL V3 Projekte - Menschen, Me- 

thoden, Meilensteine, 2. Auflage, Norderstedt 2009. 

Lienemann, G.: ITIL - Change Management - Hinweise und Vorgehensweisen aus der Praxis, 

1. Auflage, Hannover 2006. 

Mayer, H. O.: Interview und schriftliche Befragung: Entwicklung, Durchführung und Auswer- 

tung, 4. Auflage, München 2008.

Quellenverzeichnis IX 

Nienstermann, M.: Service Management Lösungen für KMU – ITIL-unterstützende Service 

Management-Tools, 1. Auflage, Saarbrücken 2007. 

Office of Government Commerce: Service Operation, London 2007. 

Olberich, A.: ITIL kompakt und verständlich – Effizientes IT Service Management – Den 

Standard für IT-Prozesse kennenlernen, verstehen und erfolgreich in die Praxis umsetzen , 4. 

Auflage, Wiesbaden 2008. 

Patzak, G.; Rattay, G.: Projektmanagement - Leitfaden zum Management von Projekten, Pro- 

jektportfolios und projektorientierten Unternehmen, 4., wesentlich überarbeitete Auflage, Wien 

2004. 

Rossig, W. E.; Prätsch, J.: Wissenschaftliche Arbeiten - Leitfaden für Haus- und Seminarar- 

beiten, Bachelor- und Masterthesis, Diplom- und Magisterarbeiten, Dissertationen, 7. Auflage, 

Hamburg 2008. 

Schiefer, H.; Schitter, E.: Prozesse optimieren mit ITIL ® - Abläufe mittels Prozesslandkarte 

gestalten – Compliance erreichen und Best Practices nutzen mit ISO 20000, BS 15000 & ISO 

9000, 2. Auflage, Wiesbaden 2008. 

Schmidt, R.; Dohle , H. (Hrsg.): ITIL V3 umsetzen – Gestaltung, Steuerung und Verbesserung 

von IT-Services, 1. Auflage, Düsseldorf 2009. 

Steinweg, C.: Projektkompass Softwareentwicklung – Geschäftsorientierte Entwicklung von 

IT-Systemen, 4. Auflage, Braunschweig/Wiesbaden 2002. 

van Bon, J.; de Jong, A.; Kolthof, A.; Pieper, M.; Tjassing, R.; van der Veen, A.; 

Verheijen, T.: IT Service Management basierend auf ITIL V3 – Das Taschenbuch, 3. Auflage, 

Zaltbommel 2008. 

Zielke, F.; Schinkel, A.-W.; Oldag, J.; Weber, G.: ITIL überzeugend einführen - Methoden 

und soziale Kompetenzen, 1. Auflage, Düsseldorf 2010.

Quellenverzeichnis X 

Internet 

Alberts, S.: HZD ITSM-Fachforum 30.09.09, http://www.itsm- 

consulting.de/files/HZD%20ITSM-Fachforum%2030.09.09.pdf, 22.03.2010. 

Bundesministerium der Justiz: TMG - Einzelnorm, http://www.gesetze-im- 

internet.de/tmg/__5.html, 27.03.2010. 

Bundesministerium für Wirtschaft und Technologie (Hrsg.): Der Mittelstand in der Bun- 

desrepublik Deutschland - Eine volkswirtschaftliche Bestandsaufnahme, BMWi Dokumentation 

Nr. 561, Berlin 2007, http://www.ifm-bonn.org/assets/documents/BMWI-Dokumentation- 

561.pdf, 14.03.2010. 

Ellermann, H.: Münchener Rück: >> ITIL ist einfach

Quellenverzeichnis XI 

Wikipedia: Wikipedia:Relevanzkriterien, 

http://de.wikipedia.org/wiki/Wikipedia:Relevanzkriterien#Wirtschaftsunternehmen, 25.03.2010. 

Vogel, M.: Mitbestimmung bei IT-Systemen: Achtung: Betriebsrat!, 

http://www.cio.de/karriere/805409/index2.html, 02.05.2010. 

Persönliche Mitteilungen 

Alberts, S.: Subject: AW:Frage wegen der Einführung von ITIL-Prozessen bei der HZD, 

Susanne.Alberts@hzd.hessen.de, 23.03.2010. 

Handgräntinger, S.: Subject: AW: Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.

Eidesstattliche Erklärung XII 

Eidesstattliche Erklärung 

Ich versichere, dass ich die vorstehende Arbeit selbstständig angefertigt und mich fremder Hilfe 

nicht bedient habe. 

Alle Stellen, die wörtlich oder sinngemäß veröffentlichtem oder nicht veröffentlichtem Schrift- 

tum entnommen sind, habe ich als solche kenntlich gemacht. 

Die Arbeit hat in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgele- 

gen 

Mönchengladbach, Datum ________________________________ 

Vorname Nachname

Die Bachelorarbeit können Sie hier downloaden - Patrick Pauen

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?