Major Incident Management: War Room, Kommunikation und Eskalation

Wenn “einfach mal ein Ticket erstellen” nicht mehr reicht

Ein normaler Incident ist ein Ticket: Ticket auf, du oder jemand aus dem Team loest es, Ticket zu. Ein Major Incident ist etwas anderes. Das ERP-System der ganzen Firma ist down. Die Produktion steht still, weil das MES nicht mehr mit der SPS kommuniziert. Der Exchange-Server ist unerreichbar und 200 Mitarbeitende koennen keine Mails mehr senden. In diesen Momenten reicht der normale Ticketprozess nicht mehr aus – du brauchst eine andere Betriebsart: koordiniert, schnell, mit klaren Rollen und einer Kommunikation, die nicht im Chaos versinkt.

Major Incident Management (MIM) ist der Prozess, der genau das leistet. Er ist Teil von ITIL 4 (als eigene “Practice” innerhalb von Incident Management), aber die Konzepte – War Room, Incident Commander, Eskalationsstufen, Bridge Calls, Postmortem – sind praktisch industrieuebergreifend gleich, egal ob bei Google, Atlassian oder in einem Schweizer KMU mit 80 Mitarbeitenden.

Was macht einen Incident zum “Major Incident”?

Nicht jeder Ausfall ist ein Major Incident. Die Unterscheidung ist wichtig, weil ein MIM-Prozess Ressourcen bindet (mehrere Leute, Management-Aufmerksamkeit, oft auch externe Kommunikation) – den willst du nicht bei jedem defekten Drucker auslösen.

Trigger-Kriterien

Ein Incident wird typischerweise zum Major Incident erklaert, wenn mindestens eines dieser Kriterien zutrifft:

• Hoher Impact: Ein geschaeftskritischer Service ist komplett ausgefallen oder stark beeintraechtigt (nicht nur ein einzelner User).
• Breite Betroffenheit: Eine ganze Abteilung, ein Standort oder die gesamte Firma ist betroffen.
• Business-kritische Zeitfenster: Der Ausfall trifft auf Monatsabschluss, Lohnlauf, eine Produktionsschicht oder einen Kundentermin.
• Sicherheitsrelevanz: Verdacht auf Datenabfluss, Ransomware oder unautorisierten Zugriff (hier greift zusaetzlich euer Incident-Response-Plan, siehe unten verlinkt).
• Keine bekannte Loesung: Der Standard-Workaround aus der Wissensdatenbank funktioniert nicht, die Ursache ist unklar.
• Eskalationsdruck von aussen: Kunden, Lieferanten oder die Geschaeftsleitung melden sich bereits proaktiv.

Severity-Klassifizierung (SEV-Modell)

Die meisten Organisationen (Atlassian, PagerDuty, Google SRE) nutzen ein SEV-Schema, um Impact und Reaktionsgeschwindigkeit zu koppeln. Ein einfaches, KMU-taugliches Modell:

Der War-Room-Prozess

Sobald ein Incident als Major Incident klassifiziert ist, wird ein War Room (auch “Incident Bridge” oder “Situation Room”) eroeffnet – physisch oder, im hybriden Alltag, meist virtuell (Teams-Call, dedizierter Kanal). Der Zweck: Alle relevanten Personen an einem Ort, ein einziger Kommunikationsstrang, keine parallelen Slack-Threads mit widerspruechlichen Informationen.

Die Kernrollen

Ein sauber gefuehrter War Room hat klar getrennte Rollen. Das Muster stammt urspruenglich aus dem Feuerwehr-Einsatzwesen (Incident Command System) und wurde von Tech-Firmen wie Google und PagerDuty uebernommen.

Ablauf eines Major Incidents (Schritt fuer Schritt)

1. Erkennung        → Monitoring-Alert, User-Meldung oder Eskalation vom Service Desk
2. Klassifizierung   → SEV-Stufe festlegen, Major Incident erklaeren
3. War Room oeffnen  → Dedizierter Call/Kanal, Incident Commander benennen
4. Rollen zuweisen   → IC, Communications Lead, Ops Lead, Scribe
5. Erstkommunikation → Erste Stakeholder-Info innerhalb von 15 Min
6. Diagnose & Fix    → Parallelisierte Fehlersuche unter Führung des Ops Lead
7. Statuskadenz      → Regelmaessige Updates (siehe unten) bis zur Loesung
8. Wiederherstellung → Service laeuft, Verifikation durch Monitoring + User
9. Entwarnung        → Abschluss-Kommunikation an alle Stakeholder
10. Post Incident Review → Blameless Postmortem innerhalb von 3-5 Arbeitstagen

