Logo von PREVISEC, einer Software für Incident Management und Krisenmanagement
Alexander Berger, CEO, SMART DATA Deutschland GmbH
14.09.2022

Ein effektiver Incident Management Prozess ist für Unternehmen unerlässlich, um schnell auf Störungen und Probleme reagieren zu können. Doch wie kann dieser Prozess sinnvoll strukturiert werden und worauf muss man achten? In diesem Artikel erfahren Sie alles, was Sie über den Incident Management Prozess wissen müssen. In diesem Beitrag gehen wir der Frage nach, wie man einen Incident Management Prozess strukturieren kann. Der Aufbau soll ein Verständnis für die strukturierte Behandlung von Incidents schaffen und kann helfen, selbst einen Incident Management Prozess aufzubauen.

Jedes Unternehmen betreibt Incident Management

Viele allerdings haben das nie explizit für sich definiert oder gar einen Incident Management Prozess dazu aufgesetzt. Vereinfacht kann man aber sagen: Wenn Probleme auftreten, die den Geschäftsbetrieb beeinträchtigen könnten oder dies bereits akut tun, dann werden sie gelöst. Incident Management liegt also im ureigenen Interesse von Unternehmen, am Markt Bestand zu haben und erfolgreich wirtschaften zu wollen. Einen Incident Management Prozess zu strukturieren hat verschiedenste Vorteile: In erster Linie geht es darum, Reaktion und Lösungen zu beschleunigen, wirksamer zu machen und Fehler nachhaltig zu eliminieren. Daneben hilft eine Formalisierung, beim Informationsmanagement gegenüber verschiedensten Stakeholdern besser zu werden, Know-How für das Unternehmen in verwertbarer Form zu sichern und Risiken zu minimieren.

Oft wird Incident Management als eine Teildisziplin eines Verantwortungsbereichs (häufig: IT) verstanden und aufgesetzt. Tatsächlich ist es nach unserem Verständnis jedoch eine höchst interdisziplinäre Aufgabe. Mehr zu unserer Idee von Incident Management lesen Sie in diesem Artikel. Incident Management ist ein Prozess, der darauf abzielt, die Auswirkungen von Störungen auf eine Organisation zu minimieren. Es beinhaltet die Identifizierung, Priorisierung und Behebung von Störungen in einer schnellen und effizienten Weise.

Wie strukturiere ich einen Incident Management Prozess?

Im Folgenden erläutern wir einige grundlegende Phasen zur Erstellung eines Incident Management Prozesses, die wir mit allgemeinen Beispielen und Überlegungen skizzieren. Sie sind natürlich nicht als Blaupause zu verstehen – in jedem Unternehmen muss solch ein Prozess individuell (übrigens natürlich auch thematisch differenziert) erarbeitet und implementiert werden. Die Schritte helfen jedoch, wichtige Eckpunkte zu beachten und eine solide Basis zu schaffen, die dann weiter ausgebaut werden kann.

Ziele des Incident Management Prozess

Es empfiehlt sich zu Beginn festzulegen, welche Ziele Sie mit dem Incident Management (Prozess) verfolgen. Wie werden Sie bewerten, ob oder wie weit Sie die Ziele erreicht haben? Die Beantwortung der „Ziel-Frage“ ist wichtig, um beim Design aller weiteren Bausteine angemessene und zielführende Lösungen zu finden ohne unnötigen Overhead aufzubauen.
Wenn Sie die Ziele insbesondere bei der Implementierung kommunizieren und erklären, schaffen Sie zudem eine höhere Akzeptanz bei allen Beteiligten und mitunter ein besseres Verständnis/Intuition dafür, was im Incident Management passieren soll.

Relevante Incidents

Die Erstellung jedes Incident Management Prozesses oder -Konzepts beruht auf einem gemeinsamen Verständnis davon, welche Risiken und Probleme im Unternehmen auftreten können und eine Bedrohung für den Geschäftserfolg darstellen. Welche thematische Gliederung sich hier anbietet hängt meist davon ab, wie die Organisation aufgebaut ist, die mit den diversen Vorfällen umzugehen hat. Da jedes Szenario auch entsprechend definiert werden muss ist es wichtig, bei den Unterscheidungen nicht zu sehr ins Detail zu gehen, sondern – wo immer sinnvoll – Ähnlichkeiten auszunutzen und Incident-Typen zusammenzufassen.
Um auf die relevanten Themen zu kommen gibt es verschiedene Ansätze und Informationsquellen. Dazu gehören die Befragung von Mitarbeitern, die Sichtung bestehender Risk Assessments, Herleitung aus SLAs/Liefer- oder Abnahmeverträgen, gesetzliche Vorschriften, weitergehende (Selbst-)Verpflichtungen des Unternehmens, historische Daten aus dem Incident Management.

