Ihr Daten-Template für Incident Management

Der Aktivitätsname beschreibt einen einzelnen Schritt oder eine Aufgabe im Incident-Management-Prozess. Diese Aktivitäten bilden die Bausteine der Prozesslandkarte und können automatisierte Systemereignisse wie „SLA Breach Detected“ oder manuelle Benutzeraktionen wie „Agent Assigned“ und „Workaround Provided“ umfassen.

Für die Process-Mining-Analyse ist dieses Attribut grundlegend. Es definiert die Knoten im Prozessgraphen und ermöglicht es Analysten, den Arbeitsfluss zu visualisieren, typische Pfade zu erkennen, Engpässe aufzudecken und Abweichungen vom Standardverfahren zu analysieren. Die Granularität und Klarheit der Aktivitätsnamen wirken sich unmittelbar auf die Qualität und Tiefe der daraus gewonnenen Erkenntnisse aus.

Dieses Attribut definiert die Prozessschritte und ermöglicht die Visualisierung und Analyse des Verlaufs im Lebenszyklus eines Incidents.

Häufig abgeleitet aus einer Kombination von Event Logs, Audit Trails, Aufzeichnungen zu Statusänderungen oder Feldern mit Aufgabenbeschreibungen im Incident-Management-System.

Der Ereignis-Timestamp kennzeichnet den exakten Zeitpunkt, zu dem eine Aktivität stattgefunden hat. Jede Aktivität im Lebenszyklus eines Incidents sollte über einen zugehörigen Timestamp verfügen, damit eine chronologische Abfolge der Ereignisse entsteht.

Dieses Attribut ist für jede zeitbasierte Process-Mining-Analyse entscheidend. Es ermöglicht die Berechnung von Durchlaufzeiten zwischen Aktivitäten, der Dauer einzelner Schritte und der gesamten Lösungszeit eines Incidents. Durch die Analyse von Timestamps können Unternehmen Engpässe erkennen, die Einhaltung von SLAs messen und nachvollziehen, wie sich die Prozessleistung im Zeitverlauf verändert. Der Timestamp bildet die Grundlage für die Berechnung wichtiger Leistungskennzahlen wie der durchschnittlichen Lösungszeit.

Er liefert die chronologische Reihenfolge der Ereignisse. Diese ist entscheidend für die Berechnung von Zeitdauern, die Erkennung von Engpässen und die Analyse der Prozessleistung im Zeitverlauf.

Zu finden in Event Logs, Tabellen mit der Audit-Historie oder als „last modified“ beziehungsweise „creation date“ in bestimmten zugehörigen Datensätzen.

Die Incident-ID ist ein eindeutiger alphanumerischer Code, der einen Incident im System von allen anderen Incidents unterscheidet. Sie wird bei der Erstellung eines neuen Incidents generiert und bleibt unverändert, bis der Incident dauerhaft archiviert oder gelöscht wird.

Im Process Mining bildet die Incident-ID die Grundlage der Analyse und dient als Case-ID. Sie ermöglicht es der Software, alle zugehörigen Ereignisse, Statusänderungen und Aktivitäten zu einer einzigen, zusammenhängenden Prozessinstanz zu verknüpfen. Indem alle Ereignisse unter einer gemeinsamen Incident-ID gruppiert werden, können Analysten den durchgängigen Verlauf jedes Incidents präzise abbilden, von der ersten Meldung bis zur endgültigen Lösung und zum Abschluss.

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

Dies ist der Primärschlüssel eines Incidents und befindet sich typischerweise im Kopfbereich oder im Hauptdatensatz jeder Incident-Tabelle beziehungsweise jedes Incident-Objekts.

Der Timestamp der letzten Datenaktualisierung gibt an, wann die Daten zuletzt aus dem Quellsystem extrahiert oder mit ihm synchronisiert wurden. Dieses Metadatenfeld beschreibt die Aktualität der analysierten Daten.

In der Process-Mining-Analyse ist dieses Attribut wichtig, um die Aktualität der gewonnenen Erkenntnisse einzuschätzen. Es zeigt, ob Benutzer Echtzeitinformationen oder eine Momentaufnahme aus einem früheren Zeitpunkt betrachten. Dieser Kontext ist für das operative Monitoring entscheidend und stellt sicher, dass Entscheidungen auf aktuellen, relevanten Daten beruhen.

Es zeigt die Aktualität der Daten an und stellt sicher, dass Analysten den zeitlichen Stand ihrer Prozessanalyse richtig einschätzen können.

