Incident Management

Ein Incident ist nach ITIL-Definition jede ungeplante Unterbrechung oder Qualitätsminderung eines IT-Service. „Mein Mail geht nicht" ist ein Incident. „Der Drucker druckt langsam" ist ein Incident. „Das CRM lädt 30 Sekunden statt 2 Sekunden" ist auch ein Incident – obwohl es noch läuft. Das zentrale Ziel des Incident Management ist klar: den normalen Service so schnell wie möglich wiederherstellen. Nicht die Ursache klären (das ist Problem Management), nicht die Struktur ändern (das ist Change Management) – einfach das Geschäft am Laufen halten. Diese Lektion zeigt dir den ITIL-konformen Incident-Prozess von der Erfassung bis zur Schließung, was einen Incident von einem Service Request unterscheidet und wie der Sonderfall „Major Incident" gehandhabt wird.

1) Was zählt als Incident – und was nicht

Beim Service Desk landen alle Arten von Anliegen. Nicht jedes davon ist ein Incident. Die wichtige Unterscheidung:

Tipp: ein Test in Worten – „Etwas, was funktionieren sollte, funktioniert nicht" = Incident. „Etwas, was es noch nicht gibt, soll bereitgestellt werden" = Service Request. ITIL nennt sie unterschiedliche Practices: Incident Management und Service Request Management. Tools wie JIRA Service Management oder ServiceNow trennen das auch auf Ticket-Typ-Ebene.

2) Der Incident-Prozess in 7 Schritten

Klick die Prozessschritte an, um die Details zu sehen:

3) Was bei jedem Incident erfasst wird

Ein Ticket lebt von guten Daten. Pflicht-Felder, die beim Anlegen erfasst werden sollten:

4) Major Incident – der Sonderfall

Ein Major Incident ist ein Incident mit besonders hoher Auswirkung oder besonders hoher Dringlichkeit – meist Prio 1. Beispiele: das Bestellsystem im E-Commerce ist down, der DC kommt nicht hoch, ein Cyberangriff läuft, das Telefonsystem schweigt. Hier reicht der Normal-Prozess nicht – es braucht eine eigene Eskalationsroutine:

5) Workaround vs. Lösung

Wichtige Unterscheidung, die in Prüfungen gerne gefragt wird:

• Workaround: kurzfristige Behebung, die den Service wiederherstellt, ohne die Ursache zu beheben. Beispiel: „Print-Spooler-Dienst neu starten" – druckt wieder, das eigentliche Problem (warum hängt der Dienst sich auf?) bleibt offen.
• Lösung / Fix: die Ursache wird beseitigt. Beispiel: Firmware-Update des Druckertreibers, das den Bug behebt.

Incident Management hat die Wiederherstellung als Ziel – ein Workaround reicht zunächst völlig. Die nachhaltige Lösung ist Sache von Problem Management. Trennung der Practices wichtig: Incident Manager schließt das Ticket, wenn der Workaround funktioniert. Parallel öffnet Problem Management einen eigenen Vorgang.

6) KPIs im Incident Management

7) Häufige Stolperfallen

• Diagnose statt Wiederherstellung. Ein Agent versucht, die Ursache zu finden, obwohl ein bekannter Workaround existiert. „Wiederherstellen jetzt, Verstehen später."
• SLA-Pause-Spielereien. Tickets werden vorschnell auf „Warten auf User" gesetzt, um die SLA-Uhr anzuhalten. Statistisch sieht alles gut aus, real wartet der Anwender. Lösung: Pause-Status auditieren.
• Ticket-Manipulation. Schließen ohne Rücksprache mit User. Lösung: Auto-Resolve mit Mail-Bestätigung („wenn keine Reaktion in 3 Tagen, wird geschlossen").
• Kein Wissens-Transfer. Identische Incidents tauchen wieder und wieder auf, weil niemand sie in die KEDB einträgt. Lösung: Pflicht-Feld „Workaround beschreiben" beim Schließen.
• Schweigen während eines Major Incidents. Techniker reparieren, niemand kommuniziert – Anwender ruft alle 5 Minuten an, blockiert die Bridge. Lösung: dedizierter Kommunikator.

Zusammenfassung

Incident Management ist die ITIL-Practice mit dem klarsten Auftrag: ungeplante Service-Störungen so schnell wie möglich beheben. Ein Incident ist eine Service-Unterbrechung; ein Service Request ist eine geplante Anwender-Anforderung – das sind verschiedene Practices. Prozessschritte: Identifizierung → Erfassung → Kategorisierung → Priorisierung → Diagnose → Lösung/Recovery → Schließung. Wichtige Daten pro Ticket: Affected User/Service/CI, Impact, Urgency, Priority. Major Incident als Sonderfall mit Major Incident Manager, War Room/Bridge-Call, häufiger Statuskommunikation und Post-Mortem-Pflicht. Unterschied Workaround (Symptom-Beseitigung) vs. Lösung (Ursache beseitigen) – Incident Management reicht der Workaround, die Ursache ist Sache von Problem Management. KPIs: MTTA, MTTR, FCR, SLA-Erfüllungsrate, Reopen-Rate, CSAT.

Verwandte Lektionen: Ticket-Priorisierung · Problem Management · Level Support · und mehrWeitere relevante LektionenKEDBChange ManagementService DeskSLACMDBMTBF/MTTRAlerting