Ablaufdiagramm Incident-Management-Prozess (ITIL) — Excel
Der Incident-Management-Prozess ist die Abfolge, mit der ein Service-Team einen gestörten IT-Service wiederherstellt: Incident erkennen und erfassen, priorisieren, diagnostizieren und eskalieren, lösen und wiederherstellen, mit dem…
Erfassen Sie in Excel einen Schritt pro Zeile mit eindeutiger Kennung, Beschreibung, Folgeschritt und verantwortlicher Rolle. Der Incident-Management-Prozess ist die Abfolge, mit der ein Service-Team einen gestörten IT-Service wiederherstellt: Incident erkennen und erfassen, priorisieren, diagnostizieren und eskalieren, lösen und wiederherstellen, mit dem Nutzer bestätigen und anschließend schließen.
Kurz gesagt
- 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 Quelldaten: Ablaufdiagramm Incident-Management-Prozess (ITIL)
Erfassen Sie in Excel einen Schritt pro Zeile mit eindeutiger Kennung, Beschreibung, Folgeschritt und verantwortlicher Rolle. 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.
Ordnen Sie die Beschreibung Box text, das Ziel Line to, den Zweigtext Line text und die Zuständigkeit Vertical lane zu. 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. Prüfen Sie alle Zweige und Zuständigkeiten im Diagramm anhand der Tabelle. Siehe auch /de/guides/excel-daten-fur-ein-flussdiagramm-strukturieren.
So funktioniert es
Benennen Sie die Bahnen nach Ihren echten Rollen
Erfassen Sie in Excel einen Schritt pro Zeile mit eindeutiger Kennung, Beschreibung, Folgeschritt und verantwortlicher Rolle. 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
Ordnen Sie die Beschreibung Box text, das Ziel Line to, den Zweigtext Line text und die Zuständigkeit Vertical lane zu. 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
Verfolgen Sie den Normalweg, Ablehnungen und Rücksprünge im Diagramm, bevor Sie es weitergeben. 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.
Häufige Fehler
Fehlende Verbindungen
Eine Aufgabenliste ist erst dann ein Prozessdiagramm, wenn jeder Schritt ein klares Ziel und jede Entscheidung benannte Ergebnisse hat. Sie schreiben oder überarbeiten das Runbook Ihres Service Desks, damit neue Mitarbeitende sehen, wohin ein Ticket läuft und wer welche Stufe verantwortet.
Häufig gestellte Fragen
Kann ich meine Excel-Datei verwenden?
Ja. Ordnen Sie die Spalten dem QueryChart-Tabelleneditor zu und prüfen Sie die Ziele nach Änderungen der Zeilen. 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.