Daten-Template: Incident Management

Der Activity Name (Aktivitätsname) beschreibt einen einzelnen Schritt oder eine Aufgabe, die als Teil des Incident Management-Prozesses ausgeführt wird. Diese Aktivitäten stellen die Bausteine der Prozesslandkarte dar und können automatisierte System Events wie 'SLA Breach Detected' oder manuelle Benutzeraktionen wie 'Agent Assigned' oder 'Workaround Provided' umfassen.

Für die Process Mining-Analyse ist dieses Attribut grundlegend. Es definiert die Knoten im Prozessgraphen und ermöglicht Analysten, den Workflow zu visualisieren, gängige Pfade zu identifizieren, Bottlenecks zu entdecken und Abweichungen vom Standardverfahren zu analysieren. Die Granularität und Klarheit der Aktivitätsnamen wirken sich direkt auf die Qualität und Tiefe der ableitbaren Insights aus.

Dieses Attribut definiert die Schritte im Prozess und ermöglicht die Visualisierung und Analyse des Ablaufs des Incident-Lebenszyklus.

Oft abgeleitet aus einer Kombination von Event Logs, Audit Trails, Statusänderungsprotokollen oder Aufgabenbeschreibungsfeldern innerhalb des Incident Management Systems.

Der Event Timestamp kennzeichnet den genauen Zeitpunkt, zu dem eine Aktivität stattgefunden hat. Jede Aktivität innerhalb des Lebenszyklus eines Incidents sollte einen entsprechenden Timestamp haben, um eine chronologische Abfolge von Ereignissen zu etablieren.

Dieses Attribut ist entscheidend für jede zeitbasierte Process-Mining-Analyse. Es ermöglicht die Berechnung von Zykluszeiten zwischen Aktivitäten, die Dauer spezifischer Schritte und die Gesamtlösungszeit des Incidents. Durch die Analyse von Timestamps können Organisationen Engpässe identifizieren, die Einhaltung von SLAs messen und verstehen, wie sich die Prozessleistung im Zeitverlauf verändert. Es ist die Grundlage für die Berechnung wichtiger Leistungskennzahlen wie der durchschnittlichen Lösungszeit.

Es liefert die chronologische Reihenfolge der Events, was unerlässlich ist, um Dauern, Bottlenecks zu berechnen und die Prozessperformance über die Zeit zu analysieren.

Gefunden in Event Logs, Audit History Tables oder als 'Last Modified' oder 'Creation Date' in spezifischen verknüpften Records.

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

Im Process Mining ist die Incident-ID der Grundstein der Analyse und dient als Case ID. Sie ermöglicht es der Software, alle zugehörigen Events, Statusänderungen und Aktivitäten zu einer einzigen, kohärenten Prozessinstanz zusammenzufügen. Indem alle Events unter einer gemeinsamen Incident-ID gruppiert werden, können Analysten den End-to-End-Verlauf jedes Incidents, von der ersten Meldung bis zur endgültigen Lösung und Schließung, genau abbilden.

Es ist unerlässlich, um alle zugehörigen Aktivitäten und Events miteinander zu verknüpfen und den End-to-End-Incident-Lebenszyklus für Process Mining zu rekonstruieren.

Dies ist der Primärschlüssel für einen Incident und wird typischerweise im Header oder Hauptdatensatz jeder Incident-Tabelle oder jedes Objekts gefunden.

Der Timestamp der letzten Datenaktualisierung gibt an, wann die Daten zuletzt aus dem Quellsystem extrahiert oder synchronisiert wurden. Dies ist ein Metadatenfeld, das die Aktualität der analysierten Daten widerspiegelt.

In der Process-Mining-Analyse ist dieses Attribut wichtig, um die Zeitnähe der generierten Erkenntnisse zu verstehen. Es hilft Benutzern zu verstehen, ob sie Echtzeitinformationen oder eine Momentaufnahme aus einem früheren Zeitpunkt betrachten. Dieser Kontext ist entscheidend für die Betriebsüberwachung und um sicherzustellen, dass Entscheidungen auf aktuellen, relevanten Daten basieren.

Es zeigt die Aktualität der Daten an und stellt sicher, dass Analysten verstehen, wie aktuell ihre Prozessanalyse ist.

Dieser Wert wird typischerweise während des Daten-Extraktions- und Transformationsprozesses (ETL) generiert und jedem Datensatz zugewiesen.

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

Obwohl es nicht direkt zum Zeichnen der Prozesskarte verwendet wird, ist dieses Attribut wertvoll für die Datenvalidierung und Governance. Es hilft Analysten dabei, Daten zu ihrem Ursprung zurückzuverfolgen, potenzielle Diskrepanzen zwischen Systemen zu verstehen und die Analyse zu segmentieren. Beispielsweise könnte man die Incident-Management-Prozesse vergleichen, die in zwei verschiedenen Systemen, wie ServiceNow und Jira, innerhalb derselben Organisation implementiert sind.

