Das Incident Management befasst sich mit allen Vorfällen, die die vereinbarte Qualität eines IT-Services und damit seinen geschäftlichen Nutzen beeinträchtigen, aktuell stören oder demnächst stören können. Sein oberstes Ziel ist es, die vereinbarte Servicequalität möglichst schnell wieder zur Verfügung zu stellen.

Das Incident-Management befasst sich mit allen drohenden oder bereits eingetretenen Beeinträchtigungen eines IT-Services aus Sicht seiner Nutzer.

Der Incident-Management-Prozess wird angestoßen durch Ereignisse aus der Betriebsüberwachung der IT-Infrastruktur und der Applikationen (siehe Event-Management) oder durch Störungsmeldungen der Nutzer eines IT-Services am IT-Service-Desk.

Nicht jeder Nutzerkontakt zum IT-Service-Desk beinhaltet notwendigerweise eine Störungsmeldung; der Nutzer kann auch Informationen abfragen oder Serviceaufträge erteilen. Im letzteren Fall wird der Prozess Request-Fulfilment angestoßen.

Es gehört nicht zu den Aufgaben des Incident-Managements, die Ursache einer Betriebsstörung zu finden und zu beseitigen. Sein Auftrag ist erledigt, sobald der Service dem Nutzer wieder in der zugesagten Qualität zur Verfügung steht. Um die Ursachenanalyse und -beseitigung häufig auftretender Betriebsstörungen kümmert sich das Problem Management.

Die Geschäftsprozesse der Universität werden möglichst wenig und möglichst kurzzeitig durch Unregelmäßigkeiten ihrer IT-Unterstützung beeinträchtigt.

Reaktionszeit:

Reaktionszeit heißt die Zeitspanne vom Eingang und der Erfassung eines Incidents bis zum ersten Kontakt des Bearbeiters (Incident-Handler) mit dem Nutzer. Sie ist in der Dienstleistungsvereinbarung festgelegt. Nach Ablauf der Reaktionszeit erfolgt eine Eskalation.

Lösungszeit:

Lösungszeit heißt die Zeitspanne vom Beginn der Bearbeitung bis zur Wiederherstellung des Services gemäß Dienstleistungsvereinbarung (SLA, Attribut 9). Wird die Lösungszeit nicht eingehalten, erfolgt eine Eskalation.

Rollen:

Rollen werden innerhalb von ITIL V3 verwendet, um Verantwortlichkeiten festzulegen. Insbesondere werde sie dazu genutzt, Prozessverantwortliche für die unterschiedlichen ITIL-V3-Prozesse zu bestimmen; daneben illustrieren sie Verantwortlichkeiten für einzelne Aktivitäten innerhalb von Arbeitsabläufe.

Rolle 1^st-Level-Support:

Der Bearbeiter im 1^st-Level-Support sorgt bei eingehenden Störungsmeldungen für die Registrierung und Einordnung und unternimmt einen unmittelbaren Lösungsversuch zur schnellstmöglichen Wiederherstellung des definierten Betriebszustands eines Service.
Ist ihm die Wiederherstellung des Service nicht möglich, leitet er die Störungsmeldung an die spezifische Bearbeitergruppe im 2^nd-Level-Support weiter.

Rolle 2^nd-Level-Support:

Der Bearbeiter im 2^nd-Level-Support übernimmt Störungsmeldungen vom 1st Level Support, die dieser nicht selbständig lösen konnte. Bei Bedarf wird er Unterstützung von Herstellern (3^rd-Level-Support) anfordern. Auch sein Ziel ist die schnellstmögliche Wiederherstellung des definierten Betriebszustands eines Service. Ist keine ursächliche Störungsbeseitigung möglich, übergibt er die Störung zur weiteren Bearbeitung an das Problem-Management.

Rolle 3^rd-Level-Support:

Der Bearbeiter im 3^rd-Level-Support ist typischerweise bei einem Hersteller von Hardware- oder Softwareprodukten angesiedelt; er wird vom 2^nd-Level-Support mit einbezogen, wenn dies zur Beseitigung von Störungen erforderlich ist. Ziel ist die schnellstmögliche Wiederherstellung des definierten Betriebszustands eines Service.

Rolle Incident-Manager:

Der Incident-Manager ist verantwortlich für die effektive Durchführung des Prozesses „Incident-Management“ und das entsprechende Berichtswesen. Er ist die erste Eskalationsstufe für Incidents, die nicht innerhalb des vereinbarten Service-Levels gelöst werden können.

Aufnahme:

Formale Aufnahme der Störungsmeldung durch den Service-Desk. Der Auslöser einer Störungsmeldung ist entweder ein Ereignis aus der Betriebsüberwachung (siehe Event-Management) oder ein Hinweis eines Nutzers per E-Mail oder Telefon.

Kategorisierung:

Liegt eine Service-Störung vor (Verletzung des SLA) oder handelt es sich um einen Service-Request? Liegt eine SLA-Verletzung vor, die durch den First Level oder den Second Level bearbeitet wird oder liegt ein Major Incident vor?

Service-Request:

Auftrag zu einer Systemänderung oder einer Konfigurationsänderung (Beispiel: Einrichten einer Benutzerkennung, Einrichten eines Gruppenlaufwerks, Einrichten einer Web-Seite). Abhängig von der Art des Auftrags wird dieser der entsprechenden Supporteinheit zum Abarbeiten übermittelt.

First-Level-Support:

Im First-Level-Support werden einfache SLA-Verletzungen bearbeitet. Der Mitarbeiter am Service Desk kann eine solche Störung ohne weitere Hilfe auf Basis der ihm vorliegenden Informationen und Hilfsmittel beheben. 

Second-Level-Support:

Im Second-Level-Support werden Störungen bearbeitet, die nicht durch den First Level Support behoben werden können. Die Mitarbeiter im Second Level sind Spezialisten für bestimmte technische Themen und Systeme. Sie entscheiden, ob zusätzlich ein externer Support hinzugezogen werden muss, ob ein Problem besteht und ob die Störung ursächlich nur durch eine grundlegende Veränderung (per Request for Change) behoben werden kann.

Major-Incident:

Ein Major-Incident besteht, wenn eine große Anzahl von Nutzern durch eine SLA-Verletzung betroffen ist und dadurch die Arbeit der Organisation gestört ist.

Wie jeder Prozess wird auch das Incident-Management laufend anhand seiner Prozesskennzahlen bewertet und verbessert. Aktuell orientieren sich die IT-Dienste an diesen Kennzahlen:

Lösungsdauer:

Durchschnittliche Zeit vom Eingang einer Störungsmeldung bis zur Wiederherstellung des gestörten Service.

Lösungsqualität:

Quote der Störungen, die innerhalb der in der Dienstleistungsvereinbarung festgelegten Zeit behoben wurden.

Lösungsquote 1^st-Level:

Quote der Incidents, die im 1^st-Level-Support gelöst wurden.