3.7 Ownership, hierarchische Eskalation und Major Incidents (Teil 2/2)

Major-Incident-Prozess

Nach der Einstufung als Major Incident beginnt eine koordinierte Bearbeitung.

Ein möglicher Ablauf:

Major Incident erkannt
        │
        ▼
Owner bestätigen
        │
        ▼
Major Incident Manager benennen
        │
        ▼
Fachteams koordinieren
        │
        ▼
Stakeholder informieren
        │
        ▼
Workaround oder Wiederherstellung
        │
        ▼
Service stabilisieren
        │
        ▼
Incident schließen
        │
        ▼
Problem Management starten

Nicht jede Organisation verwendet exakt diesen Ablauf. Entscheidend ist eine klare Koordination.

War Room

Bei kritischen Incidents wird häufig ein gemeinsamer Kommunikationskanal eingerichtet.

Beispiele:

Microsoft Teams

Slack

Telefonkonferenz

Videokonferenz

Alle beteiligten Teams arbeiten dort gemeinsam.

Vorteile:

schnellere Entscheidungen

weniger Rückfragen

keine Informationsverluste

bessere Zusammenarbeit

Kommunikationsregeln

Während eines Major Incidents sollte Kommunikation:

regelmäßig erfolgen,

sachlich bleiben,

bestätigte Fakten enthalten,

Vermutungen klar kennzeichnen,

Verantwortlichkeiten nennen,

nächste Schritte erläutern.

Ungeeignet:

"Wir glauben, dass wahrscheinlich vielleicht die Firewall schuld ist."

Besser:

"Die Ursache wird aktuell untersucht. Firewall und Netzwerk werden geprüft. Nächste Statusmeldung um 11:30 Uhr."

Stakeholder

Nicht jeder benötigt dieselben Informationen.

Stakeholder	Benötigte Informationen
Benutzer	Auswirkungen und Workaround
Service Desk	aktueller Status
Management	Geschäftsrisiken
Kunden	Serviceverfügbarkeit
Technik	Diagnoseinformationen
Lieferanten	technische Details

Informationen sollten zielgruppengerecht formuliert werden.

Single Point of Communication

Bei großen Incidents sollte möglichst nur eine abgestimmte Kommunikationsquelle verwendet werden.

Dadurch werden widersprüchliche Aussagen vermieden.

Beispiele:

Statusseite

Incident Manager

Kommunikationsverantwortlicher

Ressourcen koordinieren

Nicht jedes Team sollte unabhängig arbeiten.

Der Major Incident Manager achtet darauf,

dass

Aufgaben verteilt,

Doppelarbeiten vermieden,

Ergebnisse zusammengeführt

werden.

Dokumentation

Auch unter Zeitdruck muss dokumentiert werden.

Mindestens festhalten:

Zeitpunkt

Maßnahme

Ergebnis

Entscheidung

Verantwortlicher

Diese Informationen werden später benötigt für:

Problem Management

Lessons Learned

Audits

Verbesserungen

Nach der Wiederherstellung

Mit der Wiederherstellung endet der Major Incident nicht vollständig.

Es folgen häufig:

Ursachenanalyse

Review

Verbesserung

Knowledge-Artikel

Monitoring-Anpassungen

Automatisierungen

Major Incident Review

Nach Abschluss sollte überprüft werden:

Was ist passiert?

Warum?

Welche Maßnahmen waren erfolgreich?

Wo gab es Verzögerungen?

Welche Verbesserungen sind möglich?

Ziel ist Lernen – nicht Schuldzuweisung.

Lessons Learned

Typische Ergebnisse:

bessere Dokumentation

neue Checklisten

Monitoring erweitern

Alarmgrenzen anpassen

Runbooks verbessern

Schulungen durchführen

Automatisierungen ergänzen

Problem Management einbeziehen

Ein Major Incident endet häufig mit einem neuen Problem Record.

Dadurch kann später untersucht werden:

eigentliche Ursache

dauerhafte Lösung

Vermeidung zukünftiger Incidents

Häufige Fehler

Fehler 1

Kein eindeutiger Owner.

Fehler 2

Mehrere Teams arbeiten ohne Koordination.

Fehler 3

Benutzer erhalten keine Statusinformationen.

Fehler 4

Zu späte Eskalation.

Fehler 5

Jeder kommuniziert etwas anderes.

Fehler 6

Techniker diskutieren Vermutungen als Fakten.

Fehler 7

Keine Dokumentation während des Incidents.

Fehler 8

Nach Wiederherstellung erfolgt keine Nachbereitung.

Fehler 9

Lessons Learned werden nicht umgesetzt.

Fehler 10

Problem Management wird nicht gestartet.

Praxisbeispiel

08:15 Uhr

Mehrere Standorte melden Ausfälle.

08:20 Uhr

Major Incident aktiviert.

08:25 Uhr

Incident Manager übernimmt Koordination.

08:30 Uhr

Statusmeldung veröffentlicht.

08:40 Uhr

Netzwerk-, Server- und Cloud-Team arbeiten gemeinsam.

09:05 Uhr

Workaround verfügbar.

09:40 Uhr

Service vollständig wiederhergestellt.

10:30 Uhr

Review-Termin geplant.

Checkliste Ownership

Checkliste Eskalation

Richtige Eskalationsart gewählt

Fachinformationen vollständig

Richtige Ansprechpartner beteiligt

Entscheidungen dokumentiert

Status kommuniziert

Checkliste Major Incident

Bedeutung für Fachinformatiker für Systemintegration

Auch wenn Fachinformatiker nicht die Rolle des Incident Managers übernehmen, sind sie häufig maßgeblich an der technischen Analyse beteiligt.

Im Arbeitsalltag bedeutet das:

strukturiert arbeiten,

Ergebnisse dokumentieren,

Änderungen nachvollziehbar durchführen,

sauber kommunizieren,

und andere Teams aktiv unterstützen.

Gerade bei größeren Störungen entscheidet oft die Zusammenarbeit über die Dauer des Ausfalls.

Zusammenfassung

Incident übernehmen

↓

Owner festlegen

↓

Bearbeitung koordinieren

↓

Falls notwendig funktional oder hierarchisch eskalieren

↓

Major Incident aktivieren (wenn Kriterien erfüllt)

↓

Kommunikation sicherstellen

↓

Service wiederherstellen

↓

Review durchführen

↓

Erkenntnisse in Problem Management und Continual Improvement übernehmen

Verwandte Seiten

3.5 Auswirkungen, Dringlichkeit und Priorität

3.6 Erstdiagnose, Lösung und funktionale Eskalation

3.8 Self-Service, Wissensnutzung und Automatisierung

Problem Management

Knowledge Management

Continual Improvement

Quellen

PeopleCert – ITIL 4 / ITIL 5 Incident Management

PeopleCert – ITIL 4 / ITIL 5 Service Desk

PeopleCert – ITIL Practice Guides

ITIL Service Version 5

Framework-Stand: ITIL Version 5
Fachlicher Stand: August 2026