Ablaufdiagramm Incident-Management-Prozess (ITIL)

Was ist ablaufdiagramm incident-management-prozess (itil)?

Incident Management ist der Prozess, der einen gestörten Service so schnell wie möglich wiederherstellt. Sein Ziel ist bewusst eng gefasst: Die Nutzerin oder der Nutzer soll wieder arbeiten können. Die zugrunde liegende Ursache dauerhaft zu beseitigen, ist Aufgabe des Problem Managements: Dieser Prozess übergibt dorthin, statt die Aufgabe zu übernehmen. Genau diese Grenze verhindert, dass ein Service Desk Tickets wochenlang offen hält, während jemand einer Ursache nachgeht.

Die meisten Incident-Prozesse scheitern an den Übergaben, nicht an der Technik. Ein Ticket wird ohne ausreichende Angaben zur Auswirkung erfasst und lässt sich nicht priorisieren. Ein Major Incident wird zwanzig Minuten zu spät erkannt, weil niemand den Auslöser vorher festgelegt hat. Eine Eskalation an den Second Level bleibt liegen, weil sie niemand annimmt. Ein SLA-Ziel wird gerissen, und der Kunde erfährt es hinterher statt vorher. Ein Ticket wird auf Zuruf der Technik geschlossen, ohne dass der Nutzer bestätigt hat, dass der Service wirklich läuft. Als Swimlane-Diagramm gezeichnet, wird jede dieser Übergaben sichtbar und bekommt einen Verantwortlichen.

Diese Vorlage bildet den Ablauf über vier Bahnen ab: Melder / Nutzer, Service Desk, Incident Manager und Support Level 2 / 3. Sie enthält die beiden Zweige, die in der Dokumentation am häufigsten fehlen (das Ausrufen eines Major Incidents und die Eskalation bei drohender SLA-Verletzung), dazu eine Schleife für den Fall, dass der Nutzer die Störung weiterhin sieht, und einen Abschlusszweig, der bei unbekannter Ursache einen Problem-Datensatz anlegt.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Vier Swimlanes mit benannter Verantwortung für jeden Schritt (Melder / Nutzer, Service Desk, Incident Manager und Support Level 2 / 3) über fünf Phasen von der Erkennung bis zum Abschluss.
• Erkennen und Erfassen: „Incident erkannt oder gemeldet“ führt in „Incident mit Auswirkung erfassen“, noch bevor die Triage beginnt, damit das Ticket betroffenen Service, Umfang und Symptome trägt.
• Kategorisieren und Priorität setzen mit der anschließenden Entscheidung „Major Incident?“, deren Ja-Zweig über „Major Incident ausrufen“ und „Bridge öffnen, Stakeholder informieren“ in der Bahn des Incident Managers läuft, bevor er wieder auf die technische Arbeit trifft.
• Die Trennung zwischen First Level und Eskalation: „Im First Level gelöst?“ führt entweder zu „First-Level-Lösung anwenden“ oder übergibt das Ticket an Support Level 2 / 3 zu „Untersuchen und diagnostizieren“.
• Der SLA-Pfad: „Lösung innerhalb des SLA-Ziels?“ leitet ein Nein auf „SLA-Verletzung eskalieren und informieren“, sodass der Kunde vor Ablauf der Frist informiert wird, und kehrt danach auf „Lösung umsetzen, Service wiederherstellen“ zurück.
• Bestätigung durch den Nutzer und Abschluss: eine Wiedereröffnungsschleife von „Nutzer bestätigt die Lösung?“ zurück zur Erstdiagnose sowie die Entscheidung „Ursache weiterhin unbekannt?“, die vor „Incident geschlossen“ einen Problem-Datensatz anlegt.

Wann Sie diese Vorlage verwenden sollten

• Sie schreiben oder überarbeiten das Runbook Ihres Service Desks, damit neue Mitarbeitende sehen, wohin ein Ticket läuft und wer welche Stufe verantwortet.
• Sie legen den Auslöser für einen Major Incident und die Eskalationszeiten vorab fest, statt sie während einer Störung zu improvisieren.
• Sie konfigurieren ein ITSM-Werkzeug: Kategorien, Prioritätsmatrix, SLA-Timer und Eskalationsregeln aus dem Diagramm entsprechen genau den Feldern, die Sie dort einrichten müssen.
• Sie wollen ein kleines Team an ITIL ausrichten, ohne das vollständige Vokabular einzuführen, und brauchen Schrittbezeichnungen, die Ihre Leute im Alltag tatsächlich verwenden.
• Sie führen ein Post-Incident-Review über den Prozess selbst und wollen nachvollziehen, an welcher Stelle ein konkretes Ticket vom vorgesehenen Weg abgewichen ist.

So funktioniert es

1. Benennen Sie die Bahnen nach Ihren echten Rollen

   Ersetzen Sie Melder / Nutzer, Service Desk, Incident Manager und Support Level 2 / 3 durch die Rollen, die es in Ihrer Organisation gibt. Kleine Teams führen den Incident Manager häufig mit dem Service Desk zusammen; Organisationen mit einem NOC ergänzen oberhalb des Melders eine Bahn für die Überwachung.

