Projektmanagement & ITIL

Incident Management

Allgemeine Infos

Ein Incident ist nach ITIL eine ungeplante Unterbrechung eines Services oder eine Verschlechterung seiner Qualität. Incident Management hat das Ziel, die negativen Auswirkungen solcher Störungen zu minimieren, indem der Normalbetrieb schnell wiederhergestellt wird. Die Ursache dauerhaft zu beseitigen ist nicht Aufgabe des Incident Managements, sondern des Problem Managements.

Typische Incidents sind ein ausgefallener Drucker, eine nicht erreichbare Fachanwendung, ein volles Postfach oder ein Netzwerkausfall am Standort. Ein Major Incident ist eine Störung mit hoher Auswirkung, für die ein beschleunigtes Verfahren mit eigener Koordination und Kommunikation gilt.

Abgrenzung: Incident Response im Security-Umfeld behandelt Sicherheitsvorfälle (Angriffe, Datenabfluss) mit Forensik und Meldepflichten. Ein Sicherheitsvorfall startet oft als normales Ticket und wird dann an den Incident-Response-Prozess übergeben. Service Requests (z. B. neue Software) sind keine Incidents.

In ITIL 4 und ITIL (Version 5) ist Incident Management eine Practice. Version 5 ordnet sie den Lifecycle-Aktivitäten Operate und Support zu und betont die Verbindung zu Monitoring und Observability.

Funktionsweise & Details

Ein typischer Ablauf im Ticket-System:

  1. Erkennung durch Anwender, Monitoring-Alert oder Service Desk.
  2. Erfassung mit Zeitstempel, betroffenem Service und Kontaktdaten.
  3. Kategorisierung und Priorisierung, meist über eine Matrix aus Auswirkung (Impact) und Dringlichkeit (Urgency).
  4. Diagnose und Eskalation, funktional an Spezialisten oder hierarchisch an die Leitung.
  5. Wiederherstellung, gegebenenfalls mit einem bekannten Workaround aus der Known-Error-Datenbank.
  6. Abschluss nach Bestätigung durch den Anwender und Dokumentation der Lösung.

Bei einem Major Incident übernimmt eine Person die Koordination (Incident Commander), eine weitere die Kommunikation an Stakeholder in festen Intervallen. Danach folgt ein Post-Mortem.

Vorteile & Nutzen

  • Kürzere Ausfallzeiten, weil Priorität und Zuständigkeit sofort feststehen und niemand erst klären muss, wer sich kümmert.
  • Messbarkeit: Reaktions- und Lösungszeiten lassen sich gegen vereinbarte Service Level auswerten.
  • Wissen bleibt erhalten, da dokumentierte Lösungen beim nächsten gleichartigen Ticket helfen.
  • Grundlage für Problem Management, weil sich Häufungen erst in sauber kategorisierten Incidents erkennen lassen.

Praxisbeispiel

Bei einem Logistikdienstleister mit drei Standorten fällt montags um 7 Uhr die Lagerverwaltung aus. Der Service Desk erfasst den ersten Anruf, verknüpft die folgenden 20 Meldungen mit diesem Ticket und stuft ihn als Major Incident ein. Der IT-Leiter koordiniert, ein Kollege informiert die Standortleiter alle 30 Minuten. Nach 90 Minuten läuft das System über einen Neustart der Datenbankinstanz wieder, die Ursachenanalyse wird als Problem-Ticket weiterverfolgt.

Worauf sollte man achten?

  • Lege die Prioritätsmatrix schriftlich fest und stimme sie mit den Fachbereichen ab, sonst ist jedes Ticket dringend.
  • Verknüpfe Massenmeldungen mit einem Master-Ticket, damit Auswertungen nicht verfälscht werden.
  • Definiere vorab, ab wann ein Major Incident ausgerufen wird und wer dann welche Rolle übernimmt.
  • Prüfe bei jeder Störung, ob ein Sicherheitsvorfall vorliegen könnte, und übergib ihn dann an Incident Response, weil für erhebliche Vorfälle nach NIS2 feste Meldefristen gelten.

Fazit

Incident Management ist meist die erste ITIL-Practice, die eine IT-Abteilung einführt, weil sie den größten Teil der täglichen Arbeit strukturiert. Wichtig ist die klare Trennung zu Problem Management und Security Incident Response.

Weiterführende Links

Verwandte Artikel