Wichtig ist: Diese Zusammenstellung muss im Sinne des typischen „Management-Circles“ zur Optimierung regelmäßig aktualisiert werden. Aus der praktischen Sicht macht dies zusätzlich Sinn, das sich insbesondere externe (aber auch interne) Einflüsse und Risiken verändern und eine dementsprechende Anpassung erfordern. Versehen Sie die „Liste“ daher mit einer klaren Verantwortlichkeit und planen Sie eine regelmäßige Aktualisierung ein.

Ingress / Trigger / Feststellung

Die erste Frage zu jedem identifizierten Thema ist, wie das Unternehmen jeweils eine zuverlässige Information darüber erhalten kann, wenn sich ein entsprechender Incident zuträgt. Diesen Schritt sicherzustellen ist in einigen Fällen eine sehr große Herausforderung. Investieren Sie also ausreichend Zeit und Mühe, um das Risiko „verpasster“ oder „verspäteter“ Incidents einzudämmen. Je massiver die potentiellen Auswirkungen eines Vorfalls, desto eher lohnt sich das Engagement. Einige Leitfragen, die hier unterstützen können:

  • Woher kommt die Information zu dem Incident?
  • Wann kann ein entsprechender Incident auftreten und kann die Information dazu immer „angenommen“ werden?
  • Wie bekommt das Unternehmen Kenntnis davon? Technisches System? Beobachtung? Medien? …?
  • Wie kann die Übergabe der Information inzentiviert werden?
  • Wie kann sie abgesichert werden (Zuverlässigkeit)?
  • In welcher Form und mit welchen Detaillierungsgrad liegt die Information vermutlich vor?

First Response

In wenigen Ausnahmen ist es sinnvoll, Incidents zu erfassen bzw. reporten zu lassen und darauf keine Reaktion zu zeigen. Im Allgemeinen geht es hierbei um reine Dokumentation deren Motivation (und damit auch die ggf. nötige Inzentivierung) darauf baut, dass allen Beteiligten der spätere Nutzen einer solchen Datenbasis bekannt ist und eine konkrete Verwendung angestrebt wird.

Regelmäßig müssen Unternehmen jedoch auf eingehende Informationen zu Vorfällen reagieren. Hier gibt es zwei wesentliche Punkte zu berücksichtigen:
Einerseits ist es möglich (und je nach Thema sogar häufig), dass Informationen vielleicht nicht ausreichend vollständig vorliegen, um folgende Aktivitäten oder Entscheidungen ausreichend „gut“ zu ermöglichen. In diesem Fall ist es sinnvoll zu regeln, was der unbedingt notwendige Informationsumfang ist, der hergestellt werden muss, und wie dieser (ggf. in zweiter Instanz) erreicht werden soll. Eine themenabhängige Übersicht und Dokumentation hilft, diesen Schritt abzubilden.

Andererseits müssen Unternehmen gerade auf kritischere Incidents regelmäßig schnell reagieren. Hier steht besonders eine schnelle Annahme des Incidents, dessen Bewertung und die Einleitung nachfolgender Aktivitäten im Vordergrund. Welche fachlichen Kenntnisse werden benötigt, wie zeitkritisch ist die First Response und was ist das (jeweilige) Ziel? Welche Ressourcen werden benötigt? Wie organisieren Sie die Verfügbarkeit? Gibt es Parameter, die den Prozess bzw. die Anforderungen beeinflussen (z.B. rechtliche Anforderungen, die nur zutreffend sind für bestimmte Umstände (Bsp.: Abfluss personenbezogener Daten))?

Handling Baseline

Aus unserer Sicht ist es sinnvoll, eine Baseline aufzustellen und diese als Grundlage zu kommunizieren bzw. in die Prozesse einzubinden. Die Baseline liefert zwei wichtige Ergebnisse: Wenn sie verstanden wurde und „funktional implementiert ist“ (egal wie, Hauptsache sie funktioniert in der Praxis zuverlässig), dann sichert sie in unsicheren, mglw. unbekannten/neuen Situationen einen gewissen Handlungs- und Informationsfluss ab. Verantwortliche können sich immer an ihr orientieren, selbst wenn gänzlich neue Situationen entstehen.

