Incident Management
Ticket- und Eskalationsstandard für Störungen (P1–P3) mit stabiler Kommunikation und sauberem Abschluss.
Kurz erklärt
Diese Seite beschreibt den Arbeitsstandard für Incident Management – mit Fokus auf konkrete Entscheidungen statt allgemeiner Leitlinien.
Zentral sind hier vor allem severity-einstufung und wer informiert wen in welchem takt, damit Teams denselben Maßstab anwenden.
Nachvollziehbar wird der Standard erst durch verlinkte Nachweise wie incident-timeline und durch dokumentierte Grenzfälle/Ausnahmen.
Wann diese Seite hilft
Typische Situationen, in denen diese Seite als Arbeitsdokument Mehrwert bringt – und wo eine andere Doku passender ist.
Typische Einsätze
- wenn für Incident Management ein organisationsweiter Standard mit klaren Grenzen zu schweregrade und eskalationswege festgelegt werden soll
- wenn Entscheidungen zu severity-einstufung zwischen Teams aktuell unterschiedlich getroffen werden
- wenn Audit oder internes Review konkrete Nachweise wie incident-timeline einfordert
- wenn Ausnahmen im Bereich „Regeln & Verantwortung“ häufiger werden und sauber befristet/regelt werden müssen
Eher nicht passend bei
- wenn es bei Incident Management nur um einen einmaligen Einzelfall ohne Standardisierungsbedarf geht
- wenn ein detailliertes Projektticket oder eine technische Schritt-für-Schritt-Anleitung gepflegt werden soll
Empfohlener Ablauf
Pragmatische Reihenfolge, die in der Praxis funktioniert – vom Scope bis zum Review.
- Anwendungsbereich für Incident Management fachlich und organisatorisch festziehen; Scope-Lücken vermeiden (insb. schweregrade und eskalationswege).
- Standardentscheidungen definieren: Severity-Einstufung und wer informiert wen in welchem Takt – inklusive zuständiger Rollen.
- Ausnahmen mit Kriterien, Fristen und Re-Review modellieren; häufige Grenzfälle zu erstreaktion, kommunikation und statusupdates explizit abfangen.
- Nachweise im Regelprozess verankern (mindestens incident-timeline und statuskommunikation / verteiler).
- Prüfung anhand realer Abweichungen fahren und Stolperfallen wie „Severity wird zu spät angepasst“ in die Regel zurückspiegeln.
Entscheidungsregeln
Incident Management ist gut dokumentiert, wenn Regeln, Grenzfälle und Nachweise so konkret sind, dass Teams damit ohne Zusatzabsprachen arbeiten können.
Entscheidungsrahmen
Für Incident Management zuerst den Anwendungsbereich konkret machen: Schweregrade und Eskalationswege.
Verantwortung
Entscheidungen zu severity-einstufung und wer informiert wen in welchem takt nicht implizit lassen, sondern Rollen und Freigaben explizit benennen.
Abweichungsregeln
Ausnahmen nur zulassen, wenn sie den Standard nicht aufweichen; besonders relevant sind hier erstreaktion, kommunikation und statusupdates.
Review-Auslöser
Prüfbar ist die Regel erst, wenn incident-timeline und statuskommunikation / verteiler sauber verlinkt sind.
Was dokumentiert werden soll
Hier nur die spezifischen Inhalte zu Incident Management pflegen; allgemeine Doku-Regeln bleiben in der zentralen Leitlinie. Zentrale Leitlinie.
Die Seite ist dann gut, wenn eine Vertretung den Standard anwenden oder prüfen kann, ohne erst Personenwissen einsammeln zu müssen.
Kontext
Begriffe, Scope und Grenzen zu Incident Management konkretisieren – inklusive schweregrade und eskalationswege.
Umsetzungsvorgaben
Den Standard so notieren, dass severity-einstufung und wann ein incident geschlossen werden darf eindeutig entschieden sind.
Prüfpfad
Artefakte direkt nennen und verlinken: Incident-Timeline, Statuskommunikation / Verteiler, Root-Cause- und Maßnahmennachweise.
Offene Punkte / Ausnahmen
Aktive Ausnahmen, letzte Änderung und nächster Review gehören auf die Seite – besonders bei Themen mit erstreaktion, kommunikation und statusupdates.
Typische Stolperfallen
Pflege hier echte Fallstricke aus der Praxis von Incident Management; allgemeine Hinweise gehören in die zentrale Leitlinie. Zentrale Leitlinie.
- Umfang driftet: Severity wird zu spät angepasst.
- Regel bleibt abstrakt: Statusupdates fehlen in langen Störungen.
- Nachweis fehlt: Incident wird geschlossen ohne klare Restpunkte.
- Ausnahme entgleist: Standard bleibt abstrakt ohne Anwendungsbezug.
Prüfung & Pflege
Prüfe diese Seite gegen reale Vorgänge zu Incident Management – nicht nur gegen den Wortlaut. Entscheidend ist, ob Standard, Ausnahmen und Nachweise im Alltag tragen.
- Passt die Einstufung zum tatsächlichen Impact?
- Waren Reaktions- und Updatezeiten eingehalten?
- Sind Folgemaßnahmen einem Owner zugeordnet?
- Ist der Scope noch korrekt?
Prüf-Fokus für „Incident Management“: Regeln & Verantwortung; prüfe dabei insbesondere schweregrade und eskalationswege.
Sinnvolle Kennzahlen
Wenige Kennzahlen genügen – wichtig ist, dass sie Entscheidungen oder Verbesserungen auslösen.
Für „Incident Management“ Kennzahlen direkt an severity-einstufung und die häufigsten Praxisrisiken koppeln.
MTTA
Zeit bis zur ersten qualifizierten Reaktion
Intervall: monatlich
MTTR
Zeit bis zur Wiederherstellung des Dienstes
Intervall: monatlich
Postmortem-Abschlussquote
Anteil Incidents mit abgeschlossenem Nachgang
Intervall: quartalsweise
Nächste Schritte
Ergänze jetzt die konkrete Entscheidung zu severity-einstufung inkl. Verantwortlichen, Datum und Verweis auf incident-timeline.
Auf „Incident Management“ als Nächstes besonders klar machen: welche schweregrade und eskalationswege im Standardfall gelten und welche Ausnahmen befristet sind.