Incident Management

Incident Management ist in der Regel der erste Prozess der IT Infrastructure Library (ITIL), den Organisationen für die Implementierung oder Verbesserung in den Blick nehmen, wenn sie ITIL-Best-Practices übernehmen möchten. Die Gründe dafür sind einfach: eine verbesserte Consumerization und die Realisierung von Service Value. Incident Management ist der tägliche Prozess, den eine Organisation über den Service Desk oder Self-Help-Technologie nutzt, um Services schnell wiederherzustellen.

Eine hohe Leistungsfähigkeit dieses Prozesses ist für die Organisation und die Nutzer betroffener Services entscheidend. Ohne sie kommt es zu ungeordnetem Vorgehen, das die Leistung der Nutzer, die Leistungsfähigkeit der Organisation und den gesamten wirtschaftlichen Wert sowohl für den Kunden als auch für den Anbieter des Service beeinträchtigt. Incident Management selbst sollte die Geschäftsstrategie unterstützen, und die Geschäftsstrategie sollte die Voraussetzungen dafür schaffen, dass Incident Management wertschöpfend umgesetzt werden kann.

In diesem Leitfaden betrachten wir das Incident-Management-System von ITIL im Detail. Ausgehend von einer Definition und Zielbeschreibung des Prozesses sehen wir uns an, wie ITIL den Prozessablauf definiert, wie das Support-Team bei der Behebung von IT-Incidents zusammenarbeitet und wie sich der Erfolg des Prozesses in einem Unternehmen anhand von Key Performance Indicators (KPIs) messen lässt. Abschließend untersuchen wir, wie neue integrierte Service-Management-Software Automatisierung ermöglicht und Organisationen dabei unterstützt, einen konsolidierten Service Desk aufzubauen und Incidents effizienter zu beheben.

Was ist Incident Management?

In ITIL wird der Begriff „Incident“ verwendet, um eine ungeplante Unterbrechung oder Qualitätsminderung eines IT-Service zu beschreiben, die für große Organisationen sehr kostspielig sein kann. Das Hauptziel des Incident-Management-Prozesses besteht darin, den Service für Nutzer bei Unterbrechungen so schnell wie möglich wiederherzustellen.

Neben der grundlegenden Anfrageerfüllung ist Incident Management einer der wichtigsten Prozesse, die IT-Organisationen täglich steuern. Während der Prozess der Anfrageerfüllung dazu dient, Standardanfragen von Nutzern wie das Ändern eines Passworts zu bearbeiten, befasst sich Incident Management mit tatsächlichen Serviceausfällen – mit dem Ziel, den Ausfall zu beheben und den Service für Nutzer so schnell wie möglich wiederherzustellen.

Im fünfstufigen Service-Lifecycle-Modell von ITIL fällt Incident Management unter „Service Operation“. Dies ist die vierte Phase des Service-Lebenszyklus und die Phase, in der ein Service bereits von der Organisation betrieben wird. Der Prozess trägt dazu bei, dass eine Organisation den maximalen Wert aus den von ihr unterstützten Services und Anwendungen ziehen kann, indem Leistung, Verfügbarkeit und Nutzerzugriff auf den Service sichergestellt werden.

Was sind Incident-Management-Prozesse und -Workflows?

Incident Management ist der Prozess, den IT-Organisationen nutzen, um den Lebenszyklus gemeldeter Incidents zu verwalten. Dieser Prozess besteht aus mehreren Schritten, häufig als Teilprozesse bezeichnet, die alle ausgeführt werden müssen, damit Incidents angemessen behoben und dokumentiert werden. Im Folgenden beschreiben wir die einzelnen Teilprozesse und ihren Nutzen für die Organisation.

Incident-Management-Support

