# 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,
- Abhängigkeiten erkannt,
- und nächste Schritte eindeutig zugewiesen 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**

- [ ] Owner eindeutig festgelegt
- [ ] Verantwortlichkeiten bekannt
- [ ] Benutzer informiert
- [ ] Eskalationen überwacht
- [ ] Ticket aktiv verfolgt

---

**Checkliste Eskalation**

- [ ] richtige Eskalationsart gewählt
- [ ] Fachinformationen vollständig
- [ ] richtige Ansprechpartner beteiligt
- [ ] Entscheidungen dokumentiert
- [ ] Status kommuniziert

---

**Checkliste Major Incident**

- [ ] Major Incident bestätigt
- [ ] Incident Manager benannt
- [ ] Kommunikationskanal eingerichtet
- [ ] Stakeholder informiert
- [ ] Workaround geprüft
- [ ] Maßnahmen dokumentiert
- [ ] regelmäßige Statusmeldungen
- [ ] Wiederherstellung bestätigt
- [ ] Review geplant
- [ ] Problem Record erstellt, falls erforderlich

---

**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