Incident Management ist aus operativer Sicht eine der direkten Kundenschnittstellen. Die strukturierte, zügige und professionelle Bearbeitung von Störungen an IT Services ist somit zur Erfüllung der heutigen Anforderungen an die IT unumgänglich. Die folgenden fünf Punkte helfen dir, ein effizientes Incident Management zu realisieren.
Wie dir als Leser sicherlich nicht unbekannt ist, muss sich die IT häufig als Leistungsbestätigung damit zufrieden geben „wenn keiner meckert“. Funktioniert jedoch etwas nicht, nach Definition liegt also eine Störung eines IT-Services und deren Komponente vor, müssen wir als IT schnell und kompetent reagieren und eine Lösung herbeiführen können. Dies funktioniert nur, wenn ein gemeinsames Verständnis des Bearbeitungsprozesses, sowie deren Rahmenparameter vorherrschen. Wird ein Incident eröffnet, muss dem Bearbeiter ein klares Bild vorliegen, nach welchen Kriterien er diesen Vorfall zu priorisieren, zu kategorisieren und im Fall der Weiterleitung, an wen zuzuweisen hat.
Wie dieser Prozess aussehen kann und welche Rahmenparamater beim Incident Management notwendig sind, ist denke ich ausreichend im Internet dokumentiert. Eine gute Einführung hierzu bietet die Seite der IT Process Maps zum Incident Management.
Gezielt Mehraufwände reduzieren
Klassischerweise dient das Incident Management bei ITSM Tool Integrationen häufig als eine der ersten einzuführenden Disziplinen, da dies gerne als wenig komplex und schnell umzusetzen angesehen wird. Sind zwar vielleicht keine komplexen Workflows oder Skripte zu erstellen, kann es dennoch genau wegen dieser Auffassung der Einfachheit zu einigen Fallstricken und anschließenden Mehraufwänden in der Improvementphase, bzw. dem Early Life Support kommen. Um dies zu verhindern, können die Beachtung folgender Punkte Abhilfe schaffen:
- Priorität ohne Standardwert:
Bei der Generierung der Priorität wird im Incident Management für gewöhnlich eine Prioritätenmatrix aus bspw. Auswirkung (impact) und Dringlichkeit (urgency) verwendet. Bei Definition der dort auswählbaren Feldattribute, kann ein zusätzlicher Wert „none“ als gesetzter Standardwert in Kombination mit der Konfiguration als Pflichtfeld verhindern, dass im Reporting nachher eine zu hohe , bzw. verfälschte Anzahl von Incidents mit bspw. zu niedriger Priorität vorhanden sind (wenn bspw. die Standardwerte auf „niedrig“ gesetzt sind und somit Priorität 4 gesetzt wird). Durch das Setzen auf none sowie der Deklaration als Pflichtfeld, wird der Bearbeiter immer dazu angehalten, die Werte zur Errechnung der Priorität aktiv und mit Sinn und Verstand auszuwählen und somit eine falsche Priorisierung durch vergessen der Feldauswahl zu vermeiden. - Hinzufügen eines Reassignment-Counts:
Neben der SLA Überwachung zur Lösung von Incidents, sowie ggfs. vorhandenen Eskalationsmechanismen, kann es nützlich sein, einen sogenannten Reassignment Count hinzuzufügen. Die Logik dahinter ist recht simpel; ein zusätzliches Zahlenfeld gibt lediglich hochzählend aus, wie oft das Feld der Incidentzuweisung bereits geändert wurde. Geht ein Incident vom Bearbeiter an ein 2nd Level Team, entgeht bereits dem Bearbeiter, wenn das dahinterliegende Team diesen vielleicht aufgrund falscher Zuständigkeit wieder weitergibt. Anhand des Feldes kann weitere Logik etabliert werden. Bspw. erhält der Incident Manager einen Hinweis auf seinem Dashboard, wenn der Count den Wert 3 erreicht und kann somit frühzeitig einschreiten, bzw. sog. Ticket-Pingpong effizient unterbinden. - Autoclose von alten Incidents:
Zur Wahrung einer sauberen Incidentmanagement Reportbasis kann es sinnvoll sein, ein Autoclose von Incidents nach einer Zeitspanne von bspw. 14 Tagen zu konfiguieren. Sicher werden dazu diverse Gegenargumente vorherrschen, wenn bspw. tatsächlich zur Lösung noch auf Rückantwort eines Dritten o.Ä. gewartet wird. Man sollte das für und wieder dann offen intern diskutieren. Aus meiner Sicht ist aber ein sauberer Incidentbestand mehr Wert als das ewige mitschleifen von Ticketleichen. Positiver Nebeneffekt ist, dass auch die Incidents nicht mehr offen bleiben, wo sich das Problem schon erledigt hat, sich der Incident Opener aber nicht mehr meldet. Was in der Realität mehr als oft genug der Fall ist. Meldet sich ein Incident Opener tatsächlich erneut, kann ebenfalls in der Diskussion entschieden werden, ob entweder der Autoclose Mechanismus nur aus „solved“ setzt und somit ggfs. ein „reopen“ möglich ist, oder ob der Autoclose Mechanismus auf closed setzt und einfach ein neuer Incident Record erstellt und mit dem geschlossenen Ticket verknüpft wird. Letzteres ist aus meiner Sicht die saubere und konsequentere Variante. - Einbindung der Knowledge Base:
Besonders in größeren Umgebungen mit vielen Service Desk Bearbeitern, kommen täglich viele neue Erkenntnisse zu Stande. Umso wichtiger ist dann die effiziente „Bekanntmachung“, also das verfügbar Machen dieser Kenntnisse. Neben der direkte Einbindung in ein Enduserportal zur generellen Vermeidung von Incidents, kann auch die Einbindung in das Backend-Formular des Bearbeiters die Anzahl des o.g. Reassignment-Counts reduzieren. Findet der Bearbeiter schon bei der ersten Durchsicht (oder im telefonische Meldefall, sogar bei Aufnahme des Incidents) der Informationen zu einem Incident eine zur Lösung verhelfende Information aus der Knowledge Base, ist der Enduser zufrieden und der Service Desk Mitarbeiter schneller wieder für die Bearbeitung weiterer Aufgaben frei. - Regelmäßiger Review des Kategoriebaumes und deren Assignmentgruppen:
Dreh- und Angelpunkt einer effizienten und schnellen Bearbeitung von Incidents ist einer korrekte Kategorisierung, sowie der daran hängenden, korrekten Teamzuweisung zur Lösung des Problemes. Genau diese Zusammenhänge sollten in einem regelmäßigen Turnus gemeinsam mit den Gruppen- oder zumindest den Abteilungsleitern analysiert und ggfs. aktualisiert werden. Nichts kostet mehr Zeit, als eine Fehlzuweisung, welche immer wieder erneut korrigiert werden muss. Dieser kurze Einmalaufwand kann sich, immer wieder auftretend, bei tausenden von Incidents schnell zu einem großen Mehraufwand summieren.
Fazit
Wie eingangs erwähnt, ist also eine saubere und aktuelle Sach- und Informationslage für das Incident Management Gold wert. Eine gute Verteilung bekannter Informationen, sowie eine hohe Transparenz durch sinnvoll eingesetztes Reporting hilft dem Incident Manager und letztlich dem Service Desk Team, eine effiziente und zufriedenstellende Bearbeitung von Störungsmeldungen durchzuführen, was am Ende den ein oder anderen User sogar zu positiven Äußerungen über die schnelle und professionelle IT zu bewegen vermag.