ITIL: Einführung des Incident Managements

Die Einführung von IT-Service Management auf Basis von ITIL beginnt in der Regel mit der Einführung einzelner Prozesse, mit denen der Grundstein für die Einführung weiterer Prozesse gelegt werden soll. Heute setzen wir uns mit dem Prozess Incident Management auseinander, der sich besonders dafür eignet, als erstes eingeführt zu werden.

Entscheidung

Wenn ein Unternehmen die Entscheidung fällt, ITIL-Prozesse einzuführen, gibt es in der Regel handfeste Probleme mit der IT. Klassische Kritikpunkte sind: „Die IT ist zu teuer“ oder „Die IT funktioniert nie, wenn man sie braucht“. Schnell wird klar, dass man nicht alle Prozesse auf einmal einführen kann. Es stellt sich daher die Frage: „Wo fangen wir an?“

Die Entscheidung wird relativ schnell getroffen, da der Kunde in der Regel die Qualität der Services, die Häufigkeit von Störungen (Incidents) oder die zu langsame Behebung von Störungen bemängelt. Insofern startet man sehr oft mit dem Incident Mana­ge­ment Prozess.

Zielsetzung des Incident Managements

ITIL verfolgt mit dem Prozess Incident Management das Ziel „Erhöhung der Kundenzufriedenheit durch schnellstmögliche Wiederherstellung des vereinbarten Services“. Eine Störung oder Unterbrechung des Services wird als Incident bezeichnet. In dem Ziel selbst tauchen mehrere Begriffe auf, die näher betrachtet werden müssen, da sie wesentliche Anforderungen an den Prozess beschreiben:

• Kunde:
  Der Kunde ist der Nutzer des IT-Services. Sein Primärziel ist sein Business. Die IT ist für ihn lediglich ein Hilfsmittel. Der Kunde kann auch eine Abteilung der eigenen Firma sein.
  
  
• Service:
  ITIL definiert Service als Kombination von Produkt und Leistung.
  
  
• Vereinbart:
  Die Services mit ihrer Qualität müssen in Abstimmung mit dem Kunden definiert sein.
  
  
• Schnellstmögliche Wiederherstellung
  des Services setzt voraus, dass man einen guten Überblick über das System mit seinen Services und Abhängigkeiten hat, um im Incident-Fall die richtigen Maßnahmen einzuleiten.

ITIL definiert für verschiedene Aufgaben innerhalb der Prozesse verschiedene Rollen. Eine wesentliche Rolle ist die des Incident Managers. Er ist dafür verantwortlich, dass der Prozess das Ziel erreicht. Die Rolle wird von einer Person wahrgenommen, die auch weitere Aufgaben im Unternehmen übernehmen kann.

Projekt "Einführung Incident Management"

Die Einführung des Prozesses sollte als Projekt mit den folgenden Phasen durchgeführt werden:

Abb. 1: Deming Cycle.

1. Initialisierung
2. Prozessdesign
3. Detailausarbeitung
4. Einführung
5. Abschluss

Bei der Durchführung gibt es einige Iterationspunkte, die ein Review enthalten und einen Rück­sprung zu vorhergehenden Schritten ermöglichen. Es empfiehlt sich, die Anzahl der Iterationen direkt beim Projektstart zu begren­zen, um eine Abgrenzung zum kontinuierlichen Verbesserungsprozess zu erhalten. Dieser wird innerhalb von ITIL mit Hilfe des Deming Cycles (siehe Abbildung 1) verdeutlicht.

Phase 1: Initialisierung

In der ersten Phase werden die Projektleitung und das Team benannt. Die Projektleitung selbst sollte der zukünftige Incident Manager übernehmen. Hiermit wird verhindert, dass sofort nach Projektende wesentliche Änderungen am Prozess durchgeführt werden. Danach wird festgelegt, für welche Kunden der Prozess eingeführt werden soll. Man sollte hier am Anfang lieber etwas zurückhaltender sein.

Für die weiteren Kunden sollte der zeitliche Rahmen und die Art der Umsetzung definiert werden. Neben dem Umfang sollten auch die Ziele und die Anzahl der Iterationen bis zum Projektende abgestimmt werden. Für die Phase 2 sollten zwei bis drei Iterationen und für die Phase 4 eine Iteration eingeplant werden.

Zu diesem Zeitpunkt muss auch der Kunde informiert werden. Anforderungen des Kunden an den Prozess sollten gegebenenfalls zusätzlich aufgenommen werden. Eine gemeinsame Planung sollte erstellt werden. Je nach Anpassung der Altabläufe muss auch der Kunde seine internen Prozesse anpassen.