Dieser Wert wird typischerweise während des Datenextraktions- und Transformationsprozesses (ETL) generiert und jedem Datensatz als Timestamp hinzugefügt.

Das Attribut „Quellsystem“ identifiziert den Ursprung der Daten. In Umgebungen mit mehreren ITSM-Tools oder integrierten Systemen hilft dieses Feld dabei, Datensätze aus unterschiedlichen Quellen zu unterscheiden.

Obwohl dieses Attribut nicht direkt zum Zeichnen der Prozesslandkarte verwendet wird, ist es für die Datenvalidierung und Governance wertvoll. Es ermöglicht Analysten, Daten bis zu ihrem Ursprung zurückzuverfolgen, mögliche Abweichungen zwischen Systemen zu verstehen und die Analyse zu segmentieren. So lassen sich beispielsweise die in zwei unterschiedlichen Systemen wie ServiceNow und Jira implementierten Incident-Management-Prozesse innerhalb derselben Organisation vergleichen.

Es liefert Kontext zum Ursprung der Daten. Dieser ist für die Datenvalidierung, die Fehleranalyse und den Vergleich in Umgebungen mit mehreren Systemen entscheidend.

Dabei handelt es sich häufig um einen statischen Wert, der während der Datenextraktion ergänzt wird, oder um ein Feld in den Tabellen des Quellsystems.

Die Incident-Kategorie bietet eine strukturierte Möglichkeit, Incidents nach ihrer Art zu klassifizieren. Dabei handelt es sich typischerweise um ein hierarchisches Feld, das eine zunehmend detaillierte Klassifizierung ermöglicht und Incidents für Berichte und Analysen in logische Gruppen einteilt.

Die Kategorisierung ist für die Ursachen- und Trendanalyse entscheidend. Durch die Analyse von nach Kategorie gefilterten Prozesslandkarten können Unternehmen wiederkehrende Probleme und Muster für bestimmte Incident-Arten erkennen. So kann der Lösungsprozess eines „Software“-Incidents deutlich anders aussehen als der eines „Hardware“-Incidents. Diese Daten fließen in KPIs wie die Genauigkeit der Erstklassifizierung und die Rate wiederkehrender Incidents ein.

Sie ist für die Ursachenanalyse, die Erkennung von Trends bei wiederkehrenden Incidents und das Verständnis der Bearbeitung unterschiedlicher Problemarten entscheidend.

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

Der Incident-Status zeigt die Phase eines Incidents zu einem bestimmten Zeitpunkt an. Er liefert einen Überblick darüber, an welcher Stelle des Lösungsprozesses sich der Incident befindet. Häufige Statuswerte sind „New“, „Assigned“, „Work in Progress“, „Pending“, „Resolved“ und „Closed“.

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

Der Status ist entscheidend, um den Fortschritt eines Incidents zu verstehen, und wird häufig zur Generierung von Aktivitäten für die Prozesslandkarte verwendet. Die Analyse der Verweildauer in den einzelnen Statuswerten hilft, Verzögerungen zu lokalisieren.

Typischerweise als Primärfeld im Hauptdatensatz des Incidents oder im Verlaufsprotokoll des Incidents verfügbar.

Die Lösungsmethode beschreibt das Ergebnis des Incidents und die Art seiner Lösung. Dabei kann es sich um einen standardisierten Code oder eine Freitextbeschreibung der durchgeführten Maßnahmen handeln. Beispiele sind „Benutzerschulung“, „Software-Patch angewendet“, „Kein Fehler festgestellt“ oder „Doppelter Incident“.

Dieses Attribut liefert wichtigen Kontext zum Ende des Prozesses. Im Process Mining hilft die Analyse von Incidents nach Lösungsmethode dabei, die Wirksamkeit verschiedener Lösungen zu verstehen. Sie kann Fälle sichtbar machen, die ohne tatsächliche Fehlerbehebung geschlossen wurden, oder typische Lösungsmuster für bestimmte Incident-Kategorien aufzeigen. Diese Erkenntnisse können zum Aufbau einer Wissensdatenbank und zur Verbesserung der Lösungsrate beim Erstkontakt verwendet werden.

Es liefert Erkenntnisse darüber, wie Probleme gelöst werden. Das ist entscheidend, um Möglichkeiten für Automatisierung, die Verbesserung der Wissensdatenbank und Schulungen zu erkennen.

Typischerweise handelt es sich um ein Feld, das der Support-Agent ausfüllt, wenn er einen Incident in den Status „Resolved“ oder „Closed“ versetzt.

