-
Leseprobe zu
„Incident Management“ von Kay Wolf und Stefan Sahling
ISBN (Buch): 978-3-446-44138-5 ISBN (E-Book):
978-3-446-44181-1
Weitere Informationen und Bestellungen unter
http://www.hanser-fachbuch.de/978-3-446-44138-5
sowie im Buchhandel
© Carl Hanser Verlag München
-
Inhalt
Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . XI
Die Autoren . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XIII
Danksagungen . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XV
1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1
Zielgruppen – How to use this book . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 41.2 Disclaimer . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 51.3 Das erste Treffen oder
wie alles begann . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 5
2 Die Grundlagen, Standards und Definitionen . . . . . . . . . .
. . . . . . . . . . . . 112.1 Information Technology Infrastructure
Library (ITIL®) . . . . . . . . . . . . . . . . . . . . . . 142.2
ITIL® und ISO/IEC 20000 . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 202.3 Lean SixSigma
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 222.4 Incident Management
nach ITIL® . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 262.5 Wechselwirkungen und Einflussfaktoren
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.5.1 Problem Management . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 282.5.2 Configuration
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 282.5.3 Change Management . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
292.5.4 Event Management . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 312.5.5 Service
Level Management . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 312.5.6 Availability Management . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 322.5.7 Capacity Management . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 322.5.8 IT Service
Continuity Management (ITSCM) . . . . . . . . . . . . . . . . . . .
. . . . . 332.5.9 IT Financial Management . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 332.5.10
ITSicherheitsmanagement . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 342.5.11 Der Help Desk/Single
Point of Contact . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . 34
2.6 Incident Management vs. Problem Management . . . . . . . . .
. . . . . . . . . . . . . . . . . . 352.7 Key Performance
Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 37
2.7.1 Kritische Erfolgsfaktoren und KPIs . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 382.7.2 Definition von KPIs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 38
-
VIII Inhalt
2.7.3 Implementierung von KPIs . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 452.7.4 Darstellung und
Anpassung von KPIs und deren Messungen . . . . . . . . . . 46
3 Der Incident . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.1
IncidentArten . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.2
Verfügbarkeit – „der Feind des Incident Management“ . . . . . . . .
. . . . . . . . . . . . . . 573.3 Ursachen von Incidents . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 63
3.3.1 Technologie . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.3.2
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 723.3.3 Business .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 743.3.4 Prozesse . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 763.3.5 Personal . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 783.3.6 Umweltfaktoren/höhere Gewalt . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803.3.7
Wechselwirkungen von Faktoren . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 81
3.4 Phasen eines Incidents . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883.5
Kosten von Incidents . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.5.1 Direkte und indirekte IncidentKosten . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 923.5.2 Kosten einer
IncidentLösung nach erfolgreicher Störungsbehebung . . . . 963.5.3
Kostenfaktoren – die waren Kostentreiber eines Incidents . . .
. . . . . . . . . 973.5.4 Ermittlung der Kosten . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
106
3.6 Kosten des IncidentManagement Prozesses . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 1113.7 Klassifizierung von
Incidents (IncidentKategorien) . . . . . . . . . . . . . . . . . .
. . . . . . 113
3.7.1 Definition . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143.7.2
Grauzonen und Angstfaktor . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 1183.7.3 Review der
Kategorien – wo endet E2E? . . . . . . . . . . . . . . . . . .
. . . . . . . . . 1193.7.4 Zusätzliche Kategorien . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
120
4 Das Incident Handling . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 1234.1 Erwarte
das Unerwartete . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 1234.2 FirstAidKit –
erste Maßnahmen . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 1274.3 Feueralarm und Sinnloseskalation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 1324.4 Stufenweise Notifikation und Eskalation . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384.5
Automatisieren von Benachrichtigungen . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 1404.6 MeetMeLine und
„IncidentTouristen“ . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 147
4.6.1 Ein Ausflug in die Kommunikationstheorie . . . . . . . . .
. . . . . . . . . . . . . . . . 1474.6.2 Telefonkonferenzen und
MeetMeLines . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1524.6.3 Trennen der MeetMeLines . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 1544.6.4 Der Souffleur
und Instant Messaging . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 1584.6.5 IncidentTouristen verursachen Staus . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 1604.6.6 Suchen Sie
Verbündete! . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 1654.6.7 Statusinformation . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 1664.6.8 Beispiel – Durchführung BusinessUpdate . .
. . . . . . . . . . . . . . . . . . . . . . . . 1714.6.9 Effiziente
Telefonkonferenzen – wie lade ich Kollegen aus? . . . . . . .
. . . . . 173
-
Inhalt IX
4.7 Priorisieren und Maßnahmen einleiten . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 1774.7.1 Symptome
genau verifizieren . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 1804.7.2 Aus Symptomen eine Diagnose
formulieren . . . . . . . . . . . . . . . . . . . . . . . .
1824.7.3 Mit Wissen und Erfahrung vergleichen . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 1834.7.4 Ursachen ausschließen
anhand der Symptome . . . . . . . . . . . . . . . . . . . . . .
1864.7.5 Die „Unbekannten“ definieren . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 1904.7.6 Schritte zur
Validierung und Lösungen definieren . . . . . . . . . . . . . . . .
. . . 1924.7.7 Prioritäten vergeben und Schritte umsetzen . . . . .
. . . . . . . . . . . . . . . . . . . 197
4.8 UAT und Lösung bekannt geben . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 2014.9
CloseDownPhase – Übergabe an das Problem Management . . . . .
. . . . . . . . . . . . 2054.10 Fehleranalyse und
Problemlösungstechniken . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 209
4.10.1 Problemdefinition . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 2124.10.2
Unterschiedsreduktion und Separationsprinzip . . . . . . . . . . .
. . . . . . . . . . 2134.10.3 Brainstorming . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . 2154.10.4 635Methode . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2164.10.5
Ursache und Wirkungsdiagramm . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 2164.10.6 Provokationstechnik . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . 218
4.11 Lessons Learned . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
219
5 Der Incident Manager . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 2235.1 Einleitung .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 2305.2 Rollen und
Verantwortlichkeiten . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 232
5.2.1 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2325.2.2 Verantwortlichkeiten . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 234
5.3 Knowhow/Skill Set . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2375.3.1 Soft Skills . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2375.3.2 Technisches Knowhow . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 2385.3.3
ProzessKnowhow . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 240
5.4 Incident Management Training . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 2415.4.1
Schwerpunkte . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . 2425.4.2
Übungssituationen . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 243
6 Der Faktor Mensch . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 2476.1
Kulturelle Unterschiede . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 253
6.1.1 Arbeit ohne Grenzen . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 2546.1.2 Auch
Technologie kennt ihre Grenzen . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 2566.1.3 Einflussfaktoren auf das Incident
Management . . . . . . . . . . . . . . . . . . . . . 2586.1.4 Der
Faktor Kultur . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 259
6.2 Internationale Zusammenarbeit . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 2686.3
Fehlerkultur . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
6.3.1 Vertuscher . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2796.3.2
Blockierer . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 2816.3.3
Mitläufer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 2816.3.4
Antreiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 282
-
X Inhalt
6.4 Persönliche Beziehungen – Relationship . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 2836.5
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
285
7 Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2937.1 Implementierung des Incident Management . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 298
7.1.1 IstAufnahme . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 3017.1.2
Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 3047.1.3
DesignPhase . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . 3057.1.4
Implementierung und Optimierung . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 307
7.2 Help Desk . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3097.2.1 Aufgaben des Help Desk . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 3097.2.2 Design und
Implementierung Help Desk . . . . . . . . . . . . . . . . . . . . .
. . . . . . 3117.2.3 Help Desk vs. Service Desk . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3157.2.4
Statistische Daten und KPI Help Desk . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 3167.2.5 Berechnung der Kosten des IT
Service Desk . . . . . . . . . . . . . . . . . . . . . . . .
317
7.3 Outsourcing und MultivendorKonzept . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . 3197.3.1
OutsourcingKonzepte . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 3217.3.2 Auswirkungen der
Vertragsform auf das Incident Management . . . . . . . . 3387.3.3
Outsourcing und SLA . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 343
7.4 Notfallübung (Fire Drills) . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3447.4.1
Kalter oder theoretischer Fire Drill . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 3457.4.2 Wartungsfenster/Changes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 3467.4.3 Heißer Test . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
347
7.5 Incident Management Center und Situation Command Center . .
. . . . . . . . . . . . . 3477.5.1 Das Incident Management Center
(IMC) . . . . . . . . . . . . . . . . . . . . . . . . . . .
3477.5.2 Situation Command Center (die Kommandozentrale) . . . . .
. . . . . . . . . . . . 352
7.6 Incidents und Follow the Sun . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 3547.7 Das IT
SWAT Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 360
7.7.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 3607.7.2
Stellung im Incident Management . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 3627.7.3 Aktivierung . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 3637.7.4 Aufbau und Struktur . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
364
7.8 Die 3DiAnalyse . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3667.8.1 3Di und Technologie . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 3677.8.2 3Di und
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 3677.8.3 3Di und Business . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 3687.8.4 3Di und Prozesse . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3697.8.5 3Di und Personal . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 3717.8.6 3Di
und Umwelt . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 3747.8.7 Beispiel einer
3DiAnalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 374
7.9 Der Kreis schließt sich . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
376
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . 379
-
Vorwort
In der heutigen Zeit ist das Thema Incident Management wichtiger
denn je. Die Erhöhung der ITLieferkomplexität vor allem auch für
KernITProzesse durch globale Lieferorganisationen, Best und
Offshoring sowie Outsourcing führen zu stärkeren Abhängigkeiten des
Business von IT – Ausfällen, welche zu substanziellen Verlusten und
schlimmstenfalls in den Ruin führen können. Ein sehr aktuelles
Thema ist Cyber Crime. Es war noch nie so einfach, Unternehmen
anzugreifen und auszuspionieren. Ein gut eingespieltes Incident
Management erlaubt auch hier die gut vorbereitete, wirksame und
schnelle Reaktion auf einen solchen Angriff bei einem Security
Incident.Als Manager von Integration Engineering in UK und Peer für
ITArchitektur in Europa für den Kunden General Motors habe ich
lange Jahre mit Kay Wolf und Stefan Sahling bei Electronic Data
Systems (EDS) zusammengearbeitet.In dieser Zeit war es eine unserer
Aufgaben, das EDSManagement darin zu unterstützen, die
IncidentManagementProzesse für globale Accounts zu definieren und
zu verbessern, aufzubauen und mit den besten Mitarbeitern zu
besetzen. Vieles, was Sie in diesem Buch lesen, wurde während
dieser gemeinsamen Jahre definiert, gelernt, umgesetzt, vor allem
aber: wirklich erlebt.Unsere schlank aufgestellte europäische
Organisation gestaltete sich in ihrer Umsetzung in einem hohen Maß
kundenbezogen und zielorientiert. Durch die zielgerechte Umsetzung
unserer zentralen Prozesse und agilen Lösungsansätze gelang es uns
deshalb sehr bald, einen ausgezeichneten Ruf innerhalb der global
agierenden EDS zu erwerben.Dies hatte zur Folge, dass wir zunehmend
von mehreren globalen Accounts angefordert wurden, um bei der
Lösung von festgefahrenen Situationen – wie zum Beispiel Major
Incidents, Projekte, die kurz vor dem Scheitern standen, oder
Accounts, die mit vertraglicher Rückabwicklung drohten – zu
helfen.Die Mischung aus der Erzählung persönlich erlebter oder von
Kollegen geschilderten Situationen sowie der sehr umfängliche
Überblick über die Prozesswelt der modernen IT vermittelt dem Leser
einen lebendigen realitätsnahen Eindruck, der sich jedoch strikt an
die technischen und organisatorischen Vorgaben unserer Branche
hält. Einige der Geschichten sind mir so gut in Erinnerung
geblieben, dass ich auch heute noch darüber schmunzeln
muss.„Konrads Notizen“ werden ITMitarbeitern und ITManagern helfen,
Incidents effektiver und messbarer zu bewältigen und einer
schnellen Lösung zuführen zu können – unabhängig
-
XII Vorwort
davon, ob der Betreffende bereits über einschlägige
IncidentManagementErfahrungen verfügt oder nicht.Auch die
Abstraktion einiger zentraler Punkte, die in diesem Buch
ausführlich dargestellt werden, sind über den
IncidentManagementBereich hinaus von großem Wert und sollten
allgemein beherzigt werden.Erwähnenswert sind: Employee
Empowerment, zielgerichtete Kommunikation, analytisches
Problemverständnis, strukturierte Lösungsorientierung, Taxonomien,
KPIMessungen, CSFWertigkeit, Einsatz der richtigen Ressource für
den richtigen Zweck, Ausbildung der Mitarbeiter, Verständnis von
direkten und indirekten Kosten sowie deren Ursache, Reduktion auf
die wirklich notwendigen Prozesse und Eskalation nicht als
Freizeitbeschäftigung und Bühne, sondern um die fokussierte und
schnelle Lösung von Problemen durch notwendige Entscheidungen
sicherzustellen.Ich wünsche Ihnen genauso viel Spaß beim Lesen
dieses Buchs wie ich hatte und bin sicher, dass die geneigten Leser
alle viel daraus lernen können.
Ralph OelssnerAllianz Group Information Security Architect
-
Stefan SahlingStefan Sahling, geboren 1967 in Flörsheim am Main,
war von 1996 bis 1990 für ein USUnternehmen als Sales Executive
Europa tätig. 1990 wechselte er zu Electronic Data Systems (EDS)
und durchlief im Laufe der Jahre verschiedene Positionen, unter
anderem als Service Delivery Manager und Global Operations Manager.
Stefan Sahling war für mehrere internationale Unternehmen tätig und
konnte dabei einen tiefen Einblick in die Prozesse globaler
Unternehmen und die Anforderungen der Business Units an die
UnternehmensIT bekommen. Seit 2009 ist Stefan Sahling bei Hewlett
Packard angestellt, hat ein Patent eingereicht und ist derzeit als
EMEA Manager für Mainframe Hosting Services tätig.
Kay Wolf Kay Wolf wurde 1970 in Magdeburg geboren. Im Anschluss
an seine neunjährige Zeit in der Armee wechselte er im Jahre 1997
zu Electronic Data Systems (EDS) und bekleidete dort verschiedene
Positionen als Technischer Projektleiter, Program Manager,
Consultant für Netzwerktechnik, Lean SixSigma und IT Service
Management. Er war für mehrere globale Unternehmen tätig und konnte
somit einen tiefen Einblick in die IT und deren Prozesse erhalten.
Seit 2009 ist Kay Wolf bei Hewlett Packard angestellt. Er hat zwei
Patente für IT Prozesse eingereicht und bekleidet derzeit die
Position eines Technical Transformation Managers bei einem globalen
Versicherer.
Die Autoren
-
1 Einleitung„Houston, wir haben ein Problem.“
Diese berühmten fünf Worte sind in die Geschichte eingegangen
und werden nicht erst seit dem preisgekrönten Film „Apollo 13“ oft
zitiert. Die Luft und Raumfahrttechnik hat in ihrer langjährigen
Geschichte viele strukturierte Prozesse zur Erkennung und Behebung
von Störungen (Incidents) entwickelt. Aus diesem Grund vertreten
einige Leute die Ansicht, dass die Luft und Raumfahrttechnik damit
einer der Mitbegründer des modernen Incident und Problem Management
ist. Tatsächlich wurden in dieser Branche im Laufe der Zeit
praxisnahe Prozesse entwickelt, die es ermöglichen, Vorkehrungen
für eine Vielzahl an möglichen Störungen zu treffen. So findet man
heute in Flugzeugen die unterschiedlichsten Handbücher und
Checklisten, in denen Anleitungen für verschiedene mögliche
Störungen hinterlegt sind.Dies ist einer der Gründe, weshalb das
Flugzeug zu einem der sichersten Verkehrsmittel der Welt
wurde.Natürlich darf dabei nicht vergessen werden, dass es in der
Geschichte der Luftfahrt eine Reihe von Katastrophen gab, die viele
Menschenleben gekostet haben. Zwar führte jeder dieser Unfälle
dazu, dass die verwendeten Prozesse überarbeitet und Technologien
weiter verbessert wurden, aber es gab schmerzliche Verluste. Mit
der Zeit lernte man, dass es sinnvoller ist, nicht erst einen
möglichen Unfall abzuwarten, um eine Korrektur der Prozesse und
Technologien einzuleiten, sondern Vorhersagen anhand von Tests und
Berechnungen zu treffen und Vorkehrungen einzuleiten, um damit
mögliche weitere Vorfälle so weit wie möglich auszuschließen. Bei
derartigen Analysen müssen gleichermaßen Mensch wie Maschine
berücksichtigt werden. Die Schnittstellen der Prozesse, die sich
zwischen Mensch und Technologie abspielen, müssen genauestens
definiert und auf die Technik abgestimmt werden. Der Mensch
wiederum muss in der Lage sein, die Prozesse zu durchschauen und
strikt einzuhalten, was in Extremsituationen ein hohes Maß an
Disziplin er fordert.Die Menschheit hat in der Vergangenheit
bewiesen, dass sie in der Lage ist, aus Fehlern zu lernen: Die
Ursachen müssen analysiert und die daraus gewonnenen Erkenntnisse
umgesetzt werden, um Wiederholungen zu vermeiden.Neue Technologien
und Prozesse müssen anhand der Analyseergebnisse verständlich
dokumentiert, effizient designt und benutzerfreundlich gestaltet
werden. Oberstes Ziel muss
-
2 1 Einleitung
sein, alle Bedien und Arbeitsschritte auch unter den
schwierigsten Umständen durchführen zu können. Dies kann nur dann
erreicht werden, wenn jegliche Einzelschritte praxisnah
ausgearbeitet und erprobt wurden. Was hat das mit IT zu tun?Im
Vergleich zur Luftfahrt blickt die ITIndustrie auf eine weitaus
kürzere Geschichte zurück und es stellt sich die Frage, ob sich die
Lerneffekte aus der Luftfahrt womöglich auf die IT übertragen
lassen, um auch hier optimierte, vor allem aber verständliche
Prozesse und Abläufe zur Verfügung zu stellen.Die Frage liegt nahe,
denn gerade in der ITIndustrie lassen sich effektive Prozesse
entwickeln und simulieren, ohne ein hohes Risiko eingehen zu müssen
– in der Praxis sieht das oft ganz anders aus. Gerade neue
Technologien bergen oft ungeahnte Risiken und werfen Fragen auf,
deren Lösung mitunter immense Schwierigkeiten bereiten kann. Es
können Situationen und Probleme getestet werden, die vorher noch
völlig unbekannt waren. Soweit die Theorie.Auf die Frage nach
bislang unbekannten Problemen, die sich aus diesen neuartigen
Technologien ergeben können, gibt es weder vorgefertigte Antworten
noch mathematische Gleichungen! Die besten Techniker der Welt
können sich nur auf Dinge vorbereiten, die sie bereits
kennen.Prozessanalysten und Mathematiker zermartern sich seit
Jahrzehnten das Gehirn darüber, wie man hier Abhilfe schaffen
könnte, um sich auf das Unbekannte vorzubereiten. Gibt es eine
Gleichung, die es uns erlaubt, sie nach der Unbekannten X hin
aufzulösen?
„Wir wissen, was wir nicht wissen, aber wir wissen nicht, was
wir noch nicht wissen.“
Kurzum: Erwarte das Unerwartete und bereite Dich darauf vor.Die
Konfrontation mit neuen Technologien kann eine durchaus spannende
Sache sein, ist doch die Auseinandersetzung mit „unbekannten“
Problemen in der Wissenschaft „daily business“ und kann im
Büroalltag eine willkommene Unterbrechung der täglichen Routine
bedeuten. „Willkommen“ natürlich nur dann, wenn nicht gerade Leib
und Leben oder das Überleben des Unternehmens davon abhängen. Die
Auseinandersetzung mit dem Unbekannten ist zweifelsohne die
treibende Kraft für Wissenschaftler und Abenteurer und die
Triebfeder dafür, neue Erfindungen zu kreieren oder neue
Erkenntnisse zu gewinnen. In der Vergangenheit sind ganze
Industriezweige aus der Lösung neuer Probleme entstanden: z. B.
teflonbeschichtete Pfannen, DuckTapes oder auch
Antihaftbeschichtungen.Unsere Vorfahren glaubten zu Beginn des 20.
Jahrhunderts tatsächlich, dass alles, was es zu erfinden gebe,
bereits erfunden sei. Der Glaube an die Unbesiegbarkeit der Technik
wurde jedoch jäh durch den Untergang der Titanic beendet. Wird man
auf Wissenslücken aufmerksam gemacht und aus dem Irrglauben „Wir
wissen bereits alles“ herausgerissen, spricht die Psychologie von
einem Paradigmenwechsel und meint damit, dass sich hier die
Sichtweise verschiebt oder gar erweitert. Der Betrachter erkennt,
dass die vorliegende Sicht der Dinge nicht mit der neuen Realität
übereinstimmt. Dabei kann die neue Realität komplexer oder aber
auch einfacher sein.Um es auf den Punkt zu bringen, genau darum
geht es in diesem Buch. Es geht darum, ein prinzipielles
Bewusstsein aufzubauen, dass es Dinge und Ereignisse beim Betrieb
der IT gibt, die man noch nicht kennt — egal, auf wie viel
Berufserfahrung derjenige verweisen
-
1 Einleitung 3
kann oder welche technische Ausbildung er auch immer genossen
haben mag. Dieses Buch soll Sie dabei unterstützen, sich in Zukunft
auf mögliche unerwartete Ereignisse optimal vorzubereiten. Die
beschriebenen Lösungsansätze lassen sich prinzipiell natürlich auch
auf andere Lebensbereiche anwenden, da die Kernfrage stets
lautet:
„Wie bereitet man sich auf das Unerwartete vor?“Gerade der
ITBereich stellt den Anspruch, innovativ zu sein und herkömmliche
Probleme zuverlässig und strukturiert zu bewältigen.Zu schön –
werden manche Leute antworten, die vielleicht bereits ihre
Erfahrungen mit den unterschiedlichsten Bugs und „Help Desks“ der
ITIndustrie gemacht haben – und sie haben Recht.Der folgende
Vergleich mag ein wenig übertrieben sein, aber wenn Sie sich die
Folge enttäuschender Anrufe bei einem Servicedesk oder ITHelpDesk
ins Gedächtnis rufen, die Sie womöglich schon hinter sich haben,
und sich vorstellen, Ihr Leben hinge von der Kompetenz und
Effizienz Ihres jeweiligen Gegenübers ab, wird Ihnen dann angst und
bange? Stellen Sie sich vor, Sie wären Jim Lovell, Kapitän der
Apollo13Mission, auf dem Weg zum Mond und haben das Problem, dass
Ihre Raumkapsel plötzlich funktionsuntüchtig ist. Ihr „Anruf“ beim
Help Desk würde über das eigene Leben und das Leben der gesamten
Crew entscheiden. Hätten Sie Vertrauen in Ihr Gegenüber oder würden
Sie lieber den noch verbleibenden Sauerstoff nutzen, um das
Testament zu schreiben?Um ehrlich zu sein: Die meisten ITProzesse,
die wir kennengelernt haben, lesen sich nur auf dem Papier gut,
denn sie wurden zu großen Teilen aus der Theorie heraus definiert.
Sobald ein unvorhergesehenes Ereignis eintritt, wird Ihr Anruf
weitergeleitet oder Sie werden vertröstet.Manchmal aber gibt es
dann doch diesen „einen Menschen“, der uns kompetent zur Seite
gestanden und richtig weitergeholfen hat. Wir sind heute schon zum
Teil derart an einen schlechten Service und schlechte Ergebnisse
gewöhnt, dass wir regelrecht überrascht sind, wenn wir auf einen
Mitarbeiter treffen, der sich durch Kompetenz, Schnelligkeit und
Eigeninitiative auszeichnet. Noch viel schlimmer! Wir sind es gar
nicht mehr gewohnt, schnell, effizient und erfolgreich am Telefon
bedient zu werden, und meinen, es sei außergewöhnlich, wenn wir auf
einen kompetenten Mitarbeiter treffen.Es stellt sich daher die
Frage, was einen erfolgreichen „Problemlöser“, Incident Manager
(oder wie auch immer man ihn nennt) ausmacht? Wie wird man ein
erfolgreicher Problemlöser? Kann man sich diese Fähigkeiten
erarbeiten? Lässt sich so etwas lernen? Kann das vielleicht
jeder?In den vergangenen Jahren hat uns die Beantwortung dieser
Fragen nicht ruhen lassen. Während unserer Projekte in globalen
Unternehmen in verschiedenen Ländern ist uns immer wieder eines
aufgefallen: So verschieden die herausragenden Incident Manager in
den Unternehmen auch sein mögen, die Herangehensweise an aktuelle
Probleme ähnelt sich stets in den folgenden Punkten: Struktur,
Praxisorientierung, Disziplin.
-
4 1 Einleitung
In diesem Buch werden wir gemeinsam hinter die Kulissen des
Incident Management in der ITIndustrie schauen. Wir werden einige
Standards wie die „IT Infrastructure Library“ hinterfragen und in
der Praxis erprobte Lösungsansätze aufzeigen. Wir möchten Ihnen
bewährte „best practices“ aufzeigen und ebenso innovative Konzepte
diskutieren. Ein Patentrezept zur Lösung aller komplexen Incidents
in der IT zu jedem Zeitpunkt gibt es derzeit nicht und wird es
aller Voraussicht nach auch nicht geben, aber es gibt
Möglichkeiten, sich auf verschiedene Schwierigkeiten
vorzubereiten.
■■ 1.1■Zielgruppen – How to use this book
Das vorliegende Werk bietet Ihnen vielfältige Informationen und
Praxistipps; ob als Neueinsteiger oder ITProfi, der dem Thema
Incident Management zum ersten Mal aus Prozesssicht gegenübersteht.
Dieses Buch soll einem breiten Spektrum von Anwendern eine Hilfe zu
sein.
NeueinsteigerAls Einsteiger können Sie sich auf die Geschichte
unseres Titelhelden Herrn Löscher konzentrieren, der teils
erfundene, teils reale Erlebnisse in der IT lebhaft vermitteln
soll. Damit fällt Ihnen der Einstieg in die Thematik womöglich
etwas leichter und eventuell werden sich erfahrene ITler an einigen
Stellen wiederfinden, da sie vielleicht schon einmal ähnliche
Erfahrungen machen mussten. Lassen Sie sich durch die Coverstory
leiten und begleiten Sie unsere Hauptfigur Konrad auf seinem Weg
durch die verschiedenen Prozesse seiner Arbeit und seine Ausbildung
zum Incident Manager. Dadurch wird es Ihnen leicht fallen, das Buch
durchzuarbeiten und sich einen Gesamtüberblick über das Thema
Incident Management zu verschaffen.Wenn Sie bereits Erfahrungen in
der IT mit dem Thema Incident Management gemacht haben, zeigen wir
Ihnen unterschiedliche Konzepte auf, welche bei der Optimierung
Ihrer Arbeit Hilfestellungen geben sollen. Unser Anspruch besteht
darin, hierbei nicht nur Diskussionsstoff für Veränderungsprozesse
an die Hand zu geben, sondern auch praxisorientierte Checklisten
und andere Hilfsmittel bereitzustellen, auf die Sie in Ihrer
täglichen Arbeit zurückgreifen können.
Erfahrene Incident ManagerAls Profi werden Sie Ihre eigenen
Erfahrungen an der einen oder anderen Stelle des Buchs wiederfinden
und vielleicht neue Ansätze für Ihre tägliche Arbeit mitnehmen. Die
zahlreichen Checklisten und Beispiele stammen aus der Praxis und
sollen Ihnen eine wertvolle Unterstützung für Ihre tägliche Arbeit
bieten. Daher sind wir nicht nur für Ihre Anregungen und
Ergänzungen dankbar, sondern stellen diese Daten über unsere
Website einem breiten Nutzerkreis zur Verfügung.
-
1.3 Das erste Treffen oder wie alles begann 5
Service Manager oder CIOsAls Manager der IT erhalten Sie
wertvolle Informationen zur Implementierung eines neuen oder
Verbesserung Ihres bereits existierenden Incident Management.
Nutzen Sie unsere Hinweise und besprechen Sie die verschiedenen
Konzepte und Ansätze in Ihrem Bereich, mit Ihren Kollegen und mit
Ihren Kunden.Als Incident Manager oder Angestellter mit
Managementverantwortung werden Ihnen die aufgezeigten
Betrachtungsweisen und Erfahrungen mit Konzepten sowie die
Auswirkung der menschlichen Faktoren die Möglichkeit geben, den
IncidentManagementProzess effizienter zu gestalten. Hierbei reden
wir nicht von „Erstlösungsraten“ oder Einsparungspotenzial wie
„Head Count Reductions“, sondern von echten intelligenten Lösungen
mit messbarer Verbesserung der Kundenzufriedenheit.Unsere
Zielsetzung ist es, Ihnen bei der Entscheidung, welches Konzept das
Beste für das eigene Unternehmen ist, die maßgeblichen Kriterien an
die Hand zu geben sowie dabei zu helfen, eine optimale Einbindung
der Prozesse an ihr Arbeitsumfeld zu leisten.Welche Position Sie in
Ihrem Unternehmen auch immer bekleiden: Bei der nächsten großen
Störung sind Sie gut vorbereitet, greifen zu diesem Leitfaden und
sagen sich: „Kein Problem – „Don’t Panic!“.Besuchen Sie uns unter
www.incidentmanagement.de und teilen Sie Ihre Erfahrungen mit
ITProfis.
■■ 1.2■Disclaimer
Die Autoren haben während ihrer Tätigkeit in der IT bei vielen
internationalen Konzernen umfangreiche Erfahrungen in den
verschiedensten Rollen als Project Manager, Operations Manager,
Incident und Change Manager oder Chief Technologist sammeln können,
welche die Geschichten in diesem Buch inspiriert haben. Die
geschilderten Prozesse und Abläufe beziehen sich auf Tatsachen. Die
hier aufgeführten Personen sowie die Rahmenhandlungen sind jedoch
frei erfunden. Jegliche Ähnlichkeit mit lebenden Personen, Firmen
oder tatsächlichen Ereignissen wäre rein zufällig und
unbeabsichtigt. Ein Bezug zu realen Unternehmen der fiktiven
Geschichte ist nicht beabsichtigt.
■■ 1.3■Das erste Treffen oder wie alles begann
Konrad hatte heute nicht den besten Start. Direkt nachdem er ins
Büro kam, hat es gekracht – Servercrash. Gleich mehrere Server auf
einmal und wie immer war niemand schuld. Und natürlich ist es
reiner Zufall, dass die Serverjungs in der Nacht von Mittwoch auf
Donnerstag ihre Changes eingespielt haben. Aber jetzt hat Konrad
erst einmal 30 Minuten Pause, gerade Zeit genug, um schnell einen
Happen zu essen.
-
6 1 Einleitung
Jeden Donnerstag gibt es eine kleine Rettung für Konrad, denn in
der Kantine ist Schnitzeltag und hinter der Ausgabe steht seine
Lieblingsaushilfe Janina. Konrad mag sie irgendwie und nicht nur,
weil sie ihm immer eine Extraportion auf den Teller gibt. Zufrieden
nimmt er seine Extraportion entgegen und begibt sich auf die Suche
nach einem ruhigen Platz.„Ich glaube, das war mein Highlight für
heute.“Donnerstags ist immer alles voll hier und ich habe keine
Lust auf einen aufgezwungenen Small Talk, denkt sich Konrad. Cool,
direkt neben den Blumenkisten sind noch zwei Plätze frei und wenn
ich mein Tablett rüberschiebe, sieht es so aus, als würde da jemand
sitzen und essen. Mal sehen, vielleicht klappt es ja.Durch die
Kantine schlenzt ein hagerer Mann mit seinem Tablett. Er wirkt
unauffällig und in Gedanken versunken. Sein Blick kreist durch die
Halle auf der Suche nach einem freien Platz. Konrad bemerkt den
Mann erst gar nicht, doch dann erahnt er die drohende Gefahr:
„Komischer Kauz. Wer trägt denn heute noch Strickjacken?“Ihre
Blicke kreuzen sich und Konrad nickt seinem Gegenüber unwillkürlich
zu, der dies als Aufforderung versteht, zu ihm zu kommen.„Ah Mist“,
denkt sich Konrad und seine Gedanken kreisen darum, wer das wohl
sein könnte.Es kommt, wie es kommen muss. Der ältere Herr schaut
auf und spricht ihn an, ob er sich setzen darf. Zähneknirschend
willigt Konrad ein, sich mit dem älteren Herrn seinen exklusiven
Platz zwischen zwei Blumenkübeln zu teilen.Nachdem er sich gesetzt
hat, wagt Konrad einen kurzen Blick zu seinem Gegenüber, der ihn so
abrupt aus seinen Gedanken gerissen hatte. Vor ihm sitzt ein
älterer Herr mit grauen Haaren und Brille. Nichts Auffälliges,
außer dieser weinroten Strickjacke und einem hellblauen Hemd mit
Krawatte. „Zumindest habe ich es anscheinend nicht mit einem
Manager zu tun“, denkt Konrad, immer noch in Gedanken vertieft, der
eigentlich nur in Ruhe sein erlegtes Schwein verspeisen will.Das
abrupte Ende der Ruhe wird eingeleitet, als die Strickjacke zu
sprechen beginnt: „Interessante Variante, das Croissant vor dem
Schnitzel zu essen.“„Ich brauche heute richtige Nervennahrung“,
erwidert Konrad etwas platt.„So richtig glücklich sehen Sie aber
nicht aus“, bemerkt sein ihm immer noch unbekanntes Gegenüber.
Konrad hat einfach keine Lust, sich zu unterhalten, aber er möchte
nicht unhöflich sein. „Ach nee, wissen Sie was, ich hatte gerade
einen Incident, ein Großteil unserer Server ist abgestürzt. Nicht,
dass mich das donnerstags wirklich überraschen würde.“„Es ist
manchmal schon ein Drama mit den Incidents. Mir ist auch schon
aufgefallen, dass sich die Incidents gerade an den Donnerstagen
häufen“, erwidert sein Gegenüber. „Aber wir haben uns noch gar
nicht vorgestellt!“„Stimmt, entschuldigen Sie bitte, mein Name ist
Löscher, Konrad Löscher.“ „Und ich bin David Mikkelson.“ „Ach
wirklich? Sie sind Herr Mikkelson? Ich wollte Sie schon immer
einmal persönlich kennenlernen und mich bei Ihnen bedanken. Vor
vier Wochen, ich weiß nicht, ob Sie sich daran erinnern, haben Sie
uns bei dem Ausfall der internen Firewall sehr geholfen. Sie haben
die Leitung übernommen und die Störung souverän gelöst. Es war
schon beeindru
-
1.3 Das erste Treffen oder wie alles begann 7
ckend, wie Sie die Diskussionen über die Schuldzuweisungen im
Keim erstickt und damit alle Beteiligten zurück an die Lösung des
Incidents geführt haben. Vielen Dank für Ihre Unterstützung.“„Ach
ja, ich kann mich noch genau an diesen Incident erinnern, weil alle
User davon betroffen waren. Das war schon der Hammer, wie lange es
gedauert hat, die Kollegen ans Laufen zu bringen. Ich war echt
sauer. Manchmal muss man einfach alle politischen Diskussionen
beiseitelassen, damit es weitergeht. Schließlich betreiben wir IT
und kein Parlament.“ „Das sehe ich auch so. Aber es gibt wohl
einige Leute, die glauben, man könnte die Probleme schneller lösen,
indem man erst einmal die Schuldfrage diskutiert.“David nickt
zustimmend: „Es gibt einige Manager, die solche Ausfälle dazu
missbrauchen, sich zu profilieren. Das merkt man daran, dass sich
bei der Anwesenheit des Senior Management während einer Störung das
Verhalten einiger Teilnehmer gravierend ändert. Das lässt sich
nicht ändern, man muss es aber wissen. Deshalb versuche ich immer,
die Probleme auf die technische Ebene zurückzuführen, so dass kein
Platz mehr für Politik ist.“„So habe ich das noch nicht gesehen“,
erwidert Konrad überrascht. „Ich habe da doch eher mit den Leuten
zu kämpfen, die mir permanent die Zeit rauben. Man müsste da echt
mal die Stoppuhr mitlaufen lassen, um auszurechnen, wie viel Zeit
durch die Diskussionen verloren geht.“„Apropos Zeit“, meint
Mikkelson, „wurde nicht festgelegt, dass wir uns in 30 Minuten
wieder auf der MeetMeLine treffen, um über die ersten Ergebnisse
der Fehlersuche bei den Servern zu berichten?“ Konrad schaut auf
seine Uhr. „Mist, nicht einmal Zeit zum Essen hat man. Mir ist gar
nicht aufgefallen, dass Sie auch auf der MeetMeLine waren. OK, dann
wollen wir mal. Es war mir ein Vergnügen, Sie einmal persönlich
kennenzulernen, auch wenn unser Gespräch nur sehr kurz war.“„Das
sehe ich auch so. Dann lassen Sie uns doch unser Gespräch
fortsetzen. Vielleicht ist es Ihnen möglich, Dienstag in einer
Woche in meinem Büro vorbeizukommen, ich hätte da noch ein paar
Fragen an Sie“, fährt David fort und schaut Konrad erwartungsvoll
an.Konrad sagt spontan zu und fragt sich, ob es sich dabei nur um
ein Geplänkel oder echtes Interesse handelt, verabschiedet sich und
bringt sein Tablett weg.Als Konrad zurück an seinen Arbeitsplatz
kommt, findet er bereits eine EMail in seinem Postfach von Herrn
Mikkelson: „Hier die Büroadresse für Dienstag, Mittagspause in
meinem Büro, Raum 216, Block A8, David Mikkelson, Leiter der IT
EMEA, sent from mobile device . . .Am darauffolgenden Dienstag
begibt sich Konrad also voller Neugierde auf den Weg zum Büro von
Herrn Mikkelson. Nach einer kurzen Wartezeit im Büro der
Assistentin wird Konrad ins Büro gebeten. David Mikkelson steht auf
und schüttelt Konrad die Hand.„Es freut mich sehr, dass Sie
gekommen sind“, begrüßt ihn David und bittet ihn, in der Sitzecke
am Fenster Platz zu nehmen. „Hier setze ich mich mit den Leuten
hin, mit denen ich mich unterhalten möchte. Alles andere kann man
am Schreibtisch regeln. Darf ich Ihnen etwas zu trinken anbieten?
Ich freue mich, unsere Unterhaltung fortsetzen zu können, um über
die Dinge zu sprechen, die während einiger Incidents schief
gelaufen sind.“Konrad ist überrascht, denn selbst sein direkter
Vorgesetzter hat ihn bisher noch nie so offen angesprochen, um über
Probleme in seiner Abteilung zu reden.
-
8 1 Einleitung
David muss die Überraschung in Konrads Gesicht gelesen haben.
„Keine Angst! Ich meine nicht, dass Sie einen schlechten Job
abliefern. Ganz im Gegenteil! Sie haben ja schon bei mehreren
Incidents mitgewirkt und sich dabei bewährt, wie ich selbst erleben
durfte. Erinnern Sie sich noch, was Sie bezüglich der fehlenden
Initiative und Entscheidungsfreude der Mitarbeiter gesagt haben?
Ich möchte Sie ganz offen fragen, was Ihrer Meinung nach bei der
Lösung eines Incidents wichtig ist. Was macht für Sie einen guten
Incident Manager aus?“Konrad Löscher überlegt einen Moment und
antwortet: „Ich habe Ihnen ja schon gesagt, wie begeistert ich von
Ihrem Auftritt bei dem Ausfall der internen Firewall war. Besonders
beeindruckt hat mich, dass aufgrund Ihres Ausschlussverfahrens am
Ende nur noch eine Lösung möglich war. Ich denke, dass ein Incident
Manager vor allem auf die Lösung fokussiert sein muss. Entscheidend
ist doch schließlich, zu wissen, wer das entsprechende Knowhow hat
und wer welche Services liefert.“David Mikkelson schaut ihn
aufmerksam an: „Wunderbar, ich wusste, dass wir eine ähnliche
Vorstellung von Problemen und deren Lösungen haben. Wissen Sie,
wenn ich mir die Dauer von Incidents im Allgemeinen anschaue, dann
bin ich noch unzufrieden. Ich bin der Meinung, wir müssten den
Prozess etwas professioneller angehen. Wir nehmen Incidents hin,
als ob sie unvermeidbar wären. Ich bin mir sicher, dass wir die
Wiederholung von Ausfällen vermeiden könnten, wenn wir eine
Abteilung hätten, die sich nur um Incidents kümmert. Ich meine
damit einen eigenen Bereich für Incident Management.“„Genau das ist
auch meine Meinung“, erwidert Konrad sofort. „Wenn ich mir alleine
den Incident aus der letzten Woche anschaue, dann ist das bereits
das dritte Mal, dass die ServerAdministratoren irgendwelche
ungetesteten Softwareprodukte eingespielt haben. Ganz abgesehen von
der Zeit, die mir für meine eigentliche Arbeit verloren
geht.“Mikkelson hebt die Augenbrauen. „Da ist was dran. Ok, ich
will nicht weiter um den heißen Brei herumreden. Es ist nicht das
erste Mal, dass ich bei Incidents anwesend war, die Sie betreut
haben. Mir gefällt Ihre Arbeitsweise und ich würde gerne mehr aus
Ihnen herauskitzeln. Können Sie sich vorstellen, Ihren Bereich zu
verlassen und etwas ganz anderes auszuprobieren? Mein Ziel ist es,
eine IncidentManagementOrganisation aufzubauen, und Sie sollen mir
dabei helfen. Das neue IncidentManagementTeam soll sich zukünftig
ausschließlich mit der Entwicklung der Prozesse und der Lösung von
Incidents beschäftigen.“Damit hat Konrad nicht gerechnet! „Wow! Das
kommt jetzt echt überraschend. Ich finde es toll, dass Sie mir so
etwas zutrauen. Ich habe mir darüber noch gar keine Gedanken
gemacht, aber es hört sich gut an.“ Er wirft einen kurzen Blick aus
dem Fenster: „Wie haben Sie sich das mit der neuen Abteilung
vorgestellt?“David beginnt seine Vorstellungen zu erläutern:
„Wissen Sie, als ich damals in der IT angefangen habe, mussten wir
während unserer Ausbildungsphase alle Abteilungen durchlaufen. Das
hat uns geholfen zu verstehen, wer im Unternehmen welche Leistung
erbringt und wie das Ganze am Ende des Tages ein Gesamtbild ergibt.
Wenn ich mir betrachte, in wie viele Bereiche unsere IT aufgeteilt
ist, wundert es mich nicht, dass wir heute so viele Probleme haben.
Viele unserer Kollegen haben zum Beispiel überhaupt keine Ahnung
mehr davon, welche Aufgaben unsere FirewallJungs erfüllen.Ich habe
lange darüber nachgedacht. Ein Mitarbeiter, der erfolgreich
Incidents lösen will, sollte ein einigermaßen umfassendes Wissen
davon haben, was die IT leistet, wie diese Leistungen erbracht
werden und vor allem welche Organisationen daran beteiligt sind.
Des
-
1.3 Das erste Treffen oder wie alles begann 9
wegen würde ich Ihnen als angehendem Incident Manager einen
Einblick in die einzelnen Abteilungen verschaffen. Dabei sollten
Sie primär die Brille eines Incident Managers aufhaben. Das heißt
also, immer genau überlegen, wer könnte mit seinem Wissen bei einem
Incident behilflich sein. Mir geht es hier nicht um eine
Dokumentation unseres Unternehmens, die habe ich bereits. Mir geht
es darum, dass Sie sich Ihre eigenen Notizen machen und wir
zusammen eine Dokumentation für alle angehenden Incident Manager
erstellen“.„Verstehe!“ nickt Konrad, „Sie meinen also eher so etwas
wie ein Handbuch?“„Genau! Da fallen mir sofort zwei Dinge ein. Zum
einen muss beschrieben sein, wie ein Incident richtig abgearbeitet
wird, und zum anderen, wie man sich in einer Telefonkonferenz
korrekt verhält. Das wissen nämlich auch noch nicht alle.“ „Hört
sich wirklich interessant an“, platzt es aus Konrad raus. „Ich wäre
quasi mein eigenes Projekt?“„Na ja, nicht ganz, ich habe schon noch
ein Wörtchen mitzureden. Ich möchte schließlich ja auch nicht, dass
Sie sich alleine gelassen fühlen.“„Nein, ja – ich meine klar!“
stottert Konrad und verrät damit seine Aufregung. Das ist schon ein
Hammer, jemand wie er soll plötzlich direkt an den Leiter der IT
berichten und sogar mit ihm eine eigene Abteilung aufbauen. Das ist
schon eine echte Herausforderung für jemanden, der irgendwann im
ITHelpDesk als Agent im Unternehmen angefangen hat.„Herr
Mikkelson“, bricht es direkt aus ihm heraus. „Das alles hört sich
sehr gut an. Ich glaube, dass das eine sehr interessante Aufgabe
ist, und nehme Ihr Angebot gerne an.“David streckt ihm die Hand
entgegen und sagt: „Dann fangen wir jetzt erst einmal damit an,
dass Sie nicht für mich, sondern mit mir arbeiten. Schlagen Sie ein
und wir können schon mal mit den Vorbereitungen anfangen. Mit der
Personalabteilung habe ich bereits gesprochen und im Prinzip können
Sie nächste Woche beginnen.“ Er steht auf, geht zu seinem
Schreibtisch, öffnet die oberste Schublade und entnimmt ihr ein
Notizbuch mit einem Ledereinband. David reicht Konrad das Buch und
sagt zu ihm: „Das ist sozusagen ihr Ausbildungsbuch. Noch sind die
Seiten in diesem Buch leer. Sie haben nun den Auftrag, alle
Informationen, die Sie erarbeiten, hier zu notieren, und es immer
mit sich zu führen. Leben Sie mit dem Buch! Die Idee ist, dass wir
am Ende Ihres Weges Ihre Notizen übertragen und damit ein Handbuch
erstellen – es wird quasi unsere Bibel oder ich nenne es:
„Die goldenen Regeln des Incident Management“.Überwältigt von
den sich überschlagenden Ereignissen nimmt Konrad das Buch
sprachlos entgegen. Noch immer kann er nicht glauben, was gerade
geschehen ist.„O. k. – dann verabreden wir uns für Montag um neun
Uhr. Wenn das für Sie in Ordnung ist, rede ich gleich mit Ihrem
Chef. Sie hätten dann noch Zeit, in Ihrer Abteilung alles zu
regeln.“Konrad verabschiedet sich. Noch hat er nicht ganz
begriffen, was hier gerade passiert ist. Auf seinem Weg nach
draußen blickt er immer wieder auf das Notizbuch in seiner
Hand.
-
Index
Symbole3Di-Analyse 366 – Architektur 367 – Business 368 –
Personal 371 – Prozesse 369 – Technologie 367 – Umwelt 374
AAutomatisierte Benachrichtigung siehe
BenachrichtigungAvailability siehe Verfügbarkeit
BBenachrichtigung 140 – automatisiert 142 –
Standardisierung 144
Brainstorming 215Business-Update 171
CCause and Effective Diagram siehe Problem-
lösungstechnikenCMDB 185Configuration Management Data Base
siehe
CMDBCritical Success Factor siehe Kritische
Erfolgsfaktoren
DDirekte Kosten Incident siehe Incident - Kosten
EErste Hilfe siehe First-Aid-KitEskalation 132, 138
FFehleranalyse 209Fehlerkultur 278 – Antreiber 282 –
Blockierer 281 – Mitläufer 281 – Vertuscher 279
Fire Drill 344 – Changes 346 – heißer Test 347 –
theoretischer 345
First-Aid-Kit 127Follow The Sun 354 – Übergabe (hand
over) 357
HHelp Desk 34, 309 – Aufgaben 309 – Design 311 –
Implementierung 311 – Kosten 317 – KPI 316
IIMC siehe Incident Management CenterImplementierung siehe
Incident ManagementIncident 53 – Arten 55 – Business-Update 171 –
Close Down 205
-
380 Index
– Direkte Kosten 92 – handling 123 – Indirekte Kosten 92 –
Kategorien siehe Kategorien Incident – Kostenfaktoren siehe
Kostenfaktoren Incident – Maßnahmen 177 – Phasen 88 –
Priorisieren 177 – Problemdefinition 212 – Statusinformationen 166
– Symptome (verifizieren) 180 – Ursachen 63
Incident Kalkulator siehe Kosten IncidentIncident Management –
Implementierung 298 – Kosten-Prozess 111 – Multivendor 336 –
Optimierung 307 – Schnittstellen 27 – Training 241
Incident Management Center 347Incident Manager – Know-how 237 –
Rollen 232 – Skills 237 – Verantwortlichkeiten 234
Indirekte Kosten Incident siehe Incident - Kosten
Instant Messaging 158Internationale
Zusammenarbeit 268Ishikawa-Diagramm siehe Problemlösungs-
technikenISO 20000 20ITIL® 14 –
Prozesse/Funktionen/Rollen 17
IT SWAT 360 – Aktivierung 363 – Aufbau 364 – Struktur 364
KKategorien Incident 113 – Definition 114
Key Performance Indicator 37Kommandozentrale siehe Situation
Command
CenterKommunikationsstrukturen 150Konzepte 293 – 3Di-Analyse 366
– Fire Drill 344 – Follow The Sun 354 – Incident Management
Center 347
– IT SWAT 360 – Multivendor 319, 332 – Outtasking 326 –
Situation Command Center 352
Kostenfaktoren Incident 97Kosten Incident – Ermittlung 106 –
Incident Kalkulator 107
KPI siehe Key Performance IndicatorKritische Erfolgsfaktoren 38
– Definition 38 – Implementierung 45
Kultur 259Kulturelle Unterschiede 253
LLean SixSigma 22 – DMADV 24 – DMAIC 24
MMaßnahmen 177Mean Time between Failure siehe VerfügbarkeitMean
Time To Repair siehe VerfügbarkeitMeet-Me-Line 147, 152Motivation –
Äußere Motivation 287 – Extrinsische Motivation siehe Äußere
Motivation
– Innere Motivation 286 – Intrinsische Motivation siehe Innere
Motivation
MTBF siehe VerfügbarkeitMTTR siehe VerfügbarkeitMultivendor 319,
332
– Vertrag 327 – Vertragsformen 338
NNotfallübung siehe Fire DrillNotifikation 132, 138
OOutsourcing 319 – SLA 343
Outtasking 326
-
Index 381
PPersönliche Beziehungen siehe RelationshipPraxisbeispiel 18,
42, 47, 60, 65, 68, 70, 77, 79,
80, 94, 97, 101, 113, 126, 129, 134, 136, 161, 176, 185, 198,
210, 220, 231, 233, 271, 275, 276, 280, 283, 285, 287, 289, 300,
322, 334, 335, 338, 346, 348, 349, 370, 371, 372, 375
Priorisierung 177Problemdefinition 212Problemlösungstechniken 209 –
6-3-5 Methode 216 – Brainstorming 215 – Ishikawa-Diagramm 216 –
Provokationstechnik 218 – Seperationsprinzip 213 –
Unterschiedsreduktion 213 – Ursache-Wirkungsdiagramm 216
RRASIC Chart 324Relationship 283
SSCC siehe Situation Command CenterService Desk 315Situation
Command Center 352SWAT siehe IT SWATSymptome (verifizieren) 180
TTelefonkonferenzen 152Tests siehe User Acceptance Test
UUAT siehe User Acceptance TestUrsachen Incidents –
Architektur 72 – Business 74 – Hardware 67 – Höhere Gewalt 80 –
Infrastruktur 69 – Personal 78 – Prozesse 76 – Softwarefehler 64 –
Technologie 64 – Umwelt 80 – Wechselwirkungen 81
User Acceptance Test 201
VVerfügbarkeit 57 – MTBF 59 – MTTR 59
ZZusammenarbeit international 268
978-3-446-44138-5_0978-3-446-44138-5_1978-3-446-44138-5_2978-3-446-44138-5_3