Es liefert Kontext für den Ursprung der Daten, was für die Datenvalidierung, Fehlerbehebung und vergleichende Analyse in Multi-System-Umgebungen entscheidend ist.

Dies ist oft ein statischer Wert, der während des Daten-Extraktionsprozesses hinzugefügt wird oder ein Feld, das in den Tabellen des Quellsystems verfügbar ist.

Die Incident-Kategorie bietet eine strukturierte Möglichkeit, Incidents nach ihrer Art zu klassifizieren. Dies ist typischerweise ein hierarchisches Feld, das eine schrittweise detailliertere Klassifizierung ermöglicht und hilft, Incidents für Berichterstattung und Analyse in logische Gruppen zu ordnen.

Die Kategorisierung ist entscheidend für die Ursachen- und Trendanalyse. Durch die Analyse von Prozesskarten, die nach Kategorien gefiltert sind, können Organisationen wiederkehrende Probleme und Muster identifizieren, die mit bestimmten Incident-Typen verbunden sind. Beispielsweise kann der Lösungsprozess für einen „Software“-Incident ganz anders aussehen als für einen „Hardware“-Incident. Diese Daten bilden die Grundlage für KPIs wie die Genauigkeit der initialen Kategorisierung und die Wiederholungsrate von Incidents.

Es ist wesentlich für die Grundursachenanalyse, die Identifizierung von Trends bei wiederkehrenden Incidents und das Verständnis, wie verschiedene Arten von Problemen gehandhabt werden.

Dies ist ein standardmäßiger, oft obligatorischer Satz von Feldern im Incident-Datensatz, der zur Klassifizierung verwendet wird.

Der Incident-Status gibt die Phase eines Incidents zu einem bestimmten Zeitpunkt an. Er bietet eine übergeordnete Sicht darauf, wo sich der Incident im Lösungsprozess befindet. Gängige Status sind neu, zugewiesen, in Bearbeitung, ausstehend, gelöst und geschlossen.

Dieses Attribut ist grundlegend für die Prozessanalyse, da Statusänderungen oft die Aktivitäten in der Prozesskarte definieren. Die Analyse der Verweildauer in jedem Status hilft, Engpässe zu identifizieren, wie beispielsweise Incidents, die lange im Status „Ausstehend“ verharren. Es wird auch verwendet, um den Rückstand offener Incidents zu berechnen und den Fortschritt der Lösung zu verfolgen.

Es ist entscheidend, um den Fortschritt des Incidents zu verstehen und wird oft verwendet, um Aktivitäten für die Prozesskarte zu generieren. Die Analyse der in jedem Status verbrachten Zeit hilft, Verzögerungen zu lokalisieren.

Typischerweise als primäres Feld im Hauptdatensatz des Incidents oder im History Log des Incidents verfügbar.

Die Lösungsmethode beschreibt das Ergebnis des Incidents und wie er gelöst wurde. Dies könnte ein standardisierter Code oder eine Freitextbeschreibung der ergriffenen Maßnahmen sein. Beispiele sind „Benutzerschulung“, „Software-Patch angewendet“, „Kein Fehler gefunden“ oder „Duplikat-Incident“.

Dieses Attribut liefert entscheidenden Kontext für das Ende des Prozesses. Im Process Mining hilft die Analyse von Incidents nach ihrer Lösungsmethode, die Effektivität verschiedener Lösungen zu verstehen. Es kann Fälle hervorheben, die ohne eine tatsächliche Behebung geschlossen wurden, oder gemeinsame Lösungsmuster für spezifische Incident-Kategorien identifizieren, die dann genutzt werden können, um eine Wissensdatenbank aufzubauen und die First Contact Resolution-Raten zu verbessern.

Es bietet Einblicke, wie Probleme gelöst werden, was entscheidend ist, um Möglichkeiten für Automatisierung, Wissensdatenbankverbesserungen und Schulungen zu identifizieren.

Typischerweise ein Feld, das vom Support-Agenten ausgefüllt wird, sobald ein Incident in den Status 'Resolved' oder 'Closed' verschoben wird.

Der Meldekanal gibt die Quelle der Incident-Meldung an. Dieses Attribut verfolgt, wie Benutzer mit der Supportfunktion interagieren, sei es über direkte Kontaktmethoden wie Telefonanrufe oder automatisierte Methoden wie Systemüberwachungsalarme.

Die Analyse des Prozesses auf Basis des Meldekanals kann wichtige Effizienzunterschiede aufzeigen. Beispielsweise könnten Incidents, die über ein Self-Service-Portal gemeldet werden, schneller gelöst werden, da sie oft strukturiertere Informationen im Voraus enthalten. Diese Analyse hilft Organisationen, ihre Supportkanäle zu optimieren und die Nutzung effizienterer Methoden zu fördern.

