Ihr Incident-Management Daten Template

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 Ereignisse, Statusänderungen und Aktivitäten zu einer einzigen, zusammenhängenden Prozessinstanz zusammenzufügen. Indem alle Ereignisse 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 Ereignisse 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 in der Regel im Header oder HauptDatensatz jeder Incident-Tabelle oder jedes Objekts gefunden.

Der Aktivitätsname (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 Prozessablauf dar und können automatisierte System Ereignisse wie 'SLA Breach Detected' oder manuelle Benutzeraktionen wie 'Agent Assigned' oder 'Workaround Provided' umfassen.

Für die Process Mining-Analyse ist dieses Attribut wichtig. Es definiert die Knoten im Prozessgraphen und ermöglicht Analysten, den Workflow zu visualisieren, gängige Pfade zu identifizieren, Engpässe zu entdecken und Abweichungen vom Standardverfahren zu analysierenn. Die Granularität und Klarheit der Aktivitätsnamen wirken sich direkt auf die Qualität und Tiefe der ableitbaren Erkenntnisse 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 Zeitstempel kennzeichnet den genauen Zeitpunkt, zu dem eine Aktivität stattgefunden hat. Jede Aktivität innerhalb des Lebenszyklus eines Incidents sollte einen entsprechenden Zeitstempel haben, um eine chronologische Abfolge von Ereignissen zu etablieren.

Dieses Attribut ist maßgeblich für jede zeitbasierte Process-Mining-Analyse. Es ermöglicht die Berechnung von Durchlaufzeiten zwischen Aktivitäten, die Dauer spezifischer Schritte und die Gesamtlösungszeit des Incidents. Durch die Analyse von Zeitstempels 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 den Antrag bearbeitet.urchschnittlichen Lösungszeit.

Es liefert die chronologische Reihenfolge der Ereignisse, was notwendig ist, um Dauern, Engpässe zu berechnen und die Prozess-Performance über die Zeit zu analysierenn.

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

Der Zeitstempel 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 EchtzeitHinweisrmationen oder eine Momentaufnahme aus einem früheren Zeitpunkt betrachten. Dieser Kontext ist maßgeblich 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 in der Regel während des Datenextraktions- 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 wichtig 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 in der Regel 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 maßgeblich 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-Typn 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, ausstehende Zahlungen identifizieren.end, gelöst und geschlossen.

Dieses Attribut ist die Basis 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 maßgeblich, 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 finden.

Typischerweise als primäres Feld im HauptDatensatz des Incidents oder im Änderungsprotokoll 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 wichtigen 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 geverwendet werden können, um eine WissensDatenbank aufzubauen und die First Contact Resolution-Raten zu verbessern.

Es bietet Einblicke, wie Probleme gelöst werden, was wichtig 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 pflegen.

Es hilft, die Effizienz und die Lösungspfade von Incidents basierend auf ihrer Quelle zu analysierenn, 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 in der Regel 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 Prozess-Performance 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 maßgeblich für die Ursachenanalyse und die Priorisierung von Ressourcen für ein proaktives Problemmanagement, 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 einsetzen, um den Fluss von Incidents zwischen Teams zu visualisieren, die Verweildauer in der Warteschlange jedes Teams zu messen und Engpässe 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 maßgeblich für die Analyse von Übergaben zwischen Teams, die Messung von Wartezeiten und das Verständnis der teamspezifischen Leistungsfähigkeit und Arbeitslastverteilung.

Diese Information wird in der Regel 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, Leistungsfähigkeit und der Neuzuweisungsmuster innerhalb oder zwischen Teams.

Dieses Feld, das auf dem Haupt-Incident-Datensatz zu finden ist, wird aktualisiert, wenn ein Agent die Zuständigkeit übernimmt oder den Antrag bearbeitet.er 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 den Antrag bearbeitet.essen 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 in der Regel mit dem Benutzer gefüllt wird, der den Antrag bearbeitet.as 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 Neine Erstzuweisung oder mangelndes Wissen innerhalb der Kundensupports 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 Antrag bearbeitet.en 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 Datenbase (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 Dienste oder Assets konzentriert. Organisationen können identifizieren, welche Dienste die meisten Incidents verursachen, deren Lösungsprozesse analysierenn und die Anstrengungen im Problemmanagement priorisieren, um die Stabilität kritischer Business Dienste zu verbessern. Es ist ein Schlüsselelement, um die vollständigeren geschäftlichen Auswirkungen von IT-Incidents zu verstehen.

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

Typischerweise aus einer Configuration Management Datenbase (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 Leistungsfähigkeit Übersicht 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-Verstöße sind, und ermöglicht gezielte Prozessoptimierungsmaßnahmen.

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

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