Was ist Incident Management? Prozess, Rahmenwerk und Kennzahlen

Das Incident Management ist der Prozess, mit dem Unternehmen ungeplante Störungen von IT-Diensten oder Geschäftsabläufen erkennen, protokollieren, untersuchen und beheben. Ganz gleich, ob es sich um einen Serverausfall, eine fehlgeschlagene Bereitstellung oder einen Softwarefehler handelt, der einen einzelnen Benutzer betrifft – ein klar definierter Incident-Management-Prozess hilft Teams dabei, den Dienst schnell wiederherzustellen und die Auswirkungen auf das Geschäft zu minimieren.

Die Herausforderung besteht darin, dass sich Vorfälle oft gleichzeitig über Chat, E-Mail und mehrere Tools erstrecken, was die Koordination erschwert. Da immer mehr Unternehmen für ihren täglichen Betrieb auf Microsoft Teams setzen, suchen viele nach Möglichkeiten, das Incident Management in derselben Umgebung durchzuführen, in der bereits die Kommunikation stattfindet.

Was ist Incident Management?

Incident Management ist der Prozess der Erkennung, Protokollierung, Klassifizierung, Untersuchung und Behebung ungeplanter Störungen von IT-Diensten oder Geschäftsabläufen. Das Ziel besteht darin, den normalen Dienstbetrieb so schnell wie möglich wiederherzustellen und gleichzeitig die Auswirkungen auf das Geschäft zu minimieren.

Im IT-Service-Management (ITSM) ist das Incident Management eine Kernpraxis, die durch das ITIL-Framework (Information Technology Infrastructure Library) definiert wird. ITIL definiert einen Vorfall als „eine ungeplante Unterbrechung eines IT-Dienstes oder eine Beeinträchtigung der Qualität eines IT-Dienstes“. Dies umfasst alles von einem Serverausfall bis hin zu einem Softwarefehler, der einen einzelnen Benutzer betrifft.

Incident Management vs. Incident Response

Jede Incident Response ist eine Form des Incident Managements, doch das Incident Management umfasst weit mehr als nur Sicherheitsvorfälle.

• Das Incident Management umfasst den gesamten Lebenszyklus jeder ungeplanten Dienstunterbrechung, von der Erkennung über die Behebung bis hin zum Abschluss. Es handelt sich um eine breit angelegte operative Praxis, die für alltägliche IT-Probleme in jedem Unternehmen gilt.

• Incident Response bezieht sich in der Regel speziell auf die Bewältigung von Sicherheitsvorfällen: Datenverletzungen, Cyberangriffe und andere Bedrohungen. Incident Response folgt speziellen Rahmenwerken wie NIST und bezieht häufig Akteure aus den Bereichen Sicherheit, Recht und Führungsebene mit ein.

Kategorie	Incident Management	Incident Response
Umfang	Alle ungeplanten Serviceunterbrechungen	Sicherheitsvorfälle: Verletzungen, Cyberangriffe, Bedrohungen
Framework	ITIL	NIST, ISO 27035
Teams	IT Betrieb, Service Desk	Sicherheits-, Rechts- und Führungsteams
Ziel	Den Service so schnell wie möglich wiederherstellen	Die Bedrohung eindämmen, untersuchen und beseitigen

Vorfall vs. Problem vs. Serviceanfrage

Diese drei Begriffe werden oft synonym verwendet, bezeichnen im ITSM jedoch unterschiedliche Sachverhalte:

• Vorfall: Eine ungeplante Störung, die eine sofortige Reaktion erfordert, um den Dienst wiederherzustellen. Beispiel: Benutzer können nicht auf eine Geschäftsanwendung zugreifen.

• Problem: Die zugrunde liegende Ursache eines oder mehrerer Vorfälle. Das Problemmanagement untersucht und beseitigt die Ursache, um eine Wiederholung zu verhindern.

• Serviceanfrage: Eine routinemäßige, vorab genehmigte Anfrage, die keine Dienstunterbrechung beinhaltet. Beispiel: Ein neuer Mitarbeiter beantragt Zugriff auf Software.