Ziel des Incident-Management-Supports ist es, die Tools, Prozesse, Fähigkeiten und Regeln bereitzustellen und zu pflegen, die für eine effektive und effiziente Bearbeitung von Incidents erforderlich sind. Dieser Prozess trägt dazu bei, dass Service-Desk-Mitarbeiter oder Techniker ausreichend geschult und ausgebildet sind, um auf Incidents innerhalb der IT-Organisation zu reagieren und diese zu beheben. Zudem pflegt der Prozess die Regeln und Workflows für die Bearbeitung und Behebung von Incidents, sodass Techniker jederzeit wissen, welcher nächste Schritt erforderlich ist, um einen Incident zu lösen.

Incident-Protokollierung und -Kategorisierung

Ziel dieses Teilprozesses ist es, Incident-Meldungen mit der gebotenen Sorgfalt zu erfassen und zu priorisieren, um eine schnelle und wirksame Behebung zu ermöglichen. Organisationen verfügen häufig nur über begrenzte Ressourcen zur Behebung von Incidents und anderen IT-Problemen. Daher ist die effektive Priorisierung eingehender Incident-Meldungen ein entscheidender Schritt, um Arbeitsressourcen angemessen den Incidents mit der höchsten Priorität zuzuweisen. IT-Organisationen müssen in der Lage sein, Umfang und Schweregrad eines gemeldeten Incidents kompetent zu bestimmen und ihn entsprechend zu priorisieren. Die Protokollierung und Kategorisierung von Incidents ist häufig automatisiert, etwa wenn eine IT-Operations-Monitoring-Lösung aufgrund eines Performance- oder Verfügbarkeitsereignisses einen Incident erstellt.

Sofortige Incident-Behebung durch 1st-Level-Support

Wenn ein Nutzer einen Incident zum ersten Mal an den Service Desk meldet, berichtet er das Problem in der Regel einem 1st-Level-Servicetechniker. Idealerweise kann der 1st-Level-Techniker den Incident beim ersten Anruf und innerhalb einer von der IT-Organisation festgelegten Zielzeit beheben und den IT-Service wiederherstellen. Kann ein Incident nicht innerhalb der Zielzeit behoben werden oder ist ein höheres Maß an spezialisiertem technischem Wissen erforderlich, erfolgt eine Eskalation, und ein 2nd-Level-Support-Techniker kann den Incident übernehmen.

Incident-Behebung durch 2nd-Level-Support

Sobald ein Incident über eine Behebung beim ersten Anruf durch den 1st-Level-Support hinaus eskaliert wurde, kann ein 2nd-Level-Support-Techniker den Incident übernehmen und nach einem Workaround suchen, um den Service so schnell wie möglich wiederherzustellen. Auf dieser Ebene kann der Techniker Support-Gruppen oder Drittanbieter in die Behebung des Incidents einbeziehen. Wenn der Incident beispielsweise auf eine fehlerhafte Anwendung zurückzuführen ist, kann der 2nd-Level-Techniker das Unternehmen kontaktieren, das die Anwendung entwickelt hat, um zusätzliche Unterstützung bei der Behebung zu erhalten. Gibt es keine Möglichkeit, die Ursache des Incidents zu beheben, kann der 2nd-Level-Support-Techniker einen Problem Record erstellen und den Incident an den Prozess bzw. das Team für Problem Management übergeben.

Bearbeitung von Major Incidents

Zuvor haben wir die Bedeutung der Priorisierung von Incidents nach ihrer Dringlichkeit erwähnt, damit Ressourcen möglichst effizient eingesetzt werden können. Major Incidents sind die IT-Incidents mit der höchsten Priorität, die eine Organisation erkennen kann – sie stellen schwerwiegende Unterbrechungen oder Bedrohungen für Geschäftsaktivitäten dar und müssen mit höchster Dringlichkeit behoben werden, um finanzielle Verluste oder andere kritische Folgen zu verhindern. Major Incidents werden schnell über 1st-Level- und 2nd-Level-Support-Mitarbeiter eskaliert und können Drittanbieter einbeziehen, wenn der Incident nicht rasch behoben wird. Auch hier gilt: Ist eine Behebung der Ursache nicht möglich, wird der Incident an Problem Management übergeben.

Incident-Überwachung und -Eskalation