Zum anderen gibt sie verschiedenen Incident Management Prozessen eine Ähnlichkeit und macht es involvierten Parteien so leichter, sich in verschiedenen Bereichen zurechtzufinden. Das ist eine echte Hilfe für Sie bei der Implementierung des Konzepts und steigert erfahrungsgemäß die Akzeptanz von Reporting und Management von Incidents. Typischerweise beinhaltet die Baseline thematisch gruppierte Benachrichtigungsaktivitäten (zur Sicherstellung eines Informationsflusses, der Folgehandlungen überhaupt erst möglich macht) sowie Basisaktivitäten für die weitere Informationsgewinnung und eine saubere Dokumentation.

Individuelles Handling

Selbstverständlich erfordern die meisten Incidents darüber hinaus ergänzende Aktivitäten in verschiedenster Form, um den thematisch individuellen Anforderungen gerecht zu werden und Ihre Ziele zu erfüllen. Sie werden diese vermutlich mit Experten aus entsprechenden Fachbereichen erarbeiten und diskutieren. Denken Sie neben fachlichen, operativen oder technischen Lösungen immer auch an die kommunikative Komponente – intern wie extern.
Kombinieren Sie den jeweiligen Incident Prozess möglichst konsistent nach dem Schema „Baseline + indiv. Handling“. Nur in Ausnahmen sollten Sie die Baseline dabei weglassen oder modifizieren.

Dokumentation im Incident Management Prozess

Die Dokumentation von Lösungsprozessen dient einerseits Nachvollziehbarkeit und Nachweis. Andererseits sichert sie relevante Informationen über Erfolg, Misserfolg, Kosten, Wirksamkeit von Maßnahmen, etc. zu Incidents und deren Behebung für das Unternehmen. In einigen Fällen gibt es auch gesetzliche oder operative  Anforderungen, die Sie erfüllen müssen, um z.B. Compliance herzustellen, Haftung auszuschließen oder Leistungen beanspruchen zu können.
Halten Sie die Dokumentation möglichst kurz und mit „einfachen Angaben“ standardisiert. Freie Ausführungen und wechselnde Strukturen sind sehr schwer auszuwerten/zu analysieren. Genau hieraus können Sie sich aber Themen wie Wirksamkeit, Effizienz, etc. erschließen. Achten Sie also auf eine dienliche Erfassung.

Closing

Für jeden Incident (oder Gruppen davon) sollte möglichst objektiv definiert sein, wann er als abgeschlossen gilt und entsprechend abgelegt werden kann. So verhindern Sie, dass Incidents aufgrund individueller Einschätzungen zu früh vom Radar verschwinden und im Nachhinein Probleme machen (Kosten, Haftung Reputation, wiederholte Probleme).
Die individuelle Bewertung einer Situation ist immer auch von den eigenen Möglichkeiten, bereits investierten Ressourcen, der persönlichen Risikowahrnehmung und anderen Umgebungsfaktoren (wie z.B. das allgemeine aktuelle Stresslevel) abhängig. Versuchen Sie dies möglichst durch ein hinreichendes „Bewertungsschema“ auszuschließen. Das Closing sollte immer auch Teil der Dokumentation sein.

Das Bewertungsschema kann beispielsweise folgende Kriterien enthalten: Ist das Problem behoben? Wurde die Ursache identifiziert und beseitigt? Wurden alle betroffenen Systeme und Prozesse wiederhergestellt?

Ein Beispiel für eine Art von Incident Management Prozessen ist der IM Prozess nach der ITITL-Spezifikation in der IT. Dazu gibt es hier eine recht umfassende Knowledgebase: https://wiki.de.it-processmaps.com/index.php/Incident_Management

Ganz wichtig: Incidents sind KEIN reines IT-Thema! Warum? Punkt 1 unserer 3 Mythen über Incidents klärt auf.
Weiterhin haben wir ein paar Gedanken zur Definition notiert: Definition Incident Management

Wie geht’s mit PREVISEC?

Jetzt Produkt-tour starten

Erreichbarkeiten sicherstellen:
Alarmierungen mit PREVISEC

Alarmierung auf Smartphone als Teil des Incident Managements
mehr

Wenn Incidents zu Krisen eskalieren: Krisenmanagement mit PREVISEC

ein Team arbeitet an Incident Management Konzept
mehr

Was bringt ein Notfall- und Krisenmanagement
im Unternehmen

Ein Rettungsring auf einem Schiff, Blick auf das Meer
mehr

3 Mythen über
Incident Management

Eine Lupe als Symbol für die Identifikation von Datenquellen für das Krisenmanagement
mehr