Das Vorfallmanagement konzentriert sich auf die Geschwindigkeit der Lösung. Das Problemmanagement konzentriert sich auf die Ursachenanalyse. Beide sind eigenständige Disziplinen, auch wenn sie vom selben Team bearbeitet werden.

Der Prozess des Vorfallmanagements

Die meisten IT Teams folgen einem strukturierten, wiederholbaren Prozess, um Vorfälle einheitlich zu bearbeiten. Hier sind die Standardschritte:

1. Erkennung und Protokollierung

Der Vorfall wird identifiziert, entweder durch ein vom Benutzer eingereichtes Ticket, eine automatisierte Überwachungswarnung oder durch direkte Beobachtung durch IT-Mitarbeiter. Alle relevanten Details werden erfasst: Zeitpunkt, betroffene Systeme, Auswirkungen auf die Benutzer und erste Symptome.

Eine genaue Protokollierung in dieser Phase ist entscheidend. Unvollständige Aufzeichnungen führen zu einer langsameren Diagnose und Lücken bei der Nachbetrachtung des Vorfalls. Jeder Vorfall, unabhängig von seinem Schweregrad, sollte protokolliert werden, bevor mit der Untersuchung begonnen wird.

2. Klassifizierung und Priorisierung

Der Vorfall wird nach Art kategorisiert und erhält je nach Auswirkung und Dringlichkeit eine Prioritätsstufe (P1–P4). Dieser Schritt legt fest, wer reagiert, wie schnell und über welchen Eskalationspfad.

Prioritätsstufen für Vorfälle

Die Priorität bestimmt, wie schnell ein Vorfall behoben werden muss. Die meisten Organisationen verwenden eine vierstufige Skala, die auf Auswirkung und Dringlichkeit basiert.

Priorität	Stufe	Reaktionszeit	Beschreibung
P1	Kritisch	15 Minuten	Kompletter Ausfall, der alle oder die meisten Benutzer betrifft. Sofortige Eskalation an alle Beteiligten erforderlich.
P2	Hoch	1 Stunde	Erhebliche Auswirkungen auf eine große Gruppe oder einen wichtigen Geschäftsprozess. Zuweisung an erfahrene Mitarbeiter mit regelmäßigen Updates.
P3	Mittel	Innerhalb eines Arbeitstages	Begrenzte Auswirkungen mit verfügbaren Workarounds. Bearbeitung innerhalb des vereinbarten SLA-Fensters.
P4	Niedrig	Warteschlange	Minimale Auswirkungen, einzelner Benutzer oder unkritisches System. Keine Dringlichkeit. Erledigung nach Reihenfolge.

3. Untersuchung und Diagnose

Das zuständige Team oder die zuständige Person untersucht die Ursache. Dies kann die Überprüfung von Systemprotokollen, die Reproduktion des Problems oder die Weiterleitung an einen Spezialisten umfassen. Der Schwerpunkt liegt in dieser Phase auf der Suche nach einer Abhilfe, nicht unbedingt auf der dauerhaften Behebung des zugrunde liegenden Problems.

Eine vorübergehende Abhilfe, die den Dienst wiederherstellt, ist in dieser Phase ein akzeptables Ergebnis. Eine vollständige Ursachenanalyse kann nach der Wiederherstellung des Dienstes erfolgen.

4. Eskalation

Wenn der First Level Support den Vorfall nicht beheben kann, wird er an ein Spezialistenteam oder den Second Level Support eskaliert. Die Eskalation kann funktional (an ein anderes Team) oder hierarchisch (an einen Manager oder leitenden Ingenieur) erfolgen.

5. Behebung und Wiederherstellung

Es wird eine Lösung implementiert und der Dienst wiederhergestellt. Die Behebung wird detailliert dokumentiert: Was wurde unternommen, warum hat es funktioniert und was war die bestätigte Ursache? Die Benutzer werden darüber informiert, dass der Vorfall behoben wurde. Diese Dokumentation bildet die Grundlage für die Analyse nach dem Vorfall und für langfristige Verbesserungen.

