Ihr Daten-Template für Incident Management

Der Aktivitätsname bezeichnet einen einzelnen Schritt oder eine Aufgabe im Incident-Management-Prozess. Diese Aktivitäten bilden die Bausteine der Prozessdarstellung. Dazu gehören automatisierte Systemereignisse wie „SLA-Verstoß erkannt“ ebenso wie manuelle Aktionen von Benutzern, etwa „Agent zugewiesen“ oder „Workaround bereitgestellt“.

Für die Process-Mining-Analyse ist dieses Attribut grundlegend. Es legt die Knoten im Prozessgraph fest und ermöglicht es Analysten, den Arbeitsablauf zu visualisieren, häufige Pfade zu ermitteln, Engpässe zu entdecken und Abweichungen von der Standardvorgehensweise zu analysieren. Wie detailliert und eindeutig die Aktivitätsnamen sind, wirkt sich unmittelbar auf die Qualität und Aussagekraft der gewonnenen Erkenntnisse aus.

Dieses Attribut legt die Prozessschritte fest und ermöglicht es, den Ablauf des Incident-Lebenszyklus zu visualisieren und zu analysieren.

Wird häufig aus einer Kombination von Ereignisprotokollen, Audit-Trails, Statusänderungsdatensätzen oder Aufgabenbeschreibungen im Incident-Management-System abgeleitet.

Der Ereigniszeitstempel gibt den genauen Zeitpunkt einer Aktivität an. Für jede Aktivität im Lebenszyklus eines Incidents sollte ein entsprechender Zeitstempel vorliegen, damit sich die Ereignisse chronologisch ordnen lassen.

Dieses Attribut ist für jede zeitbasierte Process-Mining-Analyse entscheidend. Es ermöglicht die Berechnung der Zykluszeiten zwischen Aktivitäten, der Dauer einzelner Schritte und der gesamten Lösungszeit eines Incidents. Durch die Analyse der Zeitstempel können Unternehmen Engpässe erkennen, die Einhaltung von SLAs messen und nachvollziehen, wie sich die Prozessleistung im Zeitverlauf verändert. Die Zeitstempel bilden die Grundlage für Kennzahlen wie die durchschnittliche Lösungszeit.

Er gibt die chronologische Reihenfolge der Ereignisse an. Das ist entscheidend, um Zeitspannen zu berechnen, Engpässe zu erkennen und die Prozessleistung im Zeitverlauf zu analysieren.

Zu finden in Ereignisprotokollen, Audit-Verlaufstabellen oder als „zuletzt geändert“ beziehungsweise „Erstellungsdatum“ in bestimmten zugehörigen Datensätzen.

Die Incident-ID ist ein eindeutiger alphanumerischer Code, der einen Incident von allen anderen im System unterscheidet. Sie wird beim Erstellen eines Incidents generiert und bleibt unverändert, bis der Incident endgültig archiviert oder gelöscht wird.

Beim Process Mining bildet die Incident-ID die Grundlage der Analyse und dient als Case-ID. Mit ihr kann die Software alle zugehörigen Ereignisse, Statusänderungen und Aktivitäten zu einer einzigen Prozessinstanz zusammenführen. Werden alle Ereignisse unter einer gemeinsamen Incident-ID gruppiert, können Analysten den gesamten Ablauf jedes Incidents präzise abbilden, von der ersten Meldung bis zur endgültigen Lösung und zum Abschluss.

Sie ist unverzichtbar, um alle zugehörigen Aktivitäten und Ereignisse miteinander zu verknüpfen und den gesamten Lebenszyklus eines Incidents für das Process Mining zu rekonstruieren.

Dies ist der Primärschlüssel eines Incidents. Er befindet sich üblicherweise in der Kopfzeile oder im Hauptdatensatz jeder Incident-Tabelle oder jedes Incident-Objekts.

Der Zeitstempel der letzten Datenaktualisierung gibt an, wann die Daten zuletzt aus dem Quellsystem extrahiert oder mit ihm synchronisiert wurden. Dieses Metadatenfeld zeigt, wie aktuell die analysierten Daten sind.

