Incident Management

Einführung

Jede Minute ungeplanter IT-Ausfall kann Unternehmen hohe Kosten verursachen und Geschäftsprozesse empfindlich stören. Studien zeigen, dass bereits wenige Stunden Stillstand den finanziellen Schaden in die Millionen treiben können.

IT-Organisationen müssen daher sicherstellen, dass Störungen nicht nur erkannt, sondern strukturiert und mit klaren Verantwortlichkeiten bearbeitet werden.

In dieser Lerneinheit zum Incident Management lernst du, wie Störungen systematisch erfasst, priorisiert und bearbeitet werden, damit kritische Geschäftsprozesse schnellstmöglich wieder funktionsfähig sind.

Lernziele

Nach dieser Lerneinheit kannst du:

  1. Die Begriffe Incident, Event, Service Request und Problem definieren und korrekt voneinander abgrenzen.
  2. Die Priorisierungsmethodik im Incident Management anwenden, indem du Impact und Urgency zu einer Priority kombinierst und den Zusammenhang zu SLA, OLA und UC erklärst.
  3. Den Prozessablauf des Incident Managements mit allen neun Aktivitäten in der richtigen Reihenfolge darstellen und zwischen funktionaler und hierarchischer Eskalation unterscheiden.
  4. Die Rollen (Incident Manager, 1st Level, 2nd Level, 3rd Level Support) und ihre Aufgaben zuordnen sowie wesentliche Kennzahlen (KPI) wie Time to Restore Service und SLA-Einhaltung erläutern.

Überleitung

Das Incident Management ist einer der zentralen Prozesse im IT Service Management. Es sorgt dafür, dass Störungen effizient bearbeitet werden, um die Auswirkungen auf Geschäftsprozesse so gering wie möglich zu halten. In diesem ersten Teil legen wir den Fokus auf die Grundlagen, die Abgrenzung von Begriffen sowie auf die Priorisierung von Incidents.

Begriffe & Abgrenzungen

Ein Incident ist eine ungeplante Unterbrechung oder Qualitätsminderung eines IT‑Services. Das Incident Management verwaltet den Lebenszyklus aller Incidents. Dabei spielt das Service Desk als Single Point of Contact eine zentrale Rolle.

Ein Incident Record dokumentiert den gesamten Lebenszyklus eines Incidents.

Service Desk – Incident Management (Bildrechte: Ausbildung in der IT)

Begriffe & Abgrenzungen

Abgrenzung zu anderen Begriffen

  • Event: Jede wahrnehmbare Zustandsänderung in einem System oder Service (z. B. Logeintrag). Nicht jedes Event ist ein Incident.
  • Service Request: Standardanforderungen eines Nutzers, z. B. Passwort zurücksetzen. Gehört zum Request Fulfillment, nicht zum Incident Management.
  • Problem: Die unbekannte Ursache eines oder mehrerer Incidents. Probleme werden im Problem Management behandelt.

Beispiel: Ein Anwender meldet, dass sein E-Mail-Client nicht startet. Das ist ein Incident. Wenn Monitoring meldet, dass eine Festplatte im RAID ausgefallen ist, ist dies ein Event. Erst wenn die Redundanz nicht mehr ausreicht, wird es zum Incident.

Priorisierung im Incident Management

Die Priorisierung von Incidents erfolgt anhand von Impact (Auswirkung) und Urgency (Dringlichkeit). Diese beiden Werte bestimmen die Priority, die wiederum die Reaktions- und Lösungszeiten gemäß Service Level Agreement (SLA) steuert.

Definitionen

  • Impact (Auswirkung): Ausmaß der Auswirkung auf Geschäftsprozesse (z. B. Anzahl betroffener Nutzer).
  • Urgency (Dringlichkeit): Zeitliche Kritikalität (z. B. muss sofort gelöst werden, da ein wichtiger Geschäftsprozess steht).
  • Priority (Priorität): Ergebnis der Kombination aus Impact und Urgency. Sie bestimmt die Bearbeitungsreihenfolge.

Priorisierungsmatrix Incident Management – Priorität nach Dringlichkeit × Auswirkung (inkl. Ziel-Lösungszeit)

Dringlichkeit \ AuswirkungHochMittelNiedrig
Hoch1 (< 1 Std.)2 (< 8 Std.)3 (< 24 Std.)
Mittel2 (< 8 Std.)3 (< 24 Std.)4 (< 48 Std.)
Niedrig3 (< 24 Std.)4 (< 48 Std.)5 (nach Planung)

Legende: Priorität 1 = höchste Priorität (kürzeste Lösungszeit), Priorität 5 = niedrigste Priorität.

Beispiel:

  • Ein Drucker im Büro eines Mitarbeiters fällt aus → niedriger Impact, niedrige Urgency → geringe Priorität.
  • Online-Banking-System fällt aus → hoher Impact, hohe Urgency → höchste Priorität.

Standardisierung & Sonderfälle

Neben individuellen Störungen gibt es standardisierte Vorgehensweisen und Sonderfälle:

  • Incident-Modelle: Vorgefertigte Abläufe für wiederkehrende Incidents (z. B. Passwort-Reset).
  • Workaround: Zwischenlösung, die Auswirkungen verringert, bis eine endgültige Lösung vorliegt.
  • Major Incident: Besonders schwerwiegende Störung mit hoher geschäftlicher Auswirkung, die spezielle Verfahren erfordert.

Praxisbeispiele

  • Passwort vergessen: Standard-Incident, der mit einem festgelegten Modell bearbeitet wird.
  • Defekte Festplatte im RAID: Wird als Incident dokumentiert, auch wenn die Serviceverfügbarkeit zunächst nicht eingeschränkt ist.
⏳ Lädt Dataview-Inhalt...

Rollen im Incident Management

