Störungen der Abläufe in der IT sind oft unangenehm und treffen Unternehmen mitunter sehr empfindlich. Das vorrangige Ziel des Incident-Management-Prozesses nach ITIL ist es, die schnellstmögliche Wiederherstellung der Service-Tätigkeit zu organisieren.

In diesem Beitrag erfahren Sie:

• welche Aufgaben und Zielsetzungen der Incident-Management-Prozess nach ITIL erfüllt,
• wie der Prozess optimal eingeführt und gestaltet wird,
• wie Sie Fehler bei der Implementierung vermeiden.

Allgemeine Beschreibung

Das folgende Kapitel beschäftigt sich mit den elementaren Zielen und Aufgaben des Incident Managements und berücksichtigt dabei ganz konkret Erfahrungen aus zahlreichen Projekten. Aufgezeigt werden die kritischen Erfolgsfaktoren, die bei der erfolgreichen Implementierung des Prozesses zu berücksichtigen sind. Praxisgerechte Kennzahlen, Modellierungshinweise für das Prozessdesign sowie zahlreiche Tipps zeigen, wie typische Fehler bei der Einführung des Prozesses vermieden werden können.

Zielsetzung

Incident Management setzt sich in der Regel aus dem 1st Level Service Desk, 2nd Level nachgelagerte, verteilte Supportinstanzen und dem 3rd Level Hersteller und Entwickler zusammen. Das vorrangige Ziel des Incident-Management-Prozesses ist die »schnellstmögliche Wiederherstellung der Service-Tätigkeit«.

In dieser Definition verbergen sich zwei Fragen, die die Umsetzung des Prozesses schwierig machen:

• 1. Wie ist die schnellstmögliche Wiederherstellung überhaupt zu definieren? Die einfachste und sinnvollste Antwort auf diese Frage ist es, diese Zeit nach der im Service Level Agreement SLA vereinbarten Wiederherstellungszeit auszurichten. Sollten jedoch noch keine SLAs definiert beziehungsweise kein Prozess des Service Level Managements implementiert sein, so sind Erfahrungswerte für Wiederherstellungszeiten der einzelnen Services zu Grunde zu legen.

• 2. Was sind Services? Services sind eine Kombination aus einzelnen Produkten und ihren Dienstleistungen. So können also beispielsweise die Auslieferung eines Desktop-PC und die damit verbundenen Entstörungsleistungen als Service definiert werden.

Eine schnellstmögliche Wiederherstellung der Service-Tätigkeit führt zu einer erhöhten Verfügbarkeit der IT-Services: Ausfallzeiten Downtimes werden reduziert und damit die wirtschaftliche Nutzung der IT-Infrastruktur optimiert.

Aufgaben

Die wesentliche Aufgabe des Incident-Management-Prozesses ist bereits durch die Zielsetzung vorgegeben: Es geht um die Behebung von Incidents, in der mit dem Kunden durchschnittlich vereinbarten Zeit dies geschieht durch einen strukturierten, aufeinander abgestimmten Prozess. Innerhalb dieses Prozesses wird zunächst die Anfrage Service Request oder Störungsmeldung aufgenommen und strukturiert vor allem: Kategorie, Priorität und Service Level im IT-Service-Management-Tool erfasst. Im Weiteren wird geprüft, ob zu dem Incident eine Lösung beziehungsweise ein Workaround vorliegt oder ob mit der Lösungssuche begonnen werden muss. Hier liegt nun die wesentliche Herausforderung des Incident-Management-Prozesses: zu bestimmen, in welcher Zeit und mit welchem Aufwand eine Lösung herbei geführt wird. In älteren IT-Strukturen lässt sich immer noch feststellen, dass sich die einzelnen Levels zu umfangreich mit der Ursachenforschung der Störungen auseinandersetzen. Oft liegt eine Vereinbarung Agreement über die Quantität und Qualität der Lösungssuche erst gar nicht vor. Aus der Implementierung zahlreicher Incident-Management-Prozesse in mittleren und größeren Unternehmen haben sich folgende Erfahrungswerte gebildet: Das Lösen von Incidents im 1st Level sollte auf die Suche nach gleichen beziehungsweise gleichartigen Incidents in der Lösungsdatenbank beschränkt werden verbunden mit einer integrierten oder dynamischen Schnittstelle zu einer Wissensmanagementdatenbank. Ist hiermit keine Lösung zu erzielen, sollte sich der 1st Level noch auf den Anwender-PC soweit es sich um eine damit verbundene Störung handelt aufschalten und versuchen, die Störung zu beheben. Diese Aktivitäten sollten eine Dauer von durchschnittlich fünf bis maximal 15 Minuten nicht übersteigen. Ist dann keine Lösung beziehungsweise kein Workaround gefunden worden, wird der Incident an den 2nd Level übergeben. Dieser setzt sich aus Facheinheiten zusammen, die sich in der Regel aus der Kombination der Betreuung von mehreren Serviceleistungen ergeben, und kümmert sich um die Lösung. Auch in diesem 2nd Level geht es um die schnellstmögliche Wiederherstellung der Servicetätigkeit: Sollte keine Lösung gefunden werden, so ist mindestens ein Workaround zur Verfügung zu stellen. Ist auch dies nicht im 2nd Level möglich, so bleibt der letztliche Prozessweg zum 3rd Level Entwickler beziehungsweise Hersteller. Dieser Weg ist in der Praxis häufig sehr mühsam beziehungsweise zeitaufwändig. Entwickler beziehungsweise Hersteller benötigen im Vergleich zum 1st und 2nd Level meist eine recht lange Zeit, um sich der Störung anzunehmen und eine kurzfristige schnellstmögliche Lösung beziehungsweise einen Workaround zu finden. Insgesamt muss der Incident-Management-Prozess dazu genutzt werden, schnelle Lösungen zu finden beziehungsweise Workarounds zur Verfügung zu stellen, damit der Anwender erstmal weiter arbeiten und seinen Aufgaben nachkommen kann »egal wie«. Eine dezidierte Ursachenforschung hat im Incident-Management-Prozess nichts zu suchen dies ist Aufgabe des Problem-Management-Prozesses!