Ein zentraler Punkt: Der IC eroeffnet den War Room nicht erst, wenn “alles klar ist”, sondern sofort nach der Klassifizierung – auch wenn noch niemand weiss, was die Ursache ist. Der War Room ist der Ort, an dem man gemeinsam herausfindet, was los ist, nicht erst, wenn man es schon weiss.

Stakeholder-Kommunikationsplan

Die haeufigste Ursache fuer Frust bei Major Incidents ist nicht die technische Loesungszeit – es ist fehlende oder widerspruechliche Kommunikation. Ein Kommunikationsplan definiert im Voraus, wer wann worueber informiert wird.

Stakeholder-Matrix

Beispiel-Vorlage fuer eine Erstkommunikation

Betreff: [MAJOR INCIDENT] ERP-System nicht erreichbar - SEV1

Status: OFFEN
Beginn: 07.07.2026, 09:14 Uhr
Betroffen: Alle Standorte, ERP-System (Bestellungen, Lagerverwaltung)
Impact: Keine Auftragserfassung, Lager-Buchungen aktuell nicht moeglich
Workaround: Dringende Auftraege bitte manuell in Excel-Vorlage (Link) erfassen
Massnahmen: IT-Team analysiert Datenbankverbindung, externe Hotline
            beim ERP-Hersteller kontaktiert
Naechstes Update: 09:45 Uhr oder frueher bei neuen Erkenntnissen
Incident Commander: Max Muster, +41 79 xxx xx xx

Diese Struktur (Status, Beginn, Impact, Workaround, Massnahmen, naechstes Update, Verantwortlicher) sollte immer gleich bleiben – Empfaenger gewoehnen sich daran und finden die relevante Info sofort.

Bridge Calls und Statusupdate-Kadenz

Aufbau eines Bridge Calls

Ein Bridge Call (bei Microsoft Teams z. B. ein dauerhaft offenes Meeting mit Aufzeichnung) sollte eine klare Struktur haben, sonst wird er schnell zum unstrukturierten Stimmengewirr:

1. Rollen ansagen: IC begruesst kurz, benennt Communications Lead und Ops Lead, falls noch nicht geschehen.
2. Lagebild: Kurzer Ist-Stand in 2-3 Saetzen (kein Rueckblick auf die letzten 20 Minuten).
3. Parallelisierung: IC verteilt Arbeitsstraenge (“Team A prueft die Datenbank, Team B prueft das Netzwerk”) statt dass alle am selben Log schauen.
4. Stummschaltung: Wer gerade nicht aktiv beitraegt, bleibt stumm – Bridge Calls mit 15 offenen Mikrofonen sind unproduktiv.
5. Zeitbox: Alle 15-30 Minuten kurze Sync-Punkte statt Dauergespraech ohne Struktur.

Kadenz-Tabelle nach Schweregrad

Eskalationsstufen

Eskalation heisst nicht “Schuldzuweisung nach oben”, sondern zusaetzliche Ressourcen oder Entscheidungsbefugnis in den Prozess holen. Es gibt zwei Arten:

• Funktionale Eskalation: Du holst mehr Fachwissen dazu (Level-2/Level-3-Support, Hersteller-Hotline, externer Dienstleister).
• Hierarchische Eskalation: Du holst mehr Entscheidungsbefugnis dazu (IT-Leitung, Geschaeftsleitung), z. B. um ein Budget fuer Notfallmassnahmen freizugeben oder eine Produktionsschicht abzubrechen.

Eskalationsmatrix (Beispiel KMU)

Entscheidungsbaum: Eskalieren oder nicht?

Ist der Service komplett ausgefallen ODER
sind mehr als eine Abteilung/ein Standort betroffen?
│
├── NEIN → Normaler Ticketprozess, keine Eskalation noetig
│
└── JA → Ist die Ursache innerhalb 15-30 Min identifizierbar?
         │
         ├── JA → Team loest selbst, Stakeholder informieren
         │
         └── NEIN → Major Incident erklaeren, War Room eroeffnen
                     │
                     └── Laeuft die Loesungszeit ueber Schwellenwert (z. B. 2h)?
                         │
                         ├── NEIN → Weiter im War Room, Kadenz einhalten
                         │
                         └── JA → Hierarchische Eskalation an Geschaeftsleitung