Es hilft, die Effizienz und die Lösungspfade von Incidents basierend auf ihrer Quelle zu analysieren, was die Kanalstrategie und Ressourcenzuweisung beeinflussen kann.

Diese Information wird üblicherweise automatisch erfasst oder vom Agenten ausgewählt, wenn ein Incident erstellt wird.

Die Priorität ist ein Schlüsselattribut, das verwendet wird, um die relative Wichtigkeit eines Incidents und die erforderliche Reaktionsgeschwindigkeit zu bestimmen. Sie wird oft aus einer Kombination des Impacts und der Dringlichkeit eines Incidents abgeleitet. Die Stufen reichen typischerweise von kritisch bis niedrig.

Im Process Mining ermöglicht die Analyse von Incidents nach Priorität ein tieferes Verständnis dafür, wie der Prozess verschiedene Dringlichkeitsstufen handhabt. Analysten können die Lösungszeiten für Incidents mit hoher im Vergleich zu niedriger Priorität vergleichen, um zu sehen, ob SLAs eingehalten und Ressourcen effektiv zugewiesen werden. Es hilft, Fragen zu beantworten wie: 'Bearbeiten wir unsere kritischsten Incidents tatsächlich am schnellsten?'

Es ermöglicht die Analyse der Prozessperformance für unterschiedliche Dringlichkeitsstufen und hilft zu überprüfen, ob kritische Incidents schneller bearbeitet werden als unkritische.

Verfügbar als Standardfeld im Haupt-Incident-Datensatz. Es kann manuell festgelegt oder automatisch basierend auf Auswirkungen und Dringlichkeit berechnet werden.

Die Severity (Schweregrad) definiert das Ausmaß, in dem ein Incident das Geschäft beeinträchtigt. Sie beantwortet die Frage, wie gravierend das Problem ist, unabhängig von dessen Dringlichkeit. Zum Beispiel wäre ein systemweiter Ausfall ein Incident mit hohem Schweregrad, während ein kleiner kosmetischer Fehler einen geringen Schweregrad hätte.

Die Analyse von Incidents nach Schweregrad hilft Unternehmen zu verstehen, welche Arten von Problemen die größten Störungen verursachen. Process Mining kann aufzeigen, ob Incidents mit hohem Schweregrad einem anderen, optimierten Lösungspfad folgen. Dieses Attribut ist entscheidend für die Ursachenanalyse und die Priorisierung von Ressourcen für ein proaktives Problem Management, um die schwerwiegendsten Incidents zu vermeiden.

Es hilft bei der Segmentierung von Incidents, um zu verstehen, ob Probleme mit hoher Auswirkung anders oder effizienter gelöst werden als Probleme mit geringer Auswirkung.

Ein Standardfeld im Incident-Datensatz, das oft in Verbindung mit der Dringlichkeit zur Bestimmung der Priorität verwendet wird.

Die Assigned Group (zugewiesene Gruppe) gibt an, welches Team zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Incidents werden oft zwischen verschiedenen Gruppen weitergeleitet, wie dem Level 1 Service Desk, einem Level 2 Network Team oder einem Level 3 Application Support Team.

Dieses Attribut ist unerlässlich für die Übergabe- und Workload-Analyse. Process Mining kann diese Daten nutzen, um den Fluss von Incidents zwischen Teams zu visualisieren, die Verweildauer in der Warteschlange jedes Teams zu messen und Bottlenecks zu identifizieren, die durch häufige Neuzuweisungen verursacht werden. Es hilft, Fragen zur Teameffizienz und Zusammenarbeit zu beantworten, und bildet die Grundlage für das Handoff and Reassignment Analysis Dashboard.

Es ist entscheidend für die Analyse von Übergaben zwischen Teams, die Messung von Wartezeiten und das Verständnis der teamspezifischen Performance und Arbeitslastverteilung.

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

Der Assigned Agent (zugewiesener Agent) identifiziert die spezifische Person, die für einen Incident verantwortlich ist. Während die Assigned Group auf das Team verweist, ist der Agent der individuelle Bearbeiter, der an der Lösung arbeitet.

Dieses Attribut ermöglicht eine granularere Leistungs- und Workload-Analyse. Durch die Verfolgung von Zuweisungen auf Agenten-Ebene können Manager die individuelle Produktivität bewerten, Schulungsbedarfe identifizieren und eine ausgewogene Arbeitsverteilung sicherstellen. Im Process Mining kann es komplexe Neuzuweisungsmuster aufdecken, die auf Gruppen-Ebene möglicherweise verborgen bleiben, und hilft, individuelle Beiträge zu den Lösungszeiten zu verstehen.

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