Nach einer erfolgreichen Behebung des Incidents und der Wiederherstellung des Service wird die Lösung in dem IT-Service-Management-Tool erfasst und das Ticket an den 1st Level zum Abschluss übergeben und geschlossen. So die graue Theorie. In der Praxis offenbart sich genau hier eine kritische Bruchstelle. So schwierig das professionelle Lösen in einem Prozess ist, so einfach erscheint den Bearbeitern doch die Lösungserfassung. Genau hier, in der Fehlerdokumentation, liegt eine typische Fehlerquelle. Die strukturierte Lösungsdokumentation gerade in den Levels 2 und 3 geschieht in der Praxis nur unzureichend. Der eine Bearbeiter dokumentiert sein Arbeitsergebnis mit den Worten »gelöst«, der andere mit »Drucker funktioniert wieder«, ein dritter dokumentiert in einer ausführlichen Prosa mit PDF-Anhang! Wie sollte es aber sein? Standardisiert! Es gibt kein abschließendes Muster einer bestmöglichen Lösungsdokumentation. In der Praxis überlebt genau diejenige, die zwischen den einzelnen Prozessbeteiligten gemeinsam entwickelt und abgestimmt wurde. Dabei muss der 1st Level die Lösungsdokumentation der nachgelagerten Levels verstehen, damit diese Dokumentation für nachfolgende Incidents auch tatsächlich genutzt werden kann!

Schaubild zum Incident Management

Das nachfolgende Schaubild fasst die Aufgaben des Incident-Management-Prozesses sowie die Input-/Outputbeziehungen zu weiteren Prozessen, Datenbanken und Funktionen zusammen.

Verbindung mit weiteren Prozessen

Der Incident-Management-Prozess hat in der Praxis Verbindungen zu einer Vielzahl weiterer Prozesse:

• Schnittstelle zum Problem-Management-Prozess: Das Problem Management stellt sicher, dass Known Errors, strukturelle Lösungen und Workarounds dem Incident Management zur Verfügung stehen, damit die Störungen getreu der Zielsetzung schnellstmöglich beseitigt und der reibungslose Betriebsablauf wieder hergestellt werden kann.

• Schnittstelle zum Service-Asset-and-Configuration-Management-Prozess: Die Verbindung ist insofern bedeutsam, als dass die einzelnen Störungen immer in Verbindung zu einzelnen CIs und Anwenderdaten erfasst werden, so dass genau zu erkennen ist, welche Konfigurationselemente bei welchen Anwendern gestört sind.

• Schnittstelle zum Change-Management-Prozess: Das Incident Management hat genau dann eine Verbindung zum Change Management, wenn es sich um Veränderungen in der IT-Infrastruktur handelt, die durch den Incident-Management-Prozess ausgelöst werden beziehungsweise der Prozess dadurch betroffen ist. Ersteres ist gegeben, wenn Service Requests der Anwender gestellt werden, die dann mindestens unter der Kontrolle des Change Managements abgewickelt werden zum Beispiel Austausch oder Erweiteren eines Desktop-PCs. Letzteres findet statt, wenn im Rahmen der Bearbeitung von Changes der Incident-Management-Prozess rechtzeitig vor Einführung oder Erweiterung eines Services zu informieren, häufig auch zu schulen ist, damit der entsprechende Service den Anwendern kommuniziert und diese im Ablauf unterstützt werden können.

• Schnittstelle zum Service-Level-Management-Prozess: Die Bedeutung der Schnittstelle zum Service Level Management wird in der einschlägigen Literatur häufig unterschätzt hier wird eher eine indirekte Schnittstelle gesehen. In der Praxis funktioniert jedoch der durch das Incident Management zu erbringende Service dann am besten, wenn die Prozesse gemeinsam eingeführt werden beziehungsweise bereits zu Beginn die Schnittstellen identifiziert, beschrieben und implementiert werden. Das Vorliegen eines Servicekataloges Was wird unterstützt?, von Service Level Agreements Welche Services sind in welcher Zeit wiederherzustellen? und von Service Levels Gibt es Service- und/oder Kundenunterschiede in der Qualität und Quantität der Serviceerbringung? ist unabdingbar, um durch den Incident-Management-Prozess ein wirklich funktionierendes IT-Service-Management zu erreichen!