Für die Process-Mining-Analyse ist dieses Attribut wichtig, um die Aktualität der gewonnenen Erkenntnisse einzuschätzen. Es zeigt Benutzern, ob sie Echtzeitinformationen oder einen Datenstand aus einem früheren Zeitpunkt betrachten. Dieser Kontext ist für die operative Überwachung entscheidend und stellt sicher, dass Entscheidungen auf aktuellen, relevanten Daten beruhen.

Es zeigt, wie aktuell die Daten sind, und hilft Analysten einzuschätzen, auf welchem Datenstand ihre Prozessanalyse beruht.

Dieser Wert wird üblicherweise während der Datenextraktion und -transformation (ETL) generiert und jedem Datensatz hinzugefügt.

Das Attribut „Quellsystem“ gibt an, woher die Daten stammen. In Umgebungen mit mehreren ITSM-Tools oder integrierten Systemen hilft dieses Feld, Datensätze aus unterschiedlichen Quellen zu unterscheiden.

Auch wenn dieses Attribut nicht direkt für die Prozessdarstellung verwendet wird, ist es für die Datenvalidierung und Governance wertvoll. Analysten können damit Daten bis zu ihrem Ursprung zurückverfolgen, mögliche Abweichungen zwischen Systemen nachvollziehen und die Analyse segmentieren. So lassen sich beispielsweise die Incident-Management-Prozesse in zwei verschiedenen Systemen wie ServiceNow und Jira innerhalb derselben Organisation vergleichen.

Es liefert Kontext zur Herkunft der Daten und ist daher wichtig für die Datenvalidierung, die Fehlerbehebung und den Vergleich in Umgebungen mit mehreren Systemen.

Dabei handelt es sich häufig um einen statischen Wert, der bei der Datenextraktion hinzugefügt wird, oder um ein Feld in den Tabellen des Quellsystems.

Die Incident-Kategorie bietet eine strukturierte Möglichkeit, Incidents nach ihrer Art zu klassifizieren. Sie ist üblicherweise hierarchisch aufgebaut und ermöglicht eine schrittweise detailliertere Einordnung. So lassen sich Incidents für Berichte und Analysen in sinnvolle Gruppen gliedern.

Die Kategorisierung ist wichtig für die Ursachen- und Trendanalyse. Werden Prozessdarstellungen nach Kategorien gefiltert, können Unternehmen wiederkehrende Probleme und Muster bei bestimmten Incident-Typen erkennen. Der Lösungsprozess für einen Software-Incident kann beispielsweise ganz anders aussehen als der für einen Hardware-Incident. Diese Daten fließen in Kennzahlen wie die Genauigkeit der Erstklassifizierung und die Rate wiederkehrender Incidents ein.

Das Attribut ist wichtig für die Ursachenanalyse, das Erkennen von Trends bei wiederkehrenden Incidents und das Verständnis dafür, wie unterschiedliche Problemtypen bearbeitet werden.

Dabei handelt es sich um einen standardisierten, häufig verpflichtenden Satz von Feldern im Incident-Datensatz, der zur Klassifizierung dient.

Der Incident-Status gibt an, in welcher Phase sich ein Incident zu einem bestimmten Zeitpunkt befindet. Er zeigt auf hoher Ebene, wie weit die Bearbeitung fortgeschritten ist. Zu den gängigen Status gehören „New“, „Assigned“, „In Progress“, „Pending“, „Resolved“ und „Closed“.

Dieses Attribut ist für die Prozessanalyse grundlegend, da Statusänderungen häufig die Aktivitäten in der Prozessdarstellung definieren. Die Analyse der Verweildauer in den einzelnen Status hilft, Engpässe zu erkennen, etwa wenn Incidents lange auf „Pending“ stehen. Außerdem dient sie dazu, den Rückstand offener Incidents zu berechnen und den Fortschritt bis zur Lösung nachzuverfolgen.

