Online
Fragen zur ITIL Foundation Prüfung (V3)
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 Management 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ücksprung zu vorhergehenden Schritten ermöglichen.
Es empfiehlt sich, die Anzahl der Iterationen direkt beim Projektstart
zu begrenzen, 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-Prozesses (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 weitere 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.
|