Die Bachelorarbeit können Sie hier downloaden - Patrick Pauen
Die Bachelorarbeit können Sie hier downloaden - Patrick Pauen
Die Bachelorarbeit können Sie hier downloaden - Patrick Pauen
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Status quo der Einführung ITIL-basierter Standardprozesse im<br />
Mittelstand und in mittelständischen Unternehmen sowie<br />
Entwurf eines Vorgehensmodells unter besonderer<br />
Berücksichtigung des Incident und Problem Managements<br />
<strong>Bachelorarbeit</strong><br />
vorgelegt von<br />
<strong>Patrick</strong> <strong>Pauen</strong><br />
aus Mönchengladbach<br />
geboren am: 13.08.1984<br />
Matrikel-Nr.: 696282<br />
Hochschule Niederrhein<br />
Fachbereich Wirtschaftwissenschaften<br />
Studiengang Bachelor in Information Systems<br />
Sommersemester 2010<br />
1. Prüfer: Prof. Dr. Georg Wilking<br />
2. Prüfer: Prof. Dr. <strong>Die</strong>tmar Abts
Inhaltsverzeichnis I<br />
Inhaltsverzeichnis<br />
Abkürzungsverzeichnis ............................................................................... IV<br />
Abbildungsverzeichnis ................................................................................ VI<br />
Tabellenverzeichnis .................................................................................... VII<br />
1 Einleitung ............................................................................................... 1<br />
1.1. Zielsetzung der Arbeit .................................................................................................... 2<br />
1.2. Aufbau der Arbeit .......................................................................................................... 2<br />
2 Grundlagen - Begriffe und Definitionen ................................................ 3<br />
2.1. Prozess ........................................................................................................................... 3<br />
2.2. Funktion ......................................................................................................................... 4<br />
2.3. Rolle ............................................................................................................................... 4<br />
2.3.1. Prozess-Owner ....................................................................................................... 4<br />
2.3.2. Prozess-Manager .................................................................................................... 4<br />
2.3.3. Prozess-Mitarbeiter ................................................................................................ 5<br />
2.4. Key Performance Indikatoren ........................................................................................ 5<br />
2.5. IT-Service ....................................................................................................................... 5<br />
2.6. IT-Service Management ................................................................................................. 5<br />
2.7. Mittelstand ..................................................................................................................... 5<br />
3 IT Infrastructure Library im Überblick .................................................. 7<br />
3.1. Geschichte ...................................................................................................................... 7<br />
3.2. ITIL V3 .......................................................................................................................... 8<br />
3.3. IT Service Lifecylce ....................................................................................................... 8<br />
3.3.1. Service Strategy ..................................................................................................... 9<br />
3.3.2. Service Design ....................................................................................................... 9<br />
3.3.3. Service Transition .................................................................................................. 9<br />
3.3.4. Service Operation ................................................................................................... 9<br />
3.3.5. Continual Service Improvement........................................................................... 10<br />
3.3.6. Complementary Set .............................................................................................. 10<br />
4 ITIL-basierte Prozesse im Detail ......................................................... 11<br />
4.1. Incident Management ................................................................................................... 11<br />
4.1.1. Begriffe ................................................................................................................ 11<br />
4.1.2. Prinzipien ............................................................................................................. 13<br />
4.1.3. Rollen ................................................................................................................... 14<br />
4.1.4. Prozessablauf des Incident Managements ............................................................ 16<br />
4.1.5. Methoden und Tools ............................................................................................ 20<br />
4.2. Problem Management .................................................................................................. 20<br />
4.2.1. Begriffe ................................................................................................................ 21<br />
4.2.2. Prinzipien ............................................................................................................. 22<br />
4.2.3. Rollen ................................................................................................................... 22<br />
4.2.4. Methoden und Tools ............................................................................................ 23
Inhaltsverzeichnis II<br />
4.2.5. Prozessablauf des Problem Managements ........................................................... 24<br />
5 Erhebung der Daten .............................................................................. 28<br />
5.1. Untersuchungsgegenstand ............................................................................................ 28<br />
5.2. Erhebungsmethode ....................................................................................................... 28<br />
5.3. Zielgruppe der Erhebung .............................................................................................. 30<br />
5.4. Konzeption des Fragebogens ....................................................................................... 30<br />
5.5. Auswahl der Umfrageteilnehmer ................................................................................. 33<br />
5.5.1. Wikipedia ............................................................................................................. 33<br />
5.5.2. Firmendatenbanken der Industrie und Handelskammern ..................................... 34<br />
5.5.3. Ermitteln der E-Mail-Adresse .............................................................................. 34<br />
6 Status quo von ITIL .............................................................................. 36<br />
6.1. Umfrageergebnis .......................................................................................................... 36<br />
6.1.1. Größe und Branchen der teilnehmenden Unternehmen ....................................... 36<br />
6.1.2. Status quo von ITIL ............................................................................................. 37<br />
6.1.3. Gründe für die Nutzung bzw. den Verzicht von ITIL .......................................... 38<br />
6.1.4. Verbreitung der ITIL-basierten Prozesse und Funktionen ................................... 40<br />
6.1.5. Bedarf an ITIL-basierten Prozessen und Funktionen ........................................... 41<br />
6.1.6. Verwendete ITIL-Version .................................................................................... 42<br />
6.1.7. Probleme bei der Einführung des Incident Managements.................................... 43<br />
6.1.8. Probleme bei der Einführung des Problem Managements ................................... 44<br />
6.1.9. Einfluss von ITIL auf die Prozesse ...................................................................... 45<br />
6.1.10. Diskussion der Ergebnisse ................................................................................... 49<br />
6.2. Experteninterview ........................................................................................................ 51<br />
6.2.1. Ursache für den Verzicht auf ITIL-basierte Standardprozesse ............................ 51<br />
6.2.2. Gründe für den Einsatz von ITIL-basierten Standardprozessen .......................... 51<br />
6.2.3. Erfolgsfaktoren für eine erfolgreiche Umsetzung von ITIL V3 ........................... 51<br />
6.2.4. Einfluss der aktuellen Wirtschaftskrise ................................................................ 52<br />
6.2.5. Zukünftige Entwicklung in KMU ........................................................................ 52<br />
7 Probleme bei der Einführung ............................................................... 53<br />
7.1. Probleme ...................................................................................................................... 53<br />
7.1.1. Fehlende Akzeptanz bei den Mitarbeitern ........................................................... 53<br />
7.1.2. Mangelnde Unterstützung durch das Management .............................................. 53<br />
7.1.3. Schlechte Terminplanung ..................................................................................... 53<br />
7.1.4. Fehlendes Know-How der IT-Mitarbeiter ............................................................ 54<br />
7.1.5. Fehlende technische Unterstützung durch effektive Hilfsmittel .......................... 54<br />
7.1.6. Unzureichende Tool-Unterstützung ..................................................................... 54<br />
7.1.7. Overhead während der Implementierungsphase .................................................. 54<br />
7.1.8. Ungenaue Trennung zwischen Incident und Problem Management .................... 54<br />
7.1.9. Durchdringung des Prozesses dauert länger als geplant ...................................... 55<br />
7.1.10. Kommunikationsprobleme ................................................................................... 55<br />
7.1.11. Unsaubere Abbildung von Prozessen im Tool ..................................................... 55<br />
7.1.12. Unzureichendes Training der betroffenen IT-Mitarbeiter .................................... 55<br />
7.1.13. Fehlende Ressourcen für Projektunterstützung .................................................... 55<br />
7.1.14. Falsche Priorisierung von Incidents ..................................................................... 55<br />
7.2. Fallbeispiele ................................................................................................................. 56<br />
7.2.1. Hessische Zentrale für Datenverarbeitung (HZD) ............................................... 56<br />
7.2.2. Führender deutscher DSL-Netzbetreiber für den Massenmarkt ........................... 56
Inhaltsverzeichnis III<br />
8 Vorgehensmodell.................................................................................. 58<br />
8.1. Initialisierung ............................................................................................................... 60<br />
8.1.1. Name des Projektes festlegen ............................................................................... 60<br />
8.1.2. Auswahl der Projektbeteiligten ............................................................................ 60<br />
8.1.3. Kick-off Veranstaltung durchführen .................................................................... 61<br />
8.1.4. Schulung der Projektmitglieder ............................................................................ 61<br />
8.1.5. Grobe Terminplanung .......................................................................................... 62<br />
8.1.6. Einbinden des Betriebs- bzw. Personalrats in den Planungsprozess .................... 62<br />
8.2. Zieldefinition ................................................................................................................ 63<br />
8.2.1. Zielworkshop veranstalten ................................................................................... 63<br />
8.2.2. Ziele dokumentieren ............................................................................................. 64<br />
8.2.3. Genehmigung der Ziele ........................................................................................ 64<br />
8.3. Analyse ......................................................................................................................... 64<br />
8.3.1. Ist-Analyse durchführen ....................................................................................... 64<br />
8.3.2. Erste Auswertung der Ergebnisse und Rückfrage ................................................ 66<br />
8.3.3. Handlungsfelder identifizieren und Handlungsempfehlungen ableiten ............... 66<br />
8.3.4. Anpassen der Terminplanung .............................................................................. 67<br />
8.3.5. Informationsveranstaltung für die IT-Mitarbeiter ................................................ 67<br />
8.4. Design .......................................................................................................................... 67<br />
8.4.1. Prozess-Workshop................................................................................................ 68<br />
8.4.2. Toolauswahl durchführen ..................................................................................... 73<br />
8.4.3. Prozessschulung durchführen ............................................................................... 74<br />
8.5. Durchführung der Implementierung ............................................................................ 74<br />
8.5.1. Projektmarketing betreiben .................................................................................. 74<br />
8.5.2. Tools einführen .................................................................................................... 75<br />
8.5.3. Anpassung der Tools ............................................................................................ 75<br />
8.5.4. Tool-Schulung ...................................................................................................... 75<br />
8.5.5. Erstellen von Arbeitsanweisungen ....................................................................... 75<br />
8.5.6. Erfahrungen dokumentieren und Verbesserungspotenziale identifizieren ........... 76<br />
8.6. Evaluierung und Weiterentwicklung ............................................................................ 76<br />
8.6.1. Review der Implementierung ............................................................................... 76<br />
8.6.2. Kontinuierlichen Verbesserungsprozess definieren und initiieren ....................... 77<br />
8.7. Abschluss ..................................................................................................................... 78<br />
9 Fazit ...................................................................................................... 79<br />
Quellenverzeichnis ................................................................................... VIII<br />
Eidesstattliche Erklärung ........................................................................... XII
Abkürzungsverzeichnis IV<br />
Abkürzungsverzeichnis<br />
Abb. Abbildung<br />
Abs. Absatz<br />
BSI British Standards Institution<br />
bzw. beziehungsweise<br />
Ca. circa<br />
CAB Change Advisory Board<br />
CCTA Central Computer and Telecommunications Agency<br />
CI Configuration Item<br />
CMDB Configuration Management Database<br />
CMS Configuration Management System<br />
DSL Digital Subscriber Line<br />
E-Mail Electronic Mail<br />
EC Emergency Committee<br />
EDV Elektronische Datenverarbeitung<br />
e. V. eingetragener Verein<br />
ggf. gegebenenfalls<br />
GITIMM Government Information Technology Infrastructure<br />
Management Method<br />
GmbH Gesellschaft mit beschränkter Haftung<br />
Hrsg. Herausgeber<br />
HZD Hessische Zentrale für Datenverarbeitung<br />
IfM Institut für Mittelstandsforschung<br />
IHK Industrie- und Handelskammer<br />
IT Informationstechnologie<br />
ITIL Information Technology Infrastructure Library<br />
ITSM IT Service Management<br />
itSMF IT Service Management Forum<br />
KMU Kleine und mittlere Unternehmen<br />
KPI Key Performance Indicator<br />
Mio. Millionen<br />
MoSCoW Must - Should - Could - Won't<br />
Nr. Nummer<br />
OGC Office of Government Commerce
Abkürzungsverzeichnis V<br />
OLA Operational Level Agreement<br />
PDCA Plan - Do - Check - Act<br />
RACI Responsible - Accountable - Consulted - Informed<br />
RfC Request for Change<br />
SLA Service Level Agreement<br />
SMART Spezifisch - Messbar - Akzeptiert - Realistisch - Terminierbar<br />
SWOT Strengths - Weaknesses - Opportunities - Threats<br />
Tab. Tabelle<br />
TMG Telemediengesetz<br />
UC Underpinning Contract<br />
u. U. unter Umständen<br />
vgl. vergleiche<br />
V3 Version 3<br />
VABI Verantwortlich - Ausführend - Beteiligt - Informiert<br />
z. B. zum Beispiel
Abbildungsverzeichnis VI<br />
Abbildungsverzeichnis<br />
Abb. 1: Aufbau der Arbeit ............................................................................................................ 2<br />
Abb. 2: Generisches Prozessmodell .............................................................................................. 3<br />
Abb. 3: ITIL V3 .......................................................................................................................... 10<br />
Abb. 4: Incident Model für sicherheitsrelevante Incidents ......................................................... 13<br />
Abb. 5: Incident Model für performancerelevante Incidents ...................................................... 13<br />
Abb. 6: Incident Management Prozess ........................................................................................ 16<br />
Abb. 7: Problem Management Prozess ....................................................................................... 24<br />
Abb. 8 - Anzahl der Mitarbeiter der befragten Unternehmen ..................................................... 36<br />
Abb. 9 - Branchen der befragten Unternehmen .......................................................................... 37<br />
Abb. 10 - Prozentuale Verteilung der ITIL-Nutzer ..................................................................... 37<br />
Abb. 11 - Ursachen für den Verzicht auf ITIL-basierte Standardprozesse ................................. 38<br />
Abb. 12 - Ursachen für die Nutzung von ITIL-basierten Standardprozessen ............................. 39<br />
Abb. 13 - Verbreitung der ITIL-basierten Prozesse und Funktionen .......................................... 41<br />
Abb. 14 - Noch einzuführende Prozesse und Funktionen ........................................................... 42<br />
Abb. 15 - Verwendete ITIL Version ........................................................................................... 43<br />
Abb. 16 - Anteil der Befragten mit Problemen bei der Einführung des Incident Managements 43<br />
Abb. 17 - Probleme bei der Einführung des Incident Managements .......................................... 44<br />
Abb. 18 - Anteil der Befragten mit Problemen bei der Einführung des Incident Managements 44<br />
Abb. 19 - Probleme bei der Einführung des Problem Managements .......................................... 45<br />
Abb. 20 - Vorgehensmodell ........................................................................................................ 59<br />
Abb. 21 - Beispielhafte Darstellung einer SWOT-Matrix .......................................................... 66<br />
Abb. 22 - Prozesshandbuch ......................................................................................................... 73<br />
Abb. 23 - PDCA-Zyklus ............................................................................................................. 77
Tabellenverzeichnis VII<br />
Tabellenverzeichnis<br />
Tab. 1 - KMU Definition des IfM Bonn ....................................................................................... 6<br />
Tab. 2 - Priorisierungssystematik ................................................................................................ 18<br />
Tab. 3 - Vor- und Nachteile der Erhebungsmethoden ................................................................ 29<br />
Tab. 4 - Fragebogen: 1. Block - Größe und Branche .................................................................. 31<br />
Tab. 5 - Fragebogen: 2. Block - Status quo von ITIL ................................................................ 31<br />
Tab. 6 - Fragebogen: 3. Block - Gründe für die Nutzung bzw. den Verzicht ............................. 31<br />
Tab. 7- Fragebogen: 4. Block: Verbreitung der ITIL-basierten Prozesse und Funktionen ......... 31<br />
Tab. 8 - Fragebogen: 5. Block: Bedarf an ITIL-basierten Prozessen und Funktionen ................ 32<br />
Tab. 9 - Fragebogen: 6. Block: Verwendete ITIL-Version ......................................................... 32<br />
Tab. 10 - Fragebogen: 7. Block - Probleme bei der Einführung des Incident Managements ..... 32<br />
Tab. 11 - Fragebogen: 8. Block - Probleme bei der Einführung des Problem Managements ..... 32<br />
Tab. 12 - Fragebogen: 9. Block Einfluss von ITIL auf die Prozesse .......................................... 33<br />
Tab. 13 - Zusammenhang zwischen Anzahl IT-Mitarbeiter und Nutzung von ITIL .................. 39<br />
Tab. 14 - Zusammenhang zwischen Anzahl EDV-Anwender und Nutzung von ITIL ............... 40<br />
Tab. 15 - Einfluss von ITIL auf die Benutzerfreundlichkeit der Prozesse ................................. 46<br />
Tab. 16 - Einfluss von ITIL auf die Effizienz der Prozesse ........................................................ 46<br />
Tab. 17 - Einfluss von ITIL auf die IT-Sicherheit im Unternehmen ......................................... 46<br />
Tab. 18 - Einfluss von ITIL auf die Prozessqualität im Unternehmen ....................................... 47<br />
Tab. 19 - Einfluss von ITIL auf die Transparenz der Prozesse .................................................. 47<br />
Tab. 20 - Einfluss von ITIL auf die Wirtschaftlichkeit der Prozesse .......................................... 48<br />
Tab. 21 - Einfluss von ITIL auf die Qualität des Sourcing ......................................................... 48<br />
Tab. 22 - Einfluss von ITIL auf die Reaktionszeit der IT ........................................................... 48<br />
Tab. 23 - Einfluss von ITIL auf die Stukturierung des IT-Betriebes .......................................... 49<br />
Tab. 24 - Einfluss von ITIL auf die Flexiblität der Prozesse ...................................................... 49<br />
Tab. 25 - RACI-Tabelle für das Incident Management .............................................................. 70<br />
Tab. 26 - Rollenbeschreibungen ................................................................................................. 70<br />
Tab. 27 - KPIs für das Incident und das Problem Management ................................................. 71<br />
Tab. 28 - Template für Verbesserungsvorschläge ....................................................................... 76
Einleitung 1<br />
1 Einleitung<br />
<strong>Die</strong> Rahmenbedingungen wirtschaftlichen Handelns werden schon seit einigen Jahren durch<br />
einen permanenten Wandel beeinflusst. Globalisierung und der daraus entstehende größere<br />
Konkurrenzdruck, sowie stetig wachsende Kundenerwartungen haben in den letzten Jahren zu<br />
einer steigenden Abhängigkeit der Unternehmen von der IT geführt. Somit hängt der Erfolg<br />
eines Unternehmens wesentlich von der Leistungsfähigkeit seiner IT-Architektur ab. Für eine<br />
Vielzahl von Unternehmen sind deren eingesetzte IT-Systeme unentbehrlich geworden, da sie<br />
tiefgreifend in die Abwicklung von Geschäftsprozessen eingebunden sind. <strong>Die</strong> IT-Systeme un-<br />
terstützten dabei oftmals die betrieblichen Abläufe und liefern Daten, die als Entscheidungs-<br />
grundlage dienen. Angesichts dieser Entwicklung hängt der Unternehmenserfolg maßgeblich<br />
von der Optimierung der einzelnen IT Prozesse ab um die Kosten zu senken, das Qualitätsni-<br />
veau zu verbessern und somit einen langfristigen Unternehmenserfolg gewährleisten zu <strong>können</strong>.<br />
Eine flexible Gestaltung der Geschäftsmodelle sowie der Unternehmensstrategien ist unver-<br />
meidbar um sich an die Bedingungen der dynamischen Märkte anpassen zu <strong>können</strong>. Aus diesem<br />
Grund ist es notwendig, dass Unternehmen ihre organisatorischen Strukturen, vor allem aber<br />
ihre Prozesse und Abläufe an die neuen Anforderungen anpassen. In dieser sich ständig wan-<br />
delnden Unternehmenslandschaft wird von IT-Abteilungen eine ständige Flexibilität sowie kur-<br />
ze Reaktionszeiten erwartet. <strong>Die</strong> unmittelbare Bereitstellung von kundenspezifischen qualitativ<br />
hochwertiger IT-Services müssen trotz immer fortwährenden Kürzungen der IT-Budgets prob-<br />
lemlos bereitgestellt werden.<br />
Gerade mittelständische Unternehmen sind aufgrund ihres geringen Eigenkapitals, sowie der<br />
wenigen menschlichen Ressourcen maßgeblich von ihren Prozessen abhängig. 1 Folglich ist eine<br />
Optimierung der Geschäftsprozesse besonders wichtig.<br />
Mit ITIL steht eine Sammlung fachlich-methodischer Good-Practices zur Verfügung, die auf die<br />
Optimierung von Prozessen abzielt und somit zum Erreichen der gesetzten Ziele beisteuern<br />
kann.<br />
1 Vgl. Nienstermann, M.: Service Management-Lösungen für KMU, Saarbrücken 2007, S.16.
Einleitung 2<br />
1.1. Zielsetzung der Arbeit<br />
<strong>Die</strong> Zielsetzung dieser Arbeit ist die Ermittlung des Status quo von ITIL in mittelständischen<br />
Unternehmen und Unternehmen mittlerer Größe sowie die Erarbeitung eines optimierten Vor-<br />
gehensmodells, mit dessen Hilfe das Incident und das Problem Management im Unternehmen<br />
implementiert werden kann.<br />
1.2. Aufbau der Arbeit<br />
<strong>Die</strong> vorliegende <strong>Bachelorarbeit</strong> gliedert sich inhaltlich in drei wesentliche Abschnitte. Der erste<br />
Abschnitt beschreibt den Hintergrund und die Zielsetzung dieser Arbeit und wird in Kapitel 1<br />
erläutert. Im zweiten Abschnitt werden die theoretischen Grundlagen dieser Arbeit beschrieben.<br />
Im Rahmen dessen werden die notwendigen allgemeinen Grundlagen für das Verständnis von<br />
ITIL (Kapitel 2) vorgestellt. Basierend auf diesen Grundlagen wird im dritten Kapitel das ITIL<br />
Framework vorgestellt. <strong>Die</strong> beiden Prozesse Incident und Problem Management werden im<br />
vierten Kapitel präsentiert. Dabei werden die für das Verständnis der Prozesse notwendigen<br />
Begriffe, Aktivitäten, Rollen, Schnittstellen und Ziele detailliert beschrieben. Der dritte Ab-<br />
schnitt und gleichzeitig Schwerpunkt dieser Arbeit beschreibt das Vorgehen bei der Erhebung<br />
der Daten (Kapitel 5), das Ergebnis der Umfrage (Kapitel 6) und die typischen Probleme, die<br />
bei der Einführung von Incident und Problem Management (Kapitel 7) auftreten <strong>können</strong>. Auf<br />
Basis dieser Informationen werden anschließend Lösungsvorschläge erarbeitet, die in das Vor-<br />
gehensmodell einfließen und in Kapitel 8 vorgestellt werden.<br />
1. Abschnitt: Motivation<br />
2. Abschnitt: Theorie<br />
3. Abschnitt: Praktische Umsetzung<br />
Abb. 1: Aufbau der Arbeit<br />
Kapitel 1: Einleitung<br />
Kapitel 2: Grundlagen - Begriffe und Definitionen<br />
Kapitel 3: IT Infrastructure Library im Überblick<br />
Kapitel 4: ITIL-basierte Prozesse im Detail<br />
Incident- und Problem Management<br />
Kapitel 5: Erhebung der Daten<br />
Kapitel 6: Status quo von ITIL<br />
Kapitel 7: Probleme bei der Einführung<br />
Kapitel 8: Vorgehensmodell
Grundlagen - Begriffe und Definitionen 3<br />
2 Grundlagen - Begriffe und Definitionen<br />
Das zweite Kapitel beschreibt Begriffe und Definitionen, die als Grundlage für die nachfolgen-<br />
den Ausführungen dienen.<br />
2.1. Prozess<br />
Ein Prozess ist eine chronologische Abfolge aller Schritte, die zum Erreichen eines festgelegten<br />
Ziels erforderlich sind. 2 Aus diesem Grund ist eine klare Zielvorgabe zwingend notwendig, um<br />
eine zielorientierte Veränderung zu ermöglichen. Voraussetzung für eine zielorientierte Verän-<br />
derung ist ein definierter Input, der mit Hilfe der Aktivitäten des Prozesses in einen definierten<br />
Output umgewandelt wird. 3 <strong>Die</strong>ser Vorgang wird als generischer Prozess bezeichnet. Für das<br />
Ergebnis eines Prozesses gilt, dass es einzeln identifizierbar und messbar sein muss. Darüber<br />
hinaus verfügt jeder Prozess über ein auslösendes Ereignis, ist zeitlich unbegrenzt, beliebig oft<br />
reproduzierbar und hat einen Kunden, der auf das Prozessergebnis angewiesen ist. 4<br />
Abb. 2: Generisches Prozessmodell 5<br />
Beispiel:<br />
Ein Prozess ist z. B. das Incident Management.<br />
2 vgl. Olbrich, A.: ITIL kompakt und verständlich, 4. Auflage, Wiesbaden 2008, S. 9.<br />
3 Vgl. Ebel, N.: ITIL® V3 Basis-Zertifizierung, 1. Auflage, München 2008, S. 45.<br />
4 vgl. Olbrich, A.: ITIL kompakt und verständlich, 4. Auflage, Wiesbaden 2008, S. 9.<br />
5 Entnommen aus: Office of Government Commerce: Service Operation, London 2007, S. 15.
Grundlagen - Begriffe und Definitionen 4<br />
2.2. Funktion<br />
Eine Funktion ist eine unabhängige spezialisierte Organisationseinheit, die mit Hilfe von eige-<br />
nen Werkzeugen und Methoden das Ausführen bestimmter Tätigkeiten ermöglicht und die Ver-<br />
antwortung für die Erbringung des Ergebnisses trägt. 6 In der Regel werden für eine Funktion<br />
Aufgaben, Entscheidungskompetenzen und Verantwortlichkeiten festgelegt, die eine effektive<br />
Funktionsausübung ermöglichen.<br />
Beispiel:<br />
Eine Funktion ist z. B. der Service Desk. Der Service Desk dient den Anwendern als zentrale<br />
Anlaufstelle und informiert die Anwender gegebenenfalls über Veränderungen an der IT-<br />
Infrastruktur.<br />
2.3. Rolle<br />
Eine Rolle wird in einem Prozess definiert und dient der Zuweisung von Verantwortlichkeiten,<br />
Aktivitäten, Kompetenzen und kann von einer oder mehreren Personen wahrgenommen werden,<br />
wobei mehrere Rollen auch von ein und derselben Person ausgeübt werden <strong>können</strong>. 7<br />
<strong>Die</strong> wichtigsten Rollen sind:<br />
� Prozess-Owner 8<br />
� Prozess-Manager<br />
� Prozess-Mitarbeiter<br />
2.3.1. Prozess-Owner<br />
Der Prozess-Owner trägt die Verantwortung für die Definition, die Dokumentation und die<br />
Zielerreichung des Prozesses. Darüber hinaus ist er verantwortlich für die Definition der Kenn-<br />
zahlen. 9<br />
2.3.2. Prozess-Manager<br />
Der Prozess-Manager ist verantwortlich für die Überwachung und Einhaltung der Prozessquali-<br />
tät auf Basis der definierten Ziele, die Steuerung der Prozessaktivitäten und die Koordination<br />
der Schnittstellen. 10<br />
6<br />
Vgl. Olbrich, A.: ITIL kompakt und verständlich, 4. Auflage, Wiesbaden 2008, S. 160.<br />
7<br />
Vgl. Kempter, A.: Rollen in ITIL V3, 2010, http://wiki.de.it-processmaps.com/index.php/Rollen_in_ITIL_V3,<br />
11.03.2010.<br />
8<br />
In der Literatur wird auch von Prozess-Besitzer gesprochen.<br />
9<br />
Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.159.<br />
10<br />
Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.160.
Grundlagen - Begriffe und Definitionen 5<br />
2.3.3. Prozess-Mitarbeiter<br />
Der Prozess-Mitarbeiter sorgt für die operative Ausführung der Aktivitäten des Prozesses und<br />
eskaliert im Problemfall an den Prozess-Manager. 11<br />
2.4. Key Performance Indikatoren<br />
Ein Key Performance Indikator (KPI) ist eine Messgröße mit der man die Qualität eines Prozes-<br />
ses, eines IT-Service oder einer Aktivität messen kann. Innerhalb der IT <strong>können</strong> zahlreiche<br />
Messungen durchgeführt werden, jedoch werden nur die wichtigsten Messgrößen als KPIs defi-<br />
niert.<br />
2.5. IT-Service<br />
Ein IT-Service ist ein Nutzeneffekt, den ein IT-Service-Provider 12 für einen Kunden oder meh-<br />
rere Kunden durch die Kombination von Personen, Prozessen und Technologien erbringt. 13<br />
Beispiel:<br />
Vergabe einer E-Mailadresse an einen Kunden.<br />
2.6. IT-Service Management<br />
IT-Service Management ist die Ausrichtung der IT an die aktuellen und zukünftigen Anforde-<br />
rungen des Unternehmens und seiner Kunden durch die Steuerung der Qualität und Quantität<br />
der IT-Services. Das IT-Service Management umfasst Prozesse und Verfahren, die eine zielge-<br />
richtete, kundenfreundliche und kundenoptimierte Planung, Steuerung, Erbringung und Kontrol-<br />
le der IT Services ermöglicht, um den Kunden ein Höchstmaß an IT-Servicequalität zu bieten<br />
und eine Senkung aller anfallenden Kosten für die verschiedenen Servicetätigkeiten zu verwirk-<br />
lichen. 14 Aus diesem Grund sollten im Rahmen des IT-Service Management Begriffe normiert,<br />
Arbeitsabläufe standardisiert und Prozesse transparent gestaltet werden.<br />
2.7. Mittelstand<br />
Das Institut für Mittelstandsforschung Bonn definiert Unternehmen, die bis zu neun Mitarbeiter<br />
beschäftigen oder weniger als 1 Mio. € Jahresumsatz erwirtschaften als kleine Unternehmen.<br />
Unternehmen mit 10 bis 499 Beschäftigten respektive einem Jahresumsatz von 1 Mio. € bis<br />
11 Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.160.<br />
12 Ein IT-Service-Provider ist ein <strong>Die</strong>nstleister, der seinen Kunden einen IT-Service anbietet.<br />
13 Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 172.<br />
14 Vgl. ITIL.org: ITIL.org - Service Management,<br />
http://www.itil.org/de/vomkennen/itil/ueberblick/servicemanagement.php, 09.02.2010.
Grundlagen - Begriffe und Definitionen 6<br />
unter 50 Mio. € werden als mittlere Unternehmen definiert. Unternehmen die 500 und mehr<br />
Beschäftigte bzw. einen Umsatz von 50 Mio. € und mehr erwirtschaften werden als Großunter-<br />
nehmen bezeichnet. 15<br />
Tab. 1 - KMU Definition des IfM Bonn 16<br />
Unternehmensgröße Zahl der Beschäftigten Umsatz € / Jahr<br />
klein bis 9 bis unter 1 Millionen<br />
mittel 10 bis 499 1 bis unter 50 Millionen<br />
Mittelstand (KMU) zusammen bis 499 bis unter 50 Millionen<br />
groß 500 und mehr 50 Millionen und mehr<br />
15<br />
Vgl. Bundesministerium für Wirtschaft und Technologie (Hrsg.): Der Mittelstand der Bundesrepublik Deutschland,<br />
Berlin 2007, S 9.<br />
16<br />
In Anlehnung an: Institut für Mittelstandsforschung Bonn (Hrsg.): IfM Bonn Institut für Mittelstandsforschung<br />
Bonn, http://www.ifm-bonn.org/index.php?id=89, 09.02.2010.
IT Infrastructure Library im Überblick 7<br />
3 IT Infrastructure Library im Überblick<br />
ITIL steht für Information Technology Infrastructure Library und ist ein Good-Practice-<br />
Leitfaden, der aus der Praxis gewonnene Erkenntnisse, Modelle und Architekturen beschreibt,<br />
die als Richtlinie für den systematischen Aufbau und Betrieb einer abgestimmten professionel-<br />
len IT-Servicestruktur verwendet werden <strong>können</strong>. 17 Der Fokus von ITIL liegt dabei vordergrün-<br />
dig auf der stetigen und dauerhaften Verbesserung der Qualität der erbrachten IT-Services. ITIL<br />
liefert allerdings keine detaillierte Anleitung wie die Implementierung von ITIL erfolgen sollte,<br />
sondern beschreibt stattdessen was zu tun ist. Im Zuge dessen werden die abzubildenden Pro-<br />
zesse, Rollen, und Aufgaben vorgestellt, jedoch nicht wie diese im Einzelfall umzusetzen sind. 18<br />
Eine konkrete Umsetzung von ITIL erfolgt durch eine Anpassung der Inhalte an die individuel-<br />
len Bedürfnisse des einführenden Unternehmens, um einen bestmöglichen Erfolg zu gewährleis-<br />
ten. Dank der langjährigen Praxiserfahrung bietet ITIL eine hohe Zuverlässigkeit und hat sich<br />
mittlerweile als international anerkannter De-Facto Standard etabliert. 19<br />
3.1. Geschichte<br />
Seinen Ursprung hatte ITIL Mitte der 80er Jahre. <strong>Die</strong> damalige britische Regierung unter der<br />
Federführung der britischen Premierministerin Margaret Thatcher, beauftrage die „Central<br />
Computer and Telecommunications Agency” (CCTA) mit einer Studie. <strong>Die</strong>se hatte das Ziel,<br />
die Geschäftsprozesse der IT der britischen Regierungsstellen zu analysieren, zu beschreiben<br />
und Mittel und Wege zu finden, die stetig steigenden IT-Kosten der britischen Behörden in den<br />
Griff zu bekommen. 20 Im Rahmen dieser Studie wurde eine umfangreiche Befragung und Ist-<br />
Aufnahme in repräsentativen IT <strong>Die</strong>nstleistungsunternehmen, Rechenzentren, sowie bei Kunden<br />
und Lieferanten durchgeführt.<br />
Das Ergebnis dieser Befragung wurde im Jahr 1988 unter dem Namen „Government Informati-<br />
on Technology Infrastructure Management Method” (GITIMM) als Leitlinie für den IT-Betrieb<br />
englischer Behörden veröffentlicht. GITIMM wurde für eine Mehrzahl an Unternehmen aber<br />
erst interessant, nachdem die behördlich geprägten Prozesse an die Bedürfnisse der Industrie<br />
angepasst wurden. 21 Im Zuge dieser Anpassung wurde der Leitfaden überarbeitet und nament-<br />
lich an die neuen Gegebenheiten angepasst, bevor im Jahr 1989 mit dem „Service Level Mana-<br />
17 Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 1.<br />
18 Vgl. Olbrich, A.: ITIL kompakt und verständlich, 4. Auflage, Wiesbaden 2008, S. 1 .<br />
19 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 12.<br />
20 Vgl. Schiefer, H.; Schitter, E.: Prozesse optimieren mit ITIL ® , 2. Auflage ,Wiesbaden 2008, S. 3.<br />
21 Vgl. Ebel, N.: ITIL® V3 Basis-Zertifizierung, 1. Auflage, München 2008, S. 56.
IT Infrastructure Library im Überblick 8<br />
gement“ das erste Buch des ITIL Frameworks veröffentlicht wurde. Auch die im April 2001<br />
erfolgte Eingliederung der CCTA in das Office of Government Commerce (OGC) hatte keinen<br />
negativen Einfluss auf die Weiterentwicklung des ITIL Frameworks, denn die OGC arbeitet<br />
auch heute noch in Zusammenarbeit mit zahlreichen Management Instituten und Foren an der<br />
stetigen Verbesserung des ITIL Frameworks. 22<br />
Im Juni 2007 publizierte das OGC mit der dritten Version der IT Infrastructure Library eine<br />
neue, überarbeitete Version, deren auffälligste Änderung die Etablierung einer neuen Struktur<br />
war. <strong>Die</strong>se Struktur umfasst die folgenden drei Bereiche:<br />
� ITIL Core<br />
� ITIL Complementary Guidance<br />
� ITIL Web Support Services<br />
3.2. ITIL V3<br />
<strong>Die</strong> neue ITIL V3 beschreibt die Rolle der IT nicht länger aus der operativen Sicht, sondern in<br />
erster Linie als IT-Service-Provider und Enabler für seine Kunden. Den Fokus legt ITIL V3 auf<br />
die Bereitstellung der IT-Services und das dafür notwendige IT-Service Management. Auf diese<br />
Weise kann die IT flexibel reagieren, um den wechselnden Anforderungen der Kunden zu ge-<br />
nügen. Aus diesem Grund wurde der ITIL Service Lifecycle entwickelt.<br />
3.3. IT Service Lifecylce<br />
Der ITIL Service Lifecycle besteht aus insgesamt fünf Phasen, die jeweils in einer eigenen<br />
Kernpublikation beschrieben werden. Bei den fünf Kernpublikationen handelt es sich um:<br />
� Service Strategy<br />
� Service Design<br />
� Service Transition<br />
� Service Operation<br />
� Continual Service Improvement<br />
Ergänzt werden die fünf Kernpublikationen durch das Buch The official introduction to the ITIL<br />
Service Lifecycle.<br />
22 Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 1.
IT Infrastructure Library im Überblick 9<br />
3.3.1. Service Strategy<br />
<strong>Die</strong> ITIL Kernpublikation Service Strategy fokussiert die strategische Einordnung von IT-<br />
Services und liefert eine Beschreibung, wie das IT-Service Management gestaltet, entworfen<br />
und implementiert werden kann. 23<br />
3.3.2. Service Design<br />
<strong>Die</strong> ITIL Kernpublikation Service Design liefert eine Zusammenfassung der Prozesse, die für<br />
eine Entwicklung und Gestaltung von Services und Service Management Prozessen eine we-<br />
sentliche Rolle spielen. 24 <strong>Die</strong> folgenden Stichpunkte 25 beschreiben die inhaltlichen Schwerpunk-<br />
te der ITIL-Publikation Service Design:<br />
� Service Catalogue Management<br />
� Service Level Management<br />
� Capacity Management<br />
� Availability Management<br />
� IT Continuity Management<br />
� IT Security Management<br />
� Supplier Management<br />
3.3.3. Service Transition<br />
Das ITIL Buch Service Transition beschreibt Prozesse und Verfahren, mit deren Hilfe sowohl<br />
neue als auch angepasste IT-Services im operativen IT-Betrieb implementiert werden <strong>können</strong>. 26<br />
<strong>Die</strong> Kernthemen 27 dieser Publikation sind:<br />
� Transition Planning<br />
� Change Management<br />
� Service Asset & Configuration Management<br />
� Release Management<br />
3.3.4. Service Operation<br />
<strong>Die</strong> ITIL Publikation Service Operation beschreibt Prozesse und Methoden, die eine optimierte<br />
Bereitstellung von IT Services sowie einen optimierten Support ermöglichen. 28<br />
<strong>Die</strong> inhaltlichen Schwerpunkte 29 bilden:<br />
23 ®<br />
Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL V3, 1. Auflage, Hannover 2008, S. 3.<br />
24 ®<br />
Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL V3, 1. Auflage, Hannover 2008, S. 3.<br />
25 ®<br />
Böttcher, R.: IT-Servicemanagement mit ITIL V3, 1. Auflage, Hannover 2008, S. 3.<br />
26 ®<br />
Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL V3, 1. Auflage, Hannover 2008, S. 3.<br />
27 ®<br />
Böttcher, R.: IT-Servicemanagement mit ITIL V3, 1. Auflage, Hannover 2008, S. 3.<br />
28 ®<br />
Vgl. Buchsein, R.; Victor, F.; Günther, H.; Machmeier, V.: IT-Management mit ITIL V3, 2. Auflage, Wiesbaden<br />
2008, S. 37.<br />
29 ®<br />
Böttcher, R.: IT-Servicemanagement mit ITIL V3, 1. Auflage, Hannover 2008, S. 3.
IT Infrastructure Library im Überblick 10<br />
� Event Management<br />
� Incident Management<br />
� Request Fulfilment<br />
� Problem Management<br />
� Access Management<br />
3.3.5. Continual Service Improvement<br />
Das Continual Service Improvement befasst sich mit der kontinuierlichen und systematischen<br />
Qualitätsverbesserung von IT-Services durch die Integration bewährter Prinzipen, Verfahren<br />
und Methoden des Capability Improvements sowie des Qualitäts und Change Managements. 30<br />
3.3.6. Complementary Set<br />
Komplettiert wird die ITIL V3 Publikation durch das umfangreiche Complementary Set, das<br />
sich aus den Themengebieten „Speciality Topics, Knowledge & Skills, Governance Methodes,<br />
Standard Alignment, Case Studies, Templates, Executive Introductions, Study Aids,<br />
Qualifications, Quick Wins und Scalability‟ 31 zusammensetzt.<br />
Abb. 3: ITIL V3 32<br />
In Abbildung 3 wird der Zusammenhang der einzelnen Phasen dargestellt. Im Kern des IT-<br />
Service Lifecycle befindet sich die Service Strategy, die die Achse des IT-Service Lifecycle<br />
bildet. <strong>Die</strong> Phasen Service Design, Service Operation und Service Transition sind kreisförmig<br />
um die Strategien angeordnet. Das Continual Service Improvement umfasst die vier Phasen und<br />
veranschaulicht auf diese Weise die kontinuierliche Verbesserung über alle Phasen hinweg.<br />
30 Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 3.<br />
31 Olbrich, A.: ITIL kompakt und Verständlich, 4. Auflage, Wiesbaden 2008, S.144.<br />
32 Entnommen aus: Ebel, N.: ITIL v3® Basis-Zertifizierung, 1. Auflage, München 2008, S. 32.
ITIL-basierte Prozesse im Detail 11<br />
4 ITIL-basierte Prozesse im Detail<br />
Im vierten Kapitel werden das Incident und Problem Management sowie der Service Desk de-<br />
tailliert vorgestellt.<br />
4.1. Incident Management<br />
Das Incident Management ist ein Prozess mit der Zielsetzung, anfallende Incidents 33<br />
schnellstmöglich zu beheben um die Funktionalität des IT-Betriebes wiederherzustellen und<br />
mögliche negative Auswirkungen auf betroffene Geschäftsprozesse abzuwenden. 34<br />
4.1.1. Begriffe<br />
Zum besseren Verständnis werden im Folgenden einige Begriffe vorgestellt, die für das Ver-<br />
ständnis des Incident Managements notwendig sind.<br />
Configuration Item (CI)<br />
Configuration Items sind alle, für die Bereitstellung eines IT-Services notwendigen Komponen-<br />
ten. <strong>Die</strong> dazugehörigen Informationen werden in einem Configuration Management System<br />
(CMS) erfasst und mit Hilfe des Configuration Management verwaltet. 35<br />
Beispiel:<br />
Ein Configuration Item ist z. B. ein Monitor.<br />
Incident<br />
Ein Incident ist „ein Ereignis, das nicht zum standardmäßigen Betrieb eines Service gehört und<br />
das tatsächlich oder potenziell eine Unterbrechung oder Minderung der Service-Qualität verur-<br />
sacht." 36 Aber auch ausgefallene CIs, deren Ausfall keine direkte Auswirkung auf den Kunden<br />
hat, werden als Incidents bezeichnet.<br />
Beispiel:<br />
Der Ausfall einer Festplatte, die sich im Raid-5 Cluster befindet. <strong>Die</strong>ser Ausfall hat keine di-<br />
rekte Auswirkung, da der Cluster auch ohne die ausgefallene Festplatte funktioniert. Trotzdem<br />
handelt es sich um einen Incident.<br />
33<br />
In der Literatur wird häufig auch der Begriff Störung verwendet.<br />
34<br />
Vgl. Böttcher, R. IT-Servicemanagement mit ITIL® V3, 1. Auflage, Hannover 2008, S. 133.<br />
35 ®<br />
Vgl. Buchsein, R.; Victor, F.; Günther, H.; Machmeier, V.: IT-Management mit ITIL V3, 2. Auflage, Wiesbaden<br />
2008, S. 354.<br />
36<br />
Office of Government Commerce: Service Operation, London 2007, S. 86.
ITIL-basierte Prozesse im Detail 12<br />
Service Desk<br />
Der Service Desk ist eine zentrale Anlaufstelle, an die sich die Kunden wenden <strong>können</strong>, wenn<br />
Unterstützungsbedarf besteht. 37 Dabei fungiert der Service Desk als Schnittstelle zwischen den<br />
Kunden und den IT-Mitarbeitern. 38<br />
Service Level Agreement (SLA)<br />
Ein Service Level Agreement ist eine Vereinbarung zwischen einem IT-Service-Provider und<br />
einem Kunden hinsichtlich der zu leistenden IT-Services. 39<br />
Operational Level Agreement (OLA)<br />
Ein OLA ist eine „Vereinbarung zwischen einem IT-Service-Provider und einem anderen Teil<br />
derselben Organisation. Ein OLA unterstützt die Bereitstellung von IT-Services durch den IT-<br />
Service-Provider für den Kunden. Das OLA definiert die zu liefernden Waren oder Services und<br />
die Verantwortlichkeiten der beiden Parteien.‟ 40<br />
Underpinning Contract (UC)<br />
Ein Underpinning Contract ist „ein Vertrag zwischen einem IT-Service-Provider und einer<br />
Drittpartei. <strong>Die</strong> Drittpartei stellt Waren oder Services zur Verfügung, die die Bereitstellung<br />
eines IT-Service für einen Kunden unterstützen. Der Underpinning Contract definiert Ziele und<br />
Verantwortlichkeiten, um die in einem SLA vereinbarten Service-Level-Ziele zu erreichen.‟ 41<br />
Service Request<br />
Ein Service Request ist die Anfrage eines Anwenders nach Informationen, Beratung, einem<br />
Standard-Change oder nach Zugriff auf einen IT- Service. 42<br />
Beispiel:<br />
Ein Service-Request ist z. B. die Anfrage eines Anwenders beim Service Desk mit der Bitte das<br />
Passwort eines Benutzer-Accounts zurückzusetzen.<br />
Workaround<br />
Ein Workaround ist eine Übergangslösung, die zur Reduzierung der Auswirkung eines Incident<br />
beiträgt und solange genutzt wird, bis eine endgültige Lösung zur Beseitigung des Incident zur<br />
Verfügung steht. 43<br />
37 Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 126.<br />
38 Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 127.<br />
39 Vgl. Nienstermann, M.: Service Management-Lösungen für KMU, Saarbrücken 2007, S.60.<br />
40 Office of Government Commerce: Service Operation, London 2007, S. 381.<br />
41 Office of Government Commerce: Service Operation, London 2007, S. 394.<br />
42 Vgl. Böttcher, R. IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 134.<br />
43 Vgl. Buchsein, R.; Victor, F.; Günther, H.; Machmeier, V.: IT-Management mit ITIL ® V3, 2. Auflage, Wiesbaden<br />
2008, S. 368.
ITIL-basierte Prozesse im Detail 13<br />
4.1.2. Prinzipien<br />
Zeitvorgaben<br />
Basierend auf den vereinbarten SLA sollte für die Bearbeitung der unterschiedlichen Phasen der<br />
Incident-Abwicklung eine bestimmte Zeit definiert werden, die zur Bearbeitung des Incident zur<br />
Verfügung steht. <strong>Die</strong>se Zeit sollte als festgelegtes Ziel in den OLA oder Underpinning<br />
Contracts festgehalten werden und als Zielvorgabe dienen. Für eine einheitliche Einhaltung der<br />
Zeitvorgaben ist es wichtig, dass alle betroffenen Support-Gruppen über diese Zeitvorgaben<br />
informiert werden. 44<br />
Incident Modell<br />
Um das Incident Management effektiver zu gestalten, sollten im Vorfeld Incident Modelle defi-<br />
niert werden. Incident Modelle ermöglichen eine effektivere Bearbeitung von erneut auftreten-<br />
den Incidents. <strong>Die</strong>se <strong>können</strong> durch den bereits vorher festgelegten Ablauf innerhalb des vorge-<br />
gebenen Zeitrahmens gehandhabt werden. Auf diese Weise werden Incidents, die eine spezielle<br />
Behandlung erfordern, zielgerichtet an den zuständigen Prozess weitergeleitet. 45<br />
Beispiel: Sicherheitsrelevante Incidents<br />
Für sicherheitsrelevante Incidents könnte gelten, dass alle benötigten Informationen automati-<br />
siert an das Security Management weitergeleitet werden.<br />
Annahme und<br />
Dokumentation<br />
Abb. 4: Incident Model für sicherheitsrelevante Incidents<br />
Beispiel: Performancerelevante Incidents<br />
Für performancerelevante Incidents könnte gelten, dass sie automatisch an das Capacity Mana-<br />
gement weitergeleitet werden.<br />
Annahmen und<br />
Dokumentation<br />
Prüfung<br />
Prüfung<br />
Abb. 5: Incident Model für performancerelevante Incidents<br />
44 Vgl. Office of Government Commerce: Service Operation, London 2007, S. 54.<br />
45 Vgl. Office of Government Commerce: Service Operation, London 2007, S. 54.<br />
Weiterleitung an<br />
Security<br />
Management<br />
Weiterleitung an<br />
das Capacity<br />
Management
ITIL-basierte Prozesse im Detail 14<br />
Major Incidents<br />
Major Incidents sind kritische Störungen, die einen besonders großen Einfluss auf die Ge-<br />
schäftsprozesse des Unternehmens haben und somit besondere Maßnahmen für eine sofortige<br />
Servicewiederherstellung erfordern. Bedingt durch die besondere Relevanz des Major Incidents<br />
gelten oftmals wesentlich kürzere Bearbeitungszeiten und es muss eine höhere Dringlichkeit<br />
verwendet werden. Für eine effektive Abwicklung sollte eine Definition des Major Incidents<br />
vereinbart und auf das Gesamtsystem der Incident-Priorisierung abgestimmt werden. 46<br />
4.1.3. Rollen<br />
Im Rahmen des Incident Managements sollten die folgenden Rollen festgelegt werden:<br />
Incident Manager<br />
Der Incident Manager ist für die effektive Durchführung des Incident Managements verantwort-<br />
lich. 47 Zu seinen Hauptaufgaben gehört die Implementierung und kontinuierliche Verbesserung<br />
des Incident Managements, sowie die Planung der notwendigen Ressourcen. Aber auch die<br />
Kommunikation mit den anderen Prozess-Managern und die Erstellung von Managementberich-<br />
ten gehört zu seinen Aufgaben.<br />
1st Level Support<br />
Der 1st Level Support ist die „erste Prozessstufe im Incident Management‟ 48 und im Falle einer<br />
eingehenden Störungsmeldung der erste Ansprechpartner für den Kunden. Im Zuge dessen<br />
kümmert sich der 1st Level Support um die sofortige Behebung von einfachen Incidents. 49<br />
Wenn der Incident an dieser Stelle nicht mit angemessenem Aufwand behoben werden kann,<br />
kommt es zur Eskalation zum 2nd Level Support.<br />
2nd Level Support<br />
Der 2nd Level Support „ist die zweite Prozessstufe im Incident Management‟ 50 und übernimmt<br />
die Störungsmeldungen vom 1st Level Support. Im 2nd Level Support sind Spezialisten tätig,<br />
die sich um die Behebung des Incident kümmern. Wenn dies nicht möglich ist wird bei Bedarf<br />
die Unterstützung des 3rd Level Support angefordert. Falls ein Problem die Ursache für den<br />
Incident ist, so wird der Incident an das Problem Management übergeben. 51<br />
46 Vgl. Office of Government Commerce: Service Operation, London 2007, S. 55.<br />
47 Vgl. Kempter, A.: Rollen in ITIL V3, 2010, http://wiki.de.it-processmaps.com/index.php/Rollen_in_ITIL_V3,<br />
11.03.2010.<br />
48 Schiefer, H.; Schitter, E.: Prozesse optimieren mit ITIL ® , 2. Auflage ,Wiesbaden 2008, S. 274.<br />
49 vgl. Olbrich, A.: ITIL kompakt und verständlich, 4. Auflage, Wiesbaden 2008, S. 31.<br />
50 Schiefer, H.; Schitter, E.: Prozesse optimieren mit ITIL ® , 2. Auflage ,Wiesbaden 2008, S. 274.<br />
51 Vgl. Kempter, A.: Rollen in ITIL V3, 2010, http://wiki.de.it-processmaps.com/index.php/Rollen_in_ITIL_V3,<br />
11.03.2010.
ITIL-basierte Prozesse im Detail 15<br />
3rd Level Support<br />
Beim 3rd Level Support handelt es sich üblicherweise um die Hersteller von Hardware- oder<br />
Softwareprodukten, die zur schnellstmöglichen Behebung des Incident kontaktiert werden. 52<br />
Major Incident Team<br />
Das Major Incident Team ist ein dynamisch gegründetes Team bestehend aus IT-Managern und<br />
IT-Spezialisten, die unter der Leitung des Incident Managers die Erarbeitung einer Lösung für<br />
die Behebung des Major Incidents anstreben. 53<br />
52<br />
Vgl. Kempter, A.: Rollen in ITIL V3, 2010, http://wiki.de.it-processmaps.com/index.php/Rollen_in_ITIL_V3,<br />
11.03.2010.<br />
53<br />
Vgl. Kempter, A.: Rollen in ITIL V3, 2010, http://wiki.de.it-processmaps.com/index.php/Rollen_in_ITIL_V3,<br />
11.03.2010.
ITIL-basierte Prozesse im Detail 16<br />
4.1.4. Prozessablauf des Incident Managements<br />
Management<br />
Eskalation<br />
Über Event<br />
Management<br />
Major Incident<br />
Verfahren<br />
Ja<br />
HierarchiHierarchischescheEskalation<br />
Eskalation erfor-<br />
erforderlich?<br />
derlich ?<br />
Abb. 6: Incident Management Prozess 54<br />
Über Weboberfläche Anruf eines Anwenders<br />
Ja<br />
Nein<br />
Ja<br />
Incident Identifizierung<br />
Incident Erfassung<br />
Incident Kategorisierung<br />
Service Request?<br />
Incident Priorisierung<br />
Major Incident?<br />
Erstdiagnose<br />
Funktionale<br />
Eskalation<br />
erforderlich ?<br />
Untersuchung und<br />
Diagnose<br />
Lösung und<br />
Wiederherstellung<br />
Incident Abschluss<br />
Nein<br />
54 Entnommen aus: Office of Covernment Commerce: Service Operation, London 2007, S.56.<br />
Ende<br />
Nein<br />
Nein<br />
Ja<br />
Ja<br />
E-Mail eines techni-<br />
schen Mitarbeiters<br />
An Request<br />
Fulfilment<br />
Funktionale Eskalation<br />
2/3 Level
ITIL-basierte Prozesse im Detail 17<br />
Der Incident Management Prozess umfasst die folgenden Aktivitäten:<br />
Identifikation von Incidents<br />
Ein Incident kann nicht behoben werden, bevor dieser nicht erkannt wird. Aus diesem Grund<br />
empfiehlt ITIL die Überwachung aller wichtigen IT Komponenten um Incidents frühzeitig zu<br />
erkennen und diesen durch den Anstoß des Incident Management Prozesses frühzeitig entge-<br />
genzuwirken. Im Idealfall sollte die Behebung des Incident bereits erfolgt sein, bevor der Inci-<br />
dent sich negativ auf die Kunden und deren Arbeitsleistung auswirkt. 55<br />
Incident-Erfassung<br />
Ein Ziel des Incident Managements ist eine zügige Störungsbehebung. Voraussetzung für eine<br />
zügige Störungsbehebung ist eine zentrale Störungsannahmestelle, an die sich die Anwender im<br />
Falle eines Incident wenden <strong>können</strong>. <strong>Die</strong> Aufgabe dieser Störungsannahmestelle ist die Koordi-<br />
nation der einzelnen Incidents. ITIL empfiehlt in solchen Fällen einen Service Desk zu etablie-<br />
ren. 56 <strong>Die</strong>ser Service Desk ist die zentrale Anlaufstelle (Single Point of Contact) für alle Stö-<br />
rungsmeldungen. Um eine maximale Erreichbarkeit dieser Störungsannahmestelle gewährleis-<br />
ten zu <strong>können</strong>, sollten zunächst zentrale Rufnummern, Faxnummern und E-Mail-Postfächer<br />
eingerichtet und den Anwendern mitgeteilt werden. Auf diese Weise soll ein unkoordiniertes<br />
Fragen nach Hilfestellung in der IT verhindert werden. Stattdessen <strong>können</strong> sich die Anwender<br />
im Falle eines auftretenden Incident an den Service Desk wenden, der alle auftretenden Inci-<br />
dents erfasst.<br />
Incident-Kategorisierung<br />
<strong>Die</strong> Kategorisierung ist das Zuordnen des Incident zu einer fachlichen Gruppe wie z. B. Netz-<br />
werk, Peripherie oder Software. Grundlage der Kategorisierung ist eine eigens entwickelte ein-<br />
heitliche Kategorisierungssystematik. Sowohl die Kategorisierungssystematik als auch die Ka-<br />
tegorisierungstiefe sollte dabei individuell an die Gegebenheiten des Unternehmens angepasst<br />
werden. Mit Hilfe dieser Kategorisierung <strong>können</strong> anfallende Incidents einfacher den verantwort-<br />
lichen IT-Mitarbeitern zugeordnet und Service Requests erkannt werden. Durch die Nutzung der<br />
Kategorisierungssystematik <strong>können</strong> fälschlicherweise als Incident erfasste Service Requests als<br />
solche identifiziert und an das Request Fulfilment weitergeleitet werden. 57<br />
55 Vgl. Office of Government Commerce: Service Operation, London 2007, S.55.<br />
56 Vgl. Böttcher, R. IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 134.<br />
57 Vgl. Office of Government Commerce: Service Operation, London 2007, S.57.
ITIL-basierte Prozesse im Detail 18<br />
Incident-Priorisierung<br />
Nach der Klassifizierung erfolgt die Incident-Priorisierung bei der die beiden Faktoren Dring-<br />
lichkeit und Auswirkung mit Hilfe einer Priorisierungssystematik bewertet werden. 58 <strong>Die</strong> Nut-<br />
zung einer Priorisierungssystematik, wie sie beispielhaft in Tabelle 1 dargestellt wird, ist aber<br />
nur dann effektiv, wenn sie einheitlich von allen Mitarbeitern des Service Desk angewendet<br />
wird.<br />
Tab. 2 - Priorisierungssystematik 59<br />
Erste Diagnose<br />
Nach der Priorisierung muss eine erste Diagnose des Incident erfolgen. Dabei versucht der Ser-<br />
vice Desk-Mitarbeiter alle Symptome, sowie die Ursachen des Incident durch gezielte Fragen zu<br />
identifizieren und ermittelt welche Korrekturmaßnahmen für die Lösung des Incident erforder-<br />
lich sind. 60 Als Hilfsmittel werden in dieser Phase üblicherweise Diagnoseskripte und Known<br />
Error Datenbanken genutzt. 61 Im Idealfall erfolgt eine prompte Lösung des Incident durch den<br />
Service-Desk Mitarbeiter. Wenn dies nicht der Fall ist, dann erfolgt die Eskalation des Incident.<br />
Incident-Eskalation<br />
Auswirkung<br />
Hoch Mittel Niedrig<br />
Dringlichkeit Hoch 1 2 3<br />
Mittel 2 3 2<br />
Niedrig 3 4 5<br />
Für den Fall, dass es den Service Desk-Mitarbeitern nicht gelingt die Störung direkt zu beseiti-<br />
gen, ist eine funktionale Eskalation zum besser qualifizierten 2nd Level Support notwendig.<br />
Wenn die Störungsbeseitigung nicht in einem bestimmten Zeitraum erfolgt, muss es zu einer<br />
erneuten Eskalation kommen. Eine Eskalation ist eine Aktivität, die das Einholen zusätzlicher<br />
Ressourcen umfasst und immer dann notwendig ist, wenn der Service Desk einen Incident nicht<br />
selber lösen kann und die Erreichung von Service Level-Zielen gefährdet ist. 62 Ziel der Eskala-<br />
tionsprozedur ist die Verhinderung bzw. Minimierung von materiellen und immateriellen Schä-<br />
den, sowie die Unterstützung einer schnellen Störungsbehebung.<br />
Generell werden zwei Eskalationstypen unterschieden:<br />
Priorität Beschreibung Lösungsdauer<br />
1 kritisch < 1 Stunden<br />
2 hoch < 6 Stunden<br />
3 moderat < 24 Stunden<br />
4 niedrig < 48 Stunden<br />
5 Planung geplant<br />
58 Vgl. Office of Government Commerce: Service Operation, London 2007, S.58.<br />
59 Entnommen aus: Office of Government Commerce: Service Operation, 2007, S. 58.<br />
60 Vgl. Böttcher, R. IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 136.<br />
61 Vgl. Office of Government Commerce: Service Operation, London 2007, S.59.<br />
62 van Bon, J.; de Jong, A.; Kolthof, A.; Pieper, M.; Tjassing, R.; van der Veen, A.; Verheijen, T.: IT Service Management<br />
basierend auf ITIL V3 – Das Taschenbuch, 3. Auflage, Zaltbommel 2008, S.146.
ITIL-basierte Prozesse im Detail 19<br />
� Funktionale Eskalation:<br />
<strong>Die</strong> Weiterleitung eines Incident, Problems, Request oder Change von einem Support Le-<br />
vel zum nächsten Support Level wird als funktionale Eskalation bezeichnet. Eine funktio-<br />
nale Eskalation wird dann notwendig, wenn eine Support-Einheit nicht mehr in der Lage ist<br />
zur Problemlösung beizutragen oder die festgelegte Zeit für die Lösung des Incident abge-<br />
laufen ist. 63<br />
� Hierarchische Eskalation:<br />
<strong>Die</strong> <strong>hier</strong>archische Eskalation ist das Informieren oder Einbeziehen höherer Management-<br />
Ebenen zur Einleitung weiterer Maßnahmen. <strong>Die</strong> <strong>hier</strong>archische Eskalation innerhalb eines<br />
Prozesses erfolgt normalerweise zunächst über den Prozess-Manager und den Prozess-<br />
Owner und wird angestoßen, wenn die funktionale Eskalation nicht den gewünschten Er-<br />
folg bringt. 64<br />
Untersuchung und Diagnose<br />
Nach der Eskalation erfolgt die Untersuchung und Diagnose des Incident. Im Rahmen der Un-<br />
tersuchung werden oftmals die folgenden Aktivitäten 65 durchgeführt:<br />
� Identifikation der Ursache oder der Informationen, die die Anwender benötigen<br />
� <strong>Die</strong> chronologische Reihenfolge der Events verstehen<br />
� <strong>Die</strong> Auswirkung des Incident bestätigen<br />
� Events, die den Incident verursacht haben könnten identifizieren<br />
� Suchabfragen nach ähnlichen bzw. gleichen Vorkommnissen in bereits vorhandenen<br />
Incident- oder Problem Records. Als alternative Quellen für die Suche <strong>können</strong> auch<br />
Known Error Datenbanken oder Wissensdatenbanken von Herstellern genutzt wer-<br />
den<br />
Oftmals lassen sich auf diese Weise bereits einige Incidents beheben, ohne das eine Eskalation<br />
notwendig ist.<br />
Lösung und Wiederherstellung<br />
Auf Basis der Untersuchungsergebnisse und der Diagnose <strong>können</strong> Maßnahmen umgesetzt wer-<br />
den, die der Störungsbehebung bzw. der Wiederherstellung des Services dienen. Alle umgesetz-<br />
ten Aktivitäten und relevanten Informationen müssen dabei im Incident Record protokolliert<br />
und ständig aktualisiert werden. Wenn eine Lösung gefunden wird, dann müssen im Anschluss<br />
63 Vgl. Office of Government Commerce: Service Operation, London 2007, S. 59.<br />
64 Vgl. Office of Government Commerce: Service Operation, London 2007, S. 59.<br />
65 Vgl. Office of Government Commerce: Service Operation, London 2007, S. 59 f.
ITIL-basierte Prozesse im Detail 20<br />
daran Tests durchgeführt werden, mit deren Hilfe sichergestellt werden soll, dass die erarbeitete<br />
Lösung erfolgreich war und der Service für den bzw. die Anwender wiederhergestellt ist. 66<br />
Incident-Abschluss<br />
Mit dem Schließen des Störungstickets erfolgt der Abschluss des Störungslebenszyklus. Der<br />
Abschluss eines Störungstickets kann allerdings erst nach einer Prüfung durch den verantwort-<br />
lichen Service Desk-Mitarbeiter erfolgen. <strong>Die</strong>ser hat zu prüfen, ob die Störung vollständig und<br />
zur vollen Zufriedenheit des Anwenders gelöst wurde. 67 Des Weiteren ist zu prüfen, ob sich die<br />
anfangs festgelegte Störungskategorie als richtig erwiesen hat oder ob eine nachträgliche An-<br />
passung der Störungskategorie von Nöten ist. Darüber hinaus sind die noch ausstehenden De-<br />
tails für die Incident-Dokumentation einzuholen und die Wahrscheinlichkeit für ein erneutes<br />
Auftreten des Incident zu bestimmen. Wenn ein erneutes Auftreten wahrscheinlich ist, dann<br />
muss mit Hilfe des Problem Managements ein Problem Record erstellt werden, damit eine Ini-<br />
tiierung von präventiven Maßnahmen erfolgen kann. Zu guter Letzt erfolgt noch der formale<br />
Abschluss des Incident.<br />
4.1.5. Methoden und Tools<br />
Für die effektive Umsetzung des Incident Managements sollte das folgende Tool genutzt wer-<br />
den:<br />
Incident Management Tools<br />
Im Zuge des Incident Managements sollte ein Incident Management Tool verwendet werden,<br />
welches über eine Historie verfügt und die Informationen über die Incidents und die Probleme<br />
speichert. Darüber hinaus sollt das Tool eine Kategorisierung von Incidents ermöglichen, die<br />
Informationen über die umgesetzten Maßnahmen dokumentieren <strong>können</strong> und über Diagnose-<br />
skripte verfügen. 68 <strong>Die</strong>se Funktionalität wird üblicherweise von sogenannten Ticketing-Tools<br />
bereitgestellt.<br />
4.2. Problem Management<br />
„Das Problem Management ist der Prozess, der für das Management des Lebenszyklus aller<br />
Probleme zuständig ist.“ 69<br />
66 Vlg. Office of Government Commerce: Service Operation, London 2007, S. 61.<br />
67 Vgl. Office of Government Commerce: Service Operation, London 2007, S. 66.<br />
68 Vgl. Office of Government Commerce: Service Operation, London 2007, S. 62.<br />
69 Office of Government Commerce: Service Operation, London 2007, S. 67.
ITIL-basierte Prozesse im Detail 21<br />
„Wichtigstes Ziel des Problem Managements ist es, Probleme und daraus resultierende Inci-<br />
dents zu verhindern, das wiederholte Auftreten von Incidents auszuschließen und die Auswir-<br />
kungen von nicht vermeidbaren Incidents zu minimieren.“ 70<br />
Das Problem Management liefert eine Beschreibung aller Aktivitäten, die zur Diagnose der<br />
zugrunde liegenden Ursache von Incidents und zur Lösung der entsprechenden Probleme not-<br />
wendig sind. Das Problem Management hat darüber hinaus die Aufgabe sicherzustellen, dass<br />
die gefundenen Lösungen mit Hilfe von geeigneten Steuerungsverfahren implementiert wer-<br />
den. 71 Eine weitere Aufgabe des Problem Managements ist die Verwaltung der zur Verfügung<br />
stehenden Informationen zu den einzelnen Problemen und deren dazugehörigen Lösungen und<br />
Workarounds. 72<br />
Der Mehrwert, der durch den Einsatz des Problem Managements entsteht, kann sehr groß sein,<br />
denn das Problem Management arbeitet eng mit dem Incident und Change Management zu-<br />
sammen, um die Verfügbarkeit und Qualität von IT-Services zu verbessern. <strong>Die</strong> Informationen,<br />
die bei der Lösung von Incidents anfallen, werden erfasst und später genutzt um dauerhafte<br />
Lösungen zu identifizieren, mit denen sich die Anzahl, sowie die Lösungszeiten der anfallenden<br />
Incidents reduzieren lassen. Auf diese Weise werden Ausfallzeiten und Unterbrechungen von<br />
relevanten Systemen reduziert. Weitere Vorteile sind eine verbesserte Verfügbarkeit der IT-<br />
Services sowie eine verbesserte Produktivität der Mitarbeiter. 73<br />
4.2.1. Begriffe<br />
Im Folgenden werden zahlreiche Begriffe vorgestellt, die für das Verständnis des Problem Ma-<br />
nagement Prozesses notwendig sind.<br />
Was ist ein Problem?<br />
„Ein Problem ist die unbekannte Ursache eines oder mehrerer Incidents.‟ 74<br />
Was ist ein Known Error?<br />
Ein Known Error ist ein Problem, dessen Ursache identifiziert und für den ein Workaround<br />
gefunden und festgelegt wurde. Der Known Error wird in der Known Error Datenbank gespei-<br />
chert und auf diese Weise den Service Desk-Mitarbeitern zur Verfügung gestellt. Dadurch kön-<br />
70 Office of Government Commerce: Service Operation, London 2007, S. 67.<br />
71 Vgl. Office of Government Commerce: Service Operation, London 2007, S. 67.<br />
72 Vgl. Office of Government Commerce: Service Operation, London 2007, S. 67.<br />
73 Vgl. Office of Government Commerce: ITIL Service Operation, S. 68.<br />
74 Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 154.
ITIL-basierte Prozesse im Detail 22<br />
nen die Service Desk-Mitarbeiter in der Known Error Datenbank nach bekannten Problemen<br />
und deren Lösungen suchen. 75<br />
4.2.2. Prinzipien<br />
Problemmodelle<br />
Oftmals treten Probleme einmalig auf und müssen aus diesem Grund auch individuell behandelt<br />
werden. Es ist aber auch möglich, dass Incidents aufgrund nicht behandelter oder zugrunde<br />
liegender Probleme erneut auftreten, beispielsweise wenn die Kosten für die dauerhafte Lösung<br />
zu hoch sind und aus diesem Grund die kostenaufwendige Lösung nicht umgesetzt wird. 76<br />
Um eine schnellere Diagnose zu ermöglichen sollte deshalb nicht nur ein Known Error Record<br />
in der Known Error Datenbank erfasst werden, sondern auch ein Problemmodell erstellt werden.<br />
<strong>Die</strong>s ermöglicht eine vereinfachte Behandlung von Problemen. Das Problemmodell ist ver-<br />
gleichbar mit dem in Kapitel 4.1.2. genannten Incident-Modell und ermöglicht das Festlegen<br />
einer chronologischen Reihenfolge von Schritten, die die Abwicklung des Prozesses vereinfa-<br />
chen. Darüber hinaus werden die Zuständigkeit sowie der zur Verfügung stehende Zeitrahmen<br />
für die auszuführenden Aktionen festgelegt. <strong>Die</strong>s alles ermöglicht eine vereinfachte und be-<br />
schleunigte Behandlung von erneut auftretenden Problemen. 77<br />
4.2.3. Rollen<br />
Problem Manager<br />
Der Problem Manager ist für das Problem Management verantwortlich und kümmert sich um<br />
die Koordination der gesamten Problem Management Aktivitäten. <strong>Die</strong> weiteren Aufgaben 78 des<br />
Problem Managers sind:<br />
� Management Reporting<br />
� Pflege der Known Error Database<br />
� Formaler Abschluss der Problem Records<br />
� Verbindung zu externen Partnern in Bezug auf die Lösung von Problemen<br />
� Zusammenstellung der Problem Solving Groups<br />
Problem Solving Goups<br />
Problem Solving Groups werden abhängig vom jeweiligen Problem zusammengestellt. 79 <strong>Die</strong><br />
Zusammenstellung übernimmt der Problem Manager. 80 Üblicherweise bestehen Problem<br />
75 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 154.<br />
76 Vgl. Office of Government Commerce: ITIL Service Operation, S. 68.<br />
77 Vgl. Office of Government Commerce: ITIL Service Operation, S. 68.<br />
78 Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 156.<br />
79 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 156.<br />
80 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 156.
ITIL-basierte Prozesse im Detail 23<br />
Solving Groups aus Spezialisten, die sich um die Diagnose und Lösungssuche kümmern. Dabei<br />
kann es sich sowohl um interne, als auch um externe Spezialisten handeln. 81<br />
4.2.4. Methoden und Tools<br />
Für die effektive Umsetzung des Problem Managements empfiehlt ITIL die Nutzung von ver-<br />
schiedenen Tools, die im Folgenden vorgestellt werden:<br />
CMS<br />
Das Configuration Management System, kurz CMS, unterstützt die IT-Mitarbeiter beim Mana-<br />
gement der IT-Infrastruktur und liefert detaillierte Informationen zu den Komponenten der IT-<br />
Infrastruktur. Aus diesem Grund ist das CMS eine wertvolle Quelle für die Diagnose von Prob-<br />
lemen und unterstützt die IT-Mitarbeiter bei der Bewertung der Auswirkungen von Proble-<br />
men. 82<br />
Known Error Datenbank<br />
<strong>Die</strong> Known Error Datenbank ist ein wichtiges Hilfsmittel, welches dazu genutzt wird, die früher<br />
gewonnenen Erkenntnisse über Incidents und Probleme und deren Lösungen zu dokumentieren.<br />
Auf diese Weise wird eine schnellere Diagnose und Lösung bei einem erneuten Auftreten er-<br />
möglicht. 83 In der Known Error Datenbank werden detaillierte Informationen über die Symp-<br />
tome, Workarounds und Lösungsmaßnahmen gespeichert, die beim erneuten Auftreten des<br />
Fehlers abgerufen und genutzt werden <strong>können</strong>. 84<br />
81 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 156.<br />
82 Office of Government Commerce: ITIL Service Operation, S. 75.<br />
83 Office of Government Commerce: ITIL Service Operation, S. 75.<br />
84 Office of Government Commerce: ITIL Service Operation, S. 75.
ITIL-basierte Prozesse im Detail 24<br />
4.2.5. Prozessablauf des Problem Managements<br />
Service<br />
Desk<br />
Change<br />
Management<br />
Event Management<br />
Abb. 7: Problem Management Prozess 85<br />
Ja<br />
Incident<br />
Management<br />
Problemerkennung<br />
Problemerfassung<br />
Kategorisierung<br />
Priorisierung<br />
Untersuchung und<br />
Diagnose<br />
Workaround?<br />
Change erforderlich<br />
?<br />
Nein<br />
85 Entnommen aus: Office of Covernment Commerce: Service Operation, London 2007, S.69.<br />
Nein<br />
Known Error Record<br />
erstellen<br />
Lösung<br />
Abschluss<br />
Schwerwiegendes<br />
Problem ?<br />
Ende<br />
Proactive<br />
Problem<br />
Managemet<br />
CMS<br />
Supplier oder<br />
Auftragnehmer<br />
Known<br />
Error<br />
Datenbank<br />
Review nach<br />
schwerwiegenden<br />
Problemen
ITIL-basierte Prozesse im Detail 25<br />
Beim Problem Management werden zwei verschiedene Arten 86 des Problem Managements un-<br />
terschieden:<br />
� Reaktives Problem Management - Das reaktive Problem Management umfasst die<br />
Erkennung von Problemen und Known Errors durch die Analyse von Incidents, wenn<br />
diese bereits aufgetreten sind. 87<br />
� Proaktives Problem Management - Das proaktive Problem Management umfasst die<br />
regelmäßige Analyse von Incidents und die fortwährende Analyse der IT-Infrastruktur 88<br />
und wird zwar in der Phase der Service Operation initiiert, gehört aber in der Regel zum<br />
Continual Service Improvement. 89<br />
Problemerkennung<br />
<strong>Die</strong> Problemerkennung kann auf verschiedene Weisen erfolgen. Beispielsweise kann ein Prob-<br />
lem auf Basis der folgenden Stichpunkte 90 erkannt werden:<br />
� <strong>Die</strong> Erfahrung der Service Desk Mitarbeiter ist eine Möglichkeit um Probleme zu er-<br />
kennen. Demnach sollte ein Problem Record auch dann erfasst werden, wenn der Ser-<br />
vice Desk Mitarbeiter einen Incident beheben, jedoch nicht die Ursache eindeutig be-<br />
stimmen kann und aufgrund seiner Erfahrung die Vermutung hegt, dass ein Problem<br />
dem Incident zugrunde liegt.<br />
� <strong>Die</strong> nächste Möglichkeit ist die nachgelagerte Analyse eines Incident durch den techni-<br />
schen Support. Wenn der technische Support aufgrund der Analyse zu der Erkenntnis<br />
kommt, dass ein Problem vorliegt, dann sollte ebenfalls ein Problem Record eröffnet<br />
werden.<br />
� <strong>Die</strong> Automatische Erkennung von Problemen durch den Einsatz von Event/Alarm-Tools<br />
ist eine weitere Möglichkeit.<br />
Problemerfassung<br />
Im Zuge der Problemerfassung müssen alle relevanten Problemdetails erfasst werden. Wichtig<br />
ist darauf zu achten, dass ein Querverweis zu dem vorhandenen Incident angelegt wird, der den<br />
eigentlichen Problem Record verursacht hat. Darüber hinaus ist darauf zu achten, dass alle<br />
wichtigen Details des Incident Record in den Problem Record kopiert werden. Der Inhalt der zu<br />
kopierenden Informationen variiert und ist abhängig von dem aufgetretenen Problem. Häufig<br />
werden aber die folgenden Informationen 91 erneut dokumentiert:<br />
� Anwenderdetails<br />
� Servicedetails<br />
86 Office of Government Commerce: ITIL Service Operation, S. 68.<br />
87 Vgl. Olbrich, A.: ITIL kompakt und verständlich, 4. Auflage, Wiesbaden 2008, S. 42.<br />
88 Vgl. Olbrich, A.: ITIL kompakt und verständlich, 4. Auflage, Wiesbaden 2008, S. 42.<br />
89 Vgl. Office of Government Commerce: ITIL Service Operation, S. 68.<br />
90 Vgl. Office of Government Commerce: ITIL Service Operation, S. 68.<br />
91 Office of Government Commerce: ITIL Service Operation, S. 70.
ITIL-basierte Prozesse im Detail 26<br />
� Gerätedetails<br />
� Erfassungsdatum<br />
� Details der Priorisierung und Kategorisierung<br />
� Beschreibung des Incident<br />
� Beschreibung der Details der diagnostischen und umgesetzten Wiederherstellungsmaß-<br />
nahmen<br />
Problemkategorisierung<br />
<strong>Die</strong> Problemkategorisierung gestaltet sich analog zum Incident Management (siehe Kapitel<br />
4.1.4.). Im Zuge dessen ist darauf zu achten, dass die gleiche Systematik sowohl beim Incident<br />
als auch beim Problem Management verwendet wird. 92<br />
Problempriorisierung<br />
<strong>Die</strong> Problempriorisierung muss ebenso wie die Problemkategorisierung analog zum Incident<br />
Management erfolgen (siehe. Kapitel 4.1.4.) und zusätzlich den Schweregrad des Problems<br />
berücksichtigen. Der Schweregrad verdeutlicht, wie weitreichend ein Problem die zugrundlie-<br />
gende Infrastruktur beeinflusst.<br />
Problemuntersuchung und –diagnose<br />
Um die Ursache für ein Problem zu identifizieren muss zunächst eine Untersuchung des Prob-<br />
lems stattfinden. Dabei hängt sowohl der Umfang, als auch der Durchführungszeitraum maß-<br />
geblich von der Auswirkung, dem Schweregrad und der Dringlichkeit des Problems ab. 93 Durch<br />
den Einsatz von hilfreichen Techniken wie z. B. der Schlüsselwortsuche in der Known Error<br />
Datenbank oder der Auswertung der CMDB 94 <strong>können</strong> die Probleme effektiv untersucht wer-<br />
den. 95<br />
Workarounds<br />
Oftmals besteht die Möglichkeit einen Workaround für Incidents zu finden, die durch ein Prob-<br />
lem verursacht wurden. Workarounds sind aber nur temporäre Lösungen. Daher sollte an einer<br />
dauerhaften Lösung gearbeitet werden, sofern es vom Aufwand noch angemessen ist.<br />
Erstellen eines Known Error Record<br />
Nach Beendigung der Diagnose muss ein Known Error Record in der Known Error Datenbank<br />
erstellt werden. 96<br />
92 Office of Government Commerce: ITIL Service Operation, S. 70.<br />
93 Vgl. Office of Government Commerce: ITIL Service Operation, S. 70.<br />
94 <strong>Die</strong> CMDB ist eine Datenbank, die der Verwaltung von CIs dient.<br />
95 Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 147.<br />
96 Office of Government Commerce: ITIL Service Operation, S. 71.
ITIL-basierte Prozesse im Detail 27<br />
Problemlösung<br />
Sobald eine passende Lösung zur Behebung des Problems gefunden wurde, muss zunächst si-<br />
chergestellt werden, dass die erarbeitete Lösung keine dauerhaften Schwierigkeiten verursacht.<br />
Für den Fall, dass Änderungen an der Funktionalität notwendig sind, muss ein Request for<br />
Change (RfC) 97 erstellt und genehmigt werden, um die Lösung einsetzen zu <strong>können</strong>. Wenn es<br />
sich um ein schwerwiegendes Problem handelt, dass sich negativ auf die unternehmerische Tä-<br />
tigkeit auswirkt, ist eine umgehende Einberufung einer Dringlichkeitssitzung des Change Advi-<br />
sory Board / Emergency Committee (CAB /EC) notwendig, um sofortige Maßnahmen für den<br />
Notfall-RfC initiieren zu <strong>können</strong>. 98<br />
Wenn es sich um einen normalen RfC handelt, sollte die erarbeitete Lösung zunächst den Chan-<br />
ge Management Prozess durchlaufen. <strong>Die</strong>s hat zur Folge, dass die erarbeitete Lösung erst dann<br />
eingesetzt wird, wenn der Change genehmigt und für die Umsetzung freigegeben wurde. Soll-<br />
ten bis zur Umsetzung des Changes erneut Probleme oder Incidents auftreten, so sollte für deren<br />
Behebung die Known Error Database genutzt werden, um eine schnelle Lösung sicherzustel-<br />
len. 99<br />
Problemabschluss<br />
Nachdem der Change umgesetzt wurde, der Review erfolgreich war und die Lösung im Einsatz<br />
ist, muss zu guter Letzt der Problem Record sowie die verbliebenen offenen Incident Records<br />
formal abgeschlossen werden. 100<br />
Review nach schwerwiegenden Problemen<br />
Nach dem Auftreten und Beheben eines schwerwiegenden Problems ist ein Review durchzufüh-<br />
ren, um Rückschlüsse aus dem schwerwiegenden Problem zu ziehen und die wichtigsten Er-<br />
kenntnisse für die Zukunft zu nutzen. Im Fokus der Betrachtung stehen dabei in erster Linie das<br />
Verhalten der Mitarbeiter, Verbesserungspotenziale beim Vorgehen der Mitarbeiter und die<br />
Identifikation von Maßnahmen mit deren Hilfe das künftige Auftreten von schwerwiegenden<br />
Problemen vermieden werden kann. 101<br />
97 Ein RfC ist ein formaler Antrag zur Durchführung eins Change.<br />
98 Vgl. Office of Government Commerce: ITIL Service Operation, S. 73.<br />
99 Vgl. Office of Government Commerce: ITIL Service Operation, S. 73.<br />
100 Vgl. Office of Government Commerce: ITIL Service Operation, S. 73.<br />
101 Vgl. Office of Government Commerce: ITIL Service Operation, S. 73.
Erhebung der Daten 28<br />
5 Erhebung der Daten<br />
Im fünften Kapitel werden der Untersuchungsgegenstand, die Erhebungsmethode, die Zielgrup-<br />
pe der Befragung, das Konzept des Fragebogens und die Auswahl der Umfrageteilnehmer be-<br />
schrieben.<br />
5.1. Untersuchungsgegenstand<br />
Gegenstand der Untersuchung ist die Ermittlung des Status quo von ITIL in mittelständischen<br />
Unternehmen und Unternehmen mittlerer Größe. Im Mittelpunkt der Untersuchung stehen die<br />
ITIL-basierten Prozesse und Funktionen, die in den befragten Unternehmen zum Einsatz kom-<br />
men und jene, die in Zukunft noch implementiert werden sollen. Im Zuge der Untersuchung soll<br />
ermittelt werden, welche ITIL-Version in den befragten Unternehmen genutzt wird. Außerdem<br />
soll untersucht werden, aus welchen Gründen ITIL verwendet bzw. nicht verwendet wird. Da-<br />
rüber hinaus sollen die verschiedenen Probleme, die die Befragten bei der Einführung des Inci-<br />
dent und Problem Managements hatten, ermittelt werden. Für diese Probleme sind Lösungsvor-<br />
schläge zu erarbeiten, die in das zu entwerfende Vorgehensmodell einfließen sollen und mit<br />
dessen Hilfe die Prozesse erfolgreich implementiert werden <strong>können</strong>.<br />
5.2. Erhebungsmethode<br />
<strong>Die</strong> Erhebung der benötigten Informationen kann mit Hilfe der folgenden vier Methoden erfol-<br />
gen:<br />
� mündliche Befragung<br />
� telefonische Befragung<br />
� schriftliche Befragung<br />
� Onlineumfrage<br />
<strong>Die</strong> Vor- und Nachteile der vier Erhebungsmethoden werden in der folgenden Tabelle vorge-<br />
stellt:
Erhebung der Daten 29<br />
Tab. 3 - Vor- und Nachteile der Erhebungsmethoden<br />
Vorteile Nachteile<br />
Mündliche Befragung • Interviewer kann sich an die Be-<br />
fragungssituation anpassen 102<br />
• Fragen <strong>können</strong> erklärt werden<br />
• Höhere Rücklaufquote<br />
Telefonische Befragung • Geringe Kosten<br />
• Allokalität<br />
Schriftliche Befragung • Allokalität<br />
• Interviewer kann sich an die Be-<br />
fragungssituation anpassen 104<br />
• Fragen <strong>können</strong> erklärt werden<br />
• Relativ geringe Kosten 105<br />
• Flexible Zeiteinteilung bei der<br />
Beantwortung der Fragen 106<br />
• Fragebogen kann jederzeit beant-<br />
wortet werden<br />
• Höhere Erreichbarkeit der Aus-<br />
kunftsperson 107<br />
• Visuelle Darstellung von Zusam-<br />
menhängen möglich<br />
Onlineumfrage • Allokalität<br />
• Flexible Zeiteinteilung bei der<br />
Beantwortung der Fragen<br />
• Automatische Durchführung und<br />
Auswertung 108<br />
• Keine Erfassungsfehler<br />
• Visuelle Darstellung von Zusam-<br />
menhängen möglich<br />
• Hohe Reisekosten 103<br />
• Zeitintensive Reisen sind oftmals notwendig<br />
• Visuelle Darstellung von Zusammenhängen<br />
nicht möglich<br />
• Visuelle Darstellung von Zusammenhängen<br />
nicht möglich<br />
• Geringe Antwortquote<br />
• <strong>Die</strong> notwendige manuelle Erfassung ist<br />
arbeitsaufwendig, risikobehaftet und zeit-<br />
aufwendig<br />
• Unklare Fragestellungen <strong>können</strong> nicht<br />
erklärt werden<br />
• Unklare Fragestellungen <strong>können</strong> nicht<br />
erklärt werden<br />
<strong>Die</strong> wichtigsten Faktoren bei der Wahl der Erhebungsmethode sind die anfallenden Kosten und<br />
die zur Verfügung stehende Zeit, denn für die Durchführung der Erhebung steht nur ein gerin-<br />
ges Budget, sowie ein kurzer Zeitrahmen zur Verfügung. Aufgrund dieser ökonomischen und<br />
zeitlichen Gesichtspunkte fällt die Wahl der Erhebungsmethode auf die Onlineumfrage.<br />
102 Vgl. Rossig, W. E.; Prätsch, J.: Wissenschaftliche Arbeiten, 7. Auflage, Hamburg 2008, S. 76.<br />
103 Vgl. Mayer, H. O.: Interview und schriftliche Befragung, 4. Auflage, München 2008, S.100.<br />
104 Vgl. Rossig, W. E.; Prätsch, J.: Wissenschaftliche Arbeiten, 7. Auflage, Hamburg 2008, S. 76.<br />
105 Vgl. Rossig, W. E.; Prätsch, J.: Wissenschaftliche Arbeiten, 7. Auflage, Hamburg 2008, S. 72.<br />
106 Vgl. Rossig, W. E.; Prätsch, J.: Wissenschaftliche Arbeiten, 7. Auflage, Hamburg 2008, S. 73.<br />
107 Vgl. Rossig, W. E.; Prätsch, J.: Wissenschaftliche Arbeiten, 7. Auflage, Hamburg 2008, S. 72.<br />
108 Vgl. Rossig, W. E.; Prätsch, J.: Wissenschaftliche Arbeiten, 7. Auflage, Hamburg 2008, S. 77.
Erhebung der Daten 30<br />
5.3. Zielgruppe der Erhebung<br />
In Absprache mit Prof. Dr. Wilking werden mittelständische Unternehmen und Unternehmen<br />
mittlerer Größe als Zielgruppe für die Umfrage festgelegt. Als Unternehmen mittlerer Größe<br />
definiert Prof. Dr. Wilking alle Unternehmen, die mehr Arbeitnehmer als ein mittelständisches<br />
Unternehmen beschäftigen, aber nicht mehr als 2000 Arbeitnehmer beschäftigen . Aufgrund der<br />
umfassenden Kenntnisse über die eigene IT-Abteilung werden die Verantwortlichen der IT-<br />
Abteilung als Zielperson für die Umfrage ausgewählt.<br />
Als Grundlage für die Identifikation des Mittelstands wird die Einteilung des Institut für Mittel-<br />
standforschung Bonn genutzt. (siehe Kapitel 2.7.1.). Das Institut für Mittelstandsforschung<br />
Bonn definiert die Anzahl der Mitarbeiter und den Umsatz der Unternehmen, als die wichtigsten<br />
Kriterien zur Abgrenzung der Unternehmensgröße. Im Rahmen der Datenerhebung wird mit der<br />
Anzahl der Mitarbeiter nur eines der beiden Kriterien für die Klassifizierung der Unterneh-<br />
mensgröße verwendet, da die Frage nach dem Umsatz des Unternehmens u.U. mögliche Adres-<br />
saten von einer Teilnahme absehen lassen könnte.<br />
5.4. Konzeption des Fragebogens<br />
<strong>Die</strong> Konzeption des Fragebogens sieht eine Befragungsdauer von 6 - 9 Minuten vor, wobei die<br />
Befragungsdauer und die Anzahl der gestellten Fragen stark vom Antwortverhalten der Umfra-<br />
geteilnehmer abhängen.<br />
Das für die Umfrage verwendete System der Onlineumfrage.com GmbH 109 arbeitet mit Sprün-<br />
gen, die es ermöglichen auf das Antwortverhalten der Umfrageteilnehmer zu reagieren. Auf<br />
diese Weise kann sichergestellt werden, dass den Teilnehmern der Umfrage nur sinnvolle Fra-<br />
gen gestellt werden.<br />
Insgesamt besteht der Fragebogen aus neunzehn Fragen. Thematisch <strong>können</strong> die Fragen in die<br />
folgenden neun Frageblöcke unterteilt werden:<br />
� 1. Block: Größe und Branchen der teilnehmenden Unternehmen<br />
� 2. Block: Status quo von ITIL<br />
� 3. Block: Gründe für die Nutzung bzw. den Verzicht<br />
� 4. Block: Verbreitung der ITIL-basierten Prozesse und Funktionen<br />
� 5. Block: Bedarf an ITIL-basierten Prozessen und Funktionen<br />
109 <strong>Sie</strong>he: www.onlineumfragen.com.
Erhebung der Daten 31<br />
� 6. Block: Verwendete ITIL-Version<br />
� 7. Block: Probleme bei der Einführung des Incident Managements<br />
� 8. Block: Probleme bei der Einführung des Problem Managements<br />
� 9. Block: Einfluss von ITIL auf die Prozesse<br />
Der erste Block umfasst allgemeine Fragen zur Anzahl der Mitarbeiter und der Branche des<br />
befragten Unternehmens. Dabei dient die Frage nach der Mitarbeiterzahl nicht nur der Kategori-<br />
sierung der Umfrageteilnehmer, sondern zielt auch darauf ab, die nicht zur Zielgruppe gehören-<br />
den Unternehmen herauszufiltern und an das Ende der Umfrage zu leiten.<br />
Tab. 4 - Fragebogen: 1. Block - Größe und Branche<br />
1. Block : Größe und Branche<br />
Wie viele Mitarbeiter sind in Ihrem Unternehmen beschäftigt?<br />
In welcher Branche ist Ihr Unternehmen hauptsächlich tätig?<br />
Im zweiten Block wird ermittelt, ob ITIL in den befragten Unternehmen zum Einsatz kommt.<br />
Tab. 5 - Fragebogen: 2. Block - Status quo von ITIL<br />
Wird ITIL in Ihrem Unternehmen verwendet?<br />
2. Block : Status quo von ITIL<br />
Im dritten Themengebiet werden die Gründe für die Nutzung bzw. den Verzicht auf ITIL ermit-<br />
telt. Im Rahmen dessen wird untersucht, ob es einen Zusammenhang zwischen der Anzahl der<br />
IT-Mitarbeiter bzw. EDV-Anwender und der ITIL-Nutzung gibt.<br />
Tab. 6 - Fragebogen: 3. Block - Gründe für die Nutzung bzw. den Verzicht<br />
3. Block : Gründe für die Nutzung bzw. den Verzicht<br />
Warum wird ITIL in Ihrem Unternehmen nicht eingesetzt?<br />
Welche Ziele verfolgen <strong>Sie</strong> mit der Nutzung von ITIL?<br />
Wie viele Mitarbeiter sind in der IT tätig?<br />
Wie viele EDV - Anwender/innen gibt es in Ihrem Unternehmen?<br />
Das Ziel des vierten Themenkomplexes ist, zu ermitteln welche ITIL-basierten Prozesse und<br />
Funktionen in den Unternehmen verwendet werden.<br />
Tab. 7- Fragebogen: 4. Block: Verbreitung der ITIL-basierten Prozesse und Funktionen<br />
4. Block : Verbreitung der ITIL-basierten Prozesse und Funktionen<br />
Welche ITIL-basierten Standardprozesse und Funktionen haben <strong>Sie</strong> in Ihrem Unternehmen umgesetzt?<br />
Im fünften Block wird ermittelt, welche ITIL-basierten Prozesse und Funktionen in den Unter-<br />
nehmen noch eingeführt werden sollen.
Erhebung der Daten 32<br />
Tab. 8 - Fragebogen: 5. Block: Bedarf an ITIL-basierten Prozessen und Funktionen<br />
5. Block : Bedarf an ITIL-basierten Prozessen und Funktionen<br />
Welche ITIL-basierten Standardprozesse und Funktionen planen <strong>Sie</strong> neben den bereits vorhandenen<br />
Prozessen und Funktionen noch einzuführen?<br />
Gegenstand des sechsten Themenkomplexes ist die in den Unternehmen verwendete ITIL-<br />
Version.<br />
Tab. 9 - Fragebogen: 6. Block: Verwendete ITIL-Version<br />
6. Block : Verwendete ITIL-Version<br />
Haben <strong>Sie</strong> ihre Prozesse nach ITIL Version 3 ausgerichtet?<br />
Gegenstand des siebten Themengebiets sind die Probleme, die bei der Einführung des Incident<br />
Managements aufgetreten sind.<br />
Tab. 10 - Fragebogen: 7. Block - Probleme bei der Einführung des Incident Managements<br />
7. Block : Probleme bei der Einführung des Incident Managements<br />
Gab es Probleme bei der Einführung des Incident Managements?<br />
Welche Probleme gab es bei der Einführung des Incident Managements?<br />
Das Ziel des achten Blocks ist die Ermittlung der Probleme, die bei der Einführung des Problem<br />
Managements in den befragten Unternehmen aufgetreten sind.<br />
Tab. 11 - Fragebogen: 8. Block - Probleme bei der Einführung des Problem Managements<br />
8. Block : Probleme bei der Einführung des Problem Managements<br />
Gab es Probleme bei der Einführung des Problem Managements?<br />
Welche Probleme gab es bei der Einführung des Problem Managements?<br />
Im neunten und letzten Themenkomplex sollen die Probanden die unternehmenseigenen Prozes-<br />
se anhand der in Tabelle 12 dargestellten Kriterien bewerten. Ziel ist es herauszufinden, ob die<br />
Verwendung von ITIL-basierten Prozessen und Funktionen einen positiven Einfluss auf die<br />
Prozesse hat. Im Zuge dessen erfolgt einer Unterteilung nach Probanden, die ITIL nutzen bzw.<br />
nicht nutzen.
Erhebung der Daten 33<br />
Tab. 12 - Fragebogen: 9. Block Einfluss von ITIL auf die Prozesse<br />
Bitte bewerten <strong>Sie</strong>:<br />
9. Block : Einfluss von ITIL auf die Prozesse<br />
� die Benutzerfreundlichkeit Ihrer IT-Prozesse<br />
� die Effizienz Ihrer Prozesse<br />
� die IT-Sicherheit in Ihrem Unternehmen<br />
� die Prozessqualität in Ihrem Unternehmen<br />
� die Transparenz Ihrer Prozesse<br />
� die Wirtschaftlichkeit Ihrer Prozesse<br />
� das Sourcing in Ihrem Unternehmen<br />
� die Reaktionszeit Ihrer IT auf anfallende Störungen und Probleme<br />
� die Strukturierung Ihres IT-Betriebes<br />
� die Flexibilität Ihrer Prozesse<br />
5.5. Auswahl der Umfrageteilnehmer<br />
Um Teilnehmer aus der passenden Zielgruppe für die Onlineumfrage zu gewinnen ist es zu-<br />
nächst notwendig mittelständische Unternehmen und Unternehmen mittlerer Größe anhand der<br />
Mitarbeiterzahl zu identifizieren. Als Informationsquellen werden Wikipedia und die Firmenda-<br />
tenbanken der verschiedenen IHKs verwendet.<br />
5.5.1. Wikipedia<br />
Wikipedia ermöglicht Wirtschaftsunternehmen ein eigenes Firmenprofil mit Informationen über<br />
Produkte, Geschichte, Markt- und Mitarbeiterzahlen zu erstellen und auf Wikipedia zu veröf-<br />
fentlichen. Dafür muss das Unternehmen mindestens eines der folgenden Kriterien 110 erfüllen:<br />
Das Unternehmen<br />
� hat mindestens 1000 Vollzeitmitarbeiter oder<br />
� verfügt über mindestens 20 Zweigniederlassungen / Produktionsstandorte / Filialen (<br />
keine Verkaufsbüros oder Handelsniederlassungen) oder<br />
� wird an einer deutschen Börse im regulierten Markt oder in einem gleichwertigen Börsensegment<br />
im Ausland gehandelt oder<br />
� hat eine marktbeherrschende Stellung oder innovative Vorreiterrolle bei einer relevanten<br />
Produktgruppe oder <strong>Die</strong>nstleistung oder<br />
� kann einen Jahresumsatz von mehr als 100 Millionen € vorweisen oder<br />
� hat eines der Kriterien historisch erfüllt.<br />
110 Vgl. Wikipedia : Wikipedia:Relevanzkriterien,<br />
http://de.wikipedia.org/wiki/Wikipedia:Relevanzkriterien#Wirtschaftsunternehmen, 25.03.2010
Erhebung der Daten 34<br />
Zahlreiche Unternehmen haben die Möglichkeit genutzt und ihr eigenes Unternehmensprofil auf<br />
Wikipedia veröffentlicht. <strong>Die</strong>se Unternehmensprofile werden einzelnen Kategorien zugeordnet<br />
(z. B. „Unternehmen nach Stadt‟ 111 ). Mit Hilfe dieser Kategorisierung ist es möglich einen<br />
Überblick über Unternehmensprofile der gleichen Gattung zu bekommen und die verschiedenen<br />
Unternehmensprofile aufzurufen. Auf diese Weise kann mit Hilfe der Mitarbeiterzahl geprüft<br />
werden, ob ein Unternehmen zur Zielgruppe gehört. Kritisch anzumerken ist, dass die auf Wiki-<br />
pedia gelisteten Informationen nicht immer auf dem aktuellsten Stand sind. Folglich kann eine<br />
hundertprozentige Sicherheit, dass die Unternehmen zur Zielgruppe gehören, nicht gewährleis-<br />
tet werden. Aus diesem Grund muss während der Befragung eine erneute Überprüfung der An-<br />
zahl der Mitarbeiter erfolgen.<br />
5.5.2. Firmendatenbanken der Industrie und Handelskammern<br />
Als zweite Quelle für die Suche nach geeigneten Umfrageteilnehmern werden die Firmendaten-<br />
banken der Industrie und Handelskammern von Baden Württemberg 112 , Bayern 113 und Sach-<br />
sen 114 genutzt. <strong>Die</strong>se ermöglichen eine Suche nach Firmen anhand von ausgewählten Kriterien<br />
wie Branche, Rechtsform, Betriebsgrößenklasse oder Postleitzahl. Das für die Identifikation der<br />
potenziellen Umfrageteilnehmer relevante Kriterium ist die Betriebsgrößenklasse. Bei der Suche<br />
ist die Anzahl der angezeigten Unternehmen auf 20 begrenzt und erfolgt in Form einer zufälli-<br />
gen Auswahl. Aufgrund der Begrenzung wird der Suchvorgang mehrmals durchgeführt und die<br />
Daten werden in einer Liste gesammelt. Durch den mehrmals durchgeführten Suchvorgang ent-<br />
stehen beim Sammeln der Daten doppelte Einträge, die zu einem späteren Zeitpunkt wieder<br />
entfernt werden.<br />
5.5.3. Ermitteln der E-Mail-Adresse<br />
Um den IT-Verantwortlichen der ausgewählten Unternehmen von der Onlineumfrage in Kennt-<br />
nis setzen zu <strong>können</strong>, wird zunächst mit Hilfe der Suchmaschine Google 115 nach der Homepage<br />
des jeweiligen Unternehmens gesucht, wenn der Link zur Homepage nicht bereits in der Fir-<br />
mendatenbank oder im Unternehmensprofil angegeben ist.<br />
Nach Aufruf der Homepage der Unternehmen wird anschließend das Impressum des jeweiligen<br />
Unternehmens besucht, denn gemäß § 5 Abs. 1 Nr. 2 TMG sind Angaben, „die eine schnelle<br />
elektronische Kontaktaufnahme und unmittelbare Kommunikation ... ermöglichen, einschließ-<br />
lich der Adresse der elektronischen Post‟ 116 , im Impressum anzugeben. <strong>Die</strong>se E-Mailadresse<br />
111<br />
<strong>Sie</strong>he http://de.wikipedia.org/wiki/Kategorie:Unternehmen_%28M%C3%B6nchengladbach%29. Bei der ausgewählten<br />
Stadt handelt es sich um Mönchengladbach.<br />
112<br />
<strong>Sie</strong>he: www.bw-firmen.ihk.de<br />
113<br />
<strong>Sie</strong>he: www.firmen-in-bayern.de<br />
114<br />
<strong>Sie</strong>he: www.firmen-in-sachsen.de<br />
115<br />
<strong>Sie</strong>he: www.google.de<br />
116<br />
Bundesministerium der Justiz: TMG - Einzelnorm, http://www.gesetze-im-internet.de/tmg/__5.html, 27.03.2010.
Erhebung der Daten 35<br />
ermöglicht eine erste Kontaktaufnahme mit den Unternehmen und wird anschließend in einer<br />
Liste gesammelt. Danach wird eine E-Mail verfasst, in der die Empfänger über die Umfrage<br />
informiert und um eine Weiterleitung an den IT-Verantwortlichen des jeweiligen Unternehmens<br />
gebeten wird.
Status quo von ITIL 36<br />
6 Status quo von ITIL<br />
Kapitel sechs beschreibt die Ergebnisse der durchgeführten Umfrage und des Experteninter-<br />
views mit Steven Handgräntinger.<br />
6.1. Umfrageergebnis<br />
Von den insgesamt 700 kontaktierten IT-Leitern haben 58 an der Umfrage teilgenommen und<br />
mindestens eine Frage beantwortet. <strong>Die</strong> daraus resultierende Antwortquote von 8,28 % ist rela-<br />
tiv gering.<br />
6.1.1. Größe und Branchen der teilnehmenden Unternehmen<br />
<strong>Die</strong> Mitarbeiterzahl der befragten Unternehmen verteilt sich folgendermaßen:<br />
1 - 9 Mitarbeiter<br />
10 - 50 Mitarbeiter<br />
51 - 200 Mitarbeiter<br />
201 - 500 Mitarbeiter<br />
501 - 1000 Mitarbeiter<br />
1001 - 2000 Mitarbeiter<br />
Status quo von ITIL 37<br />
<strong>Die</strong> Verteilung der teilnehmenden Unternehmen auf die folgenden Branchen sieht folgenderma-<br />
ßen aus:<br />
In welcher Branche ist Ihr Unternehmen hauptsächlich tätig?<br />
Abb. 9 - Branchen der befragten Unternehmen<br />
Wie in Abbildung 9 dargestellt, ist die IT-Branche mit 34 % am stärksten vertreten. <strong>Die</strong> Fahr-<br />
zeugbau und Zuliefererbranche ist mit 10% und die Elektrotechnikbranche mit 8 % vertreten.<br />
6 % der teilnehmenden Unternehmen sind im Maschinen- und Anlagenbau tätig. 12 % der Be-<br />
fragten sind in sonstigen Branchen aktiv. <strong>Die</strong> verbleibenden Branchen sind mit je 2 - 4 % sehr<br />
gleichmäßig verteilt.<br />
6.1.2. Status quo von ITIL<br />
Im Folgenden wird die prozentuale Verteilung der befragten Unternehmen dargestellt, die ITIL<br />
nutzen:<br />
Wird ITIL in Ihrem Unternehmen genutzt?<br />
ja<br />
50%<br />
Abb. 10 - Prozentuale Verteilung der ITIL-Nutzer<br />
nein<br />
37,5 %<br />
Weiß nicht /<br />
Keine Angabe<br />
12,5%
Status quo von ITIL 38<br />
<strong>Die</strong> durchgeführte Umfrage hat ergeben, dass 50 % der befragten mittelständischen Unterneh-<br />
men und Unternehmen mittlerer Größe ITIL nutzen. Dem gegenüber stehen 37,5 % der Unter-<br />
nehmen, die ITIL nicht einsetzen. <strong>Die</strong> verbleibenden 12,5 % der Befragten wollten oder konnten<br />
die Frage nicht beantworten.<br />
6.1.3. Gründe für die Nutzung bzw. den Verzicht von ITIL<br />
Abbildung 11 verdeutlicht die Ursachen, warum die befragten Unternehmen auf die Einführung<br />
von ITIL-basierte Standardprozesse und Funktionen verzichten. <strong>Die</strong> Gründe dafür sind:<br />
Warum wird ITIL in Ihrem Unternehmen nicht eingesetzt?<br />
Abb. 11 - Ursachen für den Verzicht auf ITIL-basierte Standardprozesse<br />
<strong>Die</strong> häufigste Ursache, warum ITIL in den befragten Unternehmen nicht zum Einsatz kommt<br />
ist der Aufwand, der mit der Einführung von ITIL verbunden ist. Mit 29,41 % sind alternative<br />
Frameworks, die in den befragten Unternehmen zum Einsatz kommen, der zweithäufigst ge-<br />
nannte Grund. 17,65 % der befragten Unternehmen, die ITIL nicht nutzen versprechen sich<br />
durch die Verwendung von ITIL keine Vorteile. Je 5,88 % der Umfrageteilnehmer geben die zu<br />
hohen Einführungskosten, den Widerstand der Mitarbeiter, die fehlende Reife von ITIL sowie<br />
die noch laufende Prüfung von ITIL als Ursache für die Nichtberücksichtigung an.<br />
In Abbildung 12 werden die Ziele dargestellt, die die ITIL-nutzenden Unternehmen mit dem<br />
Einsatz von ITIL verfolgen.<br />
Eine ITIL Einführug wäre zu aufwendig<br />
Andere alternative Frameworks werden bereits verwendet<br />
ITIL umfasst keine detailierten Empfehlungen<br />
keine Vorteile durch den Einsatz von ITIL<br />
Einführung wird noch geprüft<br />
ITIL befindet sich noch in der Entwicklungsphase<br />
Widerstand bei den Mitarbeitern<br />
Einführungskosten sind zu hoch<br />
Weiß nicht / keine Angabe<br />
5,88%<br />
5,88%<br />
5,88%<br />
5,88%<br />
5,88%<br />
17,65%<br />
23,53%<br />
29,41%<br />
41,18%<br />
0,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00% 35,00% 40,00% 45,00%
Status quo von ITIL 39<br />
Welche Ziele verfolgen <strong>Sie</strong> mit der Nutzung von ITIL?<br />
Effizienz erhöhen<br />
Qualität der Prozesse verbessern<br />
Professionalisierung der IT<br />
Kundenzufriedenheit erhöhen<br />
Transparenz der IT Prozesse<br />
Strukturierung des IT-Betriebs verbessern<br />
Schnellere Reaktionszeiten erreichen<br />
Störanfälligkeit minimieren<br />
Kosten senken<br />
Verbesserung der IT Sicherheit<br />
ITIL-Zertifizierung ermöglichen<br />
Sonstiges<br />
Abb. 12 - Ursachen für die Nutzung von ITIL-basierten Standardprozessen<br />
Abbildung 12 verdeutlicht die Ziele, die mit der Nutzung von ITIL verfolgt werden. Demnach<br />
sind die wichtigsten Ziele die Erhöhung der Effizienz, die Verbesserung der Prozessqualität<br />
sowie die Professionalisierung der IT. Rund 2 /3 der Befragten (68,18 %) möchten die Kundenzu-<br />
friedenheit erhöhen. Weitere Ziele sind die Transparenz der IT-Prozesse und die verbesserte<br />
Strukturierung des IT-Betriebes.<br />
Um den Zusammenhang zwischen der Anzahl der IT-Mitarbeiter und der ITIL-Nutzung darzu-<br />
stellen wurde die folgende Tabelle erstellt:<br />
4,55%<br />
27,27%<br />
40,91%<br />
36,36%<br />
45,45%<br />
45,45%<br />
68,18%<br />
63,64%<br />
63,64%<br />
77,27%<br />
0,00% 10,00% 20,00% 30,00% 40,00% 50,00% 60,00% 70,00% 80,00% 90,00%<br />
Tab. 13 - Zusammenhang zwischen Anzahl IT-Mitarbeiter und Nutzung von ITIL<br />
IT-Mitarbeiter<br />
Wie viele Mitarbeiter sind in der IT tätig?<br />
ITIL Einsatz ?<br />
Ja Nein<br />
Gesamt<br />
1 - 10 21,43 % 78,57 % 100,00 %<br />
11 - 25 71,43% 28,57 % 100,00 %<br />
26 - 50 33,33 % 66,67 % 100,00 %<br />
51 - 100 80,00 % 20,00 % 100,00 %<br />
101 - 200 100,00 % 0,00 % 100,00 %<br />
201 - 500 85,71 % 14,29 % 100,00 %<br />
501 - 1000 100,00 % 0,00 % 100,00 %<br />
86,36%<br />
86,36%
Status quo von ITIL 40<br />
Tabelle 13 verdeutlicht, dass ein stark signifikanter Zusammenhang zwischen der ITIL-Nutzung<br />
und der Größe der IT-Abteilung herrscht. Je Größer die IT-Abteilung ist, umso größer ist die<br />
Wahrscheinlichkeit, dass ITIL genutzt wird.<br />
Tabelle 14 verdeutlicht den Zusammenhang zwischen der Anzahl der EDV-Anwender/innen<br />
und der Nutzung von ITIL:<br />
Tab. 14 - Zusammenhang zwischen Anzahl EDV-Anwender und Nutzung von ITIL<br />
EDV - Anwen-<br />
der/innen<br />
Wie viele EDV-Anwender / innen gibt es in Ihrem Unternehmen?<br />
ITIL-Nutzung<br />
Ja Nein<br />
Tabelle 14 illustriert, dass ab einer Anzahl von mehr als 500 EDV-Anwendern vermehrt ITIL<br />
zum Einsatz kommt. Eine Ausnahme sind die Unternehmen mit 1001 - 2000 EDV-Anwendern,<br />
bei denen die ITIL-Nutzung bzw. Nichtnutzung jeweils 50 % ausmacht.<br />
6.1.4. Verbreitung der ITIL-basierten Prozesse und Funktionen<br />
<strong>Die</strong> folgende Darstellung bildet die prozentuale Verteilung der ITIL-basierten Prozesse und<br />
Funktionen ab, die in den befragten Unternehmen zum Einsatz kommen:<br />
Gesamt<br />
1 - 50 50,00 % 50,00 % 100,00 %<br />
51 - 100 50,00 % 50,00 % 100,00 %<br />
101 - 200 42,86 % 57,14 % 100,00 %<br />
201 - 500 50 % 50 % 100,00 %<br />
501 - 1000 85,71 % 14,29 % 100,00 %<br />
1001 - 2000 50 % 50,00 % 100,00 %<br />
< 2000 100,00 % 0,00 % 100,00 %
Status quo von ITIL 41<br />
Welche ITIL-basierten Standardprozesse und Funktionen haben <strong>Sie</strong> in Ihrem Unternehmen<br />
umgesetzt?<br />
Abb. 13 - Verbreitung der ITIL-basierten Prozesse und Funktionen<br />
Besonders weit verbreitet sind der Service Desk, das Incident, das Change und das Problem<br />
Management. Dabei fällt auf, dass es sich um ITIL-basierte Prozesse und Funktionen aus der<br />
Kernpublikation Service Operation handelt, die den operativen Betrieb der IT fokussiert. Das<br />
Service Level Management als Schnittstelle zum Kunden ist als Planungsprozess am weitesten<br />
verbreitet.<br />
Service Desk<br />
Incident Management<br />
Change Management<br />
Problem Management<br />
Service Level Management<br />
Information Security …<br />
Service Reporting<br />
Monitoring and Control<br />
IT Service Continuity …<br />
Availability Management<br />
IT Operations<br />
Release and Deployment …<br />
Request Fulfillment<br />
Knowledge Management<br />
Service Asset and …<br />
Supplier Management<br />
Capacity Management<br />
Service Portfolio Management<br />
Service Catalogue Management<br />
Financial Management<br />
Continual Service Improvement<br />
Access Management<br />
Event Management<br />
Service Validation and Testing<br />
Transition Planning and Support<br />
Demand Management<br />
Evaluation<br />
9,52%<br />
9,52%<br />
0,00%<br />
23,81%<br />
23,81%<br />
19,05%<br />
19,05%<br />
19,05%<br />
19,05%<br />
33,33%<br />
33,33%<br />
33,33%<br />
28,57%<br />
28,57%<br />
28,57%<br />
6.1.5. Bedarf an ITIL-basierten Prozessen und Funktionen<br />
Abbildung 14 stellt die geplanten Prozesse und Funktionen dar, die in den befragten Unterneh-<br />
men noch implementiert werden sollen:<br />
42,86%<br />
38,10%<br />
52,38%<br />
47,62%<br />
47,62%<br />
47,62%<br />
47,62%<br />
71,43%<br />
66,67%<br />
85,71%<br />
80,95%<br />
80,95%<br />
0% 10% 20% 30% 40% 50% 60% 70% 80% 90%
Status quo von ITIL 42<br />
Welche ITIL-basierten Standardprozesse und Funktionen planen <strong>Sie</strong> neben den bereits vor-<br />
Service Asset and Configuration …<br />
Weiß nicht / Keine Angaben<br />
Service Reporting<br />
CSI Improvement Process<br />
Capacity Management<br />
Service Catalogue Management<br />
Transition Planning and Support<br />
Change Management<br />
Service Level Management<br />
Information Security Management<br />
Monitoring and Control<br />
IT Service Continuity Management<br />
Availability Management<br />
Knowledge Management<br />
Access Management<br />
Event Management<br />
Service Validation and Testing<br />
keine<br />
Financial Management<br />
Demand Management<br />
Evaluation<br />
Service Desk<br />
Incident Management<br />
Problem Management<br />
IT Operations<br />
Release and Deployment …<br />
Request Fulfillment<br />
Supplier Management<br />
Service Portfolio Management<br />
handenen Prozessen und Funktionen noch einzuführen?<br />
Abb. 14 - Noch einzuführende Prozesse und Funktionen<br />
Der größte Nachholbedarf besteht beim Service Asset und Configuration Management, sowie<br />
beim Service Reporting und Continual Service Improvement. Generell fällt auf, dass kein bzw.<br />
nur ein geringer Bedarf an operativen Prozessen wie dem Incident und dem Problem Manage-<br />
ment vorhanden ist. Stattdessen stehen Planungs- und Implementierungsprozesse wie das Ser-<br />
vice Asset und Configuration Management oder das Transition Planning und Support im Fokus.<br />
6.1.6. Verwendete ITIL-Version<br />
Abbildung 15 beschreibt die verschiedenen ITIL-Versionen, die in den befragten Unternehmen<br />
zum Einsatz kommen.<br />
0,00%<br />
0,00%<br />
0,00%<br />
0,00%<br />
0,00%<br />
0,00%<br />
0,00%<br />
0,00%<br />
5,26%<br />
5,26%<br />
5,26%<br />
5,26%<br />
10,53%<br />
10,53%<br />
10,53%<br />
10,53%<br />
10,53%<br />
10,53%<br />
10,53%<br />
10,53%<br />
10,53%<br />
10,53%<br />
15,79%<br />
15,79%<br />
15,79%<br />
21,05%<br />
21,05%<br />
26,32%<br />
31,58%<br />
0,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00% 35,00%
Status quo von ITIL 43<br />
27,27%<br />
9,09% 4,55%<br />
9,09%<br />
Abb. 15 - Verwendete ITIL Version<br />
Haben <strong>Sie</strong> ihre Prozesse nach ITIL V3 ausgerichtet?<br />
18,18%<br />
31,82%<br />
Abbildung 15 verdeutlicht, dass die Hälfte der befragten ITIL-Nutzer ihre Prozesse vollständig<br />
oder zumindest teilweise nach ITIL V3 ausgerichtet haben. Rund 9 % der Befragten planen<br />
noch den Umstieg auf ITIL V3. Auffällig ist, dass mehr als 1 /4 der befragten ITIL-Nutzer noch<br />
unentschlossen sind, ob auf ITIL V3 umgestiegen werden soll.<br />
6.1.7. Probleme bei der Einführung des Incident Managements<br />
In Abbildung 16 wird der prozentuale Anteil der Umfrageteilnehmer dargestellt, die bei der<br />
Einführung des Incident Management Probleme hatten.<br />
Abb. 16 - Anteil der Befragten mit Problemen bei der Einführung des Incident Managements<br />
Wie aus Abbildung 16 ersichtlich wird, hatten rund 53% der Umfrageteilnehmer, die das Inci-<br />
dent in ihrem Unternehmen implementiert haben, Probleme bei der Einführung.<br />
Ja<br />
Ja, aber nur einen Teil unserer Prozesse<br />
Nein, wir arbeiten noch mit ITIL Version 2, planen aber<br />
den Umstieg auf ITIL Version 3<br />
Nein, wir arbeiten noch mit ITIL Version 2 und sind<br />
noch unentschlossen, ob wir auf ITIL Version 3<br />
umsteigen sollen<br />
Nein, wir arbeiten noch mit ITIL Version 2 und planen<br />
keinen Umstieg<br />
Weiß nicht / Keine Angabe<br />
Gab es Probleme bei der Einführung des Incident Managements?<br />
Nein<br />
47,06 %<br />
Ja<br />
52,94 %
Status quo von ITIL 44<br />
Welche Probleme gab es bei der Einführung des Incident Managements?<br />
Abb. 17 - Probleme bei der Einführung des Incident Managements<br />
Mehr als 1 /3 der Befragten hatte Schwierigkeiten mit der fehlenden Akzeptanz der Mitarbeiter.<br />
Etwa 18 % der Teilnehmer fehlte die technische Unterstützung durch effektive Hilfsmittel. Ca.<br />
11 % der Umfrageteilnehmer hatten Probleme mit dem Overhead während der Implementie-<br />
rungsphase, dem fehlenden Know-How der Mitarbeiter und der länger dauernden Durchdrin-<br />
gung des Prozesses.<br />
Fehlende Akzeptanz der Mitarbeiter<br />
Fehlende technische Unterstützung durch effektive Hilfsmittel<br />
Overhead während der Implementierungsphase<br />
Fehlendes Know-How der Mitarbeiter<br />
Durchdringung des Prozesses dauert länger als geplannt<br />
Kommunikationsprobleme<br />
Unzureichende Tool-Unterstützung<br />
Unsaubere Abbildung von Prozessen im Tool<br />
Unzureichendes Training der betroffenen Mitarbeiter<br />
Schlechte Zeitplanung<br />
Mangelnde Unterstützung durch die Vorgesetzten<br />
Fehlende Ressourcen für Projektunterstützung<br />
0,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00% 35,00% 40,00%<br />
6.1.8. Probleme bei der Einführung des Problem Managements<br />
Abbildung 18 verdeutlicht den prozentualen Anteil der Umfrageteilnehmer, die das Problem<br />
Management in Ihrem Unternehmen etabliert haben und Probleme bei der Einführung hatten.<br />
Gab es Probleme bei der Einführung des Problem Managements?<br />
Nein<br />
52,94 %<br />
Abb. 18 - Anteil der Befragten mit Problemen bei der Einführung des Incident Managements<br />
5,88%<br />
5,88%<br />
5,88%<br />
5,88%<br />
5,88%<br />
5,88%<br />
5,88%<br />
11,76%<br />
11,76%<br />
11,76%<br />
Ja<br />
47,06 %<br />
17,65%<br />
35,29%
Status quo von ITIL 45<br />
Ca. 47 % der Umfrageteilnehmer hatten Probleme bei der Einführung des Problem Manage-<br />
ments. Abbildung 19 illustriert die Probleme, die im Zuge der Einführung des Problem Mana-<br />
gements aufgetreten sind.<br />
Welche Probleme gab es bei der Einführung des Problem Managements?<br />
Fehlende Akzeptanz der Mitarbeiter<br />
Fehlende technische Unterstützung durch effektive<br />
Hilfsmittel<br />
Fehlendes Know-How der Mitarbeiter<br />
Ungenaue Trennung zwischen Incident und Problem<br />
Management<br />
Fehlende Projektressourcen<br />
Overhead während der Implementierungsphase<br />
Schlechte Zeitplanung<br />
Mangelnde Unterstützung durch die Vorgesetzten<br />
Abb. 19 - Probleme bei der Einführung des Problem Managements<br />
Fast 1 /4 der Unternehmen, die das Problem Management implementiert haben, hatten Probleme<br />
mit der fehlenden Akzeptanz der Mitarbeiter oder bemängelten die fehlende technische Unter-<br />
stützung durch effektive Hilfsmittel. Rund 18 % der Umfrageteilnehmer hatten Probleme durch<br />
das fehlende Know-How der Mitarbeiter. <strong>Die</strong> restlichen Probleme wie die fehlenden Projektres-<br />
sourcen, der Overhead während der Implementierungsphase, die mangelnde Unterstützung<br />
durch die Vorgesetzten, die schlechte Zeitplanung sowie die ungenaue Trennung zwischen Inci-<br />
dent und Problem Management, sind jeweils mit rund 6% vertreten.<br />
6.1.9. Einfluss von ITIL auf die Prozesse<br />
Abschließend wurden die Umfrageteilnehmer nach ihrer subjektiven Meinung zur Benutzer-<br />
freundlichkeit, Wirtschaftlichkeit und Flexibilität ihrer Prozesse befragt. Außerdem wurde die<br />
IT-Sicherheit und das Sourcing des Unternehmens sowie die Reaktionszeit der IT auf anfallende<br />
Störungen von den Befragten bewertet. <strong>Die</strong> Ergebnisse wurden in Relation zur ITIL-Nutzung<br />
gesetzt um den Einfluss von ITIL zu ermitteln.<br />
5,88%<br />
5,88%<br />
5,88%<br />
5,88%<br />
5,88%<br />
17,65%<br />
23,53%<br />
23,53%<br />
0,00% 5,00% 10,00% 15,00% 20,00% 25,00%<br />
Tabelle 15 verdeutlicht den Einfluss von ITIL auf die Benutzerfreundlichkeit der Prozesse.
Status quo von ITIL 46<br />
Tab. 15 - Einfluss von ITIL auf die Benutzerfreundlichkeit der Prozesse<br />
ITIL-Einsatz<br />
Insgesamt hat die Nutzung von ITIL einen geringen negativen Einfluss auf die Benutzerfreund-<br />
lichkeit der Prozesse. Rund 2 /3 der befragten Unternehmen, die auf die Verwendung von ITIL<br />
verzichten, halten die Benutzerfreundlichkeit der eigenen Prozesse für gut. Im Gegensatz dazu<br />
halten 55 % der befragten ITIL-Nutzer ihre eigenen Prozesse für gut oder sehr gut.<br />
<strong>Die</strong> Auswirkung der Nutzung von ITIL auf die Effizienz der Prozesse wird in Tabelle 16 darge-<br />
stellt.<br />
Tab. 16 - Einfluss von ITIL auf die Effizienz der Prozesse<br />
ITIL-Einsatz<br />
Bewertung<br />
Benutzerfreundlichkeit der Prozesse<br />
Sehr gut Gut Genügend Ungenügend<br />
Gemäß Tabelle 16 hat der Einsatz von ITIL nur einen geringen Einfluss auf die Effizienz der<br />
Prozesse. 95 % der Unternehmen, die ITIL anwenden, empfinden die Effizienz der eigenen<br />
Prozesse als mindestens genügend. <strong>Die</strong> restlichen 5 % konnten die Effizienz der Prozesse nicht<br />
beurteilen. 93,33 % der Unternehmen, die ITIL nicht nutzen, befinden die eigenen Prozesse für<br />
wenigstens genügend. Einzige Ausnahme sind die 6,67 % der Befragten, die ITIL nicht nutzen<br />
und die eigenen Prozesse als ineffizient einschätzen.<br />
Setzt man die Meinung der Umfrageteilnehmer zur IT-Sicherheit des Unternehmens in Relation<br />
zur ITIL-Nutzung, so ergibt sich folgende Tabelle:<br />
Tab. 17 - Einfluss von ITIL auf die IT-Sicherheit im Unternehmen<br />
ITIL-Einsatz<br />
Kann ich nicht<br />
beurteilen<br />
Summe<br />
Ja 5 % 50 % 35 % 5 % 5 % 100 %<br />
Nein - 66,67 % 26,67 % 6,67 % - 100 %<br />
Bewertung<br />
Effizienz der Prozesse<br />
Sehr gut Gut Genügend Ungenügend<br />
Kann ich nicht<br />
beurteilen<br />
Summe<br />
Ja 5 % 50 % 40 % - 5 % 100 %<br />
Nein 6,67 % 53,33 % 33,33 % 6,67 % - 100 %<br />
Bewertung<br />
IT-Sicherheit im Unternehmen<br />
Sehr gut Gut Genügend Ungenügend<br />
Kann ich nicht<br />
beurteilen<br />
Summe<br />
Ja 25 % 40 % 25 % 5 % 5 % 100 %<br />
Nein 20 % 40 % 40 % - - 100 %
Status quo von ITIL 47<br />
Tabelle 17 illustriert, dass der Einsatz von ITIL in den Unternehmen zu keiner wesentlichen<br />
Verbesserung der IT-Sicherheit geführt hat, obwohl immerhin mehr als 50 % der befragten<br />
ITIL-Nutzer das Information Security Management als Prozess eingeführt haben. (siehe Kapitel<br />
6.1.4.)<br />
Tabelle 18 verdeutlicht die Qualität der Prozesse in Abhängigkeit zur ITIL-Nutzung in den be-<br />
fragten Unternehmen.<br />
Tab. 18 - Einfluss von ITIL auf die Prozessqualität im Unternehmen<br />
ITIL-Einsatz<br />
<strong>Die</strong> Analyse der Kennzahlen in Tabelle 18 ergibt, dass die Nutzung von ITIL einen negativen<br />
Einfluss auf die Qualität der Prozesse hat. Demnach befinden zwar 80 % der ITIL-Nutzer die<br />
eigene Prozessqualität für gut, sehr gut oder wenigstens genügend. Aber immerhin 15 % halten<br />
die eigene Prozessqualität für ungenügend. Rund 93 % der Befragten, die ITIL nicht einsetzen,<br />
bewerten die eigene Prozessqualität mit gut oder genügend. <strong>Die</strong> restlichen rund 7 % halten die<br />
Prozessqualität für ungenügend.<br />
Der Einfluss von ITIL auf die Transparenz der Prozesse wird in Tabelle 19 dargestellt.<br />
Tab. 19 - Einfluss von ITIL auf die Transparenz der Prozesse<br />
ITIL-Einsatz<br />
Bewertung<br />
Gemäß Tabelle 19 hat ITIL einen geringen positiven Einfluss auf die Transparenz der Prozesse,<br />
denn 85 % der befragten ITIL-Nutzer bewerten die Transparenz mit mindestens genügend wo-<br />
hingegen nur 80 % der Befragten, die ITIL nicht nutzen, die Transparenz der eigenen Prozesse<br />
mit mindestens genügend bewerten.<br />
Prozessqualität im Unternehmen<br />
Sehr gut Gut Genügend Ungenügend<br />
Kann ich nicht<br />
beurteilen<br />
Summe<br />
Ja 10 % 40 % 30 % 15 % 5 % 100 %<br />
Nein - 46,67 % 46,67 % 6,67 % - 100 %<br />
Bewertung<br />
Transparenz der Prozesse<br />
Sehr gut Gut Genügend Ungenügend<br />
Kann ich nicht<br />
beurteilen<br />
Summe<br />
Ja 10 % 25 % 50 % 10 % 5 % 100 %<br />
Nein - 46,67 % 33,33 % 20 % - 100 %<br />
Tabelle 20 stellt die Wirtschaftlichkeit der Prozesse in Abhängigkeit zur ITIL-Nutzung dar.
Status quo von ITIL 48<br />
Tab. 20 - Einfluss von ITIL auf die Wirtschaftlichkeit der Prozesse<br />
ITIL-Einsatz<br />
Tabelle 20 verdeutlicht, dass ITIL sich negativ auf die Wirtschaftlichkeit der Prozesse auswirkt.<br />
Etwa 30 % der befragten Unternehmen, die ITIL verwenden, befinden die Wirtschaftlichkeit der<br />
Prozesse als sehr gut oder gut wohingegen 46,67 % der Unternehmen, die ITIL nicht verwen-<br />
den, die Wirtschaftlichkeit mit gut bewerten.<br />
Tabelle 21 illustriert den Einfluss von ITIL auf die Qualität des Sourcing.<br />
Tab. 21 - Einfluss von ITIL auf die Qualität des Sourcing<br />
ITIL-Einsatz<br />
Anhand von Tabelle 21 wird deutlich, dass der Einsatz von ITIL einen positiven Einfluss auf<br />
das Sourcing des Unternehmens hat. Besonders auffällig ist, dass mehr als 1 /4 der befragten Un-<br />
ternehmen , die ITIL nicht nutzen, das Sourcing des Unternehmens nicht beurteilen <strong>können</strong>.<br />
Tabelle 22 verdeutlicht die Reaktionszeit der IT auf anfallende Störungen in Abhängigkeit zur<br />
ITIL-Nutzung:<br />
Tab. 22 - Einfluss von ITIL auf die Reaktionszeit der IT<br />
ITIL-Einsatz<br />
Tabelle 22 illustriert, dass die Verwendung von ITIL einen positiven Einfluss auf die Reakti-<br />
onszeit der IT hat.<br />
Bewertung<br />
Wirtschaftlichkeit der Prozesse<br />
Sehr<br />
gut<br />
Gut Genügend Ungenügend<br />
Kann ich nicht<br />
beurteilen<br />
Summe<br />
Ja 5% 25 % 50 % 15 % 5 % 100 %<br />
Nein - 46,67 % 40,00 % 13,33 % - 100 %<br />
Bewertung<br />
Das Sourcing im Unternehmen<br />
Sehr<br />
gut<br />
Gut Genügend Ungenügend<br />
Kann ich nicht<br />
beurteilen<br />
Summe<br />
Ja 5% 35 % 55 % - 5 % 100 %<br />
Nein - 33,33 % 40,00 % - 26,67 % 100 %<br />
<strong>Die</strong> Reaktionszeit der IT auf anfallende Störungen<br />
Bewertung<br />
Sehr<br />
gut<br />
Gut Genügend Ungenügend<br />
Kann ich nicht<br />
beurteilen<br />
Summe<br />
Ja 15% 70 % 10 % - 5 % 100 %<br />
Nein 13,33 % 60,00 % 26,67% - - 100 %
Status quo von ITIL 49<br />
<strong>Die</strong> Strukturierung des IT-Betriebes in Relation zur Verwendung von ITIL wird in der folgen-<br />
den Tabelle dargestellt:<br />
Tab. 23 - Einfluss von ITIL auf die Stukturierung des IT-Betriebes<br />
ITIL-Einsatz<br />
Aus Tabelle 23 geht hervor, dass die Nutzung von ITIL einen positiven Einfluss auf die Struk-<br />
turierung des IT-Betriebes hat. Mit 65% bewerten eine Mehrzahl der Unternehmen, die ITIL in<br />
ihrem Unternehmen einsetzen, die Strukturierung des IT-Betriebes mit gut oder sehr gut, wo-<br />
hingegen nur 53,33% der Unternehmen, die für ITIL keine Verwendung haben, die Strukturie-<br />
rung des eigenen IT-Betriebes mit gut oder sehr gut bewerten.<br />
Tabelle 24 illustriert die Flexibilität der Prozesse in Relation zur ITIL-Verwendung:<br />
Tab. 24 - Einfluss von ITIL auf die Flexiblität der Prozesse<br />
ITIL-Einsatz<br />
<strong>Die</strong> Verwendung von ITIL hat einen negativen Einfluss auf die Flexibilität der Prozesse. Nur<br />
55% der befragten ITIL-Nutzer bewerten die Flexibilität ihrer Prozesse mit gut oder sehr gut,<br />
wohingegen 66,67 % der befragten Unternehmen, die ITIL nicht verwenden, die Flexibilität der<br />
eigenen Prozesse mit gut oder sogar sehr gut bewerten.<br />
6.1.10. Diskussion der Ergebnisse<br />
<strong>Die</strong> Ergebnisse der Studie zeigen, dass sich ITIL in der Hälfte der mittelständischen Unterneh-<br />
men und Unternehmen mittlerer Größe etabliert hat. Nichts desto trotz konnten oder wollten<br />
12,5 % der Umfrageteilnehmer keine Antwort darauf geben, ob ITIL in ihrem Unternehmen<br />
verwendet wird. <strong>Die</strong>s könnte an der Unwissenheit der Teilnehmer gelegen haben, die ITIL nicht<br />
kannten.<br />
Bewertung<br />
<strong>Die</strong> Strukturierung des IT-Betriebes<br />
Sehr<br />
gut<br />
Ja 10 % 55 %<br />
Nein<br />
Bewertung<br />
13,33 %<br />
Gut Genügend Ungenügend<br />
40,00 %<br />
30 %<br />
46,67 %<br />
<strong>Die</strong> Flexibilität der Prozesse<br />
Sehr gut Gut Genügend Ungenügend<br />
-<br />
-<br />
Kann ich nicht<br />
beurteilen<br />
5 %<br />
-<br />
Kann ich nicht<br />
beurteilen<br />
Summe<br />
100 %<br />
100 %<br />
Summe<br />
Ja 10 % 45 % 30 % 10 % 5 % 100 %<br />
Nein 20,00 % 46,67 % 33,33 % - - 100 %
Status quo von ITIL 50<br />
Im Rahmen der Studie wurden auch die Ziele identifiziert, die die ITIL-Nutzer durch die Ver-<br />
wendung von ITIL erreichen wollen. <strong>Die</strong> häufigsten genannten Ziele sind die Verbesserung der<br />
Prozessqualität und die Steigerung der Effizienz. Weitere wichtige Ziele sind die Professionali-<br />
sierung der IT, die Erhöhung der Kundenzufriedenheit und die Transparenz der Prozesse. Es<br />
gibt auch Gründe die gegen die Nutzung von ITIL sprechen. Demnach sind der Aufwand, der<br />
mit der Einführung verbunden ist und die alternativ verwendeten Frameworks die Hauptgründe<br />
warum ITIL in manchen Unternehmen nicht eingeführt wurde.<br />
Im Zuge der Studie wurden auch die ITIL-basierten Prozesse und Funktionen identifiziert, die<br />
in den Unternehmen am häufigsten verwendet werden und die in Zukunft noch implementiert<br />
werden sollen. Primär werden mit dem Service Desk sowie dem Change, dem Problem und dem<br />
Incident Management, operative Prozesse und Funktionen des ITIL-Frameworks in den Unter-<br />
nehmen verwendet. Nachholbedarf besteht dagegen bei den Planungs- und Implementierungs-<br />
prozessen. Dabei sticht vor allem das Service Asset und Configuration Management heraus, das<br />
fast 1 /3 der befragten ITIL-Nutzer noch einführen möchte.<br />
Im Rahmen der Umfrage wurde auch ermittelt, welche ITIL Version in den Unternehmen zum<br />
Einsatz kommt. <strong>Die</strong> Umfrage hat ergeben, dass sich ITIL V3 noch nicht vollständig durchge-<br />
setzt hat. Zwar verwenden immerhin die Hälfte aller befragten ITIL-Nutzer ITIL V3 und weite-<br />
re 9% wollen ihre Prozesse nach ITIL V3 ausrichten, nichts desto trotz sehen viele Unterneh-<br />
men bisher noch nicht die Notwendigkeit ihre Prozesse nach der neuesten Version auszurichten.<br />
Im Rahmen der Untersuchung wurde auch der Einfluss von ITIL auf die Prozesse ermittelt.<br />
Demnach hat die ITIL-Nutzung keinen positiven Einfluss auf die Benutzerfreundlichkeit, die<br />
Wirtschaftlichkeit, die Flexibilität und die Effizienz der Prozesse. Positiv hat sich dagegen die<br />
ITIL-Nutzung auf die Transparenz der Prozesse, die Qualität des Sourcing, die Reaktionszeit<br />
der IT und die Strukturierung des IT-Betriebes ausgewirkt.<br />
Meiner Meinung nach kann ITIL einen positiven Einfluss auf die Qualität der Prozesse haben,<br />
solange die Prozesse nicht zu komplex gestaltet werden. Gerade mittelständische Unternehmen<br />
zeichnen sich durch enge Kundenbeziehungen, flache Hierarchien, kürzere Informationswege<br />
und eine hohe Flexibilität aus. 117 Eine Anpassung bzw. Optimierung der Prozesse ist aber mit<br />
der Bindung von zusätzlichem Personal verbunden, was in Einzelfällen zu zusätzlichen Perso-<br />
nalengpässen führen kann und sich negativ auf die Qualität der Prozesse auswirken kann.<br />
117 Vgl. Recklies, D.: Kleine und mittlere Unternehmen – Unternehmensgröße als Chance oder Handicap?,<br />
http://www.themanagement.de/Ressources/kmu.htm, 13.02.2010.
Status quo von ITIL 51<br />
6.2. Experteninterview<br />
Steven Handgräntinger, Vorstandsvorsitzender des itSMF e.V. Deutschland, stellt sich für ein<br />
Interview zur Verfügung. Im Folgenden bekommen <strong>Sie</strong> einen Überblick über die Gründe wa-<br />
rum nach Meinung von Herrn Handgräntinger Unternehmen auf die Einführung von ITIL-<br />
basierten Standardprozessen in Unternehmen verzichten und warum diese möglicherweise doch<br />
eingeführt werden sollten. Darüber hinaus werden die wesentlichen Erfolgsfaktoren für eine<br />
erfolgreiche Umsetzung von ITIL V3 in Unternehmen etwas genauer beleuchtet und die Frage<br />
geklärt, ob die aktuelle Wirtschaftskrise nach Meinung von Herrn Handgräntinger einen Ein-<br />
fluss auf die Einführung von ITIL-basierten Prozessen in Unternehmen hat und wie er die zu-<br />
künftige Entwicklung von ITIL in KMU einschätzt.<br />
6.2.1. Ursache für den Verzicht auf ITIL-basierte Standardprozesse<br />
<strong>Die</strong> Einführung von ITIL-basierten Prozessen erfordert oftmals eine Einführung, die eine Bin-<br />
dung von internen und ggf. externen Ressourcen zur Folge hat. Darüber hinaus ist der entstan-<br />
dene Mehrwert, der durch Investitionen in Prozesse entsteht oftmals weniger greifbar, als der<br />
Mehrwert, der beispielsweise durch eine Hardwareinvestition entsteht. Ein weiterer Grund<br />
weswegen mittelständische Unternehmen eventuell von einer Einführung absehen ist das bisher<br />
nicht erkannte Potenzial von IT-Services. 118<br />
6.2.2. Gründe für den Einsatz von ITIL-basierten Standardprozessen<br />
„ITSM-Prozesse sind robuste Basisprozesse, die ein Unternehmen in die Lage versetzen, Stan-<br />
dardisierung und Automatisierung der IT voranzutreiben.‟ 119 Durch die Umsetzung ergeben<br />
sich zusätzliche Einsparpotenziale und somit ein Mehrwert für das Unternehmen. 120<br />
6.2.3. Erfolgsfaktoren für eine erfolgreiche Umsetzung von ITIL V3<br />
<strong>Die</strong> wesentlichen Erfolgsfaktoren für eine erfolgreiche Umsetzung von ITIL V3 ist nach Mei-<br />
nung von Herrn Handgräntinger die Konzentration auf die Service Strategie. 121 Anschließend<br />
gilt es zu klären, wie viel IT das Business benötigt und wie die IT den Geschäftswertbeitrag<br />
steigern kann. 122 Von diesem Standpunkt aus gilt es anschließend die einzelnen Basisprozesse<br />
zu priorisieren. 123<br />
118 vgl. Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.<br />
119 Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.<br />
120 vgl. Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.<br />
121 vgl. Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.<br />
122 vgl. Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.<br />
123 vgl. Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.
Status quo von ITIL 52<br />
6.2.4. Einfluss der aktuellen Wirtschaftskrise<br />
Gerade in wirtschaftlich schlechten Zeiten wie der aktuellen Wirtschaftskrise ermöglichen die<br />
standardisierten Basisprozesse die Automatisierung und Standardisierung voranzutreiben und<br />
Einsparpotenziale zu realisieren. Dabei ist es aber wichtig nicht nur die einzelnen IT-Kosten zu<br />
analysieren, sondern auch indirekten Kosten , die durch Qualität der IT beim Endanwender ent-<br />
steht, zu berücksichtigen. Nach Meinung von Herrn Handgräntinger wird die Wirtschaftskrise<br />
Unternehmen zwingen weiter zu automatisieren. 124 „<strong>Die</strong>s ist nur durch robuste Prozesse mög-<br />
lich.‟ 125<br />
6.2.5. Zukünftige Entwicklung in KMU<br />
Beobachtungen von Herrn Handgräntinger haben ergeben, dass immer mehr ITSM-Lösungen<br />
von KMU eingesetzt werden. Ca. 30 % der Mitglieder des itSMF zählt zu den KMU und auf<br />
dem Kongress des itSMF sind „bis zu 25 % KMU als Besucher‟. <strong>Die</strong>se Zahlen unterstreichen<br />
das Interesse der KMU, zeigen aber auch dass es noch ein weiter Weg ist. 126<br />
124 vgl. Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.<br />
125 Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.<br />
126 vgl. Handgräntinger, S.: Subject: AW Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.
Probleme bei der Einführung 53<br />
7 Probleme bei der Einführung<br />
Gegenstand des siebten Kapitels sind die typischen Probleme, die im Rahmen der Einführung<br />
von Incident und Problem Management auftreten <strong>können</strong>. Im Zuge dessen werden die Proble-<br />
me, die im Rahmen der Umfrage ermittelt wurden genauer vorgestellt und die Fallbeispiele von<br />
zwei Unternehmen präsentiert, die ebenfalls Probleme bei der Prozesseinführung hatten.<br />
7.1. Probleme<br />
Im Folgenden werden zunächst die im Rahmen der Umfrage ermittelten Probleme genauer be-<br />
schrieben.<br />
7.1.1. Fehlende Akzeptanz bei den Mitarbeitern<br />
Ein wichtiger Erfolgsfaktor für eine erfolgreiche Implementierung von neuen Prozessen ist die<br />
Akzeptanz der Mitarbeiter. 127 <strong>Die</strong> Einführung von ITIL-basierten Prozessen, wie die des Inci-<br />
dent und des Problem Managements erfordert ein Umdenken der IT-Mitarbeiter und geht mit<br />
der Veränderung der gewohnten Arbeitsweise der IT-Mitarbeiter einher. Fehlende Akzeptanz<br />
kann dazu führen, „dass historisch gewachsene Verfahren gelebt werden‟ 128 und somit der neue<br />
Prozess nicht umgesetzt wird.<br />
7.1.2. Mangelnde Unterstützung durch das Management<br />
Ein häufiges Problem bei der Einführung von ITIL-basierten Prozessen ist die fehlende Unter-<br />
stützung durch das Management, obwohl diese ursprünglich zugesichert wurde. Der Alltag sieht<br />
jedoch oftmals anders aus, denn nicht jeder Mitarbeiter aus dem Management ist davon begeis-<br />
tert, dass zukünftig ein Prozess vorschreibt mit welcher Priorität z. B. ein Incident bearbeitet<br />
wird. 129<br />
7.1.3. Schlechte Terminplanung<br />
Umfangreiche Projekte wie z. B. eine Prozesseinführung benötigen eine Terminplanung die<br />
definiert, zu welchem Zeitpunkt welche Aktivität durchgeführt werden muss. Eine schlechte<br />
Terminplanung kann dazu führen, dass die notwendigen Ressourcen nicht zur Verfügung stehen<br />
und es zu unnötigen Verzögerungen bei der Prozesseinführung kommt.<br />
127 Vgl. Schmidt, R.; Dohle , H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 85.<br />
128 Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.63.<br />
129 Vgl. Schmidt, R.; Dohle , H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 85.
Probleme bei der Einführung 54<br />
7.1.4. Fehlendes Know-How der IT-Mitarbeiter<br />
Für eine effektive Umsetzung eines Prozesses ist es wichtig, dass die Mitarbeiter über das not-<br />
wendige Know-How verfügen, um die einzelnen Aktivitäten bewerkstelligen zu <strong>können</strong>. Wenn<br />
die Mitarbeiter nicht über das notwendige Fachwissen verfügen, kann dies dazu führen, dass<br />
die Aktivitäten falsch oder gar nicht umgesetzt werden.<br />
7.1.5. Fehlende technische Unterstützung durch effektive Hilfsmittel<br />
<strong>Die</strong> Arbeitsabläufe in Prozessen werden oftmals durch den Einsatz von effektiven Hilfsmitteln<br />
(Tools) unterstützt und auch vereinfacht. ITIL empfiehlt beispielsweise für das Problem Mana-<br />
gement eine Known-Error Datenbank zu implementieren, um die Informationen über die Symp-<br />
tome, Workarounds und Lösungsmaßnahmen zu speichern, die beim abermaligen Auftreten des<br />
Fehlers aufgerufen und genutzt werden <strong>können</strong> 130 . Wenn aber genau diese Hilfsmittel fehlen,<br />
dann <strong>können</strong> die Prozesse nicht effektiv umgesetzt werden.<br />
7.1.6. Unzureichende Tool-Unterstützung<br />
Wie bereits in Kapitel 7.1.5 erklärt wurde, ist der Einsatz von effektiven Hilfsmitteln ein wich-<br />
tiger Erfolgsfaktor für die erfolgreiche Umsetzung des Prozesses. Wenn diese Tools nicht über<br />
die erforderliche Funktionalität verfügen, <strong>können</strong> sie somit nicht zum Erfolg des Projektes bei-<br />
tragen.<br />
7.1.7. Overhead während der Implementierungsphase<br />
<strong>Die</strong> Einführung von Prozessen kann ein umfangreiches Unterfangen sein, das eine Menge Per-<br />
sonal in Anspruch nimmt. Gerade in der Implementierungsphase werden viele Mitarbeiter benö-<br />
tigt, die die notwendigen Schritte für die Implementierung umsetzen. Wenn dieses Personal<br />
nicht extern beschafft wird, sondern aus dem eigenen Unternehmen kommt, kann dieses nur<br />
eingeschränkt oder gar nicht den täglichen Aufgaben nachgehen. Oftmals wird gerade aber ge-<br />
nau dies von den Mitarbeitern verlangt. <strong>Sie</strong> müssen ihrer täglichen Arbeit nachgehen und<br />
gleichzeitig bei der Implementierung der Prozesse helfen. <strong>Die</strong>s bedeutet zusätzliche Arbeit und<br />
in der Regel auch Overhead für die betroffenen Mitarbeiter. 131<br />
7.1.8. Ungenaue Trennung zwischen Incident und Problem Management<br />
Das Incident und das Problem Management sind zwei unterschiedliche Prozesse mit konkurrie-<br />
renden Zielen. Das Ziel des Incident Managements ist die schnellstmögliche Behebung von<br />
anfallenden Incidents. Das Ziel des Problem Managements ist die Senkung der Störungsanfäl-<br />
ligkeit und die nachhaltige Erhöhung der Servicequalität. Eine schnellstmögliche Behebung<br />
130 Vgl. Office of Government Commerce: ITIL Service Operation, S. 75.<br />
131 Vgl. Ellermann, H.: Münchener Rück: >> ITIL ist einfach
Probleme bei der Einführung 55<br />
eines anfallenden Incident ist aber nicht möglich, wenn zunächst eine umfassende Analyse<br />
durchgeführt werden muss, um die mögliche Ursache für den Incident zu identifizieren. Eine<br />
ungenaue Trennung zwischen den beiden Prozessen hätte zur Folge, dass die Prozesse eventuell<br />
nicht optimal umgesetzt und somit die Ziele des Prozesses nicht erreicht werden.<br />
7.1.9. Durchdringung des Prozesses dauert länger als geplant<br />
Ein weiteres Problem kann entstehen, wenn die Durchdringung von Prozessen länger als geplant<br />
dauert. Auf diese Weise werden die Prozesse nicht effektiv umgesetzt mit der Folge, dass die<br />
eigentlichen Vorteile der Prozesse nicht genutzt werden.<br />
7.1.10. Kommunikationsprobleme<br />
<strong>Die</strong> Kommunikation ist ein wichtiger Erfolgsfaktor für die erfolgreiche Umsetzung des Projek-<br />
tes. Ohne eine gut funktionierende Kommunikation zwischen den Projektbeteiligten ist es mög-<br />
lich, dass Missverständnisse entstehen, die letztendlich zu Fehlleistungen führen und oftmals<br />
mit hohem Aufwand wieder behoben werden müssen.<br />
7.1.11. Unsaubere Abbildung von Prozessen im Tool<br />
<strong>Die</strong> unsaubere Abbildung von Prozessen im Tool kann dazu führen, dass die Prozesse nicht wie<br />
ursprünglich geplant umgesetzt werden und Fehlleistungen entstehen, da bestimmte Faktoren<br />
nicht berücksichtigt werden.<br />
7.1.12. Unzureichendes Training der betroffenen IT-Mitarbeiter<br />
<strong>Die</strong> Schulung der IT-Mitarbeiter ist ein wichtiger Erfolgsfaktor für eine effektive Umsetzung<br />
der Prozesse. Wenn die IT-Mitarbeiter aber nur unzureichend bzw. gar nicht geschult werden,<br />
kann dies zur Folge haben, dass den Mitarbeitern das notwendige Fachwissen für die Umset-<br />
zung der Prozesse fehlt und diese nicht oder nur unzureichend umgesetzt werden <strong>können</strong>.<br />
7.1.13. Fehlende Ressourcen für Projektunterstützung<br />
Der Erfolg eines Projektes hängt maßgeblich von der Bereitstellung der notwendigen Ressour-<br />
cen ab. Wenn die erforderlichen Ressourcen, wie z. B. die Mitarbeiter nicht zur Verfügung ste-<br />
hen, kann das Projekt auch nicht erfolgreich umgesetzt werden. Folglich sind fehlende Ressour-<br />
cen ein großes Problem während der Prozesseinführung des Incident und Problem Manage-<br />
ments.<br />
7.1.14. Falsche Priorisierung von Incidents<br />
Eine wichtige Aufgabe der Mitarbeiter des Service Desk ist die Priorisierung von Incidents.<br />
Eine falsche Einschätzung der Service Desk Mitarbeiter kann beispielsweise dazu führen, dass<br />
zunächst weniger wichtige Incidents bearbeitet werden.
Probleme bei der Einführung 56<br />
7.2. Fallbeispiele<br />
Nachfolgend werden mit der Hessischen Zentrale für Datenverarbeitung und einem Telekom-<br />
munikationsunternehmen zwei Fallbeispiele vorgestellt, die das Incident oder das Problem Ma-<br />
nagement in Ihrem Unternehmen eingeführt haben und Probleme bei der Einführung hatten.<br />
7.2.1. Hessische Zentrale für Datenverarbeitung (HZD)<br />
<strong>Die</strong> Hessische Zentrale für Datenverarbeitung, kurz HZD, ist IT-<strong>Die</strong>nstleister für die hessische<br />
Landesverwaltung mit Standorten in Wiesbaden und Hünfeld. 132 Insgesamt sind bei der HZD<br />
rund 750 Mitarbeiter beschäftigt, die im Jahr 2008 einen Umsatz von 177 Mio. € erwirtschafte-<br />
ten. 133 Im Jahr 2003 wurde mit der Einführung von IT-Servicemanagement in der HZD gestar-<br />
tet, in dessen Rahmen das Change Management als erster Prozess implementiert wurde. 134 An-<br />
schließend wurde das bis dahin umgesetzte Störungsmanagement, welches vergleichbar mit<br />
dem Incident Management ist, neu designt und an ITIL angelehnt. 135<br />
Im Laufe der Einführung der ITIL-Prozesse hatten die Projektmitarbeiter mit einem prozess-<br />
übergreifenden Problem zu kämpfen. Durch das Mitbestimmungsrecht der Personalvertretung<br />
bei der Einführung von Prozessen musste zunächst Überzeugungsarbeit geleistet werden , um<br />
überhaupt die Prozesse einführen zu dürfen. 136<br />
7.2.2. Führender deutscher DSL-Netzbetreiber für den Massenmarkt<br />
<strong>Die</strong> Unternehmensberatungsgesellschaft Putz&Partner wurde von dem führenden deutschen<br />
DSL-Netzbetreiber mit einem Projekt beauftragt, dass das Ziel hatte „zwischen dem Incident<br />
und dem Problem Management effektive Strukturen und Prozesse zu schaffen und zu etablieren,<br />
um die Kundenzufriedenheit zu erhöhen.‟ 137<br />
Bereits vor dem eigentlichen Projektstart hatten die Projektbeteiligten mit einem Problem zu<br />
kämpfen, der Skepsis der Mitarbeiter. 138 Durch zahlreiche zuvor gescheiterte Projekte, die alle<br />
das Ziel hatten, die beiden Bereiche in einen End-to-End-Prozess zu verbinden, war die Skepsis<br />
132<br />
Vgl. Sachs, F.: Hessische Zentrale für Datenverarbeitung, www.hzd.de, 23.03.2010.<br />
133<br />
Alberts, S.: HZD ITSM-Fachforum 30.09.09, http://www.itsm-consulting.de/files/HZD%20ITSM-<br />
Fachforum%2030.09.09.pdf, 22.03.2010.<br />
134<br />
Alberts, S.: HZD ITSM-Fachforum 30.09.09, http://www.itsm-consulting.de/files/HZD%20ITSM-<br />
Fachforum%2030.09.09.pdf, 22.03.2010.<br />
135<br />
Vgl. itSMF e.V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S. 221.<br />
136<br />
Vgl. Alberts, S.: Subject: AW: Frage wegen der Einführung von ITIL-Prozessen bei der HZD, susanne.alberts@hzd.hessen.de<br />
, 23.03.2010.<br />
137<br />
Nickelsen, J.: Putz & Partner Unternehmensberatung AG: Incident und Problem Management,<br />
http://www.putzundpartner.de/fallstudien/telekommunikation/incident-und-problem-management.html, 26.03.2010.<br />
138<br />
vgl. Nickelsen, J.: Putz & Partner Unternehmensberatung AG: Incident und Problem Management,<br />
http://www.putzundpartner.de/fallstudien/telekommunikation/incident-und-problem-management.html, 26.03.2010.
Probleme bei der Einführung 57<br />
bei den Mitarbeitern groß. Aus diesem Grund musste die vorherrschende Skepsis der Mitarbei-<br />
ter in Bezug auf dieses neuerliche Projekt zunächst überwunden werden. 139<br />
139 vgl. Nickelsen, J.: Putz & Partner Unternehmensberatung AG: Incident und Problem Management,<br />
http://www.putzundpartner.de/fallstudien/telekommunikation/incident-und-problem-management.html, 26.03.2010.
Vorgehensmodell 58<br />
8 Vorgehensmodell<br />
Ein Vorgehensmodell ist ein als Modell abgebildeter Prozess, welcher ein Problem lösen soll. 140<br />
Vorgehensmodelle tragen zur strukturierten Vorgehensweise bei und ermöglichen auf diese<br />
Weise ein abgestimmtes und optimiertes Vorgehen der Beteiligten. 141 In der Regel werden Vor-<br />
gehensmodelle als Projekt organisiert, <strong>können</strong> aber u. U. auch als Organisationsform umgesetzt<br />
werden. 142<br />
Im Zusammenhang mit IT-Projekten, wie dieser <strong>Bachelorarbeit</strong>, sind Vorgehensmodelle die<br />
Präzisierung eines Phasenmodells durch die Beschreibung der auszuführenden Tätigkeiten und<br />
dessen Ergebnisse. In diesem Kapitel wird ein Vorgehensmodell vorgestellt, welches basierend<br />
auf den in Kapitel 7 genannten Problemen ein reibungsloses Vorgehen für die Einführung von<br />
Incident und Problem Management ermöglichen soll.<br />
Das Incident und Problem Management sind zwei unterschiedliche Prozesse. In der Praxis ge-<br />
hören das Incident und Problem Management aber unmittelbar zusammen. Aus diesem Grund<br />
erfolgt ihre Einführung idealerweise zeitgleich. <strong>Die</strong>se Notwendigkeit resultiert aus der Tatsache,<br />
dass beim häufigen Auftreten gleichartiger Incidents in der Regel ein Problem die Ursache ist.<br />
Um dieses Problem aus der Welt zu schaffen ist das Problem Management gefordert dem nach-<br />
zugehen und mit Hilfe von eigenen Prozessabläufen das identifizierte Problem zu analysieren<br />
und letztendlich zu beheben. Aus diesem Grund macht eine zeitlich versetzte Einführung des<br />
Incident und Problem Managements keinen Sinn und sollte stattdessen zeitgleich erfolgen. 143<br />
<strong>Die</strong> Einführung von ITIL-basierten Prozessen ist ein umfangreiches Unterfangen. Aus diesem<br />
Grund sollte die Einführung von ITIL-basierten Prozessen in Form eines Projektes erfolgen, um<br />
den oftmals sehr weitreichenden Änderungen und dem Einfluss auf die Organisation gerecht zu<br />
werden. 144<br />
Um den iterativen Charakter der Projektdurchführung widerzuspiegeln ist das Vorgehensmodell<br />
in insgesamt sieben Phasen aufgeteilt. Jede einzelne Phase ist in einzelne Teilaufgaben geglie-<br />
dert, die für die Zielerreichung der jeweiligen Phase umgesetzt werden sollten.<br />
140 Vgl. Heinrich, L. J.; Stelzer, D.: Informationsmanagement, 9. Auflage, München 2009, S. 404.<br />
141 Vgl. Steinweg, C.: Projektkompass Softwareentwicklung, 4. Auflage, Braunschweig/Wiesbaden 2002, S.2.<br />
142 Vgl. Heinrich, L. J.; Stelzer, D.: Informationsmanagement, 9. Auflage, München 2009, S. 404.<br />
143 Vgl. Lienemann, G.: ITIL - Change Management, 1. Auflage, Hannover 2006, S. 46.<br />
144 Vgl. Kittel, M.; Koerting, T. J.; Schött, D.: Kompendium für ITIL V3 Projekte, 2. Auflage, Norderstedt 2009,<br />
S. 175.
Vorgehensmodell 59<br />
Abb. 20 - Vorgehensmodell
Vorgehensmodell 60<br />
8.1. Initialisierung<br />
<strong>Die</strong> erste Phase des Vorgehensmodells ist die Initialisierungs-Phase. In dieser Phase werden die<br />
notwendigen Vorbereitungsmaßnahmen für die erfolgreiche Einführung des Incident und Prob-<br />
lem Managements durchgeführt. <strong>Die</strong> Vorbereitungsmaßnahmen sind oftmals zeitaufwendig.<br />
Aus diesem Grund sollte unbedingt ausreichend Zeit für die Umsetzung der Vorbereitungsmaß-<br />
nahmen eingeplant werden.<br />
<strong>Die</strong> wichtigsten Aktivitäten in dieser Phase sind:<br />
� Name des Projektes festlegen<br />
� Auswahl der Projektbeteiligten<br />
� Kick-off Veranstaltung durchführen<br />
� Schulung der Projektteilnehmer<br />
� Grobe Terminplanung durchführen<br />
� Einbinden des Betriebs- bzw. Personalrats<br />
8.1.1. Name des Projektes festlegen<br />
Der erste Schritt der Initialisierungs-Phase ist die Festlegung des Projektnamens. <strong>Die</strong>ser ist ein<br />
Marketinginstrument um das Projekt und die damit verbundenen Änderungen unternehmensin-<br />
tern bekannt zu machen. Gleichzeitig kann der Projektname ein wichtiger Erfolgsfaktor für die<br />
Akzeptanz des Projektes sein. Um dies zu erreichen muss der Projektname jedoch überlegt aus-<br />
gewählt werden. Bei der Wahl des Projektnamen sollte darauf geachtet werden, dass der Name<br />
des Projektes inspirierend, einprägsam und aussagekräftig ist. 145<br />
8.1.2. Auswahl der Projektbeteiligten<br />
Der nächste Schritt ist die Auswahl der Projektmitglieder. <strong>Die</strong> Auswahl der Projektmitglieder ist<br />
ein wichtiger Erfolgsfaktor für die erfolgreiche Umsetzung des Projektes, denn nur wenn die<br />
Mitarbeiter über das notwendige Know-How und genügend Zeit verfügen, <strong>können</strong> sie auch zum<br />
Erfolg des Projektes beitragen. Folglich ist es unabdingbar, dass eine adäquate Besetzung des<br />
Projektteams für die Umsetzung des Projektes gewählt wird. Im Zuge dessen sollten bereits im<br />
Vorfeld des Projektes die verschiedenen Rollen der Projektmitglieder besetzt werden. 146 <strong>Die</strong><br />
wichtigsten Rollen 147 sind:<br />
� Auftraggeber<br />
� Projektleiter 148<br />
� Lenkungsausschuss 149<br />
145 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 277.<br />
146 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 279.<br />
147 Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 279.<br />
148 Der Projektleiter trägt die Verantwortung für die Steuerung des Projektes.
Vorgehensmodell 61<br />
� Projektteam 150<br />
8.1.3. Kick-off Veranstaltung durchführen<br />
Nach der Auswahl der Projektbeteiligten sollte eine Kick-off Veranstaltung stattfinden. Inner-<br />
halb dieser Veranstaltung haben die Projektbeteiligten die Möglichkeit sich gegenseitig kennen-<br />
zulernen. Aus diesem Grund sollten alle Projektbeteiligten an dieser Veranstaltung teilnehmen.<br />
<strong>Die</strong> Veranstaltung dient aber nicht nur dem Kennenlernen der einzelnen Projektbeteiligten, son-<br />
dern es werden auch wichtige Themen wie die Projektziele, die Rollen der Projektbeteiligten,<br />
die generelle Vorgehensweise im Projekt sowie die Auswirkungen des Projektes vorgestellt. 151<br />
8.1.4. Schulung der Projektmitglieder<br />
Im nächsten Schritt der Initialisierungs-Phase sollten die Mitglieder des Projektes über die<br />
Grundlagen, Anwendungsmöglichkeiten, Chancen, aber auch die Risiken von ITIL informiert<br />
werden. An dieser Stelle bietet sich die Durchführung von ITIL-Schulungen an, mit deren Hilfe<br />
die beteiligten Projektmitglieder entsprechend geschult werden <strong>können</strong>. 152 Im Zuge dieser Schu-<br />
lung ist es ratsam den Schulungsteilnehmern die wichtigsten Begriffe des IT-Service Manage-<br />
ment zu vermitteln um auf diese Weise für einen einheitlichen Sprachgebrauch zu sorgen. Da-<br />
rüber hinaus gibt es die Möglichkeit, dass die Projektteilnehmer an einer ITIL®-Foundation-<br />
Schulung teilnehmen <strong>können</strong>. 153 Im Rahmen der ITIL®-Foundation-Schulung gibt es die Mög-<br />
lichkeit die Teilnehmer gezielt in dem Prozess zu schulen, in dem sie zukünftig eine Rolle ein-<br />
nehmen sollen. 154<br />
Wie in Kapitel 7.1.1. beschrieben haben Mitarbeiter oftmals Angst vor Veränderungen. <strong>Die</strong>s ist<br />
insofern nicht verwunderlich, als dass die Veränderungen der bisherigen Prozesse einen direkten<br />
Eingriff in die bisherige Arbeitsweise der betroffenen Mitarbeiter darstellen. Genau diese Angst<br />
kann den Projektmitarbeitern im Zuge der ITIL-Schulung genommen werden. Um dies zu errei-<br />
chen müssen die Projektmitarbeiter über die geplanten Änderungen sowie die möglichen Risi-<br />
ken des Projektes informiert und auf die Relevanz für das Unternehmen hingewiesen werden.<br />
Es ist nicht ausreichend die IT-Mitarbeiter anzuweisen einen Prozess umzusetzen. Stattdessen<br />
ist es wesentlich sinnvoller mit Hilfe einer einleuchtenden Argumentation die IT-Mitarbeiter<br />
von der Bedeutung des Prozesses zu überzeugen.<br />
149 Der Lenkungsausschuss setzt sich aus dem Projektleiter, dem Auftraggeber des Projektes und bei Bedarf auch<br />
internen oder externen Berater zusammen.<br />
150 Das Projektteam setzt sich aus den Mitarbeitern des Projektes zusammen, die sich um die Umsetzung der Aktivitä-<br />
ten des Projektes kümmern.<br />
151 Vgl. Kittel, M.; Koerting, T. J.; Schött, D.: Kompendium für ITIL V3 Projekte, 2. Auflage, Norderstedt 2009, S.<br />
182.<br />
152 Vgl. itSMF e. V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S.131.<br />
153 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 301.<br />
154 Vgl. Kittel, M.; Koerting, T. J.; Schött, D.: Kompendium für ITIL V3 Projekte, 2. Auflage, Norderstedt 2009, S.<br />
232.
Vorgehensmodell 62<br />
Für die Durchführung der Schulung bietet es sich an auf das Wissen eines externen Beraters<br />
zurückzugreifen. Der Einsatz eines Beraters bietet in der Regel den Vorteil, dass dieser sowohl<br />
über das Know-How, als auch die notwendige Erfahrung für die Durchführung der Schulung<br />
verfügt. Inhaltlich sollten im Rahmen der ITIL-Schulung die wesentlichen Aspekte 155 des Inci-<br />
dent und des Problem Managements vorgestellt werden:<br />
� Ziele des Incident und des Problem Managements<br />
� Input, Aktivitäten und Output der Prozesse<br />
� Incident-Management-Owner, Problem-Management-Owner<br />
� KPIs für das Incident und das Problem Management<br />
8.1.5. Grobe Terminplanung<br />
Bereits in der Initialisierungs-Phase sollte eine grobe Terminplanung erfolgen, um den Zeitrah-<br />
men des Projektes grob abstecken zu <strong>können</strong>. 156 <strong>Die</strong> Termine sollten nur grob geplant werden,<br />
da zu diesem Zeitpunkt noch keine detaillierte Planung mit allen umzusetzenden Aktivitäten<br />
vorhanden ist. Eine beliebte Vorgehensweise um die Zieltermine des Projektes grob abschätzen<br />
zu <strong>können</strong> ist die Nutzung von Erfahrungswerten. <strong>Die</strong>se Variante bietet sich gerade dann an,<br />
wenn erfahrene externe Berater an der Umsetzung des Projektes mitwirken.<br />
8.1.6. Einbinden des Betriebs- bzw. Personalrats in den Planungsprozess<br />
Betriebs- bzw. Personalräte haben oftmals in Unternehmen bzw. Behörden einen großen Ein-<br />
fluss. Wie in Kapitel 7.2.1. beschrieben, kann dies mitunter dazu führen , dass die Umsetzung<br />
von Projekten verhindert bzw. verzögert wird. Um dies zu verhindern sollte der Betriebs- bzw.<br />
Personalrat, sofern dieser vorhanden ist, frühzeitig in die Planung mit eingebunden werden. 157<br />
Dadurch wird sichergestellt, dass sich das Projekt nicht unnötig verzögert. 158 Um die Mitarbei-<br />
tervertreter von der besonderen Relevanz des Projektes zu überzeugen ist es oftmals sinnvoll,<br />
dass der Betriebs- bzw. Personalrat durch die Unternehmensführung über die Einführung der<br />
Prozesse informiert wird. Auf diese Weise wird die besondere Bedeutung der Prozesse noch-<br />
mals hervorgehoben.<br />
Im Zuge der Einführung von ITIL-basierten Prozessen werden in der Regel KPIs zur Überwa-<br />
chung der Prozessqualität festgelegt. Häufig wird genau diese Maßnahme mit der Überwachung<br />
der IT-Mitarbeiter gleichgesetzt. Deshalb ist es besonders wichtig, dass dem Betriebs- bzw.<br />
155 Vgl. Schmidt, R.; Dohle , H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 91.<br />
156 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 280.<br />
157 Vgl. Buchsein, R.: IT-Management mit ITIV V3, 1. Auflage, Wiesbaden 2007, S. 227.<br />
158 Vogel, M.: Mitbestimmung bei IT-Systemen: Achtung: Betriebsrat!,<br />
http://www.cio.de/karriere/805409/index2.html, Abruf am 02.05.2010.
Vorgehensmodell 63<br />
Personalrat verdeutlicht wird, dass es bei Festlegung der KPIs um die Verbesserung der Ser-<br />
vicequalität geht und nicht um die Überwachung der IT-Mitarbeiter. 159<br />
Oftmals sind die Betriebs- bzw. Personalräte besonders kritisch, wenn sie in der Vergangenheit<br />
mit ähnlich gearteten Projekten schlechte Erfahrungen gemacht haben. Aus diesem Grund ist<br />
ein schrittweiser Vertrauensaufbau ein wichtiges Kriterium um die Betriebsräte von der Pro-<br />
zesseinführung zu überzeugen. In der Regel <strong>können</strong> besonders kritische Betriebs- bzw. Perso-<br />
nalräte durch das frühzeitige Einbinden in das Projekt und eine offene Kommunikation besser<br />
überzeugt werden. 160 Darüber hinaus besteht die Möglichkeit, dass die Festlegung der erhobe-<br />
nen Kennzahlen in Absprache mit dem Betriebs- bzw. Personalrat erfolgt. 161 Auf diese Weise<br />
wird sichergestellt, dass der Betriebs- bzw. Personalrat zufriedengestellt wird und der Einfüh-<br />
rung der Prozesse zustimmt.<br />
8.2. Zieldefinition<br />
<strong>Die</strong> zweite Phase des Vorgehensmodells beschäftigt sich mit der Zieldefinition des Projektes.<br />
Ein wichtiger Schritt für die erfolgreiche Durchführung des Projektes ist die Festlegung von<br />
messbaren Zielen, auf die die Projektmitglieder hinarbeiten <strong>können</strong>. Im Zuge dessen sollte die<br />
folgenden Aktivitäten durchgeführt werden:<br />
� Zielworkshop veranstalten<br />
� Ziele dokumentieren<br />
� Ziele genehmigen lassen<br />
8.2.1. Zielworkshop veranstalten<br />
Für die Festlegung der Ziele bietet es sich an einen Zielworkshop zu veranstalten, in dem die<br />
Ziele des Projektes definiert werden. 162 Bei der Wahl der Teilnehmer des Workshops sollte da-<br />
rauf geachtet werden, dass repräsentative Vertreter ausgewählt werden, die die Interessen der<br />
jeweiligen Interessengruppe vertreten. Insbesondere sollte unbedingt der Auftraggeber des Pro-<br />
jektes an dem Zielworkshop teilnehmen.<br />
Im Zuge des Zielworkshops sollte zunächst ein Brainstorming veranstaltet werden. Das Brain-<br />
storming ist eine Kreativitätstechnik mit dessen Hilfe die Teilnehmer des Zielworkshops ihre<br />
Erwartungen an das Incident und das Problem Management äußern und beispielsweise auf einer<br />
159 itSMF e. V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S.138.<br />
160 Vgl. Zielke, F.; Schinkel, A.-W.; Oldag, J.; Weber, G.: ITIL überzeugend einführen , 1. Auflage, Düsseldorf<br />
2010,S.62 f.<br />
161 Vgl. Buchsein, R.: IT-Management mit ITIV V3, 1. Auflage, Wiesbaden 2007, S. 228.<br />
162 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 283.
Vorgehensmodell 64<br />
Metaplanwand sammeln <strong>können</strong>. Bei der Zielformulierung ist darauf zu achten, dass das festge-<br />
legte Ziel SMART ist. In diesem Kontext steht SMART 163 für:<br />
� Spezifisch<br />
� Messbar<br />
� Akzeptiert<br />
� Realistisch<br />
� Terminierbar<br />
Anschließend sollten die gesammelten Ziele sinnvoll geordnet und gegebenenfalls zusammen-<br />
gefasst werden. 164 <strong>Die</strong> verschiedenen Ziele haben zum Teil unterschiedliche Bedeutungen. Aus<br />
diesem Grund sollte als nächster Schritt eine Gewichtung und Priorisierung der Ziele erfolgen.<br />
8.2.2. Ziele dokumentieren<br />
Nach der Gewichtung und Priorisierung der Ziele sollte das Ergebnis des Zielworkshops in ei-<br />
nem Zielkatalog dokumentiert werden. 165 <strong>Die</strong>ser Zielkatalog dient als Grundlage für die spätere<br />
Identifikation der Handlungsfelder und der Ableitung der Handlungsempfehlungen.<br />
8.2.3. Genehmigung der Ziele<br />
Nach der Dokumentation der Ziele muss der fertige Zielkatalog dem Auftraggeber vorgelegt<br />
und die definierten Ziele genehmigt werden. <strong>Die</strong> Genehmigung wird natürlich vereinfacht,<br />
wenn der Auftraggeber wie in Kapitel 8.2.1 empfohlen am Zielworkshop teilnimmt und bereits<br />
während des Zielworkshops seine Bedenken hinsichtlich bestimmter Ziele äußern kann.<br />
8.3. Analyse<br />
In der nächsten Phase, der sogenannten Analyse-Phase wird in erster Linie der aktuelle Zustand<br />
der IT ermittelt. <strong>Die</strong> wichtigsten Aktivitäten in der Analyse-Phase sind:<br />
� Ist-Analyse durchführen<br />
� Erste Auswertung der Ergebnisse und Rückfrage mit den Befragten<br />
� Handlungsfelder identifizieren und Handlungsempfehlungen ableiten<br />
� Anpassen der Terminplanung<br />
� Informationsveranstaltung für die IT-Mitarbeiter durchführen<br />
8.3.1. Ist-Analyse durchführen<br />
Der nächste Schritt der Analyse-Phase ist die Durchführung einer Ist-Analyse. Das Ziel der Ist-<br />
Analyse ist die Identifikation der bereits bestehenden Prozesse und Verfahren. 166 Um dies zu<br />
163 itSMF e. V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S.114.<br />
164 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 284 f.<br />
165 vgl. itSMF e. V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S.118.
Vorgehensmodell 65<br />
erreichen sollten die bereits existierenden Prozessbeschreibungen, Tooldokumentationen, Ar-<br />
beitsanweisungen und Schnittstellenbeschreibungen gesichtet werden. 167<br />
Oftmals ist die Sichtung der vorhandenen Dokumentation alleine nicht ausreichend, da diese<br />
keine Schlüsse darauf zulässt, ob die auf dem Papier beschriebenen Prozesse auch in der Praxis<br />
umgesetzt werden. 168 Aus diesem Grund ist es ratsam die betroffenen Mitarbeiter direkt zu be-<br />
fragen. Abhängig von der Anzahl der IT-Mitarbeiter kann dies ein umfangreiches Unterfangen<br />
werden. Deshalb muss im Einzelfall entschieden werden, ob die Befragung der Mitarbeiter in<br />
Form von Einzelinterviews oder Gruppeninterviews stattfinden sollte. 169<br />
6-W-Methode<br />
Für die Interviews bietet sich die Nutzung der 6-W-Methode an. Bei dieser Methode werden<br />
den Befragten sechs Basisfragen 170 gestellt:<br />
� Wer - <strong>Die</strong> Frage nach dem „Wer‟ klärt welche Person für den Prozess verantwortlich<br />
ist und die Aufgaben des Prozesses umsetzt. Darüber hinaus sollte im Zuge dessen ge-<br />
fragt werden, welche Person alternativ die Aufgaben übernehmen könnte.<br />
� Was - <strong>Die</strong> Frage nach dem „Was‟ dient der Identifikation der Aktivitäten des Prozes-<br />
ses. Das Ergebnis dieser Frage sollte in einem Aktivitätsdiagramm illustriert werden. 171<br />
� Wo - Mit der Frage nach dem „Wo‟ fliest der räumliche Aspekt in die Betrachtung mit<br />
ein.<br />
� Wann - <strong>Die</strong> Frage nach dem „Wann‟ berücksichtigt den zeitlichen Aspekt der Pro-<br />
zessbetrachtung und hinterfragt z. B. Reaktionszeiten auf Störungsmeldungen.<br />
� Warum - Nach der Frage nach dem Wann sollte mit der Frage nach dem „Warum‟ der<br />
Grund für den Einsatz der Prozessbeteiligten geklärt werden.<br />
� Wie - Nachdem geklärt ist, warum die Prozessbeteiligten tätig werden, ist zu klären wie<br />
die Prozessbeteiligten vorgehen. Im Rahmen dessen ist zu prüfen wie die eingesetzten<br />
Tools genutzt und konfiguriert werden.<br />
SWOT-Analyse<br />
Nach der Durchführung des Interviews ist es sinnvoll die Ergebnisse mit Hilfe der SWOT-<br />
Analyse zu analysieren. SWOT 172 steht für:<br />
� Strengths (Stärken)<br />
166 Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.105.<br />
167 Vgl. itSMF e.V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S. 90.<br />
168 Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.106.<br />
169 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 293.<br />
170 Vgl. itSMF e.V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S. 98 f.<br />
171 Vgl. itSMF e.V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S. 98.<br />
172 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 298.
Vorgehensmodell 66<br />
� Weaknesses (Schwächen)<br />
� Opportunites (Chancen)<br />
� Threats (Gefahren)<br />
<strong>Die</strong> SWOT-Analyse ist ein geeignetes Hilfsmittel für die Aufarbeitung der Analyseergebnisse<br />
und ermöglicht eine transparente Gegenüberstellung der Analyseergebnisse nach Stärken und<br />
Schwächen sowie nach Chancen und Bedrohungen. Für die Analyse der Ergebnisse des IST-<br />
Zustandes ist es sinnvoll die SWOT-Analyse in zwei unterschiedliche Ebenen einzuteilen. <strong>Die</strong><br />
erste Ebene berücksichtigt die Stärken und Schwächen der vorhandenen Prozesse, die zweite<br />
Ebene wird genutzt um die Chancen und Risiken der IT-Organisation zu beurteilen. 173 Für die<br />
Darstellung der Ergebnisse eignet sich besonders die Verwendung einer SWOT-Matrix, wie sie<br />
beispielhaft in Abbildung 20 dargestellt wird.<br />
Abb. 21 - Beispielhafte Darstellung einer SWOT-Matrix<br />
8.3.2. Erste Auswertung der Ergebnisse und Rückfrage<br />
Nach der Durchführung der SWOT-Analyse sollte nochmals eine Rücksprache mit den Umfra-<br />
geteilnehmern erfolgen. Im Zuge dessen sollten die ersten Ergebnisse mit den Befragten kon-<br />
struktiv diskutiert und anschließend verifiziert werden. Um eine Beschönigung der tatsächlichen<br />
Situation zu vermeiden, sollten gerade zu diesem Zeitpunkt kritische Stimmen besonders sorg-<br />
sam berücksichtigt werden. 174<br />
8.3.3. Handlungsfelder identifizieren und Handlungsempfehlungen ableiten<br />
Auf Basis der Ergebnisse der SWOT-Analyse und den festgelegten Zielen müssen als nächstes<br />
die Handlungsfelder identifiziert und die notwendigen Handlungsempfehlungen für die Imple-<br />
173 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 298.<br />
174 Vgl. Kittel, M.; Koerting, T. J.; Schött, D.: Kompendium für ITIL V3 Projekte, 2. Auflage, Norderstedt 2009, S.<br />
189.<br />
Stärken<br />
Service Desk ist eingerichtet.<br />
Tickettool ist eingerichtet.<br />
Chancen<br />
<strong>Die</strong> Mitarbeiter sind motiviert und bereit<br />
das bisherige Vorgehen zu verändern.<br />
Ein Teil der IT-Mitarbeiter haben bereits<br />
Erfahrungen mit ITIL gemacht.<br />
<strong>Die</strong> Anwender sind an einem verbesserten<br />
IT-Service interessiert.<br />
Schwächen<br />
<strong>Die</strong> Schnittstellen zu anderen<br />
Fachbereichen sind unbekannt.<br />
Das Tickettool wird nicht immer verwendet.<br />
Risiken<br />
Es gibt keine Verfahren für Major Incidents.<br />
Es gibt keine Task Force.<br />
<strong>Die</strong> Anwender sind wegen den häufigen<br />
Verzögerungen bei der Störungsbehebung<br />
verärgert.
Vorgehensmodell 67<br />
mentierung des Incident und des Problem Managements abgeleitet werden. 175 Um die Nachvoll-<br />
ziehbarkeit der Handlungsempfehlungen zu gewährleisten sollten die Handlungsempfehlungen<br />
in einem Maßnahmenkatalog dokumentiert werden. 176 Im Zuge dessen sollten die Aktivität, das<br />
Ziel, das erwartete Ergebnis, der Aufwand und gegebenenfalls Voraussetzungen dokumentiert<br />
werden. 177<br />
8.3.4. Anpassen der Terminplanung<br />
Nach der Erstellung des Maßnahmenkatalogs sind alle für den Projekterfolg notwendigen Akti-<br />
vitäten bekannt. Aus diesem Grund kann als nächster Schritt die zuvor durchgeführte Grobpla-<br />
nung der Termine angepasst und detailliert werden. Im Zuge dessen müssen die Termine kon-<br />
kretisiert, die Aktivitäten beschrieben und die Verantwortlichen für die einzelnen Aktivitäten<br />
festgelegt und informiert werden. 178<br />
8.3.5. Informationsveranstaltung für die IT-Mitarbeiter<br />
Am Ende der Analyse-Phase sollte der Lenkungsausschuss im Rahmen einer Informationsver-<br />
anstaltung die IT-Mitarbeiter über das Projekt informieren. Im Rahmen dessen sollten die IT-<br />
Mitarbeiter über die Projektbeteiligten, die Projektplanung, die Inhalte und die Konsequenzen<br />
des Projektes informiert werden und auf die anstehenden ITIL-Schulungen aufmerksam ge-<br />
macht werden. 179 Bei der Durchführung der Informationsveranstaltung ist es sinnvoll das Mana-<br />
gement in die Veranstaltung einzubinden, um die Bedeutung des Projektes hervorzuheben und<br />
die IT-Mitarbeiter auf diese Weise von der Relevanz der Projektes zu überzeugen. <strong>Die</strong>s kann<br />
sich positiv auf die Akzeptanz der Mitarbeiter auswirken. (siehe Kapitel 7.1.1.)<br />
8.4. Design<br />
In der Design-Phase wird das Vorgehen für die Implementierung festgelegt. Grundlage für die<br />
Gestaltung des Incident und des Problem Managements sind die Ergebnisse der Analyse-Phase.<br />
<strong>Die</strong> wichtigsten Aktivitäten in der Design-Phase sind:<br />
� Durchführung eines Prozess-Workshops<br />
o Prozesse definieren<br />
o Schnittstellen festlegen<br />
o KPIs festlegen<br />
o Definition der Rollen<br />
175 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 299.<br />
176 Vgl. itSMF e. V. (Hrsg.): ITIL in der Öffentlichen Verwaltung, 1. Auflage, Düsseldorf 2007, S.134.<br />
177 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 299.<br />
178 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 300.<br />
179 Vgl. Kittel, M.; Koerting, T. J.; Schött, D.: Kompendium für ITIL V3 Projekte, 2. Auflage, Norderstedt 2009, S.<br />
196.
Vorgehensmodell 68<br />
o Kriterien für die Toolauswahl ableiten<br />
o Dokumentation der Ergebnisse<br />
� Toolauswahl durchführen<br />
� Prozessschulung durchführen<br />
8.4.1. Prozess-Workshop<br />
Nachdem die Ausgangssituation, die Ziele und die Maßnahmen für die Umsetzung geklärt sind<br />
müssen als nächstes die neuen Prozesse entwickelt und an die Anforderungen des Unterneh-<br />
mens angepasst werden. Um das Incident und Problem Management zu gestalten ist es sinnvoll<br />
einen Prozess-Workshop zu veranstalten, in dessen Rahmen die Prozesse an die individuellen<br />
Bedürfnisse des Unternehmens angepasst und neu gestaltet werden. <strong>Die</strong> Hauptaufgabe der<br />
Workshop-Teilnehmer ist die Gestaltung des Incident und des Problem Managements sowie die<br />
Definition der Schnittstellen, der KPIs, der Rollen und die Ableitung der Kriterien für die Tool-<br />
auswahl. Eine weitere wichtige Aufgabe ist die Dokumentation der Ergebnisse. 180<br />
Im Vorfeld sollte aber zunächst geklärt werden, ob das Incident und das Problem Management<br />
in zwei einzelnen Prozess-Workshops gestaltet werden soll oder ob ein gemeinsamer Prozess-<br />
Workshop für die Gestaltung beider Prozesse sinnvoll ist. Für die Abhaltung eines einzelnen<br />
Workshops, in dem beide Prozesse gestaltet werden spricht die Tatsache, dass beide Prozesse<br />
stark voneinander abhängig sind und sich gegenseitig beeinflussen. Andererseits sollte darauf<br />
geachtet werden, dass nicht zu viele Personen an dem Prozess-Workshop teilnehmen, um eine<br />
optimale Zusammenarbeit zu gewährleisten. Folglich sollte im Einzelfall entschieden werden ob<br />
ein oder zwei Prozess-Workshops veranstaltet werden sollen.<br />
Generell ist es ratsam im Rahmen des Prozess-Workshops auf die Erfahrung der IT-Mitarbeiter<br />
zurückzugreifen und diese in die Gestaltung des neuen Prozesses aktiv einzubinden. 181 Auf die-<br />
se Weise kann die Akzeptanz für die geplanten Veränderungen und die Motivation für die Um-<br />
setzung erheblich gesteigert werden. 182<br />
Das Teilnehmerfeld für den Prozess-Workshop für die Gestaltung des Incident und Problem<br />
Managements kann sich z. B. aus den folgenden Teilnehmern zusammensetzen:<br />
� Problem Manager, Incident Manager<br />
� Leiter des Service Desk<br />
� Mitarbeiter des Service Desk<br />
� Vertreter des 2nd Level Support<br />
180 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 302.<br />
181 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 234.<br />
182 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 303.
Vorgehensmodell 69<br />
� Known-Error-Datenbank-Verantwortlicher , CMS-Verantwortlicher, Ticketing-Tool-<br />
Verantwortlicher<br />
Im Zuge des Prozess-Workshops werden die Prozesse, die Rollen, die Schnittstellen und die<br />
KPIs definiert bevor das Ergebnis noch dokumentiert wird.<br />
Definition der Prozesse<br />
<strong>Die</strong> Gestaltung eines Prozesses erfolgt auf Basis des generischen Prozessmodells. Demnach hat<br />
ein Prozess einen definierten Input, der mit Hilfe der Aktivitäten des Prozesses in einen defi-<br />
nierten Output umgewandelt wird. (siehe Kapitel 2.1.) Folglich müssen bei der Gestaltung des<br />
Prozesses der Input, der Output und die Aktivitäten des Prozesses festgelegt werden, wobei die<br />
Festlegung des Outputs auf Basis der vorher definierten Ziele erfolgt. 183 Das Ergebnis der Pro-<br />
zessdefinition sollte anschließend in einer Prozessbeschreibung dokumentiert werden.<br />
Definition der Rollen<br />
Der nächste Schritt ist die Definition der Rollen, die für die Umsetzung des Prozesses benötigt<br />
werden. <strong>Die</strong> Beschreibung der einzelnen Rollen sollte in sogenannten Rollenbeschreibungen<br />
festgehalten werden. <strong>Die</strong> Rollenbeschreibung enthält Informationen zu den folgenden Stich-<br />
punkten 184 :<br />
� Aufgaben<br />
� Verantwortung<br />
� Kompetenzen<br />
Um die Verantwortlichkeiten der einzelnen Aktivitäten des einzuführenden Prozesses zu doku-<br />
mentieren ist der Einsatz des RACI-Modells 185 sinnvoll. Das RACI-Modell ist ein Hilfsmittel<br />
zur Analyse und Darstellung von Verantwortlichkeiten. 186 Der Name des RACI Modells leitet<br />
sich von den Anfangsbuchstaben der folgenden englischen Begriffe 187 ab:<br />
� Responsible - benennt die für die Durchführung der Tätigkeit zuständige Person oder<br />
Gruppe<br />
� Accountable - beschreibt die für die Aktivität verantwortliche Person<br />
� Consulted - definiert die Person oder Gruppe, deren Rat eingeholt wird<br />
� Informed - beschreibt die Person oder Gruppe, die über den Verlauf bzw. das Ergebnis<br />
der Tätigkeit informiert wird<br />
Für das Incident Management sieht das RACI-Modell z. B. folgendermaßen aus:<br />
183 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 303 f.<br />
184 Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 311.<br />
185 Das RACI-Modell wird in der deutschen Literatur teilweise auch als VABI-Modell bezeichnet.<br />
186 Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.175.<br />
187 Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.175.
Vorgehensmodell 70<br />
Tab. 25 - RACI-Tabelle für das Incident Management 188<br />
Aktivität Verantwortlich<br />
Störung anlegen und<br />
klassifizieren<br />
(Responsible)<br />
Ausführend<br />
(Accountable)<br />
Teamleiter Service-Desk-<br />
Mitarbeiter<br />
Bearbeitung der Störung Teamleiter Service-Desk-<br />
Ticketabschluss und<br />
anschließendes Informie-<br />
ren des Anwenders über<br />
die Erledigung<br />
Eintragen der Lösungen<br />
in die Lösungsdatenbank<br />
Pflege der Lösungsda-<br />
tenbank<br />
2 nd Level Support für<br />
Standardsoftware<br />
2 nd Level Support für<br />
Fachapplikationen<br />
2 nd Level Support für<br />
Hardware<br />
Mitarbeiter,<br />
2 nd -Level-Mitarbeiter<br />
Teamleiter Service-Desk-<br />
Qualitätssicherung<br />
im Service Desk<br />
Qualitätssicherung<br />
im Service Desk<br />
Service-Desk-<br />
Mitarbeiter<br />
Service-Desk-<br />
Mitarbeiter<br />
Service-Desk-<br />
Mitarbeiter<br />
3 rd Level Support Service-Desk-<br />
Reports über das Incident<br />
Management erstellen<br />
Mitarbeiter<br />
Mitarbeiter<br />
Service-Desk-<br />
Mitarbeiter,<br />
2 nd -Level-Mitarbeiter<br />
Qualitätssicherung im<br />
Service Desk<br />
Dispatcher im 2 nd -Level<br />
für Standardsoftware<br />
Dispatcher im 2 nd -Level<br />
für Hardware<br />
Dispatcher im 2 nd -Level<br />
für <strong>Die</strong>nstleister<br />
Entwickler,<br />
externe <strong>Die</strong>nstleiter<br />
Incident Manager Qualitätssicherung im<br />
Service Desk<br />
Beteiligt<br />
(Consulted)<br />
Externe<br />
<strong>Die</strong>nstleister<br />
Teamleiter im<br />
Service Desk<br />
Informiert<br />
(Informed)<br />
Prozess-Owner<br />
des Incident<br />
Managements<br />
Wichtige Rollen, die beispielsweise für die jeweiligen Prozesse festgelegt werden sollten sind:<br />
Tab. 26 - Rollenbeschreibungen<br />
Incident Management Problem Management<br />
Prozess-Owner des Incident Managements Prozess-Owner des Problem Managements<br />
Incident Manager Problem Manager<br />
1st Level Support<br />
2nd Level Support<br />
Gerade mittelständische Unternehmen haben nicht unbedingt die notwendigen Ressourcen um<br />
bestimmte Rollen mit einer Vollzeitstelle zu besetzen. Aus diesem Grund kann es sinnvoll sein,<br />
dass eine Person mehrere Rollen besetzt.<br />
188 In Anlehnung an: Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 99.
Vorgehensmodell 71<br />
Definition der Schnittstellen<br />
„Damit die definierten Prozesse untereinander agieren <strong>können</strong>, müssen die Schnittstellen zum<br />
Austausch von Triggern, Daten und Informationen zwischen den Prozessen definiert wer-<br />
den‟. 189 <strong>Die</strong> Ergebnisse sollte anschließend in einer Schnittstellenbeschreibung für die jeweilige<br />
Schnittstelle festgehalten werden.<br />
Definition der KPIs<br />
Der nächste Schritt ist die Definition der zu messenden KPIs, mit deren Hilfe die Prozessquali-<br />
tät des Incident und Problem Management gemessen werden kann. 190 Bei Auswahl der KPIs ist<br />
es sinnvoll auf die Erfahrung der Mitarbeiter zu setzen und diese bei der Auswahl der KPIs ein-<br />
zubinden. Oftmals ist das Messen von KPIs ein umfangreiches Unterfangen, aus diesem Grund<br />
ist bei der Wahl der KPIs darauf zu achten, dass die KPIs sinnvoll ausgewählt werden. Es sollte<br />
nicht das primäre Ziel sein möglichst viele KPIs festzulegen, stattdessen sollten nur KPIs aus-<br />
gewählt werden, die für die Prozessoptimierung hilfreich und notwendig sind. Deshalb sollten<br />
die ausgewählten KPIs SMART (Spezifisch, Messbar, Akzeptiert, Realistisch, Terminierbar)<br />
sein. Bei der Auswahl der KPIs ist außerdem darauf zu achten, dass der Betriebsrat frühzeitig in<br />
die Auswahl eingebunden wird um weitere Konflikte und die damit verbundenen Verzögerun-<br />
gen zu vermeiden. Mögliche Beispiele wie die zu messenden KPIs aussehen könnten werden in<br />
der nachfolgenden Tabelle 25 dargestellt.<br />
Tab. 27 - KPIs für das Incident und das Problem Management<br />
Für das Incident Management Für das Problem Management<br />
� Anzahl der Incidents 191<br />
� Erstlösungsrat der Incidents 192<br />
� Durchschnittliche Wiederherstellungszeit aller Inci-<br />
dents 193<br />
� Durchschnittliche Wiederherstellungszeit pro Prioritäts-<br />
stufe 194<br />
� Durchschnittliche Wiederherstellungszeit pro Kategorie<br />
� Anzahl der Incidents nach Status<br />
� Anzahl der Incidents, die anfänglich falsch klassifiziert<br />
wurden 195<br />
� Anzahl der falsch weitergeleiteten Incidents 196<br />
� Anzahl der Probleme 197<br />
� Durchschnittliche Zeit bis zur Problem-<br />
identifizierung<br />
� Durchschnittliche Anzahl von Incidents<br />
bis das Problem identifiziert wird<br />
� Durchschnittliche Problemlösungszeit<br />
� Verhältnis reaktiver zu proaktiver Prob-<br />
lem-Tickets 198<br />
189 Beims, M.: IT-Service Management in der Praxis mit ITIL 3, 2. Auflage, München 2010, S. 312.<br />
190 Vgl. Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 136.<br />
191 Kempter, A.: ITIL-Kennzahlen Service Operation - Servicebetrieb - IT Process Wiki , http://wiki.de.itprocessmaps.com/index.php/ITIL-Kennzahlen_Service_Operation_-_Servicebetrieb,<br />
02.06.2010.<br />
192 Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.63.<br />
193 Vgl. Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 136<br />
194 Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.63.<br />
195 Vgl. Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 136<br />
196 Vgl. Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 136.
Vorgehensmodell 72<br />
Ableiten der Toolkriterien<br />
Der nächste Schritt ist das Festlegen der Anforderungen für die Toolauswahl. Im Zuge dessen<br />
müssen zunächst die Anforderungen an die Tools definiert und auf Basis der Aktivitäten des<br />
Prozesses identifiziert werden. 199 Anschließend sollte die Bedeutung der Anforderungen auf<br />
Basis des MoSCoW-Prinzip bewertet werden. MoSCoW 200 steht in diesem Kontext für:<br />
� M - MUST have this<br />
� S - SHOULD have this if at all possible<br />
� C - COULD have this if doesn't affect anything else<br />
� W - WON'T have this time but WOULD like in the future<br />
Alle Kriterien, die mit „MUST‟ bewertet werden sind die sogenannten Ausschlusskriterien.<br />
<strong>Die</strong>se müssen erfüllt werden, ansonsten werden die Tools, die diese Kriterien nicht erfüllen<br />
nicht weiter beim Auswahlverfahren berücksichtigt. Alle Anforderungen, die mit „SHOULD‟<br />
bewertet werden sind „wichtig für die effektive und effiziente Prozessdurchführung und sollten<br />
nach Möglichkeit vorhanden sein.‟ 201 „COULD‟-Anforderungen sind für das Auswahlverfahren<br />
von geringer Bedeutung und <strong>können</strong>, müssen aber nicht, erfüllt werden. <strong>Die</strong> mit „WON'T‟ be-<br />
werteten Anforderungen sind zum aktuellen Zeitpunkt nicht notwendig, werden aber in Zukunft<br />
noch benötigt. 202<br />
Durch die Identifikation und die anschließende Bewertung der Anforderungen wird sicherge-<br />
stellt, dass das später ausgewählte Tool alle erforderlichen Funktionalitäten bereitstellt und so-<br />
mit keine Probleme wegen unzureichender Tool-Unterstützung auftreten (siehe. Kapitel 7.1.6.).<br />
Nachdem die Anforderungen identifiziert und mit Hilfe des MoSCoW-Prinzip bewertet wur-<br />
den, sollten die Anforderungen in einem Anforderungskatalog dokumentiert werden. 203<br />
Dokumentation der Ergebnisse<br />
Eine der Hauptaufgaben im Rahmen des Prozess-Workshops ist die Dokumentation der erarbei-<br />
teten Ergebnisse. Für die Umsetzung der Dokumentation ist es sinnvoll ein sogenanntes Pro-<br />
zesshandbuch zu erstellen. 204 In dem Prozesshandbuch <strong>können</strong> die erarbeiteten Prozess-, Rol-<br />
len- und Schnittstellenbeschreibungen übersichtlich dokumentiert werden. Auf diese Weise<br />
197 Kempter, A.: ITIL-Kennzahlen Service Operation - Servicebetrieb - IT Process Wiki http://wiki.de.itprocessmaps.com/index.php/ITIL-Kennzahlen_Service_Operation_-_Servicebetrieb,<br />
Abruf am 02.06.2010.<br />
198 Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 168.<br />
199 Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.190.<br />
200 Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.315.<br />
201 Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.315.<br />
202 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.315.<br />
203 Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.192.<br />
204 Vgl. Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 94 ff.
Vorgehensmodell 73<br />
wird sichergestellt, dass alle notwendigen Informationen nachvollziehbar zur Verfügung gestellt<br />
werden <strong>können</strong>.<br />
Abb. 22 - Prozesshandbuch 205<br />
8.4.2. Toolauswahl durchführen<br />
Im Rahmen der Toolauswahl sollte zunächst festgelegt werden, wie viele Softwareanbieter ma-<br />
ximal in die engere Auswahl kommen. 206 Anschließend sollten Auswahlkriterien definiert wer-<br />
den mit deren Hilfe die potenziellen Anbieter identifiziert werden <strong>können</strong>. Mögliche Auswahl-<br />
kriterien 207 sind z. B.:<br />
� Zertifizierungen (ISO, ITIL-Konformität)<br />
� Branchenkenntnis<br />
� Empfehlungen / Referenzprojekte<br />
� Marktpräsenz (Marktführerschaft)<br />
Der nächste Schritt ist Durchführung einer Recherche um die am Markt befindlichen potenziel-<br />
len Anbieter nach den vorher festgelegten Kriterien zu identifizieren. Im Anschluss sollte ein<br />
Lastenheft erstellt und an die die geeignetsten Anbieter versendet werden, um ein Angebot von<br />
diesen zu erhalten. Anschließend sollte eine Bewertungsmatrix erstellt werden, mit deren Hilfe<br />
die verschiedenen Angebote verglichen werden <strong>können</strong>. <strong>Die</strong> drei Anbieter mit der besten Be-<br />
wertung sollten zu einer abschließenden Präsentation eingeladen werden, bei der das Tool von<br />
den Anbietern vorgestellt werden kann. 208 Nach der Präsentation sollten die Ergebnisse disku-<br />
205 Entnommen aus: Schmidt, R.; Dohle, H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 95.<br />
206 Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.193.<br />
207 Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.193.<br />
208 Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.198.
Vorgehensmodell 74<br />
tiert und eine abschließende Bewertung durchgeführt werden. Auf Basis dieser Bewertung er-<br />
folgt endgültige Entscheidung.<br />
8.4.3. Prozessschulung durchführen<br />
Der nächste Schritt ist die Durchführung einer Prozessschulung. <strong>Die</strong> im Rahmen der Prozess-<br />
schulung vermittelten Inhalte sollten auf den im Prozess-Workshop geplanten Soll-Prozess be-<br />
ruhen. Darüber hinaus sollten den IT-Mitarbeitern ein Überblick über das ITIL-Framework ver-<br />
schafft und die Vorteile von ITIL hervorgehen werden. Des Weiteren sollte nicht nur die neuen<br />
Prozesse vorgestellt, sondern auch die wesentlichen Abweichung vom bisherigen Vorgehen<br />
hervorgehoben werden.<br />
Das Incident und das Problem Management sind zwei unterschiedliche Prozesse, nichts desto<br />
trotz fällt es den IT-Mitarbeitern oftmals schwer beide Prozesse voneinander zu trennen. (siehe<br />
Kapitel 7.1.8.). Aus diesem Grund sollten nach der Vorstellung der verschiedenen Aspekte der<br />
jeweiligen Prozesse die unterschiedlichen Ziele und Vorgehensweisen nochmals hervorgehoben<br />
werden. Ziel ist es auf diese Weise den Unterschied zwischen den beiden Prozessen zu verdeut-<br />
lichen.<br />
8.5. Durchführung der Implementierung<br />
Nach der Durchführung des Prozess-Workshops und der anschließenden Dokumentation der<br />
Ergebnisse müssen nun das Incident und das Problem Management im Unternehmen etabliert<br />
werden. Zuvor werden aber noch die Anwender bzw. Kunden über die Änderungen informiert<br />
und ein Termin mitgeteilt, ab dem die neuen Prozesse umgesetzt und auch angewandt wer-<br />
den. 209 <strong>Die</strong> wichtigsten Aktivitäten in der Implementierungsphase sind:<br />
� Projektmarketing betreiben<br />
� Einführung der Tools<br />
� Anpassen der Tools<br />
� Erstellen der Arbeitsanweisungen<br />
8.5.1. Projektmarketing betreiben<br />
Um die Mitarbeiter über die neuen Prozesse zu informieren sollte Projektmarketing betrieben<br />
werden. 210 Das Projektmarketing umfasst „alle Aktiviten, die der Erhöhung des Bekanntheits-<br />
grads und der Imageverbesserung eines Projektes dienen‟. 211 Das Ziel des Projektmarketings ist<br />
die Anwender bzw. Kunden von der Relevanz des Projektes zu überzeugen. Aus diesem Grund<br />
209 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.317 ff.<br />
210 Vgl. Schmidt, R.; Dohle , H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 100.<br />
211 Patzak, G.; Rattay, G.: Projektmanagement, 4., wesentlich überarbeitete Auflage, Wien 2004, S. 146.
Vorgehensmodell 75<br />
sollte eine Informationsveranstaltung stattfinden, in der die Anwender bzw. Kunden von den<br />
neuen Prozessen und den damit verbundenen Änderungen informiert werden. Durch die Infor-<br />
mationsveranstaltung wird die Bedeutung der Prozesse nochmals hervorgehoben und somit die<br />
Akzeptanz bei den Mitarbeitern gefördert. Auf diese Weise kann der fehlenden Akzeptanz der<br />
IT-Mitarbeiter entgegengewirkt werden. (siehe. Kapitel 7.1.1.)<br />
8.5.2. Tools einführen<br />
Nach dem das Management die Beschaffung des Tools genehmigt hat, kann mit der Einführung<br />
des Tools angefangen werden. 212<br />
8.5.3. Anpassung der Tools<br />
Nach der der Implementierung der Tools müssen die Tools an die Anforderungen angepasst<br />
werden, damit im Prozessworkshop festgelegten Aktivitäten korrekt umgesetzt werden <strong>können</strong>.<br />
Beispielsweise könnten bei einem Ticketing-Tool die verschiedenen Kategorisierungsmöglich-<br />
keiten an die Anforderungen des Unternehmens angepasst werden.<br />
8.5.4. Tool-Schulung<br />
Nach der Einführung und Anpassung der Tools sollte der Schulungsbedarf der IT-Mitarbeiter<br />
ermittelt werden. Anschließend sollte eine Tool-Schulung mit allen Mitarbeitern veranstaltet<br />
werden, die noch geschult werden müssen.. Im Rahmen dessen sollten den Schulungsteilneh-<br />
mern das notwendige Know-How für den Umgang mit den neuen Tools vermittelt werden. Auf<br />
diese Weise wird sichergestellt, dass die Mitarbeiter mit den Tools umgehen und die Aktivitäten<br />
des Prozesses umsetzen <strong>können</strong>. Dadurch wird vermieden, dass die Mitarbeiter aufgrund von<br />
fehlendem Know-How die Tools falsch einsetzen (siehe 7.1.4.).<br />
8.5.5. Erstellen von Arbeitsanweisungen<br />
<strong>Die</strong> Aktivitäten der Prozesse wurden bereits im Rahmen des Prozess-Workshops festgelegt. Um<br />
aber eine einheitliche Vorgehensweise bei der Durchführung der Aktivitäten zu garantieren<br />
sollten sogenannte Arbeitsanweisungen erstellt werden, in denen die Aktivitäten detailliert be-<br />
schrieben werden. Im Zuge dessen sollte darauf geachtet werden, dass die Arbeitsanweisungen<br />
übertragbar gestaltet werden, um diese auch für vorübergehendes Personal verständlich zu ge-<br />
stalten. 213 Nach der Erstellung der Arbeitsanweisungen sollten diese im Prozesshandbuch do-<br />
kumentiert werden.<br />
212 Vgl. Buhl, U.: ITIL Praxisbuch, 2. Auflage, Heidelberg 2008, S.200.<br />
213 Vgl. Schmidt, R.; Dohle , H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 95.
Vorgehensmodell 76<br />
8.5.6. Erfahrungen dokumentieren und Verbesserungspotenziale identifi-<br />
zieren<br />
Während der gesamten Implementierungsphase sollten die Mitglieder des Projektes ihre eigenen<br />
Erfahrungen dokumentieren, damit diese als Grundlage für spätere Verbesserungsmaßnahmen<br />
genutzt werden <strong>können</strong>. Darüber hinaus ist es oftmals sinnvoll, die Rückmeldungen der Pro-<br />
jektmitglieder sofort zu verarbeiten und bereits in der Implementierungsphase als Änderungs-<br />
maßnahme einfließen zu lassen. Auf diese Weise wird nicht nur der Prozess praxisorientierter<br />
gestaltet, sondern auch die Akzeptanz bei den Mitarbeitern gefördert. 214<br />
Tab. 28 - Template für Verbesserungsvorschläge 215<br />
Name<br />
Betroffene Aktivität im Prozess<br />
Festgestellter Vorfall und/oder gewonnene In-<br />
formation<br />
Auswirkung auf den Betrieb<br />
Vorgeschlagene Verbesserungsmaßnahmen<br />
Verbesserungsvorschlag<br />
8.6. Evaluierung und Weiterentwicklung<br />
<strong>Die</strong> Evaluierung und Weiterentwicklungs-Phase dient in erster Linie der Identifikation von Ver-<br />
besserungspotenzial, sowohl für die Prozesse als auch für das Vorgehen bei der Implementie-<br />
rung. Deshalb wird ein Review-Workshop durchgeführt, in dessen Rahmen die folgenden Akti-<br />
vitäten umgesetzt werden:<br />
� Review der Implementierung 216<br />
� Kontinuierlichen Verbesserungsprozess definieren und initiieren 217<br />
8.6.1. Review der Implementierung<br />
<strong>Die</strong> erste Aktivität des Review-Workshops ist die Durchführung eines Reviews. Das Review<br />
dient der Nachbetrachtung der abgeschlossenen Implementierung, um aus den daraus gewonnen<br />
Erkenntnissen für zukünftige Einführungsprojekte zu lernen. Um dies zu erreichen werden die<br />
214<br />
Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.320.<br />
215<br />
In Anlehnung an: Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010,<br />
S.321.<br />
216<br />
Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.321.<br />
217<br />
Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.321.
Vorgehensmodell 77<br />
vorher definierten Ziele mit dem tatsächlichen IST-Zustand der Prozesse anhand der vorher<br />
definierten Kennzahlen verglichen. 218 Während der Implementierungsphase haben die Projekt-<br />
mitglieder die Aufgabe ihre eigenen Erfahrungen zu dokumentieren. Das daraus resultierende<br />
Feedback muss während der Review-Phase ausgewertet und die vorgeschlagenen Verbesse-<br />
rungsmaßnahmen auf Machbarkeit und Auswirkung geprüft werden. Für den Fall, dass bei den<br />
implementierten Prozessen noch Anpassungsbedarf besteht, müssen Handlungsempfehlungen<br />
aus dem Feedback der Projektmitglieder abgeleitet werden. 219<br />
8.6.2. Kontinuierlichen Verbesserungsprozess definieren und initiieren<br />
Um die freigegebenen Handlungsempfehlungen umsetzen zu <strong>können</strong> ist es notwendig einen<br />
Aktivitätenplan zu erstellen. 220 Der Aktivitätenplan beschreibt die umzusetzenden Aktivitäten<br />
und ordnet diesen Aktivitäten einen festen Termin, einen Verantwortlichen sowie die benötigten<br />
Ressourcen zu.<br />
Das eigentliche Ziel dieses Vorhabens ist die kontinuierliche Verbesserung der eingeführten<br />
Prozesse. Um das Verbesserungspotenzial sukzessive ausschöpfen zu <strong>können</strong> sollte ein Kreis-<br />
lauf etabliert werden, der sich am Deming Cycle orientiert. Das von Edward Deming entwickel-<br />
te Modell wird auch als PDCA-Zyklus bezeichnet und setzt sich aus den folgenden vier Pha-<br />
sen 221 zusammen:<br />
� Plan - In der Plan-Phase werden die neuen Maßnahmen zur Qualitätsverbesserung geplant.<br />
� Do - In der Do-Phase erfolgt die Umsetzung der geplanten Maßnahmen.<br />
� Check - In der Check-Phase wird der Erfolg der Maßnahmen gemessen.<br />
� Act - In der Act-Phase werden die Abweichungen vom eigentlichen Ziel erkannt und<br />
Korrekturmaßnahmen durch einen erneuten Durchlauf des PDCA-Zyklus initiiert<br />
Abb. 23 - PDCA-Zyklus 222<br />
218 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.321.<br />
219 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.321.<br />
220 Vgl. Beims, M.: IT-Service Management in der Praxis mit ITIL® 3, 2. Auflage, München 2010, S.321 f.<br />
221 Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 172.<br />
222 In Anlehnung an: Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 154.
Vorgehensmodell 78<br />
Mit jedem Durchlauf des PDCA-Zyklus wird die Qualität des Prozesses schrittweise verbes-<br />
sert. 223<br />
8.7. Abschluss<br />
Abschließend sollte der Projekterfolg im Rahmen einer Abschlussfeier mit den Projektmitarbei-<br />
tern und den Mitarbeitern des Problem- und Incident Managements zelebriert werden, um die<br />
Projekteinführung angemessen abzuschließen. 224<br />
223 Vgl. Böttcher, R.: IT-Servicemanagement mit ITIL ® V3, 1. Auflage, Hannover 2008, S. 154.<br />
224 Vgl. Schmidt, R.; Dohle , H. (Hrsg.): ITIL V3 umsetzen, 1. Auflage, Düsseldorf 2009, S. 119.
Fazit 79<br />
9 Fazit<br />
Im Rahmen der vorliegenden <strong>Bachelorarbeit</strong> wurde der Status quo von ITIL in mittelständi-<br />
schen Unternehmen und Unternehmen mittlerer Größe ermittelt und die typischen Probleme<br />
identifiziert, die bei der Einführung des Incident und Problem Management in den befragten<br />
Unternehmen auftraten. Basierend auf diesen Informationen wurde ein optimiertes Vorgehens-<br />
modell entworfen, mit dessen Hilfe die beiden Prozesse eingeführt werden <strong>können</strong>.<br />
Für diese Studie wurden 700 Unternehmen kontaktiert von denen 58 an der Erhebung teilge-<br />
nommen haben. Das Ergebnis dieser Studie zeigt, dass sich ITIL noch nicht vollständig in den<br />
mittelständischen Unternehmen und Unternehmen mittlerer Größe durchgesetzt hat. Demnach<br />
nutzen lediglich 50 % der befragen Unternehmen ITIL. <strong>Die</strong> Ursachen für den Verzicht sind<br />
vielseitig, einerseits greifen zahlreiche Unternehmen auf die Möglichkeit zurück alternative<br />
Frameworks zu verwenden, andererseits ist die Einführung von ITIL oftmals mit viel Aufwand<br />
verbunden. <strong>Die</strong> im Rahmen der <strong>Bachelorarbeit</strong> durchgeführte Studie zeigt, dass eine direkte<br />
Interdependenz zwischen der ITIL-Nutzung und den IT-Mitarbeitern herrscht. Je größer die<br />
Anzahl der IT-Mitarbeiter ist, desto häufiger kommt ITIL zum Einsatz. <strong>Die</strong> Einführung von<br />
ITIL-basierten Prozessen und Funktionen ist ein umfangreiches Unterfangen, welches mit der<br />
Bindung von zusätzlichem Personal verbunden ist. Aus diesem Grund verzichten gerade Unter-<br />
nehmen mit wenigen IT-Mitarbeitern auf eine Einführung von ITIL.<br />
Ferner zeigen die Ergebnisse der vorliegenden Studie, dass gerade operative Prozesse und Funk-<br />
tionen, wie der Service Desk, das Incident und das Problem Management vermehrt in den Un-<br />
ternehmen zum Einsatz kommt. Prozesse wie das Demand Management oder Transition und<br />
Support kommen dagegen selten zum Einsatz. Nachholbedarf besteht in erster Linie bei den<br />
Planungs- und Implementierungsprozessen, wie dem Service Asset und Configuration Mana-<br />
gement oder dem Transition Planung und Support.<br />
<strong>Die</strong> Einführung von ITIL-basierten Prozessen ist oftmals mit Problemen verbunden. Rund 50 %<br />
der Unternehmen die entweder das Incident oder das Problem Management eingeführt haben,<br />
hatten Probleme bei der Einführung. Im Rahmen dessen hatte die Unternehmen in erster Linie<br />
mit der fehlenden Akzeptanz der Mitarbeiter, der fehlenden technischen Unterstützung durch<br />
effektive Hilfsmittel, sowie dem fehlenden Know-How der Mitarbeiter zu kämpfen. Das im<br />
Rahmen dieser <strong>Bachelorarbeit</strong> entworfene Vorgehensmodell kann mittelständischen Unterneh-
Fazit 80<br />
men und Unternehmen mittlerer Größe die Möglichkeit bieten, Probleme zu vermeiden und das<br />
Incident- und das Problem Management effektiv einzuführen.
Quellenverzeichnis VIII<br />
Quellenverzeichnis<br />
Literatur<br />
Beims, M.: IT-Service Management in der Praxis mit ITIL® 3 - Zielfindung, Methoden, Reali-<br />
sierung, 2. Auflage, München 2010.<br />
Böttcher, R.: IT-Servicemanagement mit ITIL ® V3 – Einführung Zusammenfassung und Über-<br />
sicht der elementaren Empfehlungen, 1. Auflage, Hannover 2008.<br />
Buchsein, R.; Victor, F.; Günther, H.; Machmeier, V.: IT- Management mit ITIL ® V3 – Stra-<br />
tegien, Kennzahlen, Umsetzung, 2. Auflage, Wiesbaden 2008.<br />
Buhl, U.: ITIL Praxisbuch – Beispiele und Tipps für die erfolgreiche Prozessoptimierung, 2.<br />
Auflage, Heidelberg 2008.<br />
Ebel, N.: ITIL® V3 Basis-Zertifizierung - Grundlagenwissen und Zertifizierungsvorbereitung<br />
für die ITIL® Foundation-Prüfung, 1. Auflage, München 2008.<br />
Heinrich, L. J.; Stelzer, D.: Informationsmanagement – Grundlagen Aufgaben, Methoden,<br />
München 2009.<br />
itSMF e. V. (Hrsg.): ITIL in der Öffentlichen Verwaltung - Planung, Einführung und Steuerung<br />
von IT-Service-Prozessen, 1. Auflage, Düsseldorf 2007.<br />
Kittel, M.; Koerting, T. J.; Schött, D.: Kompendium für ITIL V3 Projekte - Menschen, Me-<br />
thoden, Meilensteine, 2. Auflage, Norderstedt 2009.<br />
Lienemann, G.: ITIL - Change Management - Hinweise und Vorgehensweisen aus der Praxis,<br />
1. Auflage, Hannover 2006.<br />
Mayer, H. O.: Interview und schriftliche Befragung: Entwicklung, Durchführung und Auswer-<br />
tung, 4. Auflage, München 2008.
Quellenverzeichnis IX<br />
Nienstermann, M.: Service Management Lösungen für KMU – ITIL-unterstützende Service<br />
Management-Tools, 1. Auflage, Saarbrücken 2007.<br />
Office of Government Commerce: Service Operation, London 2007.<br />
Olberich, A.: ITIL kompakt und verständlich – Effizientes IT Service Management – Den<br />
Standard für IT-Prozesse kennenlernen, verstehen und erfolgreich in die Praxis umsetzen , 4.<br />
Auflage, Wiesbaden 2008.<br />
Patzak, G.; Rattay, G.: Projektmanagement - Leitfaden zum Management von Projekten, Pro-<br />
jektportfolios und projektorientierten Unternehmen, 4., wesentlich überarbeitete Auflage, Wien<br />
2004.<br />
Rossig, W. E.; Prätsch, J.: Wissenschaftliche Arbeiten - Leitfaden für Haus- und Seminarar-<br />
beiten, Bachelor- und Masterthesis, Diplom- und Magisterarbeiten, Dissertationen, 7. Auflage,<br />
Hamburg 2008.<br />
Schiefer, H.; Schitter, E.: Prozesse optimieren mit ITIL ® - Abläufe mittels Prozesslandkarte<br />
gestalten – Compliance erreichen und Best Practices nutzen mit ISO 20000, BS 15000 & ISO<br />
9000, 2. Auflage, Wiesbaden 2008.<br />
Schmidt, R.; Dohle , H. (Hrsg.): ITIL V3 umsetzen – Gestaltung, Steuerung und Verbesserung<br />
von IT-Services, 1. Auflage, Düsseldorf 2009.<br />
Steinweg, C.: Projektkompass Softwareentwicklung – Geschäftsorientierte Entwicklung von<br />
IT-Systemen, 4. Auflage, Braunschweig/Wiesbaden 2002.<br />
van Bon, J.; de Jong, A.; Kolthof, A.; Pieper, M.; Tjassing, R.; van der Veen, A.;<br />
Verheijen, T.: IT Service Management basierend auf ITIL V3 – Das Taschenbuch, 3. Auflage,<br />
Zaltbommel 2008.<br />
Zielke, F.; Schinkel, A.-W.; Oldag, J.; Weber, G.: ITIL überzeugend einführen - Methoden<br />
und soziale Kompetenzen, 1. Auflage, Düsseldorf 2010.
Quellenverzeichnis X<br />
Internet<br />
Alberts, S.: HZD ITSM-Fachforum 30.09.09, http://www.itsm-<br />
consulting.de/files/HZD%20ITSM-Fachforum%2030.09.09.pdf, 22.03.2010.<br />
Bundesministerium der Justiz: TMG - Einzelnorm, http://www.gesetze-im-<br />
internet.de/tmg/__5.html, 27.03.2010.<br />
Bundesministerium für Wirtschaft und Technologie (Hrsg.): Der Mittelstand in der Bun-<br />
desrepublik Deutschland - Eine volkswirtschaftliche Bestandsaufnahme, BMWi Dokumentation<br />
Nr. 561, Berlin 2007, http://www.ifm-bonn.org/assets/documents/BMWI-Dokumentation-<br />
561.pdf, 14.03.2010.<br />
Ellermann, H.: Münchener Rück: >> ITIL ist einfach
Quellenverzeichnis XI<br />
Wikipedia: Wikipedia:Relevanzkriterien,<br />
http://de.wikipedia.org/wiki/Wikipedia:Relevanzkriterien#Wirtschaftsunternehmen, 25.03.2010.<br />
Vogel, M.: Mitbestimmung bei IT-Systemen: Achtung: Betriebsrat!,<br />
http://www.cio.de/karriere/805409/index2.html, 02.05.2010.<br />
Persönliche Mitteilungen<br />
Alberts, S.: Subject: AW:Frage wegen der Einführung von ITIL-Prozessen bei der HZD,<br />
Susanne.Alberts@hzd.hessen.de, 23.03.2010.<br />
Handgräntinger, S.: Subject: AW: Interview zum Thema ITIL, hgonline@web.de, 11.10.2009.
Eidesstattliche Erklärung XII<br />
Eidesstattliche Erklärung<br />
Ich versichere, dass ich die vorstehende Arbeit selbstständig angefertigt und mich fremder Hilfe<br />
nicht bedient habe.<br />
Alle Stellen, die wörtlich oder sinngemäß veröffentlichtem oder nicht veröffentlichtem Schrift-<br />
tum entnommen sind, habe ich als solche kenntlich gemacht.<br />
<strong>Die</strong> Arbeit hat in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgele-<br />
gen<br />
Mönchengladbach, Datum ________________________________<br />
Vorname Nachname