Der Status ist entscheidend, um den Fortschritt eines Incidents nachzuvollziehen, und wird häufig verwendet, um Aktivitäten für die Prozessdarstellung zu generieren. Die Verweildauer in den einzelnen Status hilft, Verzögerungen zu erkennen.

Üblicherweise als Hauptfeld im Incident-Datensatz oder im Verlaufsprotokoll des Incidents verfügbar.

Die Lösungsmethode beschreibt das Ergebnis eines Incidents und wie er gelöst wurde. Sie kann als standardisierter Code oder als Freitext zu den ergriffenen Maßnahmen vorliegen. Beispiele sind „Benutzer geschult“, „Software-Patch eingespielt“, „Kein Fehler gefunden“ oder „Doppelter Incident“.

Dieses Attribut liefert wichtigen Kontext zum Ende des Prozesses. Bei der Analyse nach Lösungsmethode zeigt Process Mining, wie wirksam unterschiedliche Lösungen sind. So lassen sich Fälle erkennen, die ohne tatsächliche Fehlerbehebung geschlossen wurden, oder häufige Lösungsmuster für bestimmte Incident-Kategorien ermitteln. Diese Erkenntnisse können in eine Wissensdatenbank einfließen und die Lösungsrate beim Erstkontakt verbessern.

Das Attribut zeigt, wie Probleme gelöst werden. So lassen sich Möglichkeiten zur Automatisierung, zur Verbesserung der Wissensdatenbank und für Schulungen erkennen.

Dieses Feld wird üblicherweise vom Supportmitarbeiter ausgefüllt, wenn er den Incident auf „Resolved“ oder „Closed“ setzt.

Der Meldekanal gibt an, über welchen Weg ein Incident eingereicht wurde. Dieses Attribut erfasst, wie Benutzer den Support kontaktieren, ob direkt per Telefon oder automatisiert, etwa durch Systemüberwachungsalarme.

Die Analyse des Prozesses nach Meldekanal kann wichtige Effizienzunterschiede aufzeigen. Über ein Self-Service-Portal gemeldete Incidents lassen sich beispielsweise möglicherweise schneller lösen, weil von Anfang an strukturiertere Informationen vorliegen. Diese Analyse hilft Unternehmen, ihre Supportkanäle zu optimieren und effizientere Meldewege zu fördern.

Damit lässt sich die Effizienz und der Lösungsweg von Incidents nach ihrer Quelle analysieren. Die Ergebnisse können in die Kanalstrategie und Ressourcenverteilung einfließen.

Diese Information wird üblicherweise automatisch erfasst oder beim Erstellen eines Incidents vom Agenten ausgewählt.

Die Priorität ist ein wichtiges Attribut, um die relative Bedeutung eines Incidents und die erforderliche Reaktionsgeschwindigkeit festzulegen. Häufig wird sie aus den Auswirkungen und der Dringlichkeit des Incidents abgeleitet. Die Stufen reichen üblicherweise von kritisch bis niedrig.

Beim Process Mining ermöglicht die Analyse nach Priorität einen genaueren Einblick darin, wie der Prozess mit unterschiedlichen Dringlichkeitsstufen umgeht. Analysten können die Lösungszeiten von Incidents mit hoher und niedriger Priorität vergleichen und prüfen, ob SLAs eingehalten und Ressourcen wirksam eingesetzt werden. So lässt sich beispielsweise die Frage beantworten: „Bearbeiten wir unsere kritischsten Incidents tatsächlich am schnellsten?“

Damit lässt sich die Prozessleistung für unterschiedliche Dringlichkeitsstufen analysieren und prüfen, ob kritische Incidents schneller als weniger kritische bearbeitet werden.

Als Standardfeld im Hauptdatensatz des Incidents verfügbar. Die Priorität kann manuell festgelegt oder anhand der Auswirkungen und der Dringlichkeit automatisch berechnet werden.

Der Schweregrad beschreibt, wie stark ein Incident das Unternehmen beeinträchtigt. Er beantwortet die Frage, wie schwerwiegend das Problem ist, unabhängig von seiner Dringlichkeit. Ein unternehmensweiter Systemausfall wäre beispielsweise ein Incident mit hohem Schweregrad, während ein kleiner kosmetischer Fehler einen niedrigen Schweregrad hätte.

