So erstellen Sie einen Incident-Management-Prozess

So funktioniert es

1. Schreiben Sie die Prioritätsmatrix vor dem Diagramm

   Priorität ergibt sich aus Auswirkung und Dringlichkeit, und beide brauchen benannte Stufen: wie viele Nutzer, welche Serviceklasse, ob Geld oder Sicherheit im Spiel ist, wie schnell der Schaden wächst, ob ein Workaround trägt. Stimmen Sie das zuerst ab, denn eine beim Modellieren erfundene Matrix beschreibt den letzten Vorfall und nicht den nächsten.

2. Legen Sie fest, was ein Major Incident wirklich ändert

   Listen Sie auf, was die Ausrufung einbringt: einen benannten Verantwortlichen, eine Bridge, Updates nach festem Takt, die Erlaubnis, die normale Änderungsfreigabe zu umgehen. Ändert sich nichts außer dem Etikett, ist der Zweig Dekoration. Das Beispiel verwendet zwei ganze Schritte darauf, und das ist der ehrliche Aufwand, der dahintersteckt.

3. Tippen Sie Erfassung und Einstufung als Zeilen

   Jede Zeile in QueryChart ist ein Kasten. Tragen Sie den Auslöser in die Spalte Boxtext ein, dann den Erfassungsschritt, dann den Einstufungsschritt, und zeigen Sie mit jeder Zeile in der Spalte Linie zu auf die nächste. Nach drei Zeilen hat die Karte ihr Argument vorgebracht: Die Priorität in Zeile 3 wird aus dem berechnet, was Zeile 2 erfasst hat — und damit ist Zeile 2 eine Gestaltungsentscheidung und kein Formular.

4. Verzweigen Sie die Schweregrad-Frage und beschriften Sie beide Ausgänge

   Ändern Sie die Spalte Form der Einstufungszeile auf Entscheidung, listen Sie beide Ziele in Linie zu und geben Sie dann jeder Nummer ihre Antwort im Linientext. Das Diagramm verzweigt einmal, bei „Major Incident?“, obwohl die Matrix vier oder fünf Stufen hat — und diese zwei Beschriftungen leisten mehr als jedes andere Paar hier, weil sie die einzige Stelle sind, an der sich der Weg ändert.

5. Richten Sie den Wiedereröffnungsweg auf eine kleinere Zeilennummer

   Eine Behebung, die der Melder ablehnt, geht zurück in die Diagnose: Der Ausgang „Wiedereröffnet“ aus Zeile 15 zeigt auf Zeile 7. Ein falsch gesetzter Schweregrad braucht dieselbe Behandlung, und das Beispiel zeichnet sie nicht — ergänzen Sie einen Zweig von den Diagnosezeilen zurück zu „Kategorisieren und Priorität setzen“. Jeder davon ist eine kleinere Nummer in der Spalte Linie zu.

6. Kalibrieren Sie die Matrix und benennen Sie, wer ausruft

   Legen Sie die Matrix dorthin, wo die Person, die das Ticket erfasst, sie lesen kann, und testen Sie sie: Geben Sie zwei Personen aus verschiedenen Schichten dieselben drei Beschreibungen und vergleichen Sie, was sie setzen. Uneinigkeit heißt fehlende Stufe, nicht unaufmerksame Kollegin. Benennen Sie dann pro Schicht die Person, die bei „Major Incident?“ mit Ja antworten darf, bevor der Incident Manager wach ist.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Incident und Problem?

Ein Incident ist eine Unterbrechung eines Service; ein Problem ist die zugrunde liegende Ursache eines oder mehrerer Incidents. Sie werden als getrennte Prozesse geführt, weil sie auf unterschiedlichen Uhren laufen: Incident Management wird an der Zeit bis zur Wiederherstellung gemessen, Problem Management daran, ob die Ursache tatsächlich beseitigt wurde — und das kann Wochen dauern. Beides zu verschmelzen bedeutet, dass die Ursachenarbeit die Dringlichkeit des Incidents erbt und in dem Moment abgebrochen wird, in dem der Service zurück ist.

Wie wird die Priorität eines Incidents bestimmt?

Aus Auswirkung und Dringlichkeit nach einer veröffentlichten Matrix, nicht danach, wer fragt. Auswirkung ist, wie viel der Organisation betroffen ist: Nutzer, Standorte, Serviceklasse, ob Geld oder Sicherheit im Spiel ist. Dringlichkeit ist, wie schnell der Schaden wächst und ob ein Workaround trägt. Die Matrix macht aus diesem Paar eine Priorität, und sie verdient ihren Platz nur, wenn die Zahlen hinter der Einschätzung mit festgehalten werden — eine Priorität, die niemand nachvollziehen kann, lässt sich nicht bestreiten, wenn sie sich als falsch erweist.

Wann wird ein Vorfall zum Major Incident erklärt?

Wenn er eine vorab abgestimmte Schwelle überschreitet — ein Service der höchsten Klasse ausgefallen, eine festgelegte Zahl arbeitsunfähiger Personen, regulatorische oder sicherheitsrelevante Betroffenheit, ein vermuteter Datenschutzvorfall. Die Ausrufung verdient ihren Platz nur, wenn sie Verhalten ändert: ein benannter Incident Manager, eine Bridge, Updates in festem Takt. Zu spät auszurufen ist der verbreitete Fehler, und die Kosten des Ausrufens mit anschließender Entwarnung liegen weit unter den Kosten einer stillen Stunde.

Sollte ein wiedereröffneter Incident ein neues Ticket sein?

Nein — eröffnen Sie das ursprüngliche wieder, denn die beiden Datensätze beantworten verschiedene Fragen. Ein neues Ticket setzt die Lösungsuhr zurück und meldet eine gescheiterte Behebung als zwei erfolgreiche, und genau diese Verzerrung verbirgt einen instabilen Service. Auf demselben Datensatz wiederzueröffnen hält die Historie an einer Stelle und macht die Wiedereröffnungsrate messbar — und die Wiedereröffnungsrate ist das ehrlichste Qualitätssignal, das ein Incident-Prozess erzeugt.