6. Abschluss

Der Vorfall wird offiziell abgeschlossen, nachdem bestätigt wurde, dass die Lösung stabil ist. Dazu gehören bei größeren Vorfällen eine Nachbetrachtung, die Dokumentation der gewonnenen Erkenntnisse sowie etwaige Folgemaßnahmen zur Vermeidung einer Wiederholung.

Der Abschluss des Prozesses mit dem Nutzer oder Stakeholder, der den Vorfall gemeldet hat, ist ein wichtiger Schritt, der oft übersprungen wird.

Arten des Incident Managements

Unternehmen wenden je nach ihrer Struktur und ihren betrieblichen Anforderungen unterschiedliche Modelle an:

• IT-Incident-Management (ITIL): Das traditionelle Modell, das von IT-Betriebs- und Service-Desk-Teams verwendet wird. Es folgt strukturierten Ticketing-Prozessen, Eskalationswegen und SLA-basierten Lösungszielen. Am besten geeignet für Unternehmen mit definierten IT-Servicekataloge und mehrstufigen Support-Teams. Managed-Service-Provider, die Helpdesk-Betrieb für mehrere Kunden betreiben, wenden dasselbe Modell in großem Maßstab an siehe MSP Helpdesk Best Practices, um zu erfahren, wie das in der Praxis funktioniert.

• DevOps Incident Management: Wird von Softwareentwicklungs- und DevOps-Teams eingesetzt, um Vorfälle in Entwicklungspipelines und Produktionsumgebungen zu beheben. Der Schwerpunkt liegt auf schneller Erkennung, raschen Rollbacks und kontinuierlicher Verbesserung durch schuldfreie Nachbesprechungen.

• SRE-Incident-Management: Site Reliability Engineering-Teams wenden Fehlerbudgets und Service Level Objectives (SLOs) an, um Vorfälle zu verwalten. Der Fokus liegt auf der langfristigen Systemzuverlässigkeit und nicht nur auf der sofortigen Lösung.

• Sicherheits Incident Management: Ein spezialisierter Prozess zur Bewältigung von Cybersicherheitsvorfällen wie Datenlecks, Malware-Infektionen oder unbefugtem Zugriff. Er umfasst Eindämmung, forensische Untersuchung, behördliche Meldung und Absicherung nach dem Vorfall.

Viele Unternehmen verfolgen einen hybriden Ansatz und wenden je nach Schweregrad und Art des Vorfalls unterschiedliche Modelle an.

So messen Sie die Leistung des Incident Managements

Durch die Leistungsmessung wird das Incident Management von einer reaktiven Funktion zu einem Prozess der kontinuierlichen Verbesserung. Die nützlichsten Kennzahlen sind:

• Mean Time to Detect (MTTD): Die durchschnittliche Zeit zwischen dem Beginn eines Vorfalls und seiner ersten Erkennung. Eine hohe MTTD deutet auf Lücken in der Überwachung oder bei den Meldewegen der Benutzer hin.

• Mean Time to Resolve (MTTR): Die durchschnittliche Zeit vom Erkennen bis zur vollständigen Behebung. Dies ist die am häufigsten erfasste Kennzahl im Incident Management und diejenige, die am unmittelbarsten mit den geschäftlichen Auswirkungen verbunden ist.

• SLA-Einhaltungsrate: Der Prozentsatz der Incidents, die innerhalb ihres SLA-Zielzeitfensters gelöst wurden, separat nach Prioritätsstufe erfasst. Dies zeigt auf, wo Ihr Prozess versagt.

• Vorfallvolumen nach Kategorie: Die zeitliche Verfolgung von Vorfällen nach Typ deckt wiederkehrende Muster auf. Ein Anstieg in einer bestimmten Kategorie deutet oft auf ein zugrunde liegendes Infrastruktur- oder Prozessproblem hin.