Die Analyse nach Schweregrad zeigt Unternehmen, welche Arten von Problemen die größten Störungen verursachen. Process Mining kann aufdecken, ob Incidents mit hohem Schweregrad einem anderen, effizienteren Lösungsweg folgen. Dieses Attribut ist wichtig für die Ursachenanalyse und die Priorisierung von Ressourcen im proaktiven Problemmanagement, damit sich schwerwiegende Incidents nicht wiederholen.

Damit lassen sich Incidents segmentieren und Unterschiede darin erkennen, ob Probleme mit großen Auswirkungen anders oder effizienter gelöst werden als solche mit geringeren Auswirkungen.

Ein Standardfeld im Incident-Datensatz, das häufig zusammen mit der Dringlichkeit zur Festlegung der Priorität verwendet wird.

Die zugewiesene Gruppe gibt an, welches Team zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Incidents werden häufig zwischen verschiedenen Gruppen weitergeleitet, etwa zwischen dem Service Desk der Stufe 1, einem Netzwerkteam der Stufe 2 oder einem Anwendungssupportteam der Stufe 3.

Dieses Attribut ist für die Analyse von Übergaben und Arbeitslasten unverzichtbar. Process Mining kann damit den Weg von Incidents zwischen Teams visualisieren, die Verweildauer in den Warteschlangen der Teams messen und Engpässe durch häufige Neuzuweisungen erkennen. So lassen sich Fragen zur Effizienz und Zusammenarbeit der Teams beantworten. Die Daten bilden außerdem die Grundlage für das Dashboard zur Analyse von Übergaben und Neuzuweisungen.

Das Attribut ist entscheidend, um Übergaben zwischen Teams zu analysieren, Wartezeiten in Warteschlangen zu messen und die teambezogene Leistung sowie die Verteilung der Arbeitslast nachzuvollziehen.

Diese Information ist üblicherweise im Incident-Datensatz gespeichert und wird bei jeder Zuweisung des Incidents an ein neues Team aktualisiert.

Der zugewiesene Agent bezeichnet die konkrete Person, die für einen Incident verantwortlich ist. Während die zugewiesene Gruppe das Team angibt, ist der Agent die Person, die an der Lösung arbeitet.

Dieses Attribut ermöglicht eine detailliertere Analyse von Leistung und Arbeitslast. Durch die Nachverfolgung der Zuweisungen auf Agentenebene können Führungskräfte die individuelle Produktivität beurteilen, Schulungsbedarf erkennen und die Arbeit ausgewogen verteilen. Beim Process Mining lassen sich damit komplexe Muster bei Neuzuweisungen aufdecken, die auf Gruppenebene möglicherweise verborgen bleiben. Außerdem wird sichtbar, welchen Beitrag einzelne Personen zu den Lösungszeiten leisten.

Damit lassen sich Arbeitslast, Leistung und Neuzuweisungsmuster einzelner Personen innerhalb von Teams und zwischen Teams detailliert analysieren.

Dieses Feld befindet sich im Hauptdatensatz des Incidents. Es wird aktualisiert, wenn ein Agent die Zuständigkeit übernimmt oder ihm der Incident zugewiesen wird.

Der Anfragende ist die Person, die von dem Problem betroffen ist und die Incident-Meldung veranlasst hat. Dabei kann es sich um einen internen Mitarbeiter oder einen externen Kunden handeln. Das Attribut kann auch die Abteilung oder Organisation des Anfragenden erfassen.

Die Analyse nach Anfragendem oder dessen Abteilung zeigt, ob bestimmte Benutzergruppen häufiger von Problemen betroffen sind als andere. Das kann auf Schulungsbedarf oder lokale Probleme mit der IT-Umgebung hinweisen. Beim Process Mining ermöglicht das Attribut eine benutzerorientierte Sicht auf den Supportprozess und hilft, die Erfahrungen verschiedener Benutzergruppen zu verstehen.

