Vorfallmanagement für High-Velocity-Teams
So meisterst du den Vorfallmanagementprozess wie ein IT-Operations-Profi
Von Nick Wright, Atlassian Service Operations Manager
Ich möchte zunächst etwas Wichtiges loswerden: Supportmitarbeiter an vorderster Front sind die heimlichen Helden jedes Unternehmens.
Und ich meine wirklich jedes Unternehmens.
Ich bin fest davon überzeugt, dass technischer Support als eine Dienstleistungsbranche betrachtet und Kunden die Möglichkeit gegeben werden sollte, Agenten ein Trinkgeld zu spendieren, wenn sie exzellenten Service bieten. Ich würde nur allzu gern allen Supportmitarbeitern ein Trinkgeld geben, die meine Probleme schnell – und mit einem Lächeln – beheben.
Aber ich schweife vom Thema ab. Wenn du dies liest, leitest du wahrscheinlich ein Helpdesk-Team oder bist in einem solchen tätig. Vielleicht bist du auch gerade dabei, Feuer auszutreten, und die Situation wird unerträglich. Deshalb wollen wir jetzt etwas unternehmen, um deinen IT-Vorfallmanagementprozess auf Vordermann zu bringen
Bevor wir uns jedoch mit dem Vorfallmanagement befassen, sollten wir uns auf eine gemeinsame Terminologie einigen.
I truly believe that tech support should be considered a service industry, and customers should be able to leave tips for agents who deliver excellent service. I would happily leave a tip for every killer support person who resolved my issues quickly—and with a smile–if only I could.
But I digress. If you’re reading this, you probably manage or serve on a help desk team. Your hair is probably also on fire right now. It really burns. The smell is awful, too. So let’s do something about that—and get your IT incident management process under control.
Before we dive into incident management, though, let’s get on the same page about some common terminology.
ITSM und Vorfallmanagement
Wenn du in der IT arbeitest, bist du wahrscheinlich mit Begrifflichkeiten wie ITIL, ITSM, Vorfällen und Problemen vertraut. Damit aber alle wissen, wovon ich spreche, werde ich hier einige kurze Definitionen aufführen, die wir bei Atlassian verwenden:
ITIL (Information Technology Infrastructure Library) ist eine Reihe von Best Practices für das ITSM (betrachte es als eine Art Playbook).
ITSM (IT-Servicemanagement) ist ein gängiger Ansatz zur Erstellung, Unterstützung und Verwaltung von IT-Services. Im Grunde folgt ITSM der Überzeugung, dass die IT als Service bereitgestellt werden sollte. Und eine der wesentlichen Praktiken von ITSM ist das Vorfallmanagement.
Vorfälle sind ungeplante Ereignisse jeglicher Art, die die Servicequalität stören oder (mit großer Wahrscheinlichkeit) beeinträchtigen werden. Wenn eine Geschäftsanwendung ausfällt, handelt es sich um einen Vorfall. Ein Webserver, der gerade noch so funktioniert, aber noch nicht ausgefallen ist, kann ebenfalls ein Vorfall sein. Er läuft langsam und beeinträchtigt die Produktivität. Und was noch schlimmer ist: Er läuft Gefahr, komplett auszufallen.
Ein Problem ist die bisher nicht bekannte Ursache für einen oder mehrere Vorfälle. Für die beiden oben genannten Vorfälle, bei denen beispielsweise das Netzwerk nur noch gerade so funktioniert oder eine Geschäftsanwendung ausgefallen ist, könnte ein falsch konfigurierter Router verantwortlich sein.
Die Bedeutung des Vorfallmanagements als eine ITSM-Praktik
Wozu dient also das Vorfallmanagement? Warum gehört es überhaupt zum ITSM?
Die Antwort darauf findet sich in den Auswirkungen. Untersuchungen ergaben, dass Systemausfälle Unternehmen durchschnittlich zwischen 100.000 und 300.000 US-Dollar pro Stunde kosten.
Mithilfe eines klar definierten Vorfallmanagementprozesses ist es möglich, diese Kosten drastisch zu senken. Zu den Vorteilen eines klar definierten Prozesses zählen:
- Schnellere Behebung von Vorfällen
- Geringere Kosten oder Umsatzverluste für das Unternehmen
- Bessere interne und externe Kommunikation bei Vorfällen
- Kontinuierliche Weiterbildung und Verbesserung
Workflow des Ereignismanagements
Ich werde das ITIL-Framework verwenden, um dir einen allgemeinen Überblick über die ordnungsgemäße Bearbeitung von Tickets zu bieten. Die meisten anderen beliebten Frameworks funktionieren aber ähnlich und verwenden lediglich eine etwas andere Sprache.
Für das Vorfallmanagement braucht man unbedingt einen funktionierenden Prozess, an den man sich zu halten hat.
Das allein kann schon als Herausforderung erscheinen, aber die gute Nachricht ist, dass du aus den Erfahrungen Tausender anderer IT-Serviceteams lernen kannst.
Einer der größten Fehler von vielbeschäftigten, wachsenden IT-Organisationen besteht darin, das Rad neu erfinden, Prozesse von Grund auf neu erstellen (ohne Beachtung von Best Practices) oder eigene Tools für die Ticketerstellung entwickeln zu wollen.
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
Nick Wright
Service Operations Manager, Atlassian
Mein Team und ich stellen sicher, dass die Cloud-Anwendungen und -Infrastrukturen von Atlassian optimal funktionieren. Und ich gebe gerne Auskunft darüber, wie wir das auch während einer schnellen Skalierung bewerkstelligen. Ich bin Neuseeländer, kann aber trotz meines sprachlichen Handicaps problemlos Fish and Chips sagen. Meine Freizeit verbringe ich gerne mit Rad fahren, Gaming, meiner Frau und meiner süßen kleinen Tochter.
Informationen zur Kommunikation bei Vorfällen mit Statuspage
In diesem Tutorial zeigen wir dir, wie du mithilfe von Vorfallvorlagen bei Ausfällen effektiv kommunizierst. Sie sind an viele Arten von Serviceunterbrechungen anpassbar.
Dieses Tutorial ansehenVorlagen und Beispiele für die Vorfallkommunikation
Wenn du Vorfälle bearbeitest, können sich Vorlagen für die Kommunikation als äußerst nützlich erweisen. Lade die Vorlagen herunter, die unsere Teams verwenden, und lerne weitere Beispiele für typische Vorfälle kennen.
Artikel lesen