So meisterst du den Vorfallmanagementprozess wie ein IT-Operations-Profi

Einen Vorfall identifizieren und protokollieren

Ein Vorfall kann viele Ursachen haben. Vielleicht ruft ein Mitarbeiter an, um ihn zu melden, oder dir kann ein unglücklich platzierter Netzwerkhub wegen eines undichten Daches buchstäblich durch die Deckenplatte auf den Schoß fallen. (Nicht, dass wir aus Erfahrung sprechen …)

Was immer die Ursache ist – die ersten beiden Schritte sind ganz einfach: Jemand identifiziert einen Vorfall und ein anderer protokolliert ihn.

Wenn der Vorfall bei dir eingeht und er bereits über den Servicedesk protokolliert wurde, wurden diese ersten beiden Schritte bereits für dich erledigt. Wenn du einen Anruf erhältst oder der Vorfall per E-Mail, SMS oder Brieftaube gemeldet wird, ist es Aufgabe des Servicedesk-Teams, ihn ordnungsgemäß in deinem Servicedesk zu protokollieren.

Diese Vorfallprotokolle (d. h. Tickets) umfassen normalerweise Folgendes:

• Name der Person, die den Vorfall meldet
• Datum und Uhrzeit der Meldung des Vorfalls
• Beschreibung des Vorfalls (Was ist ausgefallen oder funktioniert nicht richtig?)
• Eine dem Vorfall zugewiesene eindeutige Identifikationsnummer zur Nachverfolgung

Vorfall kategorisieren

Die nächsten zwei Schritte – Kategorisierung und Priorisierung – sind beide entscheidend und werden doch gern übersehen. Sie entscheiden auch darüber, ob ein Servicedesk seine Arbeit im Griff hat, oder eben nicht.

Zunächst einmal musst du jedem Vorfall eine logische, intuitive Kategorie (und ggf. Unterkategorie) zuweisen. Falls du diesen Schritt auslässt, hast du später keine Möglichkeit mehr, deine Daten zu analysieren und nach Trends und Mustern zu suchen. Das ist aber ein wichtiger Bestandteil eines effektiven Problemmanagements, um zukünftige Vorfälle zu verhindern.

Denke also unbedingt daran und finde dich nicht mit einer IT-Servicedesk-Lösung ab, die keine problemlose Anpassung von Vorfallkategorien zulässt.

Vorfall priorisieren

Im zweiten Schritt muss jeder Vorfall priorisiert werden.

Um einen Vorfall zu priorisieren, bewertest du zunächst dessen Auswirkungen auf das Geschäft. Berücksichtige hierbei die Anzahl der Personen, die davon betroffen sein werden, sowie die potenziellen Konsequenzen für die Finanzen, die Sicherheit und die Compliance. So kannst du beurteilen, wie viel Schaden der Vorfall anrichtet und wie dringend das Unternehmen ihn beheben muss.

Die Best Practice besteht in diesem Fall darin, deine Schweregrade und Prioritätsstufen zu definieren, bevor ein Vorfall eintritt. Das macht es für Vorfallmanager einfacher, die Priorität schnell zu ermitteln.

Wenn du Zweifel bezüglich der Prioritätsstufe hast, nimmst du die nächsthöhere. Vorsicht ist schließlich besser als Nachsicht, und so verhinderst du, dass dir etwas Gravierendes durch die Maschen schlüpft.

Nachdem du diese Prioritäten festgelegt hast, gehst du auf alle offenen Vorfälle nach ihrer Priorität ein. Die meisten Unternehmen legen klare Servicevereinbarungen für jede Prioritätsstufe fest, damit Kunden wissen, wie schnell sie eine Antwort und Lösung erwarten können. Diese Praxis möchte ich dir wirklich ans Herz legen.

Reagieren

Die Incident Response ist ein ziemlich breit gefasster Begriff, deshalb werden wir sie auf die Schritte herunterbrechen, die du mit großer Wahrscheinlichkeit ausführen wirst, sobald du einen Vorfall identifiziert, kategorisiert und priorisiert hast.

Erstdiagnose
Betrachte dies wie eine Triage, die in Krankenhäusern an neuen Patienten vorgenommen wird. Servicedesk-Mitarbeiter stellen eine schnelle Hypothese über das mögliche Problem auf, um dieses selbst zu beheben, oder sie halten sich an geeignete Verfahren, um die richtigen Ressourcen zur Lösung des Problems zusammenzustellen.

Bei diesem Schritt können sich Wissensdatenbanken und Diagnosehandbücher als nützliche Hilfsmittel erweisen.

Wenn der First-Level-Servicedesk-Agent basierend auf seiner Erstdiagnose und mithilfe eigener Kenntnisse und Tools den Vorfall beheben kann, ist der Vorfall erledigt. Wenn nicht, muss er eskaliert werden.

Eskalation von Vorfällen
Eskalation klingt irgendwie negativ, ist es aber nicht.