Damit ist eine benutzerorientierte Analyse möglich. Sie zeigt, ob bestimmte Benutzer, Abteilungen oder Standorte überproportional viele Incidents verursachen.

Ein Standardfeld im Incident-Datensatz, das üblicherweise den Benutzer enthält, der das Ticket erstellt hat oder in dessen Auftrag es erstellt wurde.

Die Anzahl der Neuzuweisungen ist eine Kennzahl für die Übergaben, die ein Incident während seines Lebenszyklus durchläuft. Ein hoher Wert weist häufig auf Ineffizienz, eine falsche anfängliche Weiterleitung oder fehlendes Wissen in den Supportteams hin.

Dieses Attribut ist für die Process-Mining-Analyse besonders hilfreich. Process Mining kann Neuzuweisungen zwar visualisieren, doch ein vorab berechneter Wert erleichtert das Filtern und die Messung von Kennzahlen. Die Anzahl wird direkt im Dashboard zur Analyse von Übergaben und Neuzuweisungen verwendet. Sie hilft, Fälle zu erkennen, in denen Tickets zwischen Teams hin- und hergeschoben werden. Das verlängert die Lösungszeiten und frustriert die Benutzer.

Diese Kennzahl macht die Ineffizienz des Prozesses direkt messbar. Hohe Werte gehen häufig mit längeren Lösungszeiten einher und weisen auf Probleme bei der Weiterleitung oder den Fähigkeiten der Teams hin.

Häufig als Standard-Zählerfeld im Incident-Datensatz verfügbar. Falls nicht, lässt sich der Wert ermitteln, indem die Zuweisungsänderungen im Audit-Protokoll des Incidents gezählt werden.

Der betroffene Service verknüpft einen Incident mit einer bestimmten Komponente der IT-Infrastruktur, etwa einer Geschäftsanwendung, einem Server oder einem Netzwerkgerät. Häufig besteht eine Verbindung zu einer Configuration Management Database (CMDB).

Dieses Attribut liefert wichtigen geschäftlichen Kontext zum Incident. Beim Process Mining ermöglicht es Analysen zur Zuverlässigkeit bestimmter Services oder Anlagen. Unternehmen können ermitteln, welche Services die meisten Incidents verursachen, deren Lösungsprozesse analysieren und Maßnahmen im Problemmanagement priorisieren, um die Stabilität geschäftskritischer Services zu verbessern. Das Attribut ist wichtig, um die umfassenderen geschäftlichen Auswirkungen von IT-Incidents zu verstehen.

Es verknüpft Incidents mit bestimmten Geschäftsservices oder IT-Komponenten. So lässt sich analysieren, welche Services besonders häufig Probleme verursachen und welche Auswirkungen diese haben.

Wird üblicherweise aus einer Configuration Management Database (CMDB) verknüpft oder im Incident-Formular aus einer Liste im Servicekatalog ausgewählt.

Das SLA-Statusfeld zeigt auf einen Blick, wie ein Vorfall im Vergleich zu festgelegten Zeitvorgaben abschneidet, etwa bei der Reaktions- oder Lösungszeit. Häufige Status sind „In Bearbeitung“, „Gefährdet“ und „Überschritten“.

Dieses Attribut misst direkt die Servicequalität und ist eine wichtige Grundlage für das Dashboard „Übersicht der SLA-Leistung“. Mit Process Mining lassen sich die Abläufe bei Vorfällen mit und ohne SLA-Verstoß vergleichen. So erkennen Sie, welche Aktivitäten, Verzögerungen oder Nacharbeitsschleifen maßgeblich zu SLA-Verstößen führen und können gezielte Prozessverbesserungen angehen.

Das Feld misst direkt, ob die Ziele erreicht werden. Die Analyse von Vorfällen mit SLA-Verstoß zeigt, welche Prozessprobleme zu einer mangelhaften Servicebereitstellung führen.

In der Regel berechnet das ITSM-Tool dieses Feld automatisch und aktualisiert es anhand der Priorität und des Alters des Vorfalls sowie der festgelegten SLA-Regeln.