IT-Organisationen, die ITIL-Best-Practices folgen, richten ein System zur Überwachung des Status und der Eskalationen jedes gemeldeten IT-Incidents ein und pflegen es. IT-Manager, die für Incident Management zuständig sind, sollten die Anzahl der aktuell gemeldeten Incidents nachverfolgen und deren Status im Incident-Management-Prozess einsehen können. Service Level Agreements werden verletzt, wenn das Incident-Management-Team zu lange für die Reaktion auf Incidents benötigt, und Serviceausfälle führen zu Geschäftsunterbrechungen. Incident-Überwachung wird eingesetzt, um sicherzustellen, dass Incident-Management-Tickets zeitnah gelöst und durch den Prozess geführt werden, sodass die Service Levels der Organisation eingehalten werden.

Incident-Abschluss und -Bewertung

Sobald ein Incident wirksam behoben wurde, wird der Incident Record einem abschließenden Qualitätssicherungsschritt unterzogen. Dieser Teilprozess bestätigt, dass der Incident behoben wurde und dass der Lebenszyklus des Incidents ausreichend detailliert dokumentiert ist. Die Erkenntnisse aus dem Incident-Bericht können von der Organisation künftig genutzt werden, unter anderem als Input für den Knowledge Management Prozess. Incident-Abschluss und -Bewertung tragen dazu bei, dass die Organisation alle wichtigen Informationen zu einem Incident erfasst und aus dem behobenen Incident Erkenntnisse gewinnt.

Proaktive Nutzerinformation

Incident-Management-Meldungen werden in der Regel über den Service Desk der Organisation eingereicht, der als zentrale Anlaufstelle für IT-Ressourcen innerhalb der Organisation dient. Das Service-Desk-Team kann dieses Kommunikationsportal auch nutzen, um Nutzer proaktiv über bekannte Probleme und Serviceausfälle innerhalb der Organisation zu informieren. Dieser Teilprozess hilft, Informationen in der gesamten Organisation zu verbreiten und die Anzahl der Anfragen und Nachfragen beim Service Desk zu reduzieren, indem aktuelle Informationen zu Serviceausfällen innerhalb der Organisation bereitgestellt werden.

Incident-Management-Reporting

Dieser Teilprozess erfasst Informationen aus dem Incident-Management-Prozess und stellt sie den anderen Service-Management-Prozessen zur Verfügung, sodass die Organisation die Möglichkeit hat, ihre Leistung auf Grundlage von Daten aus früheren Incidents zu verbessern.

Wie messen Organisationen den Erfolg im Incident Management?

Die Messung des Erfolgs von Prozessen über den gesamten ITIL-Service-Lebenszyklus hinweg ist der Schlüssel zur kontinuierlichen Serviceverbesserung. Organisationen sollten Kennzahlen festlegen, mit denen die Leistung jedes Prozesses überwacht wird, und präzise darüber berichten, um die besten Verbesserungsmöglichkeiten zu identifizieren. Im Folgenden haben wir fünf der wichtigsten KPIs aufgeführt, mit denen Organisationen sicherstellen können, dass ihr Incident-Management-Prozess die erwartete Leistung erbringt.

Status von Incidents – Organisationen können Software einsetzen, um den Status von Incidents zu verfolgen, die derzeit im Rahmen des Incident-Management-Prozesses bearbeitet werden. Ein Echtzeitblick auf den Status aller offenen Incidents kann zeigen, wo die größten Rückstände entstehen und wie die Organisation Ressourcen am besten einsetzen kann, um den Ablauf zu verbessern und Lösungszeiten zu verkürzen. Wenn beispielsweise viele Incidents im 2nd-Level-Support stecken bleiben, ohne gelöst zu werden, könnte das Unternehmen mehrere mögliche Lösungen verfolgen:

1. Mehr 2nd-Level-Support-Mitarbeiter einsetzen, um die Bearbeitung von Incidents zu beschleunigen.
2. Zusätzliche Schulungen für 2nd-Level-Support-Mitarbeiter anbieten, um die Effizienz der Incident-Behebung zu steigern.
3. Zusätzliche Schulungen für 1st-Level-Support-Mitarbeiter anbieten, um Eskalationen zu reduzieren.
4. 3rd-Level-Support einbeziehen, der bei der Bearbeitung eines Rückstands von Incidents eines bestimmten Typs helfen kann (beispielsweise bei einem Rückstand von Incidents aufgrund eines fehlerhaften Druckers den Hersteller kontaktieren, um bei der Problemlösung zu unterstützen).

First Call Resolution – Die First-Call-Resolution-Rate zeigt, wie häufig Incidents durch technische 1st-Level-Support-Mitarbeiter bereits beim ersten Anruf gelöst werden. Zeitnahe Lösungen sind das Ergebnis gut geschulter Mitarbeiter mit ausreichender Erfahrung sowie Zugang zu Ressourcen und Wissen.

Durchschnittliche Kosten pro Incident/Aufwand für Incident-Behebung – Organisationen können entweder die durchschnittlichen Kosten pro bearbeitetem Incident oder den durchschnittlichen Aufwand zur Behebung jedes Incidents messen. Organisationen möchten diese Kosten minimieren und gleichzeitig Service Level Agreements einhalten sowie Kundenzufriedenheit sicherstellen. IT-Investitionen, die zu einer höheren geschäftlichen Verfügbarkeit führen, sollten einen positiven Return on Investment erzielen.

Durchschnittliche erste Reaktionszeit – Dieser KPI misst die durchschnittliche Zeit zwischen der Meldung eines Incidents durch einen Nutzer und der Reaktion des Service Desk auf den Incident. Wenn der Service Desk Incidents schnell beheben kann, es jedoch drei Stunden dauert, bis eine Antwort erfolgt, könnte die Organisation erwägen, mehr 1st-Level-Servicetechniker einzusetzen, um die Reaktionszeit zu verkürzen und entsprechend die Serviceverfügbarkeit zu erhöhen.

Anzahl wiederholter Incidents – Wiederholte oder erneut geöffnete Incidents sind für Ihre Organisation problematisch. Sie können bedeuten, dass Support-Techniker die Ursache eines Problems nicht identifiziert haben und es deshalb immer wieder auftritt. Vielleicht weiß das IT-Team, wie das Problem behoben werden kann, und die Nutzer könnten es tatsächlich selbst lösen, aber es stehen keine Ressourcen zur Verfügung, um Self-Service zu ermöglichen. Wiederholte Incidents lassen sich vermeiden, indem die Ursache eines Problems ermittelt und proaktiv mit Nutzern kommuniziert wird, damit sie das Problem lösen können, ohne es an die IT zu melden.

Rollen und Verantwortlichkeiten im Incident Management

Klar definierte Rollen und Verantwortlichkeiten sind entscheidend für die effektive Umsetzung des Incident-Management-Prozesses. Das Incident-Management-Team besteht aus folgenden Rollen:

Incident Manager

Der Incident Manager trägt die Hauptverantwortung dafür, den Incident-Management-Prozess voranzutreiben und kontinuierlich zu verbessern. In kleinen bis mittelgroßen Organisationen wird diese Rolle häufig dem Service Desk Manager zugewiesen; in größeren Organisationen kann sie als eigenständige Rolle definiert sein. Zu den wichtigsten Verantwortlichkeiten gehören: Teamführung, Berichterstattung von Key Performance Indicators (KPIs) an das Management, direkte Steuerung des First- und Second-Line-Supports, Verwaltung des Incident-Management-Systems und Durchsetzung des Incident-Management-Prozessablaufs.

First-Line-Support

First-Line-Service-Desk-Techniker sind die zentrale Anlaufstelle für Endnutzer, die Informationen suchen oder Serviceunterbrechungen melden. Sie sind hauptsächlich für den initialen Support und die Klassifizierung von Incidents sowie für den unmittelbaren Versuch verantwortlich, einen ausgefallenen Service so schnell wie möglich wiederherzustellen. Können sie den Incident nicht beheben, leitet der First-Line-Service-Desk-Techniker den Incident an geeignete Support-Mitarbeiter weiter, überwacht die Aktivitäten und hält die Nutzer über den Status ihres Incidents auf dem Laufenden.

