Major Incident Prozess braucht eine Rollenkarte für den ersten Krisenruf

Major Incident Prozess klingt nach Handbuch, Eskalationsstufe und Krisenmodus. In der ersten halben Stunde entscheidet aber meist etwas Einfacheres: Wissen alle, welche Rolle sie gerade haben?

Ein Major Incident ist eine IT-Störung mit hoher geschäftlicher Wirkung. Gemeint sind Ausfälle oder starke Einschränkungen, bei denen Service Desk, Betrieb, Fachbereich und Management schnell dieselbe Lage verstehen müssen. Der Major Incident Prozess soll diese Arbeit führen. Er legt fest, wer bewertet, wer entscheidet, wer kommuniziert und wie der Betrieb nach dem ersten Druck wieder in einen sauberen Ablauf zurückfindet.

Für ITSM-Generalisten ist das Thema wichtig, weil schwere Störungen nicht nur technisch gelöst werden. Parallel laufen Nutzeranfragen, Managementfragen, Workaround-Entscheidungen, Statusmeldungen, Lieferantenkontakte und Dokumentationspflichten. Ohne klare Rollen entsteht aus einem Krisenruf schnell ein lauter Gruppenchat. Dann arbeiten gute Leute gegeneinander, obwohl alle helfen wollen.

Der erste Krisenruf braucht weniger Stimmen und klarere Rollen

In der Praxis wird der erste Krisenruf oft zu groß. Fachbereiche melden Auswirkungen, Techniker prüfen Systeme, der Service Desk fragt nach Aussagen für Nutzer, ein Manager will eine Prognose und ein Lieferant wartet auf Logs. Das ist nachvollziehbar. Es ist aber kein Prozess, solange niemand führt, sortiert und Entscheidungen trennt.

Eine Rollenkarte ist deshalb kein Organigramm. Sie ist ein kurzer Arbeitszettel für den Ernstfall. Darauf steht, welche Rolle im Krisenruf besetzt sein muss, welche Entscheidung diese Rolle trifft und welche Information sie nicht selbst lösen soll. Der Wert liegt in der Begrenzung. Nicht jeder Beteiligte muss in jede Diskussion. Nicht jede technische Spur gehört in den Hauptcall. Nicht jede Nachfrage verdient sofort eine Managementrunde.

Der Beitrag Problem Management vs Incident Management im Alltag trennen zeigt die gleiche Grundlogik aus einer anderen Perspektive. Incident Management stabilisiert den Service. Problem Management sucht Ursachen. Beim Major Incident Prozess kommt hinzu, dass Führung und Kommunikation parallel stabil bleiben müssen.

Fünf Rollen reichen für den Start

Für viele Organisationen ist eine schlanke Rollenkarte wirksamer als ein langer Eskalationsplan. Sie sollte mindestens fünf Funktionen unterscheiden.

• Einsatzleitung: führt den Krisenruf, setzt Prioritäten, entscheidet über nächste Schritte und beendet Abschweifungen.
• Technische Analyse: prüft Symptome, Hypothesen, Logs, Änderungen und Wiederherstellungswege.
• Service Owner: bewertet Geschäftsauswirkung, Nutzerpriorität und akzeptable Workarounds.
• Kommunikation: formuliert Statusmeldungen für Service Desk, Fachbereiche, Management und gegebenenfalls Kunden.
• Protokoll und Nachweis: hält Zeiten, Entscheidungen, Annahmen, Workarounds und offene Punkte fest.

Diese Rollen können in kleinen Teams von weniger Personen übernommen werden. Entscheidend ist nicht die Anzahl der Menschen, sondern die sichtbare Trennung der Aufgaben. Wer gerade technische Ursachen sucht, sollte nicht gleichzeitig den Managementtext schreiben. Wer den Krisenruf führt, sollte nicht im Detail eine Logzeile debuggen. Wer protokolliert, braucht die Freiheit, auch unsichere Annahmen und verworfene Optionen sauber festzuhalten.

Die Rollenkarte schützt vor Chat-Eskalation

Chatkanäle sind in Störungen nützlich. Sie werden aber riskant, wenn sie den Prozess ersetzen. Dann laufen technische Hypothesen, Statusfragen, Schuldzuweisungen, Screenshots, Kundenmeldungen und Managementdruck in derselben Spur. Der Major Incident Prozess braucht deshalb eine Regel, welche Information in den Hauptkanal gehört und welche in Nebenkanäle ausgelagert wird.

Eine einfache Vorgabe hilft: Der Hauptcall entscheidet und informiert. Technische Detailarbeit läuft in einem Arbeitskanal. Kommunikationsentwürfe laufen in einem separaten Freigabepfad. Das Protokoll übernimmt nur geprüfte Entscheidungen, Zeiten und relevante Hypothesen. So bleibt der Krisenruf führbar, ohne technische Tiefe zu verlieren.

Der Artikel Standardänderungen brauchen einen Freigabeplan statt Bauchgefühl beschreibt, warum Entscheidungen vor der Umsetzung sichtbar sein müssen. Im Major Incident gilt das unter Zeitdruck. Auch ein Workaround ist eine Entscheidung. Er braucht Nutzen, Risiko, Rückweg und einen klaren Owner.

Entscheidungen müssen als Entscheidungen erkennbar sein

In schweren Störungen verschwimmen Beobachtung, Vermutung und Beschluss. Jemand sagt, dass ein Dienst seit einer Änderung instabil wirkt. Eine andere Person schlägt einen Neustart vor. Kurz darauf arbeitet ein Team am Rollback, während ein anderes Team noch Daten sammelt. Wenn niemand markiert, was entschieden wurde, entsteht später Streit über Ablauf, Verantwortung und Nachweis.