Dein Supportteam an vorderster Front sollte in der Lage sein, den Großteil der häufigsten Vorfälle zu lösen, ohne sie zu eskalieren. In den Fällen, bei denen dies nicht möglich ist, müssen die richtigen Informationen gesammelt und protokolliert werden, damit der Second- oder (der technischere) Third-Level-Support schnell informiert wird und dieser den Vorfall umgehend beheben kann.

Untersuchung und Diagnose
ITIL beansprucht dies als eigenen und einzigen Schritt für sich. Tatsächlich zieht er sich durch den gesamten Vorfalllebenszyklus.

Deine Supportmitarbeiter an vorderster Front führen bereits auf gewisse Weise Untersuchungen durch, indem sie Informationen dazu sammeln. Eventuell können sie sogar eine richtige Diagnose stellen und den Vorfall auch ohne Eskalation beheben.

In diesem Fall hast du direkt ein paar Schritte übersprungen: Behebung, Wiederherstellung und Schließung von Vorfällen.

In anderen Fällen werden die Schritte "Untersuchung" und "Diagnose" durchgeführt, wenn du sie an den Second- und Third-Level-Support eskalierst. Oder auch, wenn du Fachleute von außen oder Mitglieder anderer Abteilungen für die Problemlösung zurate ziehst.

Behebung und Wiederherstellung
Zum Schluss – und idealerweise im Rahmen deines festgelegten Service Level Agreement (SLA) – werden Diagnosen erstellt und die notwendigen Schritte zur Behebung des Vorfalls durchgeführt. Die Wiederherstellung bezieht sich schlicht auf die Zeitdauer, bis Vorgänge vollständig wiederhergestellt werden können. Bestimmte Fehlerkorrekturen (wie Bug-Patches) erfordern eventuell noch Tests oder müssen erst bereitgestellt werden, obwohl die richtige Lösung bereits identifiziert wurde.

Schließung von Vorfällen
Der Vorfall wird anschließend an den Servicedesk zurückgegeben (falls er eskaliert wurde), damit dieser ihn schließt. Um die Qualität aufrechtzuerhalten und einen reibungslosen Ablauf zu gewährleisten, dürfen nur Servicedesk-Mitarbeiter Vorfälle schließen. Derweil sollten sich Vorfallverantwortliche bei der Person, die den Vorfall gemeldet hat, erkundigen, ob die Lösung zufriedenstellend war und der Vorfall tatsächlich geschlossen werden kann.

Fazit: keine Schritte auslassen

Vielleicht kommt dir der Prozess vor allem dann unnötig formal vor, wenn du nur eine Handvoll Servicedesk-Analysten hast. Der Vorfalllebenszyklus ist jedoch derselbe und hat nichts mit der Struktur deines Teams zu tun.

Nehmen wir einmal an, dass du nur einen Servicedesk-Analysten hast und damit auch keinen Third-Level-Support. Vorfälle, die die Kenntnisse deines Servicedesk-Analysten übersteigen, müssen aber an jemanden eskaliert werden. Das könnte dein leitender Techniker, eine externe Beraterin oder sogar du selbst sein.

Du hast also einen Second- oder Third-Level-Support – deine Wenigkeit oder deinen leitenden Techniker.

Damit will ich auf Folgendes hinaus. Obwohl bei ITIL anscheinend viel Wert auf feine Unterschiede gelegt wird, solltest du dich davon nicht verwirren lassen. Suche nach einfachen Möglichkeiten, um deine Organisationshierarchie und Prozessworkflows so anzupassen, dass sie in ein einfaches Framework für das IT-Servicemanagement passen, wie ich es oben beschrieben habe.

Auf diese Weise wirst du einen deutlich besseren Kundenservice bereitstellen und dem Unternehmen einen wesentlich größeren Nutzen bringen. (Ein weiterer Riesenvorteil ist auch, dass du Feuer schneller austreten kannst!)

Zur Erinnerung:

• Protokolliere jeden Vorfall. Weise ihm eine eindeutige Nummer zu und nimm wichtige Details (wie Datum, Uhrzeit und Beschreibung) in einem zentralen Helpdesk-System auf.
• Wenn du ein großes internes oder externes Publikum über Vorfälle informieren musst, solltest du eine Statusseite für die Kommunikation von Vorfällen in Betracht ziehen.
• Weise jedem Vorfall eine Kategorie (und ggf. Unterkategorie) zu.
• Lege für jeden Vorfall eine Prioritätsstufe fest und für jede Prioritätsstufe ein SLA.
• Weise Vorfallbearbeitern klar definierte Rollen zu, wie Einsatzleiter, Manager für größere Vorfälle, Kommunikationsverantwortliche.
• Stelle deinem Supportteam an vorderster Front nach Möglichkeit Wissensdatenbankartikel und Skripte für die Vorfalldiagnose zur Verfügung, um es bei der schnellen Behebung von Vorfällen zu unterstützen.
• Stelle sicher, dass der Servicedesk stets die Kontrolle über den Vorfallverlauf, dessen Weiterleitung und Status behält.
• Und belasse es nicht bei der Erfassung von Vorfalldaten. Du solltest sie auch analysieren! Achte auf Trends, Muster und mögliche zugrundeliegende Probleme, um das Ausmaß von Vorfällen und Risiken zu verringern.

Über den Autor