Bevor die eigentliche Arbeit beginnt, werden für die Detailpunkte die Bestätigung und die Unterstützung der Geschäftsleitung benötigt.

Phase 2: Prozessdesign

Im ersten Schritt dieser Phase werden die Anforderungen des Prozesses ermittelt. Hierzu sollten die vorhandenen Abläufe analysiert und Hinweise der Mitarbeiter berücksichtigt werden. In dieser sehr frühen Phase wird schon die Akzeptanz des neuen Prozesses zu wesentlichen Teilen festgelegt. Betroffene müssen zu Beteiligten werden.

Abb. 2: Incident Management Prozess.

Auf Basis dieser Ergebnisse und des ITIL-Pro­zesses (siehe Abbildung 2) wird der individuelle Prozess gestaltet. Dazu müssen die Eingangsquellen, der Ablauf, die Rollen, die Kommunikationswege, die Kennzahlen und die Schnittstellen zu anderen ITIL-Prozessen definiert werden. Technische und fachliche Anforderungen an ein einzusetzendes Tool werden definiert.

Eine wesentliche Eigenschaft von ITIL ist, dass jeder Prozess seine eigene Aufgabe hat und zur Zielerreichung und Abgrenzung Schnittstellen zu anderen Prozessen besitzt. Hier kommen wir zu einer wesentlichen Anpassung unseres Ziels, "EINEN einheitlichen ITIL-Prozess einzuführen".

Zur Realisierung der Schnittstellen müssen wei­tere Prozesse zumindest rudimentär eingeführt werden. Details hierzu werden wir später im Artikel betrachten.

• Service Desk
• Problem Management
• Service Level Management
• Change Management
• Configuration Management

Am Ende dieser Phase sollte der Prozessentwurf mit den beteiligten Kunden und der Abteilung einem Review unterzogen werden. Gegebenenfalls muss diese Phase erneut durchlaufen werden.

Phase 3: Detailausarbeitung

Die Einführung des Prozesses wird vorbereitet. Hierzu werden die Rollen in der eigentlichen Organisation vorbereitet und zum Einführungsstart implementiert. Technische Voraussetzungen werden geschaffen und die notwendigen Arbeitsanweisungen und Checklisten erstellt. Neben den prozesseigenen Punkten fließen jetzt auch die initialen Informationen der anderen Prozesse ein. Die gesammelten Ergebnisse werden erneut mit den beteiligten Kunden abgestimmt.

Parallel hierzu wird ein Tool beschafft, das den Anforderungen des Prozesses gerecht wird. Falls schon ein Tool vorhanden ist und es halbwegs den Anforderungen gerecht wird, sollte dies erst einmal genutzt werden. Kleinere Einschränkungen sind für die ersten Monate nach der Einführung akzeptabel.

Nach Abschluss der Vorbereitungen werden die betroffenen Mitarbeiter geschult. Die Schulung der Mitarbeiter sollte gründlich vorbereitet werden und nicht nur die fachlichen Aspekte betrachten, sondern auch die persönlichen Belange. Mit der Einführung von ITIL wird in der Regel ein Umdenken der Mitarbeiter notwendig: Vom Fachmann mit einer sehr technischen Ausprägung hin zum kundenorientierten Servicemitarbeiter. Hier müssen die Mitarbeiter "mitgenommen" werden.

Phase 4: Einführung

Abb. 3: Einführungsverlaufskurve.

Nachdem die Vorbereitungen abgeschlossen sind, kann die eigentliche Einführung des ITIL Incident Managements gestartet werden. Mit dem Kunden wird noch einmal abgestimmt, dass er in seiner Organisation auch den neuen Prozess vorbereitet hat. Dann steht der Einführung nichts mehr entgegen. Hier muss man sich aber genau über die Auswirkungen der Einführung im Klaren sein (siehe Abbildung 3). Am Anfang wird die eigentliche Incident-Bearbeitung schlechter laufen und aufwändiger sein als vorher. Der neue Prozess muss sich noch einschwingen. Zuerst werden diese Probleme durch den Enthusiasmus aller Beteiligten kaschiert.

Doch nach kurzer Zeit wird der Druck des Kunden größer, was sich negativ auswirkt. Hier ist es besonders wichtig, dass die beteiligten Mitarbeiter positiv von der Geschäftsführung begleitet werden. Parallel hierzu muss der Kunde durch ein gemeinsames Review und die Definition von Maßnahmen und Prozessanpassungen beteiligt werden.

Phase 5: Abschluss