Der Meldekanal zeigt die Quelle der Incident-Meldung an. Dieses Attribut erfasst, wie Benutzer mit dem Support in Kontakt treten, etwa über direkte Kontaktwege wie Telefonanrufe oder automatisierte Methoden wie Warnmeldungen aus der Systemüberwachung.

Die Analyse des Prozesses nach Meldekanal kann wichtige Effizienzunterschiede sichtbar machen. Über ein Self-Service-Portal gemeldete Incidents werden beispielsweise möglicherweise schneller gelöst, weil sie bereits strukturiertere Informationen enthalten. Diese Analyse hilft Unternehmen, ihre Supportkanäle zu optimieren und die Nutzung effizienterer Methoden zu fördern.

Es hilft, Effizienz und Lösungswege von Incidents nach ihrer Quelle zu analysieren. Die Ergebnisse können in die Kanalstrategie und Ressourcenplanung einfließen.

Diese Information wird normalerweise automatisch erfasst oder vom Agenten bei der Erstellung eines Incidents ausgewählt.

Die Priorität ist ein wichtiges Attribut zur Bestimmung der relativen Bedeutung eines Incidents und der erforderlichen Reaktionsgeschwindigkeit. Sie wird häufig aus den Auswirkungen und der Dringlichkeit des Incidents abgeleitet. Die Stufen reichen typischerweise von kritisch bis niedrig.

Im Process Mining ermöglicht die Analyse von Incidents nach Priorität ein genaueres Verständnis dafür, wie der Prozess mit unterschiedlichen Dringlichkeitsstufen umgeht. Analysten können die Lösungszeiten von Incidents mit hoher und niedriger Priorität vergleichen, um zu prüfen, ob SLAs eingehalten und Ressourcen wirksam eingesetzt werden. So lässt sich beispielsweise beantworten: „Werden unsere kritischsten Incidents tatsächlich am schnellsten bearbeitet?“

Sie ermöglicht die Analyse der Prozessleistung für unterschiedliche Dringlichkeitsstufen und hilft zu prüfen, ob kritische Incidents schneller bearbeitet werden als nicht kritische.

Als Standardfeld im Hauptdatensatz des Incidents verfügbar. Der Wert kann manuell festgelegt oder anhand von Auswirkungen und Dringlichkeit automatisch berechnet werden.

Der Schweregrad definiert die Auswirkungen eines Incidents auf das Unternehmen. 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 von Incidents nach Schweregrad hilft Unternehmen zu verstehen, welche Problemarten die größten Beeinträchtigungen verursachen. Process Mining kann zeigen, ob Incidents mit hohem Schweregrad einem anderen, stärker standardisierten Lösungsweg folgen. Dieses Attribut ist für die Ursachenanalyse und die Priorisierung von Ressourcen im proaktiven Problem Management entscheidend, um das erneute Auftreten schwerwiegender Incidents zu verhindern.

Es ermöglicht die Segmentierung von Incidents, um zu verstehen, ob Probleme mit großen Auswirkungen anders oder effizienter gelöst werden als Probleme mit geringeren Auswirkungen.

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

Die zugewiesene Gruppe zeigt 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 und einem Application-Support-Team der Stufe 3.

Dieses Attribut ist für die Analyse von Übergaben und Arbeitslasten entscheidend. Process Mining kann damit den Fluss von Incidents zwischen Teams visualisieren, die Verweildauer in der Warteschlange jedes Teams messen und Engpässe durch häufige Neuzuweisungen erkennen. Es hilft bei Fragen zur Teameffizienz und Zusammenarbeit und bildet die Grundlage für das Dashboard zur Übergabe- und Neuzuweisungsanalyse.

Es ist entscheidend für die Analyse von Übergaben zwischen Teams, die Messung von Wartezeiten in Warteschlangen sowie das Verständnis der teambezogenen Leistung und Arbeitslastverteilung.

Diese Information wird typischerweise im Incident-Datensatz gespeichert und jedes Mal aktualisiert, wenn der Incident einem neuen Team zugewiesen wird.

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

Dieses Attribut ermöglicht eine detailliertere Analyse von Leistung und Arbeitslast. Durch die Nachverfolgung von Zuweisungen auf Agentenebene können Führungskräfte die individuelle Produktivität bewerten, Schulungsbedarf erkennen und eine ausgewogene Arbeitsverteilung sicherstellen. Im Process Mining lassen sich komplexe Muster bei Neuzuweisungen erkennen, die auf Gruppenebene verborgen bleiben könnten. Außerdem wird sichtbar, welchen Beitrag einzelne Personen zu den Lösungszeiten leisten.

