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