• Wiedereröffnungsrate: Der Prozentsatz der Vorfälle, die nach ihrer Markierung als gelöst wiedereröffnet wurden. Eine hohe Wiedereröffnungsrate deutet auf eine mangelhafte Ursachenanalyse oder einen vorzeitigen Abschluss hin.

  
  

Diese Kennzahlen sollten regelmäßig überprüft und zur Förderung von Prozessverbesserungen genutzt werden, nicht nur zur Berichterstattung über die Leistung.

Incident Management in Microsoft Teams

Microsoft Teams hat sich zu einer praktischen Umgebung für das Incident-Management entwickelt, da Kommunikation und Koordination bereits dort stattfinden. Dank eines direkt in Teams integrierten Ticket-Systems können Vorfälle erfasst, zugewiesen, nachverfolgt und aktualisiert werden, ohne zwischen verschiedenen Tools wechseln zu müssen.

Ein in Teams integriertes Ticketingsystem wie Ticketing as a Service sorgt für eine strukturierte Bearbeitung von Vorfällen, indem es folgende Aufgaben vereinfacht:

• Empfang und Erfassung von Vorfallmeldungen direkt in Teams

• Zuweisung von Tickets an die richtigen Teammitglieder, ohne die Plattform verlassen zu müssen

• Verfolgung des Status und der Priorität von Vorfällen in Echtzeit

• Kommunikation von Lösungsfortschritten über dieselbe Oberfläche, die auch für die tägliche Arbeit genutzt wird

• Führung eines vollständigen Vorfallprotokolls für Nachbetrachtungen und Audit-Zwecke

Eine Schritt-für-Schritt-Anleitung zur Konfiguration von Ticketing as a Service speziell für die Bearbeitung von Vorfällen finden Sie unter Einrichten des Vorfallmanagements in Microsoft Teams. Teams, die neben Vorfällen auch laufende betriebliche Probleme verwalten müssen, können denselben Workflow für die Problemverfolgung in Microsoft Teams anwenden.

Für Organisationen, die bereits Microsoft 365 nutzen, reduziert dieser Ansatz die Vielzahl an Tools und hält den Workflow für das Vorfallmanagement innerhalb der Umgebung, die Ihr Team bereits verwendet.

Mehr Kontrolle beim Vorfallmanagement in Microsoft Teams

Ticketing as a Service von Teamswork ist ein Microsoft 365-zertifiziertes Helpdesk System, das für Teams entwickelt wurde, die eine strukturiertere Methode zur Bearbeitung von Vorfällen in Microsoft Teams benötigen. Mit steigendem Vorfallvolumen wird es immer schwieriger, allein auf den Chat zu setzen, um die Zuständigkeit zu klären, den Fortschritt zu verfolgen und zuverlässig zu dokumentieren, was bereits gelöst wurde.

Durch die Einführung einer Ticketing Ebene direkt in Teams können Unternehmen von reaktiven Unterhaltungen zu einem konsistenteren Vorfall Workflow übergehen. Die Zuständigkeiten werden klarer, Prioritäten lassen sich leichter verwalten und die Reaktionsfristen bleiben für das gesamte Team sichtbar. Gleichzeitig arbeiten Sie weiterhin in der Umgebung, die Ihre Mitarbeiter bereits nutzen, ohne weitere Tools hinzuzufügen.

Try Ticketing as a Service for free

---

TeamsWork ist Mitglied des Microsoft Partner Network und spezialisiert auf die Entwicklung von Produktivitäts-Apps, die die Leistungsfähigkeit der Microsoft Teams-Plattform und ihres dynamischen Ökosystems nutzen. Ihre SaaS-Produkte wie CRM as a Service, Ticketing as a Service und Checklist as a Service werden von Nutzern hochgeschätzt. Sie überzeugen durch eine benutzerfreundliche Oberfläche, nahtlose Integration in Microsoft Teams und erschwingliche Preismodelle. TeamsWork legt Wert darauf, innovative Softwarelösungen zu entwickeln, die die Produktivität von Unternehmen steigern und für jedes Budget erschwinglich sind.