Nachdem die ersten Review-Maßnahmen erfolgreich umgesetzt sind, sollte der Prozess sich eingeschwungen haben. Das Einführungsprojekt wird abgeschlossen und der Prozess an den Incident Manager übergeben. Der Projektverlauf wird nun bezüglich des Verlaufs an sich betrachtet, um firmenspezifische Verbesserungspotentiale für die Einführung weiterer ITIL-Prozesse abzuleiten. Zum Abschluss bietet es sich an, den Projekterfolg mit der Projektgruppe und den Mitarbeitern des Incident Managements zu feiern.

Schnittstellen

In der Design-Phase haben wir gesehen, dass verschiedene Schnittstellen zu weiteren Prozessen benötigt werden. Wie schon angekündigt, muss man an vielen Punkten nicht sofort den kompletten Prozess einführen. Es reicht teilweise schon aus, wenn die Prozesse pro forma mit den Schnittstellen zum Incident Management aufgesetzt werden.

Schnittstelle: Service Desk

Der Service Desk stellt an sich keinen ITIL-Prozess dar. Er ist aber eine unverzichtbare Funktion des Incident Managements. Hierbei nimmt er zwei wesentliche Funktionen ein:

1. Kundenschnittstelle:
   Der Service Desk stellt den zentralen Anlaufpunkt des Kunden dar. Er alleine nimmt alle Störungsmeldungen und Anfragen entgegen. Alle Informationen in Richtung des Kunden laufen über ihn.
   
   
2. Incident Besitzer:
   Alle Incidents gehören dem Service Desk. Er stellt sicher, dass sie gemäß den Vorgaben bearbeitet werden und keiner vergessen wird. Gegebenenfalls werden die notwendigen Eskalationen angestoßen.

Wesentlicher Vorteil dieser Entkopplung ist einerseits der Zentralismus: Mehrere gleichartige Störungsmeldungen werden frühzeitig erkannt und können schneller gelöst werden. Darüber hinaus werden die anderen Abteilungen entlastet und können sich auf ihre Basisaufgaben konzentrieren.

Schnittstelle: Problem Management

Das Problem Management übernimmt vom Incident Management die Ursachenforschung und stellt Workarounds bis zur endgültigen Behebung zur Verfügung. Diese nennt man in ITIL "Known Errors". Die Trennung bewirkt, dass man sich beim Incident Management primär um die Beseitigung kümmert, damit die schnellstmögliche Wiederherstellung des Services gewährleistet ist.

Diesen Prozess muss man nicht direkt mit einführen. Es ist allerdings wichtig, dass die Bearbeiter sich der unterschiedlichen Ziele bewusst sind und diese aktiv unterstützen. Die Known Errors können im ersten Schritt auch z. B. in einer Excel-Tabelle gepflegt werden.

Schnittstelle: Service Level Management

Die Schnittstelle zum Service Level Management ist eine der wichtigsten Schnittstellen. Sie liefert dem Incident Management die benötigten Basisinformationen zu den Anforderungen des Services wie Priorität, Verfügbarkeit, Reaktionszeit, Backup-Klassen usw. Anhand dieser Informationen kann beurteilt werden, welcher Service mit dem Kunden vereinbart wurde.

Dieser Prozess muss nicht in ganzer Breite installiert werden. Es sollte aber zumindest ein Mitarbeiter beauftragt werden, die benötigten Informationen zur Verfügung zu stellen. Hier sollten auch Standard Service Level für die Services definiert werden, für die noch kein spezifischer Service Level vereinbart wurde.

Diese Vorgaben sind wichtig, da anhand dieser Informationen wichtige Entscheidungen bezüglich der Reihenfolge der Incident-Beseitigung getroffen werden können. Die Verantwortung hierfür darf nicht auf die Mitarbeiter im Incident Management abgewälzt werden.

Schnittstellen: Change und Configuration Management

Beide Prozesse stellen dem Incident Management aktuelle Informationen zur Verfügung. Das Configuration Management über die Konfiguration der Systeme. Das Change Management über die letzten Änderungen. Beide sollen helfen, Störungen so schnell wie möglich zu lösen. Beide Prozesse muss man allerdings nicht zwingend einführen, um Incident Management zu betreiben.

Resümee

Die Einführung des Incident Management Prozesses bringt viel Aufwand, Anpassungsprobleme und temporäre Unzufriedenheit des Kunden mit sich. Mittelfristig trägt er aber dazu bei, dass der Kunde seine Services, für die er ja auch bezahlt, so erhält, wie er sie vereinbart hat. Durch einen funktionierenden Incident Management Prozess kann man seine internen Kosten senken und gleichzeitig die Kundenzufriedenheit erhöhen.

Christian Ramm (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen