Incident Management. Komplexe Störungen in der IT erfolgreich beheben. Bearbeitet von Kay Wolf, Stefan Sahling

Transkript

1 Incident Management Komplexe Störungen in der IT erfolgreich beheben Bearbeitet von Kay Wolf, Stefan Sahling 1. Auflage Buch. 395 S. ISBN Format (B x L): 18 x 24,5 cm Gewicht: 833 g Wirtschaft > Betriebswirtschaft: Theorie & Allgemeines > Wirtschaftsinformatik, SAP, IT-Management schnell und portofrei erhältlich bei Die Online-Fachbuchhandlung beck-shop.de ist spezialisiert auf Fachbücher, insbesondere Recht, Steuern und Wirtschaft. Im Sortiment finden Sie alle Medien (Bücher, Zeitschriften, CDs, ebooks, etc.) aller Verlage. Ergänzt wird das Programm durch Services wie Neuerscheinungsdienst oder Zusammenstellungen von Büchern zu Sonderpreisen. Der Shop führt mehr als 8 Millionen Produkte.

2 Leseprobe zu Incident Management von Kay Wolf und Stefan Sahling ISBN (Buch): ISBN (E-Book): Weitere Informationen und Bestellungen unter sowie im Buchhandel Carl Hanser Verlag München

3 Inhalt Vorwort XI Die Autoren XIII Danksagungen XV 1 Einleitung Zielgruppen How to use this book Disclaimer Das erste Treffen oder wie alles begann Die Grundlagen, Standards und Definitionen Information Technology Infrastructure Library (ITIL ) ITIL und ISO/IEC Lean SixSigma Incident Management nach ITIL Wechselwirkungen und Einflussfaktoren Problem Management Configuration Management Change Management Event Management Service Level Management Availability Management Capacity Management IT Service Continuity Management (ITSCM) IT Financial Management IT-Sicherheitsmanagement Der Help Desk/Single Point of Contact Incident Management vs. Problem M anagement Key Performance Indicators Kritische Erfolgsfaktoren und KPIs Definition von KPIs

4 VIII Inhalt Implementierung von KPIs Darstellung und Anpassung von KPIs und deren Messungen Der Incident Incident-Arten Verfügbarkeit der Feind des Incident Management Ursachen von Incidents Technologie Architektur Business Prozesse Personal Umweltfaktoren/höhere Gewalt Wechselwirkungen von Faktoren Phasen eines Incidents Kosten von Incidents Direkte und indirekte Incident-Kosten Kosten einer Incident-Lösung nach erfolgreicher Störungsbehebung Kostenfaktoren die waren Kostentreiber eines Incidents Ermittlung der Kosten Kosten des Incident-Management- Prozesses Klassifizierung von Incidents (Incident-Kategorien) Definition Grauzonen und Angstfaktor Review der Kategorien wo endet E2E? Zusätzliche Kategorien Das Incident Handling Erwarte das Unerwartete First-Aid-Kit erste Maßnahmen Feueralarm und Sinnloseskalation Stufenweise Notifikation und Eskalation Automatisieren von Benachrichtigungen Meet-Me-Line und Incident-Touristen Ein Ausflug in die Kommunikationstheorie Telefonkonferenzen und Meet-Me-Lines Trennen der Meet-Me-Lines Der Souffleur und Instant Messaging Incident-Touristen verursachen Staus Suchen Sie Verbündete! Statusinformation Beispiel Durchführung Business-Update Effiziente Telefonkonferenzen wie lade ich Kollegen aus?

5 Inhalt IX 4.7 Priorisieren und Maßnahmen einleiten Symptome genau verifizieren Aus Symptomen eine Diagnose formulieren Mit Wissen und Erfahrung vergleichen Ursachen ausschließen anhand der Symptome Die Unbekannten definieren Schritte zur Validierung und Lösungen definieren Prioritäten vergeben und Schritte umsetzen UAT und Lösung bekannt geben Close-Down-Phase Übergabe an das Problem Management Fehleranalyse und Problemlösungstechniken Problemdefinition Unterschiedsreduktion und Separationsprinzip Brainstorming Methode Ursache- und Wirkungsdiagramm Provokationstechnik Lessons Learned Der Incident Manager Einleitung Rollen und Verantwortlichkeiten Rollen Verantwortlichkeiten Know-how/Skill Set Soft Skills Technisches Know-how Prozess-Know-how Incident Management Training Schwerpunkte Übungssituationen Der Faktor Mensch Kulturelle Unterschiede Arbeit ohne Grenzen Auch Technologie kennt ihre Grenzen Einflussfaktoren auf das Incident Management Der Faktor Kultur Internationale Zusammenarbeit Fehlerkultur Vertuscher Blockierer Mitläufer Antreiber

6 X Inhalt 6.4 Persönliche Beziehungen Relationship Motivation Konzepte Implementierung des Incident Management Ist-Aufnahme Analyse Design-Phase Implementierung und Optimierung Help Desk Aufgaben des Help Desk Design und Implementierung Help Desk Help Desk vs. Service Desk Statistische Daten und KPI Help Desk Berechnung der Kosten des IT Service Desk Outsourcing und Multivendor-Konzept Outsourcing-Konzepte Auswirkungen der Vertragsform auf das Incident Management Outsourcing und SLA Notfallübung (Fire Drills) Kalter oder theoretischer Fire Drill Wartungsfenster/Changes Heißer Test Incident Management Center und Situation Command Center Das Incident Management Center (IMC) Situation Command Center (die Kommandozentrale) Incidents und Follow the Sun Das IT SWAT Team Grundlagen Stellung im Incident Management Aktivierung Aufbau und Struktur Die 3Di-Analyse Di und Technologie Di und Architektur Di und Business Di und Prozesse Di und Personal Di und Umwelt Beispiel einer 3Di-Analyse Der Kreis schließt sich Index

7 Vorwort In der heutigen Zeit ist das Thema Incident Management wichtiger denn je. Die Erhöhung der IT-Lieferkomplexität vor allem auch für Kern-IT-Prozesse durch globale Lieferorganisa tionen, 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 IT-Architektur in Europa für den Kunden General Motors habe ich lange Jahre mit Kay Wolf und Stefan Sahling bei Elec tronic Data Systems (EDS) zusammengearbeitet. In dieser Zeit war es eine unserer Aufgaben, das EDS-Management darin zu unterstützen, die Incident-Management-Prozesse 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 Inci dents, 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 Situa tionen sowie der sehr umfängliche Überblick über die Prozesswelt der modernen IT vermit telt dem Leser einen lebendigen realitätsnahen Eindruck, der sich jedoch strikt an die tech nischen 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 IT-Mitarbeitern und IT-Managern helfen, Incidents effektiver und messbarer zu bewältigen und einer schnellen Lösung zuführen zu können unabhängig

8 XII Vorwort davon, ob der Betreffende bereits über einschlägige Incident-Management-Erfahrungen ver fügt oder nicht. Auch die Abstraktion einiger zentraler Punkte, die in diesem Buch ausführlich dargestellt werden, sind über den Incident-Management-Bereich hinaus von großem Wert und sollten allgemein beherzigt werden. Erwähnenswert sind: Employee Empowerment, zielgerichtete Kommunikation, analytisches Problemverständnis, strukturierte Lösungsorientierung, Taxonomien, KPI-Messungen, CSFWertigkeit, Einsatz der richtigen Ressource für den richtigen Zweck, Ausbildung der Mitar beiter, 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 Oelssner Allianz Group Information Security Architect

9 Die Autoren Stefan Sahling Stefan Sahling, geboren 1967 in Flörsheim am Main, war von 1996 bis 1990 für ein USUnternehmen als Sales Executive Europa tätig 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 interna tionale Unternehmen tätig und konnte dabei einen tiefen Einblick in die Prozesse globaler Unternehmen und die Anforderungen der Business Units an die Unternehmens-IT bekom men. 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.

10 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 pra xisnahe Prozesse entwickelt, die es ermöglichen, Vorkehrungen für eine Vielzahl an mög lichen 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 Pro zesse und Technologien einzuleiten, sondern Vorhersagen anhand von Tests und Berech nungen 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 durch schauen 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 umge setzt werden, um Wiederholungen zu vermeiden. Neue Technologien und Prozesse müssen anhand der Analyseergebnisse verständlich doku mentiert, effizient designt und benutzerfreundlich gestaltet werden. Oberstes Ziel muss

11 2 1 Einleitung sein, alle Bedien- und Arbeitsschritte auch unter den schwierigsten Umständen durchfüh ren 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 IT-Industrie 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 IT-Industrie lassen sich effektive Prozesse ent wickeln 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 wer fen 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 Techno logien ergeben können, gibt es weder vorgefertigte Antworten noch mathematische Glei chungen! 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 Unbe kannten 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, Duck-Tapes 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 komple xer 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

12 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 IT-Bereich 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 IT-Industrie gemacht haben und sie haben Recht. Der folgende Vergleich mag ein wenig übertrieben sein, aber wenn Sie sich die Folge enttäu schender Anrufe bei einem Servicedesk oder IT-Help-Desk ins Gedächtnis rufen, die Sie womöglich schon hinter sich haben, und sich vorstellen, Ihr Leben hinge von der Kompe tenz 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 Apollo-13-Mission, 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 ver bleibenden Sauerstoff nutzen, um das Testament zu schreiben? Um ehrlich zu sein: Die meisten IT-Prozesse, 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 wer den 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 Eigen initiative 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öhn lich, 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 Problem lö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.

13 4 1 Einleitung In diesem Buch werden wir gemeinsam hinter die Kulissen des Incident Management in der IT-Industrie 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öglichkei ten, 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 Neuein steiger oder IT-Profi, der dem Thema Incident Management zum ersten Mal aus Prozess sicht gegenübersteht. Dieses Buch soll einem breiten Spektrum von Anwendern eine Hilfe zu sein. Neueinsteiger Als Einsteiger können Sie sich auf die Geschichte unseres Titelhelden Herrn Löscher kon zentrieren, 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 IT-ler 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 Dis kussionsstoff für Veränderungsprozesse an die Hand zu geben, sondern auch praxisorien tierte Checklisten und andere Hilfsmittel bereitzustellen, auf die Sie in Ihrer täglichen Arbeit zurückgreifen können. Erfahrene Incident Manager Als 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 zahlrei chen 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.

14 1.3 Das erste Treffen oder wie alles begann 5 Service Manager oder CIOs Als 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 Incident-Management-Prozess effi zienter zu gestalten. Hierbei reden wir nicht von Erstlösungsraten oder Einsparungspo tenzial wie Head Count Reductions, sondern von echten intelligenten Lösungen mit mess barer 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 Pro blem Don t Panic!. Besuchen Sie uns unter und teilen Sie Ihre Erfahrungen mit IT-Profis. 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 tat sächlichen Ereignissen wäre rein zufällig und unbeabsichtigt. Ein Bezug zu realen Unter nehmen 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 Donners tag ihre Changes eingespielt haben. Aber jetzt hat Konrad erst einmal 30 Minuten Pause, gerade Zeit genug, um schnell einen Happen zu essen.

15 6 1 Einleitung Jeden Donnerstag gibt es eine kleine Rettung für Konrad, denn in der Kantine ist Schnitzel tag 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 exklu siven 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 hell blauen 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: Inte ressante 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öf lich 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

16 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 betrof fen 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 Manage ment 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 wie der auf der Meet-Me-Line 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 Meet-Me-Line 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 in seinem Postfach von Herrn Mikkelson: Hier die Büroadresse für Dienstag, Mittagspause in mei nem 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 Kon rad 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 Sitz ecke 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.

17 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. Erin nern 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 fokus siert 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 ähn liche 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 Aus fällen vermeiden könnten, wenn wir eine Abteilung hätten, die sich nur um Incidents küm mert. 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 Ser ver-administratoren 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 heraus kitzeln. Können Sie sich vorstellen, Ihren Bereich zu verlassen und etwas ganz anderes auszuprobieren? Mein Ziel ist es, eine Incident-Management-Organisation aufzubauen, und Sie sollen mir dabei helfen. Das neue Incident-Management-Team soll sich zukünftig aus schließ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 ange fangen habe, mussten wir während unserer Ausbildungsphase alle Abteilungen durchlau fen. 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 Prob leme haben. Viele unserer Kollegen haben zum Beispiel überhaupt keine Ahnung mehr davon, welche Aufgaben unsere Firewall-Jungs 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