Level-Two-Support

Second-Line-Support-Techniker verfügen in der Regel über weitergehende Kenntnisse als First-Line-Service-Desk-Techniker. Sie können für Incidents verantwortlich werden, die der First-Line-Support nicht lösen kann. Diese Techniker können mit externen Experten von Software- oder Hardwareanbietern zusammenarbeiten, um den normalen Service so schnell wie möglich wiederherzustellen.

Incident-Management-KPIs

Messungen sind in allen Phasen des ITIL-Lebenszyklus wichtig. Jeder Prozess verfügt über Kennzahlen, die überwacht und berichtet werden sollten, um die Gesamtleistung effektiv zu bewerten. Continuous Service Improvement erfordert, dass die Leistung jedes Prozesses gemessen wird, um verbesserungsbedürftige Bereiche zu identifizieren.

Typische Incident-Management-Kennzahlen sind:

• Gesamtzahl gemeldeter Incidents (nach Kategorie, Priorität, Person, Organisationseinheit usw.)
• Status von Incidents
• Zeit zwischen Erstellung und Lösung eines Incidents
• Incidents und SLA (eingehalten, verletzt)
• Durchschnittliche Kosten pro Incident
• Wiedereröffnungsrate
• Ohne Eskalation bearbeitete Incidents
• First Call Resolution
• Configuration Items mit wiederkehrenden Incidents
• Incidents nach Tageszeit

KPIs sollten mit Critical Success Factors (CSF) verknüpft sein, und CSFs sollten mit Zielen verknüpft sein. Diese Beziehung unterstützt Entscheidungen zur Aufrechterhaltung des aktuellen Zustands und zur Verbesserung in Richtung des gewünschten Zustands. Auch wenn jede Organisation unterschiedlich ist, helfen relevante Berichte für Nutzer, Mitarbeiter und Management dabei, wichtige Entscheidungen zu unterstützen, mit denen sowohl Prozesse als auch das Unternehmen insgesamt verbessert werden können.

Best Practices für die Implementierung von Incident Management

Die Einführung des ITIL-Frameworks in einem Unternehmen kann eine anspruchsvolle Aufgabe sein. Wie bei jedem ITIL-Prozess erfordert auch die Implementierung von Incident Management Unterstützung aus dem Business. Besonders wichtig ist es, die Zustimmung von Führungskräften und dem oberen Management zu gewinnen. Vor Beginn des Einführungsprozesses sollte mindestens eine Person für das übergreifende Projektmanagement und die Orchestrierung der Einhaltung von Best Practices für Incident Management zuständig sein. Ebenfalls äußerst hilfreich ist der Einsatz eines IT-Service-Management-Tools (ITSM), das Ihre aktuellen Prozesse und die Prozesse des gewünschten zukünftigen Zustands unterstützt, sowie eines Service Desk, der als primäre Schnittstelle zur IT-Abteilung dient.

1) Aktuellen Incident-Management-Prozess verstehen

Manchmal verfügt eine Organisation über keinen einheitlichen Prozess zur Bearbeitung von Incidents oder hat einen weniger ausgereiften Prozess im Einsatz. In jedem Fall ist es wichtig, den bestehenden Prozess so gut wie möglich abzubilden, um zu verstehen, was der aktuelle Service-Desk-Prozess bietet.

2) Langfristige Vision für den Incident-Management-Prozess identifizieren

Ebenso wichtig ist es zu verstehen, was die Organisation vom Incident-Management-Prozess erwartet. Die Erwartung kann auf generischen Incident-Management-Vorlagen basieren, die im ITSM-Tool enthalten sind, oder auf einem stärker angepassten Prozess, der auf den spezifischen Anforderungen der Organisation beruht.

3) Gap-Analyse durchführen

