mindsquare.de durchsuchen

Incident Manager

Incident Manager

Wen rufen Sie, wenn es brennt? Die Feuerwehr! Wen rufen Sie, wenn eine Störung im IT Betrieb auftaucht? Die Incident Manager!

Auch wenn es bei Ihnen in der IT hoffentlich nicht im wortwörtlichen Sinne brennt, so eignet sich dieser Vergleich sehr gut um die Arbeit des Incident Managements zu verstehen.

 

Immerhin sieht die Arbeit des Incident Managers der des Feuerwehrmannes sehr ähnlich. Denn worum geht es vor allem bei der Arbeit der Feuerwehr? – darum, etwa bei einem Häuserbrand den Schaden zu begrenzen und somit den Bewohnern zu erlauben, schnellstmöglich dem Feuer zu trotz wieder in Ihre Unterkunft zu kommen.

Beim Incident Management sieht es ähnlich aus. Hier gilt es, den Schaden durch auftretende Störungen in der IT zu minimieren und den Anwendern zu ermöglichen, möglichst schnell wieder die Arbeit aufzunehmen. Die Incident Manager, die hierfür die Verantwortung übernehmen, sind die Mitarbeiter des 1st, 2nd oder 3rd Level Supports Ihrer IT.

Aber was ist eigentlich eine Störung?

ITIL definiert eine Störung als:

  • Eine ungeplante Unterbrechung oder Qualitätsminderung eines IT-Services bzw. ein Ereignis, das in der Zukunft einen IT-Service beeinträchtigen könnte.

IT Service Management Software

Zu Beginn einer Störung steht zumeist ein über eine speziell dafür vorgesehene Software aufgegebenes Störungsticket. Die Software hierzu gibt es von einer Vielzahl an Anbietern, wie etwa von HP in Form des Service Manager von HP oder von IBM als Smart Cloud Control Desk. Anwender können hier ihre Störungen entweder selber aufgeben oder aber bei Mitarbeitern des 1st Level Supports anrufen, woraufhin diese ein Ticket eröffnen.

Checkliste managed Support

Mit dieser Checkliste können Sie kontrollieren, ob Ihr Support durch die interne IT-Abteilung abgedeckt wird, oder ob Sie Unterstützung durch managed Support benötigen.

Es werden allerdings nicht alle Störungen von Menschen aufgegebenen. In vielen Unternehmen gibt es eine Vielzahl automatisierter Tickets, die als Reaktion auf eine Störung ohne menschliches Zutun erstellt werden.

Die ersten Schritte des Incident Managements dienen dem Verständnis der Störung. Im Idealfall befinden sich alle hierfür notwendigen Informationen innerhalb des Tickets. Welche Informationen notwendig sind, hängt ganz stark von der Art der Störung ab und lässt sich dadurch nicht pauschal für alle Fälle beantworten. Dennoch macht es hier Sinn, dass eine Checkliste erstellt und bei jeder Störung abgearbeitet wird. Bereits beantwortete Fragen wie „Wann trat die Störung auf?“ oder erfüllte Aufforderungen wie „Bitte hängen Sie einen Screenshot der Fehlermeldung an.“ können den Incident Managern viel Zeit sparen.

Werden dennoch weitere Informationen benötigt, so sollte sich der Incident Manager mit dem Anwender, der die Störung aufgegeben hat in Verbindung setzen.

Wie arbeitet ein Incident Manager?

Die inhaltliche Bearbeitung der Störung hängt im nächsten Schritt ganz stark von der Art des zugrunde liegenden Fehlers ab. So kann es bei technischen Schwierigkeiten sinnvoll sein, verknüpfte Joblogs oder Reports zu überprüfen.

Dennoch gibt es hier keine für alle Incidents identische Musterlösung. Während der gesamten Incident Bearbeitung ist es sinnvoll, sämtliche Analysetätigkeiten zu dokumentieren und auch die nächsten Schritte zu vermerken.

Incident Manager

So können Sie sicherstellen, dass auch Ihre Kollegen diese Tickets bearbeiten können, ohne mit Ihnen lange Rücksprache zu halten oder Arbeiten doppelt zu verrichten. Auch die Kommunikation mit den Aufgebern der Störung ist nicht zu vernachlässigen. Erst durch Rückfragen können Sie sicherstellen, dass Ihr Verständnis der Störung mit dem Verständnis des Anwenders übereinstimmt.

Schließung einer Störung:

Sie haben es geschafft die Störung zu beheben? Herzlichen Glückwunsch!

Aber Ihre Arbeit im Rahmen des Incident Managements ist noch nicht ganz vorbei, denn hier gibt es noch etwas zu beachten: Haben Sie vom Anwender die Bestätigung erhalten, dass die Störung nicht länger vorliegt? Wenn ja, wunderbar – wenn nein; dann fragen Sie nach!

Auch gilt hier wie im ganzen Prozess: die Dokumentation nicht vergessen! So können Sie sicherstellen, dass Ihre Lösung auch zukünftig nachzuvollziehen bleibt und Ihnen und Ihren Kollegen künftig wertvolle Zeit bei der Bearbeitung ähnlicher Störungen erspart bleibt.