18 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 auf haben. 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 Unterneh mens, 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 Telefonkonfe renz 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 jeman den, der irgendwann im IT-Help-Desk 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 gespro chen 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 Aus bildungsbuch. 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.

19 Index Symbole E 3Di-Analyse 366 Architektur 367 Business 368 Personal 371 Prozesse 369 Technologie 367 Umwelt 374 Erste Hilfe siehe First-Aid-Kit Eskalation 132, 138 A Automatisierte Benachrichtigung siehe Benachrichtigung Availability siehe Verfügbarkeit B Benachrichtigung 140 automatisiert 142 Standardisierung 144 Brainstorming 215 Business-Update 171 C Cause and Effective Diagram siehe Problem lösungstechniken CMDB 185 Configuration Management Data Base siehe CMDB Critical Success Factor siehe Kritische Erfolgsfaktoren D Direkte Kosten Incident siehe Incident - Kosten F Fehleranalyse 209 Fehlerkultur 278 Antreiber 282 Blockierer 281 Mitläufer 281 Vertuscher 279 Fire Drill 344 Changes 346 heißer Test 347 theoretischer 345 First-Aid-Kit 127 Follow The Sun 354 Übergabe (hand over) 357 H Help Desk 34, 309 Aufgaben 309 Design 311 Implementierung 311 Kosten 317 KPI 316 I IMC siehe Incident Management Center Implementierung siehe Incident Management Incident 53 Arten 55 Business-Update 171 Close Down 205

20 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 Incident Incident Management Implementierung 298 Kosten-Prozess 111 Multivendor 336 Optimierung 307 Schnittstellen 27 Training 241 Incident Management Center 347 Incident Manager Know-how 237 Rollen 232 Skills 237 Verantwortlichkeiten 234 Indirekte Kosten Incident siehe Incident Kosten Instant Messaging 158 Internationale Zusammenarbeit 268 Ishikawa-Diagramm siehe Problemlösungs techniken ISO ITIL 14 Prozesse/Funktionen/Rollen 17 IT SWAT 360 Aktivierung 363 Aufbau 364 Struktur 364 IT SWAT 360 Multivendor 319, 332 Outtasking 326 Situation Command Center 352 Kostenfaktoren Incident 97 Kosten Incident Ermittlung 106 Incident Kalkulator 107 KPI siehe Key Performance Indicator Kritische Erfolgsfaktoren 38 Definition 38 Implementierung 45 Kultur 259 Kulturelle Unterschiede 253 K N Kategorien Incident 113 Definition 114 Key Performance Indicator 37 Kommandozentrale siehe Situation Command Center Kommunikationsstrukturen 150 Konzepte 293 3Di-Analyse 366 Fire Drill 344 Follow The Sun 354 Incident Management Center 347 Notfallübung siehe Fire Drill Notifikation 132, 138 L Lean SixSigma 22 DMADV 24 DMAIC 24 M Maßnahmen 177 Mean Time between Failure siehe Verfügbarkeit Mean Time To Repair siehe Verfügbarkeit Meet-Me-Line 147, 152 Motivation Äußere Motivation 287 Extrinsische Motivation siehe Äußere Motivation Innere Motivation 286 Intrinsische Motivation siehe Innere Motivation MTBF siehe Verfügbarkeit MTTR siehe Verfügbarkeit Multivendor 319, 332 Vertrag 327 Vertragsformen 338 O Outsourcing 319 SLA 343 Outtasking 326

21 Index 381 P T Persönliche Beziehungen siehe Relationship Praxisbeispiel 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 177 Problemdefinition 212 Problemlösungstechniken Methode 216 Brainstorming 215 Ishikawa-Diagramm 216 Provokationstechnik 218 Seperationsprinzip 213 Unterschiedsreduktion 213 Ursache-Wirkungsdiagramm 216 Telefonkonferenzen 152 Tests siehe User Acceptance Test R RASIC Chart 324 Relationship 283 S SCC siehe Situation Command Center Service Desk 315 Situation Command Center 352 SWAT siehe IT SWAT Symptome (verifizieren) 180 U UAT siehe User Acceptance Test Ursachen 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 V Verfügbarkeit 57 MTBF 59 MTTR 59 Z Zusammenarbeit international 268