2. Definieren Sie Ihre Prioritätsmatrix

   Hinterlegen Sie Ihre Definitionen von Auswirkung und Dringlichkeit am Schritt „Kategorisieren und Priorität setzen“. Halten Sie schriftlich fest, was P1 bis P4 in Bezug auf betroffene Nutzer und Geschäftsauswirkung bedeuten, damit die Priorität hergeleitet und nicht je Ticket ausgehandelt wird.

3. Legen Sie den Auslöser für einen Major Incident fest

   Entscheiden Sie, wann die Entscheidung „Major Incident?“ mit Ja beantwortet wird: ein umsatzrelevanter Service steht, ein namentlich benanntes kritisches System fällt aus, eine Schwelle betroffener Kunden ist überschritten. Benennen Sie, wer ausrufen darf und was unmittelbar danach passiert: etwa eine Bridge öffnen und einen festen Update-Takt starten.

4. Verdrahten Sie Ihre SLA-Ziele und die Eskalation bei Verletzung

   Tragen Sie Ihre Reaktions- und Lösungsziele an der Entscheidung „Lösung innerhalb des SLA-Ziels?“ ein und halten Sie fest, wer im Eskalationszweig informiert wird und wie weit vor Fristablauf. Der Zweig dient der Frühwarnung, nicht der nachträglichen Berichterstattung.

5. Vereinbaren Sie die Regeln für Abschluss und Problem Management

   Definieren Sie, was als Bestätigung durch den Nutzer gilt, wie lange ein Ticket im Status „gelöst“ bleibt, bevor es automatisch schließt, und nach welchen Kriterien „Ursache weiterhin unbekannt?“ einen Incident ins Problem Management überführt. Übliche Auslöser sind wiederkehrende Symptome und jeder Major Incident.

6. Gehen Sie das Diagramm je Bahn durch und veröffentlichen Sie eine versionierte Fassung

   Besprechen Sie das Diagramm mit den Personen in jeder Bahn und korrigieren Sie die Schritte, die sie tatsächlich ausführen. Sobald es abgestimmt ist, veröffentlichen Sie es mit einer Freigabe als gültige Fassung, damit später nachvollziehbar bleibt, welche Revision in Kraft war.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Incident Management und Problem Management?

Incident Management stellt den Service wieder her. Problem Management beseitigt die Ursache, damit der Incident nicht erneut auftritt. Beide laufen auf unterschiedlichen Uhren: Ein Incident wird an einem SLA in Minuten oder Stunden gemessen, ein Problem-Datensatz kann wochenlang in der Untersuchung bleiben. In diesem Diagramm treffen sich beide beim Abschluss, wo „Ursache weiterhin unbekannt?“ einen Problem-Datensatz anlegt, ohne den Incident offen zu halten. Beides zu vermischen ist der häufigste Fehler: erkennbar an Tickets, die noch lange offen sind, nachdem der Nutzer längst wieder arbeitet.

Wann sollte ein Incident zum Major Incident erklärt werden?

Wenn die Auswirkung es rechtfertigt, die normale Warteschlange zu durchbrechen: Ein geschäftskritischer Service ist nicht verfügbar, eine große Nutzergruppe ist blockiert, oder es besteht ein Risiko für Sicherheit, Finanzen oder Reputation. Der Auslöser sollte aufgeschrieben sein, bevor Sie ihn brauchen, und objektiv genug, dass ihn eine First-Level-Kraft um zwei Uhr nachts anwenden kann. Nach dem Ausrufen ändert der Prozess seine Form, er wird nicht bloß schneller: Ein benannter Incident Manager übernimmt, eine Bridge wird geöffnet, und Stakeholder-Updates gehen nach festem Zeitplan hinaus, auch dann, wenn es nichts Neues gibt.

Was passiert, wenn ein Incident sein SLA-Ziel zu reißen droht?

Der Eskalationszweig ist eine hierarchische Eskalation, keine technische. Die Arbeit läuft weiter, aber der Incident Manager wird hinzugezogen, um die Erwartungen mit dem Kunden neu zu setzen, bei Bedarf Ressourcen umzuverteilen und zu dokumentieren, warum das Ziel verfehlt wird. Entscheidend ist der Zeitpunkt: Der Zweig soll vor Ablauf der Frist auslösen, etwa bei 75 Prozent der verbleibenden Zeit, damit das Gespräch mit dem Kunden vor der Verletzung stattfindet und nicht als Entschuldigung danach.

Wer schließt den Incident, und was gilt als gelöst?

Lösung und Abschluss sind zwei verschiedene Zustände. Die Technik setzt einen Incident auf gelöst, sobald die Behebung greift und der Service wieder läuft. Geschlossen wird er erst, wenn der Melder bestätigt, dass der Service für ihn funktioniert. Deshalb führt dieses Diagramm über „Funktion des Service bestätigen“ in der Melder-Bahn und die Entscheidung „Nutzer bestätigt die Lösung?“, bevor es zum Abschluss kommt. Sagt der Nutzer, die Störung bestehe fort, wird dasselbe Ticket zur Erstdiagnose wiedereröffnet, statt ein neues anzulegen. Die meisten Teams setzen zusätzlich ein Auto-Close-Fenster von üblicherweise drei bis fünf Arbeitstagen ohne Rückmeldung.