Post Incident Review / Blameless Postmortem

Nach der Entwarnung ist die Arbeit nicht fertig – jetzt kommt der Teil, der oft weggelassen wird, obwohl er den groessten langfristigen Nutzen hat: der Post Incident Review (PIR), auch Postmortem genannt.

Warum “blameless”?

Google SRE hat das Konzept der blameless postmortems gepraegt: Der Bericht unterstellt allen Beteiligten, dass sie mit dem Wissen, das ihnen zum jeweiligen Zeitpunkt zur Verfuegung stand, die vernuenftigste Entscheidung getroffen haben. Ziel ist nicht “Wer hat das verbockt?”, sondern “Welche systemischen Faktoren haben dazu gefuehrt, dass dieser Fehler ueberhaupt moeglich war – und wie verhindern wir das strukturell?”

Der Grund ist pragmatisch: Wenn Mitarbeitende Angst vor Schuldzuweisungen haben, werden sie Vorfaelle spaeter melden, Details verschweigen oder Workarounds bauen, statt Ursachen zu beheben. Eine Kultur, die aus Fehlern lernen will, muss psychologische Sicherheit garantieren.

Ablauf und Inhalt eines PIR

Ein guter PIR entsteht innerhalb von 3-5 Arbeitstagen nach Behebung (solange die Details noch frisch sind) und enthaelt mindestens:

Verknuepfe die identifizierten strukturellen Schwaechen mit eurem Problem-Management-Prozess: Ein PIR endet idealerweise mit einem oder mehreren Problem-Tickets, die die Root Cause dauerhaft beheben (z. B. Monitoring-Regel ergaenzen, Redundanz einbauen, Runbook aktualisieren).

PIR-Meeting-Etikette

• Der IC oder ein neutraler Moderator leitet das Meeting, nicht die Person, die “schuld” sein koennte.
• Sprache bewusst waehlen: “Das System hat X getan” statt “Person Y hat X gemacht”.
• Timeboxing: 45-60 Minuten reichen fuer die meisten KMU-Incidents.
• Ergebnis wird schriftlich festgehalten und ist fuer alle relevanten Teams einsehbar – nicht nur fuer die IT-Leitung.

Tooling: Was brauchst du wirklich?

Fuer ein KMU muss das Tooling nicht teuer sein. Wichtiger als das Tool ist, dass der Prozess vorher definiert und geuebt ist.

Haeufige Fallstricke in der Praxis

• Kein klarer IC: Mehrere Personen geben gleichzeitig Anweisungen, das Team arbeitet gegeneinander statt zusammen.
• Technisches Debugging und Kommunikation vermischt: Der beste Techniker soll nicht gleichzeitig Statusupdates schreiben – beides leidet.
• Zu fruehe Entwarnung: Der Service scheint zu laufen, aber es wurde nicht ueber genuegend Zeit verifiziert (Monitoring, Stichproben bei Usern) – Flapping-Incidents sind besonders frustrierend fuer Stakeholder.
• PIR wird uebersprungen, weil “eh klar war, was das Problem war”: Genau diese Faelle wiederholen sich am haeufigsten, weil die strukturelle Ursache nie behoben wurde.
• Kommunikation nur an technische Zielgruppe: Ein Statusupdate voller Fachbegriffe hilft der Geschaeftsleitung nicht – uebersetze Impact und Massnahmen in Business-Sprache.

Weiterlernen

• Google SRE Book – Postmortem Culture – Referenz fuer blameless Postmortems
• Google SRE – Incident Management Guide (PDF) – Rollen IC/CL/OL im Detail
• Atlassian – How to run a major incident management process – Praxisleitfaden mit Vorlagen
• Atlassian – Understanding incident severity levels – SEV-Klassifizierung im Detail
• Atlassian – Eskalationspfad-Vorlage (deutsch) – konkrete Eskalationsmatrix zum Anpassen
• ITIL 4 Foundation Overview – AXELOS – offizielle ITIL-4-Grundlagen

Verwandte Themen im Wiki: ITIL-Grundlagen: Incident, Problem, Change, Problem Management und Root Cause Analysis, Incident Response Plan fuer KMU, Change Management nach ITIL vertieft, Kommunikation im IT-Support, IT-Notfallplanung und Disaster Recovery