Es ermöglicht eine detaillierte Analyse der individuellen Arbeitslast, Leistung und Neuzuweisungsmuster innerhalb eines Teams oder zwischen Teams.

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

Der Anforderer ist die Person, bei der das Problem auftritt und die die Incident-Meldung initiiert hat. Dabei kann es sich um einen internen Mitarbeiter oder einen externen Kunden handeln. Das Attribut kann außerdem die Abteilung oder Organisation des Anforderers erfassen.

Die Analyse von Incidents nach Anforderer oder Anfordererabteilung zeigt, ob bestimmte Benutzergruppen häufiger Probleme melden als andere. Dies kann auf Schulungsbedarf oder lokale Umgebungsprobleme hinweisen. Im Process Mining ermöglicht das Attribut eine benutzerzentrierte Sicht auf den Supportprozess und hilft, die Erfahrung verschiedener Benutzergruppen zu verstehen.

Es ermöglicht eine benutzerzentrierte Analyse und hilft zu erkennen, ob bestimmte Benutzer, Abteilungen oder Standorte überproportional viele Incidents verursachen.

Ein Standardfeld im Incident-Datensatz, das typischerweise mit dem Benutzer befüllt wird, der das Ticket erstellt hat oder in dessen Auftrag es erstellt wurde.

Die Anzahl der Neuzuweisungen erfasst, wie viele Übergaben ein Incident während seines Lebenszyklus durchläuft. Ein hoher Wert weist häufig auf Ineffizienz, eine fehlerhafte Erstweiterleitung oder fehlendes Wissen in den Supportteams hin.

Dieses Attribut ist für die Process-Mining-Analyse besonders aussagekräftig. Process Mining kann Neuzuweisungen visualisieren, während ein vorab berechneter Zähler eine einfache Filterung und KPI-Messung ermöglicht. Er wird direkt im Dashboard zur Übergabe- und Neuzuweisungsanalyse verwendet und hilft, „Pingpong“-Szenarien zu erkennen, in denen Tickets zwischen Teams hin- und hergereicht werden. Das führt zu längeren Lösungszeiten und Unzufriedenheit bei Benutzern.

Diese Kennzahl quantifiziert die Ineffizienz des Prozesses direkt. 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 dies nicht der Fall ist, kann der Wert durch Zählen der Zuweisungsänderungen im Audit Log des Incidents abgeleitet 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 dabei eine Verbindung zu einer Configuration Management Database (CMDB).

Dieses Attribut liefert wichtigen geschäftlichen Kontext zum Incident. Im Process Mining ermöglicht es die Analyse der Zuverlässigkeit bestimmter Services oder Assets. Unternehmen können erkennen, welche Services die meisten Incidents verursachen, deren Lösungsprozesse analysieren und Maßnahmen im Problem Management priorisieren, um die Stabilität kritischer Geschäftsservices zu verbessern. Es ist ein wichtiges Element, um die umfassenderen geschäftlichen Auswirkungen von IT-Incidents zu verstehen.

Es verknüpft Incidents mit bestimmten Geschäftsservices oder IT-Komponenten und ermöglicht die Analyse, welche Services besonders störungsanfällig sind und welche Auswirkungen daraus entstehen.

Typischerweise aus einer Configuration Management Database (CMDB) verknüpft oder im Incident-Formular aus einer Liste des Servicekatalogs ausgewählt.

Der SLA-Status liefert eine Momentaufnahme der Leistung eines Incidents im Verhältnis zu vorgegebenen Zeitvorgaben, etwa der Reaktions- oder Lösungszeit. Häufige Statuswerte sind „In Progress“, „At Risk“ und „Breached“.

Dieses Attribut misst die Servicequalität direkt und ist eine wichtige Eingabe für das Dashboard zur SLA-Leistungsübersicht. Im Process Mining ermöglicht es den Vergleich der Prozessabläufe von Incidents mit und ohne SLA-Verstoß. So lassen sich die Aktivitäten, Verzögerungen oder Nacharbeitsschleifen erkennen, die maßgeblich zu SLA-Verletzungen führen. Darauf aufbauend können gezielte Prozessverbesserungen umgesetzt werden.

Es misst die Leistung direkt im Verhältnis zu den Zielvorgaben. Die Analyse von Incidents mit SLA-Verstoß hilft, Prozessfehler zu lokalisieren, die zu einer unzureichenden Servicebereitstellung führen.

Dabei handelt es sich typischerweise um ein berechnetes Feld im ITSM-Tool, das anhand von Priorität, Alter des Incidents und definierten SLA-Regeln dynamisch aktualisiert wird.