Identifizieren Sie als Nächstes, was zwischen dem aktuellen Incident-Management-Prozess der Organisation und ihrer langfristigen Vision für Incident Management angepasst werden muss. Dadurch erhalten Sie wertvolle Informationen zu Aufwand, Zeit, Kosten und Ressourcen, die erforderlich sind, um Ihre Incident-Management-Ziele und Ihre übergeordneten Serviceziele zu erreichen.

4) Implementierungs-Roadmap erstellen

Die Einführung jedes ITIL-Prozesses benötigt Zeit für die Entwicklung, und Sie benötigen eine Roadmap, um Erwartungen im Management zu steuern. Nutzen Sie diese Roadmap, um die erforderlichen Aktivitäten, Zeitrahmen und Aufwände zu beschreiben. Sie sollte Quick Wins, Tool-Implementierung, Prozessänderungen, Befähigung von Mitarbeitenden und Organisation, Kommunikationspläne sowie übergreifende Governance-Änderungen enthalten.

5) Projektimplementierung starten

Nun kann die Implementierung beginnen. Erstellen Sie einen Projektplan, der die Maßnahmen oder Aufgaben, Verantwortlichkeiten und den Zeitplan für die Erledigung aller Aufgaben definiert. Kommunizieren Sie die Erfolge auf dem Weg, sobald Sie Meilensteine erreichen, und zeigen Sie so Ihren Fortschritt in Richtung des endgültigen Implementierungsziels.

Funktions-Checkliste für Incident-Management-Software

Für IT-Organisationen, die Incident-Management-Software und/oder IT-Service-Management-Suiten mit Incident-Management-Funktionen evaluieren, ist es wichtig zu verstehen, welche Arten von Funktionen zur Unterstützung zentraler Prozesse erforderlich sind. Incident-Management-Software sollte mindestens die folgenden Funktionen bieten:

• Incident Records erstellen, ändern, lösen und schließen
• Eindeutige Datensatznummern generieren, die jedem Incident Record zugeordnet sind
• Incidents mit Problem Records, Knowledge-Artikeln, bekannten Workarounds und Requests for Change verknüpfen
• Configuration-Management-Daten mit dem Incident Record verknüpfen
• Incident Owner benachrichtigen, wenn das zugehörige Problem gelöst ist
• Historische Daten automatisch in einem Audit-Log erfassen
• Konfigurierbare Incident-Kategorisierung
• Such- und Reporting-Funktionen für Incidents
• Incidents basierend auf Ressourcenverfügbarkeit, Zeitzonen, Standorten usw. weiterleiten
• Incidents basierend auf Kategorisierung priorisieren, zuweisen und eskalieren; Eskalation basierend auf Priorität oder anderer Kategorisierung
• Integration mit Event-Monitoring-Lösungen mit der Möglichkeit, Incidents automatisch zu erstellen, zu aktualisieren und zu schließen
• Flexible Feldkonfigurationen einschließlich Freitext, Dropdown, Datum/Uhrzeit, Anhänge, Bildschirmaufnahmen
• Incidents mit Kundendaten verknüpfen
• Knowledge-Base-Lösungen/Skripte für Diagnose und Lösung nutzen
• Incidents oder zugehörige Aufgaben externen Service Providern zuweisen
• Incidents mehreren Bearbeitern zuweisen
• Aus einem Incident Record ein Problem oder einen Request for Change erstellen
• Automatisierte Incident-Benachrichtigungen (an IT-Mitarbeiter und/oder Endnutzer) basierend auf Fristen, SLAs, Abschluss und anderen Aktivitäten
• Incident Records mit SLAs verknüpfen
• Feedback von Endnutzern über eine Kundenzufriedenheitsumfrage erfassen
• Einen Incident im Namen einer anderen Person initiieren
• SLA-Uhr-Funktion anhalten, um einen Incident zurückzustellen
• Zwischen einem Incident und einem Service Request unterscheiden
• Gelösten Incident reaktivieren
• Priorität automatisch anhand von Auswirkung und Dringlichkeit bestimmen
• Integration mit Telefonie-/ACD-Systemen, um Kundeninformationen anhand der Anrufer-ID vorab auszufüllen