Dieses Feld, das auf dem Haupt-Incident-Record zu finden ist, wird aktualisiert, wenn ein Agent die Zuständigkeit übernimmt oder der Incident ihm zugewiesen wird.

Der Anfragende ist die Person, die das Problem erlebt und den Incident gemeldet hat. Dies könnte ein interner Mitarbeiter oder ein externer Kunde sein. Das Attribut kann auch die Abteilung oder Organisation des Anfragenden erfassen.

Die Analyse von Incidents nach dem Anfragenden oder dessen Abteilung hilft zu erkennen, ob bestimmte Benutzergruppen mehr Probleme haben als andere. Dies kann auf Schulungsbedarf oder lokale Umgebungsprobleme hinweisen. Im Process Mining ermöglicht dies eine benutzerzentrierte Sicht auf den Supportprozess und hilft, das Erlebnis verschiedener Benutzerkohorten zu verstehen.

Es ermöglicht eine benutzerzentrierte Analyse und hilft zu identifizieren, ob bestimmte Benutzer, Abteilungen oder Standorte eine überproportional hohe Anzahl an Incidents verursachen.

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

Die Anzahl der Neu-Zuweisungen ist eine Metrik, die die Anzahl der Weiterleitungen verfolgt, die ein Incident während seines Lebenszyklus durchläuft. Eine hohe Anzahl deutet oft auf Ineffizienz, eine falsche Erstzuweisung oder mangelndes Wissen innerhalb der Support-Teams hin.

Dies ist ein aussagekräftiges Attribut für die Process-Mining-Analyse. Während Process Mining Neu-Zuweisungen visualisieren kann, ermöglicht eine vorkalkulierte Anzahl einfaches Filtern und die Messung von KPIs. Es wird direkt im Dashboard für Handoff- und Neu-Zuweisungsanalysen verwendet und hilft, „Ping-Pong“-Szenarien zu identifizieren, bei denen Tickets zwischen Teams hin- und hergeschoben werden, was zu längeren Lösungszeiten und Benutzerfrustration führt.

Diese Metrik quantifiziert direkt die Prozessineffizienz. Hohe Anzahlen korrelieren oft mit längeren Lösungszeiten und weisen auf Probleme beim Routing oder den Teamfähigkeiten hin.

Oft als standardmäßiges Zählerfeld im Incident-Datensatz verfügbar. Andernfalls kann es durch Zählen der Zuweisungsänderungen im Audit Log des Incidents abgeleitet werden.

Der Affected Service (betroffener Dienst) verknüpft einen Incident mit einer spezifischen Komponente in der IT-Infrastruktur, wie einer Geschäftsanwendung, einem Server oder einem Netzwerkgerät. Dies ist oft an eine Configuration Management Database (CMDB) gekoppelt.

Dieses Attribut liefert einen kritischen Geschäftskontext für den Incident. Im Process Mining ermöglicht es eine Analyse, die sich auf die Zuverlässigkeit spezifischer Services oder Assets konzentriert. Organisationen können identifizieren, welche Services die meisten Incidents verursachen, deren Lösungsprozesse analysieren und die Anstrengungen im Problem Management priorisieren, um die Stabilität kritischer Business Services zu verbessern. Es ist ein Schlüsselelement, um die umfassenderen geschäftlichen Auswirkungen von IT-Incidents zu verstehen.

Es verknüpft Incidents mit spezifischen Business Services oder IT-Komponenten und ermöglicht die Analyse, welche Services am anfälligsten für Probleme sind und welche Auswirkungen diese haben.

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

Der SLA-Status bietet einen Überblick über die Leistung eines Incidents im Vergleich zu vordefinierten Zeitzielen, wie Reaktionszeit oder Lösungszeit. Gängige Status sind „In Bearbeitung“, „Gefährdet“ oder „Verletzt“.

Dieses Attribut ist ein direktes Maß für die Servicequalität und eine kritische Eingabe für das SLA Performance Overview Dashboard. Im Process Mining ermöglicht es den Vergleich von Prozessabläufen für verletzte und nicht verletzte Incidents. Dies hilft, die spezifischen Aktivitäten, Verzögerungen oder Wiederholungsschleifen zu identifizieren, die die Hauptursachen für SLA-Verletzungen sind, und ermöglicht gezielte Prozessverbesserungsmaßnahmen.

Es ist ein direktes Maß für die Performance im Vergleich zu Zielen. Die Analyse verletzter Incidents hilft, die Prozessfehler zu identifizieren, die zu einer schlechten Servicebereitstellung führen.

Dies ist typischerweise ein berechnetes Feld innerhalb des ITSM-Tools, das dynamisch basierend auf der Priorität, dem Alter des Incidents und definierten SLA-Regeln aktualisiert wird.