Darum sollte die Rollenkarte feste Entscheidungssätze vorgeben. Beispiele sind: „Wir stufen den Vorfall als Major Incident ein“, „Wir kommunizieren jetzt eingeschränkte Verfügbarkeit“, „Wir testen diesen Workaround für 20 Minuten“, „Wir bereiten Rollback vor, lösen ihn aber noch nicht aus“ oder „Wir eskalieren an den Provider mit dieser Priorität“. Solche Sätze wirken schlicht. Sie machen aber hörbar, wann aus Diskussion eine Entscheidung wird.

Der Service Desk profitiert besonders davon. Er braucht keine komplette Ursachenanalyse, um Nutzer sauber zu informieren. Er braucht belastbare Aussagen: Was ist betroffen, was ist nicht betroffen, wann kommt die nächste Aktualisierung und welcher Workaround ist freigegeben? Diese Punkte gehören in den Prozess, nicht erst in improvisierte Rückfragen.

Kommunikation ist eine eigene Arbeitsrolle

Technische Teams unterschätzen häufig, wie viel Schaden unklare Kommunikation in einer großen Störung verursacht. Zu frühe Entwarnung enttäuscht Nutzer. Zu technische Details verwirren Fachbereiche. Zu späte Updates erzeugen zusätzliche Tickets. Der Major Incident Prozess sollte deshalb eine Kommunikationsrolle haben, die nicht nebenbei von der lautesten Person übernommen wird.

Diese Rolle sammelt freigegebene Fakten, schreibt kurze Statusmeldungen und achtet auf klare Zeitpunkte. Eine brauchbare Meldung nennt betroffene Services, sichtbare Wirkung, bekannte Einschränkung, nächsten Updatezeitpunkt und gegebenenfalls Workaround. Sie vermeidet technische Spekulationen, solange diese noch nicht entscheidungsreif sind. Sie verspricht keine Lösungszeit, wenn nur eine Prüfzeit bekannt ist.

Der Beitrag Sicherheitswarnungen brauchen einen Service-Check zeigt, wie wichtig die Verbindung zwischen technischem Signal und Servicewirkung ist. Beim Major Incident gilt diese Verbindung sofort. Nutzer interessiert nicht jede interne Spur. Sie brauchen Orientierung, ob und wie sie weiterarbeiten können.

Nach dem Wiederanlauf beginnt die zweite Prozesshälfte

Ein Major Incident Prozess endet nicht mit dem ersten grünen Monitoringwert. Nach dem Wiederanlauf müssen Entscheidungen, Zeiten, Workarounds, Restprobleme und Kommunikationspunkte gesichert werden. Sonst lässt sich später kaum erkennen, ob der Ablauf gut geführt war oder nur glücklich ausgegangen ist.

Die Rollenkarte sollte deshalb schon im Krisenmodus festlegen, wer den Abschluss vorbereitet. Dazu gehören eine finale Nutzerinformation, die Übergabe offener technischer Punkte, ein Termin für die Nachbesprechung und eine klare Trennung zwischen Incident-Abschluss und Problem-Management-Aufgabe. Ohne diese Trennung bleibt die Organisation im Modus „irgendwie gelöst“. Das erschwert Lernen und Wiederverwendung.

Prüffragen für die eigene Rollenkarte

Eine Major-Incident-Rollenkarte muss nicht lang sein. Sie muss im ersten Krisenruf funktionieren. Diese Fragen prüfen, ob sie praktisch genug ist.

• Ist klar, wer den Krisenruf führt und wer ihn nicht führt?
• Ist festgelegt, wer eine Störung als Major Incident einstuft?
• Gibt es eine Rolle für Nutzer- und Managementkommunikation?
• Wer entscheidet über Workaround, Rollback, Provider-Eskalation oder weitere Wartezeit?
• Wer schreibt Zeiten, Annahmen und Beschlüsse mit?
• Wann kommt die nächste Statusmeldung, auch wenn es noch keine Lösung gibt?
• Wer trennt technische Detailarbeit vom Hauptcall?
• Wer überführt offene Ursachenanalyse in Problem Management?

Wenn diese Fragen erst im Ernstfall beantwortet werden, ist der Prozess zu spät. Besser ist eine Rollenkarte, die vorab mit Service Desk, Betrieb, Service Ownern und Kommunikation abgestimmt wird. Ein kurzer Probelauf mit einem realistischen Ausfallszenario zeigt schnell, ob die Karte verständlich ist oder nur Prozesssprache wiederholt.

Ein guter Major Incident Prozess nimmt der Störung nicht die Dringlichkeit. Er nimmt ihr die Unordnung. Die Rollenkarte sorgt dafür, dass der erste Krisenruf nicht zur offenen Bühne für jedes Detail wird. Sie macht sichtbar, wer entscheidet, wer informiert, wer analysiert und wer den Nachweis führt. Genau dadurch wird aus Druck ein steuerbarer Ablauf.

Wichtig ist dabei eine nüchterne Grenze: Die Rollenkarte ersetzt keine Technik und keine Ursachenanalyse. Sie sorgt nur dafür, dass beides im richtigen Moment gehört wird. Genau deshalb passt sie auch in kleinere IT-Organisationen.

Quellen und Stand: Quellenprüfung am 02.09.2026 anhand von Atlassian Incident Management, dem Google SRE Book zu Incident-Führung und Freshservice Incident Management. Es werden keine Preise, Tarife oder Beträge genannt. Bildquelle: Pexels / Foto-ID 3862132 / CC0-Lizenz