Es gibt mehrere Beteiligte im Incident Management:

  • Incident Manager: Verantwortlich für den gesamten Prozess, Koordination und Reporting. Besonders wichtig beim Major Incident Management.
  • 1st Level Support (Service Desk): Erste Anlaufstelle, Bearbeitung einfacher Incidents, Weiterleitung bei Bedarf.
  • 2nd Level Support: Fachliche Spezialisten, übernehmen komplexere Störungen.
  • 3rd Level Support: Hersteller oder externe Dienstleister mit tiefem technischem Wissen.

Prozessaktivitäten (End-to-End)

Das Incident Management folgt einem klar strukturierten Ablauf:

  1. Identifikation – Erkennen des Incidents durch Anwender, Monitoring oder Service Desk.
  2. Aufzeichnung – Dokumentation des Incidents im Incident Record.
  3. Kategorisierung – Zuordnung zu einer passenden Kategorie, um Bearbeitung zu erleichtern.
  4. Priorisierung – Einstufung nach Impact und Urgency
  5. Erste Diagnose – Erste Analyse durch den Service Desk.
  6. Eskalation – Bei Bedarf Übergabe an höhere Support-Level oder Management.
  7. Untersuchung & Diagnose – Detaillierte Analyse und Bearbeitung.
  8. Lösung & Wiederherstellung – Beheben des Incidents und Wiederherstellung des Services.
  9. Schließen – Dokumentation der Lösung und Bestätigung durch den Nutzer.

Beispiel: Ein Ausfall der Telefonanlage wird vom Service Desk erfasst, priorisiert und sofort an den 2nd Level weitergegeben. Nach Wiederherstellung wird der Incident offiziell geschlossen.

Eskalation & Verantwortung

Eskalationen sind notwendig, wenn ein Incident nicht im aktuellen Bearbeitungslevel gelöst werden kann oder besondere Dringlichkeit vorliegt.

Arten der Eskalation

  • Funktionale Eskalation: Übergabe an eine höhere technische Ebene (z. B. 2nd oder 3rd Level Support).
  • Hierarchische Eskalation: Einschalten des Managements bei kritischen Incidents oder drohender SLA-Verletzung.

Verantwortung

  • Der Service Desk bleibt während des gesamten Lebenszyklus verantwortlich für den Incident, auch wenn er weitergegeben wird.
  • Proaktive Kommunikation an die Nutzer ist Pflicht, insbesondere bei Major Incidents.

Beispiel: Bei einem Ausfall des ERP-Systems meldet der Service Desk den Incident sofort an das Management (hierarchische Eskalation) und leitet ihn gleichzeitig an das 3rd Level zur technischen Bearbeitung weiter (funktionale Eskalation).

Kennzahlen (KPI)

Um die Effektivität des Incident Managements zu messen, werden Key Performance Indicators genutzt:

  • Anzahl offener Incidents.
  • Anzahl Major Incidents.
  • Durchschnittliche Time to Restore Service.
  • Durchschnittliche Time to Resolve je Priorität.
  • SLA-Einhaltung in Prozent.

Diese Kennzahlen helfen, die Qualität des Prozesses zu überwachen und Verbesserungsmaßnahmen einzuleiten.

Praxisbeispiel

Ein Major Incident mit Priorität 1 (z. B. kompletter Ausfall des E-Mail-Systems) wird gemeldet. Der Service Desk informiert sofort das Management (hierarchische Eskalation), während das 2nd und 3rd Level parallel an einer Lösung arbeiten (funktionale Eskalation). Währenddessen informiert der Service Desk regelmäßig die Nutzer über den Status. Nach der Wiederherstellung wird der Incident offiziell geschlossen und dokumentiert.

⏳ Lädt Dataview-Inhalt...

Zusammenfassung

Zusammenfassung:

Grundlagen & Priorisierung im Incident Management

Im ersten Teil hast du die zentralen Begriffe und die Basismechanismen des Incident Managements kennengelernt.

  • Incident: ungeplante Unterbrechung oder Qualitätsminderung eines IT-Services.
  • Abgrenzungen: Unterschied zwischen Incident, Event, Service Request und Problem.
  • Service Desk: Single Point of Contact, verwaltet den Lebenszyklus aller Incidents.
  • Incident Record: Dokumentation des gesamten Lebenszyklus eines Incidents.
  • Priorisierung: Kombination aus Impact (Auswirkung) und Urgency (Dringlichkeit) ergibt die Priority.
  • SLA/OLA/UC: Legen Reaktions- und Lösungszeiten abhängig von Prioritäten fest.
  • Standardisierung & Sonderfälle: Incident-Modelle für wiederkehrende Fälle, Workarounds als Übergangslösung, Major Incidents mit spezieller Behandlung.

Prozessablauf, Eskalation & Rollen im Incident Management

Im zweiten Teil stand der strukturierte Ablauf, Eskalationsarten sowie Rollen und Kennzahlen im Fokus.

  • Prozessaktivitäten: Identifikation → Aufzeichnung → Kategorisierung → Priorisierung → Erste Diagnose → Eskalation → Untersuchung & Diagnose → Lösung & Wiederherstellung → Schließen.

  • Eskalationsarten:

    • Funktionale Eskalation = Übergabe an höhere Support-Level.
    • Hierarchische Eskalation = Einschalten des Managements bei kritischen Incidents.
  • Verantwortung: Der Service Desk behält die Gesamtverantwortung über den Incident.

  • Rollen: Incident Manager (Koordination, Reporting), 1st Level (erste Diagnose), 2nd Level (Spezialisten), 3rd Level (Hersteller/Externe).

  • KPI-Beispiele: Anzahl Incidents, Anzahl Major Incidents, Time to Restore/Resolve, SLA-Einhaltung.