Ablaufdiagramm Incident-Management-Prozess (ITIL)
Ablaufdiagramm für den Incident-Management-Prozess: Erfassung, Priorisierung, Eskalation von Major Incidents, SLA-Verletzung, Lösung und Abschluss über vier Swimlanes.
So funktioniert es
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.
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.
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.
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.
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.
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.