Daten-Template: Incident Management

ServiceNow Problem Management
Daten-Template: Incident Management

Ihr Incident Management Data Template

Dieses Template bietet eine umfassende Anleitung zur Sammlung der notwendigen Daten, um Ihren Incident Management-Prozess zu analysieren und zu optimieren. Es beschreibt wesentliche Datenattribute, wichtige Activities zur Verfolgung und praktische Anleitungen, wie diese Informationen aus Ihrem Quellsystem extrahiert werden können. Nutzen Sie diese Ressource, um einen robusten Event Log für eine tiefgehende Prozessanalyse und -verbesserung aufzubauen.
  • Empfohlene Attribute zur Erfassung
  • Wichtige Aktivitäten zur Verfolgung
  • Extraktionsanleitung für ServiceNow Problem Management
Neu bei Event Logs? Erfahren Sie wie man ein Process Mining Event Log erstellt.

Incident Management-Attribute

Dies sind die empfohlenen Datenfelder, die in Ihrem Event Log enthalten sein sollten, um eine umfassende Analyse Ihres Incident-Management-Prozesses zu ermöglichen.
5 Erforderlich 4 Empfohlen 11 Optional
Name Beschreibung
Aktivitätsname
ActivityName
Der Name des spezifischen Events oder der Aufgabe, das/die zu einem bestimmten Zeitpunkt innerhalb des Vorfall-Lebenszyklus stattfand.
Beschreibung

Der Activity Name beschreibt einen spezifischen Schritt oder eine Statusänderung im Incident Management Process, wie z. B. „Incident Created“, „Assigned To Agent“ oder „Incident Closed“. Diese Daten werden typischerweise aus Änderungen in wichtigen Incident Fields wie „State“ oder „Assignment Group“ oder aus spezifischen Log Entries abgeleitet.

Dieses Attribut ist entscheidend für den Aufbau der Process Map. Es definiert die Knoten im Process Graph und ermöglicht Analysten, den Flow von Incidents zu visualisieren, gängige Pfade zu identifizieren, Bottlenecks zwischen Activities zu entdecken und Prozessvarianten zu analysieren. Die Granularität und Genauigkeit dieser Activity Names wirken sich direkt auf die Qualität der Process Analysis aus.

Warum es wichtig ist

Es definiert die Schritte in der Process Map, die die Grundlage für alle Process Mining Analysen und Visualisierungen bildet.

Woher erhalten

Dies ist ein abgeleitetes Attribut, das typischerweise durch die Datentransformationslogik basierend auf Änderungen in Feldern wie state, assignment_group und assigned_to in den sys_audit- oder incident-Tabellen generiert wird.

Beispiele
Incident erstelltZuweisungsgruppe geändertLösung vorgeschlagenIncident geschlossen
Ereigniszeit
EventTime
Der präzise Timestamp, der anzeigt, wann die Aktivität stattfand.
Beschreibung

Event Time, oft als Timestamp bezeichnet, erfasst das genaue Datum und die Uhrzeit, zu der eine Aktivität abgeschlossen oder eine Statusänderung erfolgte. In ServiceNow wird dies typischerweise im Feld sys_updated_on für jede im Audit-Trail erfasste Änderung festgehalten.

Dieses Attribut ist unerlässlich für die korrekte Reihenfolge von Events und für alle zeitbasierten Analysen. Es wird verwendet, um Zykluszeiten, Wartezeiten und Dauern zwischen Aktivitäten zu berechnen, die grundlegend sind für die Identifizierung von Engpässen, die Leistungsmessung gegenüber SLAs und das Verständnis der Prozesseffizienz. Die Genauigkeit dieser Timestamps ist entscheidend für die Gültigkeit aller dauernbasierten Metriken.

Warum es wichtig ist

Dieser Timestamp ordnet alle Activities chronologisch und ermöglicht die Berechnung aller dauerbasierten Metriken, wie Cycle Times und Bottlenecks.

Woher erhalten

ServiceNow sys_audit-Tabelle, Feld sys_created_on oder das sys_updated_on-Feld aus der incident-Tabelle für den letzten Status.

Beispiele
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
Incident-ID
IncidentId
Die eindeutige Kennung für jeden Vorfall-Datensatz, die als Primärschlüssel für die Verfolgung des gesamten Lebenszyklus dient.
Beschreibung

Die Vorfall-ID ist die eindeutige Referenznummer, die jedem gemeldeten Vorfall in ServiceNow zugewiesen wird. Sie fungiert als zentraler Case-Identifikator, der alle zugehörigen Aktivitäten, Aktualisierungen und Kommunikationen vom Zeitpunkt der Erstellung eines Vorfalls bis zu dessen Abschluss verknüpft.

In der Process Mining-Analyse ist diese ID grundlegend. Sie ermöglicht es dem Tool, die Abfolge der Events für jeden einzelnen Case zusammenzufügen und bildet die Basis für die Entdeckung von Prozesslandkarten, die Analyse von Varianten und die Berechnung der Ende-zu-Ende-Dauer. Ohne eine eindeutige Vorfall-ID für jeden Case wäre es unmöglich, den Weg eines Vorfalls durch den Lösungsprozess nachzuvollziehen.

Warum es wichtig ist

Dies ist die essentielle Case ID, die alle Events im Lebenszyklus eines Incidents miteinander verbindet und so eine End-to-End-Prozessanalyse ermöglicht.

Woher erhalten

ServiceNow incident-Tabelle, Feld number.

Beispiele
INC0010001INC0010045INC0010239
Letzte Datenaktualisierung
LastDataUpdate
Der Zeitstempel, der angibt, wann die Daten für diesen Datensatz zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung

Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder Datenaktualisierung aus ServiceNow. Es handelt sich um ein Metadatenfeld, das die Aktualität der analysierten Daten widerspiegelt und kein Event im Prozess selbst darstellt.

Diese Information ist entscheidend für das Verständnis der Aktualität der Analyse. Sie zeigt den Nutzern, wie aktuell die Daten sind, was wichtig für operative Dashboards und die Entscheidungsfindung basierend auf aktuellen Events ist. Sie hilft, Erwartungen an die Relevanz und Aktualität der Daten zu steuern.

Warum es wichtig ist

Es informiert Benutzer über die Aktualität der Daten, was entscheidend für die Relevanz und Genauigkeit der Analyse ist.

Woher erhalten

Dieser Timestamp wird vom Datenextraktions-Tool oder Datenextraktionsprozess zum Zeitpunkt des Datenladevorgangs generiert und befüllt.

Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Quellsystem
SourceSystem
Das System, aus dem diese Daten extrahiert wurden.
Beschreibung

Dieses Attribut identifiziert die Herkunft der Incidentdaten, in diesem Fall aus dem ServiceNow Problem Management. Es ist typischerweise ein statischer Wert, der während der Datenextraktions- und Transformationsphase hinzugefügt wird.

In Umgebungen, in denen Daten aus mehreren Systemen für die Analyse kombiniert werden, ist dieses Feld entscheidend für die Datenherkunft und Datentrennung. Es stellt sicher, dass Kennzahlen und Prozesse im richtigen Kontext analysiert werden und ermöglicht es Analysten, Prozesse über verschiedene Quellsysteme hinweg zu vergleichen.

Warum es wichtig ist

Es liefert entscheidenden Kontext zur Datenherkunft, sichert die Data Lineage und ermöglicht eine korrekte Interpretation in Multi-System-Umgebungen.

Woher erhalten

Dies ist typischerweise ein statischer Wert, der während des Datenextraktionsprozesses hinzugefügt wird.

Beispiele
ServiceNow Problem ManagementServiceNow
Incident-Status
IncidentState
Der aktuelle Status des Vorfalls in seinem Lebenszyklus.
Beschreibung

Der Vorfallstatus gibt das aktuelle Stadium des Vorfalls an, z. B. 'Neu', 'In Bearbeitung', 'In Wartestellung' oder 'Gelöst'. Statusänderungen sind oft die primäre Quelle für die Generierung von Aktivitäten im Event Log für Process Mining.

Die Analyse der in jedem Status verbrachten Zeit ist eine effektive Methode, um Engpässe zu identifizieren. Eine lange Dauer im Status 'In Wartestellung' könnte beispielsweise auf Abhängigkeiten von externen Faktoren oder Benutzern hinweisen. Die Abfolge der Statusänderungen bildet auch die Basis der Prozesslandkarte und zeigt, wie Vorfälle bis zur Lösung voranschreiten.

Warum es wichtig ist

Es verfolgt den Fortschritt des Incidents und ist entscheidend für die Analyse der in verschiedenen Phasen verbrachten Zeit und die Identifizierung von Process Bottlenecks.

Woher erhalten

ServiceNow incident-Tabelle, Feld incident_state oder state.

Beispiele
NeuIn BearbeitungWartet auf BenutzerinformationenResolvedGeschlossen
Priorität
Priority
Die Prioritätsstufe des Vorfalls, die die erforderliche Dringlichkeit der Reaktion vorgibt.
Beschreibung

Priorität ist ein zentrales Feld in ServiceNow, das die Reihenfolge und Geschwindigkeit der Incident-Bearbeitung festlegt. Sie leitet sich typischerweise aus dem Impact und der Urgency des Incidents ab und beeinflusst direkt die SLA-Ziele.

Dieses Attribut ist grundlegend für die Segmentierung und Performance-Analyse. Das Dashboard "SLA Compliance Overview" nutzt die Priorität, um zu bewerten, ob hochpriorisierte Incidents innerhalb ihrer Zielzeiten gelöst werden. Die Analyse der Cycle Times nach Priorität hilft zu bestätigen, dass kritische Incidents tatsächlich schneller bearbeitet werden als weniger wichtige. Es ist eine entscheidende Dimension für fast jedes KPI und Dashboard.

Warum es wichtig ist

Es ermöglicht die Segmentierung von Incidents nach geschäftlicher Bedeutung, was für die Überwachung der SLA-Compliance und die Ressourcenzuweisung entscheidend ist.

Woher erhalten

ServiceNow incident-Tabelle, Feld priority.

Beispiele
1 - Kritisch2 - Hoch3 - Moderat4 - Niedrig
Zugeordnet an
AssignedTo
Der einzelne Benutzer oder Agent, dem derzeit die Bearbeitung des Vorfalls zugewiesen ist.
Beschreibung

Dieses Attribut identifiziert den jeweils für den Incident zuständigen Supportmitarbeiter. Diese Information ist entscheidend, um die Arbeitslastverteilung, die Mitarbeiterleistung und Übergaben zwischen Mitarbeitenden zu verstehen.

In der Analyse hilft 'Assigned To' bei der Visualisierung der Ressourcenallokation und der Identifizierung überlasteter Mitarbeiter. Es wird auch im Handoff and Reassignment Dashboard verwendet, um zu verfolgen, wie oft ein Incident seinen Bearbeiter wechselt, was ein Indikator für Ineffizienz oder Wissenslücken sein kann. Die Analyse der Lösungszeiten pro Mitarbeiter kann zudem Spitzenleistungen hervorheben oder Mitarbeiter mit Schulungsbedarf aufzeigen.

Warum es wichtig ist

Es ermöglicht die Analyse der Agentenarbeitslast, Leistung und individuellen Übergaben, die entscheidend für das Verständnis der Ressourceneffizienz sind.

Woher erhalten

ServiceNow incident-Tabelle, Feld assigned_to.

Beispiele
Beth AnglinDavid LooHoward Johnson
Zuweisungsgruppe
AssignmentGroup
Das Support-Team oder die Gruppe, die für die Bearbeitung des Vorfalls verantwortlich ist.
Beschreibung

Die Zuweisungsgruppe stellt das Agententeam dar, das für die Behebung eines Vorfalls zuständig ist. Vorfälle werden oft zwischen verschiedenen Gruppen weitergeleitet, z. B. von einem Level-1-Helpdesk an ein spezialisiertes Level-2-Netzwerkteam.

Dieses Attribut ist entscheidend für die Analyse von teamübergreifenden Übergaben und die Identifizierung systemischer Engpässe. Das Dashboard 'Übergabe- und Neuzuweisungsrate' stützt sich stark auf diese Daten, um zu zeigen, welche Teams häufig in Weiterleitungen involviert sind. Es ermöglicht auch Leistungsvergleiche zwischen verschiedenen Support-Gruppen und hilft zu verstehen, wo die Lösungskompetenz innerhalb der Organisation liegt.

Warum es wichtig ist

Dies verfolgt, welches Team verantwortlich ist, und ermöglicht die Analyse von Teamleistung, Arbeitslast und Handoffs zwischen Gruppen.

Woher erhalten

ServiceNow incident-Tabelle, Feld assignment_group.

Beispiele
Service Desk**Netzwerk-Support**Datenbankadministratoren
Anrufer
CallerId
Der Benutzer, der den Vorfall ursprünglich gemeldet hat.
Beschreibung

Der Melder identifiziert den Endbenutzer oder Kunden, der vom Vorfall betroffen ist und ihn gemeldet hat. Diese Information gibt Aufschluss darüber, wer von Serviceunterbrechungen betroffen ist.

Obwohl nicht immer zentral für den Prozessfluss selbst, kann die Analyse von Vorfällen nach Melder aufzeigen, ob spezifische Einzelpersonen oder Abteilungen unverhältnismäßig stark von Problemen betroffen sind. Dies kann auf Schulungsbedarf oder lokale Umgebungsprobleme hinweisen. Es bietet auch eine direkte Verbindung zum Kunden für Zufriedenheitsumfragen und Kommunikation.

Warum es wichtig ist

Es identifiziert den betroffenen Benutzer, was eine Analyse nach Abteilung oder Individuum ermöglicht und Kontext für die Benutzerkommunikation bietet.

Woher erhalten

ServiceNow incident-Tabelle, Feld caller_id.

Beispiele
Abel TuterCarolina PashDon Goodliffe
Anzahl der Neuzuweisungen
ReassignmentCount
Die Anzahl der Neuzuweisungen des Vorfalls an eine andere Gruppe oder einen anderen Agenten.
Beschreibung

Dieses Feld verfolgt die gesamte Anzahl der Übertragungen eines Incidents zwischen verschiedenen Zuordnungsgruppen (Assignment Groups). Es ist ein direktes Maß für Prozessreibung und wird oft als wichtiger Leistungsindikator (KPI) verwendet.

Dieses Attribut ist der primäre Treiber für das Handoff and Reassignment Rate Dashboard und den KPI Average Handoffs per Incident. Eine hohe Anzahl von Neuzuordnungen deutet oft auf Probleme wie falsche anfängliche Weiterleitung, mangelnde Fähigkeiten in einer Supportstufe oder unklare Prozessverantwortung hin. Die Reduzierung dieser Zahl ist ein häufiges Ziel für Prozessverbesserungsinitiativen, da sie typischerweise zu schnelleren Lösungszeiten führt.

Warum es wichtig ist

Dies misst direkt Prozessübergaben (Handoffs), einen Schlüsselindikator für Ineffizienz, falsche Weiterleitung und Verbesserungspotenziale.

Woher erhalten

ServiceNow incident-Tabelle, Feld reassignment_count.

Beispiele
0135
Durchlaufzeit
CycleTime
Die Gesamtdauer von der Erstellung eines Vorfalls bis zu seinem Abschluss.
Beschreibung

Die Cycle Time ist eine berechnete Metrik, die die End-to-End-Dauer des Incident Management Prozesses für einen einzelnen Case darstellt. Sie wird typischerweise als Differenz zwischen dem 'Closed'-Timestamp und dem 'Created'-Timestamp berechnet.

Dies ist eine der fundamentalsten KPIs im Process Mining, die das 'Incident Resolution Cycle Time'-Dashboard direkt unterstützt. Die Analyse der durchschnittlichen Cycle Time sowie ihrer Verteilung hilft Organisationen, die Gesamteffizienz zu messen, Leistungs-Baselines festzulegen und die Auswirkungen von Prozessänderungen zu identifizieren. Die Aufschlüsselung dieser Metrik nach Attributen wie Priorität oder Kategorie zeigt, welche Arten von Vorfällen am längsten zur Behebung benötigen.

Warum es wichtig ist

Dieser zentrale KPI misst die End-to-End-Effizienz des Prozesses und wird verwendet, um langwierige Cases zu identifizieren und die Gesamtleistung zu verfolgen.

Woher erhalten

Berechnet durch Subtraktion des ersten Event-Timestamps vom letzten Event-Timestamps für jede Incident ID.

Beispiele
2592008640001209600
Kategorie
Category
Die übergeordnete Klassifizierung des Vorfalls, wie Hardware, Software oder Netzwerk.
Beschreibung

Die Kategorie bietet eine allgemeine Klassifizierung der Vorfallart. Dies hilft, oft in Kombination mit einer Unterkategorie, bei der Weiterleitung des Vorfalls an das richtige Support-Team und wird für die Berichterstattung und Trendanalyse verwendet.

Für Process Mining ist dieses Attribut entscheidend für die Dashboards 'Genauigkeit der Vorfallkategorisierung' und 'Volumen wiederkehrender Vorfälle'. Durch die Analyse von Vorfällen, bei denen die Kategorie während des Prozesses geändert wird, können Organisationen Probleme bei der initialen Triage identifizieren. Das Filtern der Prozesslandkarte nach Kategorie kann auch aufzeigen, ob bestimmte Arten von Vorfällen unterschiedliche Lösungspfade verfolgen oder einzigartige Engpässe aufweisen.

Warum es wichtig ist

Es ermöglicht die Analyse von Incident-Typen, hilft bei der Messung der Kategorisierungsgenauigkeit und ist entscheidend für das Routing und die Trendanalyse.

Woher erhalten

ServiceNow incident-Tabelle, Feld category.

Beispiele
HardwareSoftware**Netzwerk**Datenbank
Konfigurationselement
ConfigurationItem
Die spezifische IT-Komponente, der Service oder das Asset, die/das vom Vorfall betroffen ist.
Beschreibung

Das Konfigurationselement (CI) ist das Asset aus der Configuration Management Database (CMDB), das vom Vorfall betroffen ist. Dies kann ein Server, eine Anwendung, ein Laptop oder ein Netzwerkgerät sein.

Die Analyse von Vorfällen nach CI ist äußerst wertvoll, um unzuverlässige Assets oder Services zu identifizieren. Sie hilft dabei, die Teile der IT-Infrastruktur zu lokalisieren, die die meisten Vorfälle verursachen. Dies kann Investitionen in Upgrades oder Ersetzungen steuern. Im Process Mining kann das Filtern nach CI aufzeigen, ob Vorfälle im Zusammenhang mit kritischen Anwendungen anders oder effizienter behandelt werden als andere.

Warum es wichtig ist

Es identifiziert das betroffene Asset, was hilft, problematische Komponenten in der IT-Infrastruktur zu lokalisieren und Verbesserungsbemühungen zu fokussieren.

Woher erhalten

ServiceNow incident-Tabelle, Feld cmdb_ci.

Beispiele
SAP ERP ProductionOracle DB Server 05E-Mail-Dienst
Lösungscode
ResolutionCode
Ein Code, der angibt, wie der Incident letztendlich gelöst wurde.
Beschreibung

Der Lösungscode gibt die Art der angewendeten Lösung an, z. B. ob sie durch einen Benutzer gelöst, durch einen bekannten Fehler behoben oder ob eine Problemumgehung bereitgestellt wurde. Dieses Feld wird typischerweise vom Agenten beim Schließen des Vorfalls ausgefüllt.

Dieses Attribut unterstützt direkt das Dashboard 'Effektivität der Lösungsart'. Es ermöglicht die Analyse, wie viele Vorfälle mit dauerhaften Lösungen im Vergleich zu temporären Problemumgehungen geschlossen werden, was ein Schlüsselindikator für Servicequalität und langfristige Stabilität ist. Eine hohe Rate an Problemumgehungen könnte darauf hindeuten, dass zugrunde liegende Probleme nicht angemessen behandelt werden.

Warum es wichtig ist

Es klärt die Lösungsmethode, was die Analyse dauerhafter Lösungen gegenüber temporären Workarounds ermöglicht und die Ursachenanalyse unterstützt.

Woher erhalten

ServiceNow incident-Tabelle, Feld close_code oder ein benutzerdefiniertes Lösungs-Code-Feld.

Beispiele
Gelöst (Workaround)Gelöst (Dauerhaft)Nicht gelöst (**Benutzer** abgebrochen)Bekannter **Fehler**
Problem-ID
ProblemId
Die Kennung des zugehörigen Problemdatensatzes, wenn der Vorfall mit einem größeren Problem verknüpft ist.
Beschreibung

Die Problem-ID verknüpft einen Vorfall mit einem entsprechenden Datensatz im Problemmanagement-Modul. Dies geschieht, wenn ein Vorfall als Symptom eines größeren, zugrunde liegenden Problems identifiziert wird, das mehrere Benutzer oder Services betrifft.

Diese Verknüpfung ist entscheidend für das Dashboard 'Volumen wiederkehrender Vorfälle' und den KPI 'Rate wiederkehrender Vorfälle'. Sie ermöglicht es Analysten, Vorfälle zu gruppieren, die aus derselben Grundursache stammen, die vollen Auswirkungen eines Problems zu messen und die Wirksamkeit der Problemlösungsbemühungen zu verfolgen. Eine hohe Anzahl von Vorfällen, die mit Problemen verknüpft sind, weist auf eine reaktive Support-Umgebung hin.

Warum es wichtig ist

Es verknüpft Incidents mit einer Ursache, was wesentlich für die Analyse wiederkehrender Probleme und die Messung des Einflusses des Problem Managements ist.

Woher erhalten

ServiceNow incident-Tabelle, Feld problem_id.

Beispiele
PRB0040001PRB0040015PRB0040102
Schweregrad
Severity
Das Ausmaß der geschäftlichen Auswirkungen, die durch den Vorfall verursacht wurden.
Beschreibung

Severity definiert, wie stark ein Incident die Geschäftsabläufe beeinträchtigt. Zusammen mit der Urgency wird sie oft verwendet, um die Priorität des Incidents automatisch zu berechnen.

In der Analyse ist die Severity eine Schlüsseldimension für das Dashboard "SLA Compliance Overview". Sie hilft Organisationen zu verstehen, ob sie die Service Levels für die störendsten Incidents einhalten. Sie bietet eine geschäftszentrierte Sicht auf die Performance und ergänzt die operative Sicht, die durch die Priorität gegeben ist.

Warum es wichtig ist

Es misst die geschäftlichen Auswirkungen eines Incidents und bietet eine entscheidende Dimension für die Priorisierung von Anstrengungen und die Analyse der Leistung bei kritischen Problemen.

Woher erhalten

ServiceNow incident-Tabelle, Feld severity.

Beispiele
1 - Hoch2 - Mittel3 - Niedrig
SLA Due Date
SlaDueDate
Das Zieldatum und die Zielzeit, bis zu der der Vorfall gemäß seinem SLA voraussichtlich gelöst werden soll.
Beschreibung

Das SLA-Fälligkeitsdatum ist ein berechneter Timestamp, der die Lösungsfrist für einen Vorfall darstellt. Dieses Datum wird durch das Service Level Agreement (SLA) bestimmt, das mit den Merkmalen des Vorfalls wie seiner Priorität verbunden ist.

Dieses Attribut ist unerlässlich für das Dashboard 'SLA-Compliance-Übersicht' und den KPI 'Rate der Nichteinhaltung von SLAs bei kritischen Vorfällen'. Es dient als Maßstab, mit dem die tatsächliche Lösungszeit verglichen wird. Die Analyse von Vorfällen, die kurz vor ihrem SLA-Fälligkeitsdatum stehen, kann bei der proaktiven Eskalation und Priorisierung helfen.

Warum es wichtig ist

Es definiert das Lösungsziel, wodurch die Messung der SLA-Compliance und die Identifizierung von Incidents, die Gefahr laufen, ihre Ziele zu überschreiten, ermöglicht wird.

Woher erhalten

Dieser Wert findet sich typischerweise in der task_sla-Tabelle, die mit der incident-Tabelle verknüpft ist. Das Feld planned_end_time ist der relevante Timestamp.

Beispiele
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
SLA verletzt
IsSlaBreached
Ein Kennzeichen, das anzeigt, ob die Incident-Lösung das fällige SLA-Datum überschritten hat.
Beschreibung

Dies ist ein berechnetes boolesches Attribut, das Incidents als SLA-verstoßend kennzeichnet. Es wird abgeleitet, indem der tatsächliche Lösungs-Timestamp mit dem 'SLA Due Date' verglichen wird. Liegt die Lösungszeit nach dem Fälligkeitsdatum, wird das Flag auf „true“ gesetzt.

Dieses Attribut ist die Grundlage für das SLA Compliance Overview Dashboard und verwandte KPIs. Es vereinfacht die Analyse, indem ein komplexer Zeitvergleich in eine einfache „wahr/falsch“-Dimension umgewandelt wird. Dies erleichtert das Filtern aller SLA-verstoßenden Incidents und die Analyse ihrer gemeinsamen Merkmale wie Kategorie, Zuordnungsgruppe (Assignment Group) oder Priorität.

Warum es wichtig ist

Es vereinfacht die SLA-Compliance-Analyse, ermöglicht einfaches Filtern und eine detaillierte Analyse aller Incidents, die ihre Ziele nicht erreicht haben.

Woher erhalten

Berechnet durch den Vergleich des 'Resolved At'-Timestamps mit dem 'SlaDueDate'-Timestamp. (Resolved At > SlaDueDate).

Beispiele
truefalsch
Wiedereröffnet
IsReopened
Ein Kennzeichen, das angibt, ob ein Incident nach seiner Lösung wiedereröffnet wurde.
Beschreibung

Dieses boolesche Flag wird auf „true“ gesetzt, wenn der Status eines Incidents wieder auf „aktiv“ (z. B. 'In Progress') geändert wurde, nachdem er zuvor den Status 'Resolved' oder 'Closed' erreicht hatte. Dies wird typischerweise durch die Suche nach der 'Incident Reopened'-Activity im Event Log identifiziert.

Wiedereröffnete Incidents sind ein starker Indikator für unvollständige oder ineffektive Lösungen. Die Analyse dieser Cases hilft, vorzeitige Abschlüsse oder wiederkehrende Probleme zu identifizieren, die beim ersten Mal nicht richtig behoben wurden. Eine hohe Wiedereröffnungsrate kann die Benutzerzufriedenheit und Teamproduktivität negativ beeinflussen, was dies zu einer Schlüsselmetrik für die Qualitätskontrolle macht.

Warum es wichtig ist

Dieses Flag identifiziert Fehler im Lösungsprozess und hebt Incidents hervor, die nach ihrer vermeintlichen Lösung zusätzliche Arbeit erforderten.

Woher erhalten

Berechnet durch Überprüfung der Abfolge von Aktivitäten für jeden Vorfall, um festzustellen, ob ein 'offener' Status einem 'gelösten' Status folgt.

Beispiele
truefalsch
Erforderlich Empfohlen Optional

Incident Management-Aktivitäten

Dies sind die zentralen Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um eine präzise Process Discovery und Prozessoptimierung zu gewährleisten.
6 Empfohlen 7 Optional
Aktivität Beschreibung
Arbeit begonnen
Zeigt an, dass ein **Agent** aktiv mit der **Untersuchung** oder **Bearbeitung** des **Incidents** begonnen hat. Dies wird in der **Regel** abgeleitet, wenn der **Status** des **Incidents** von 'Neu' oder 'Zugewiesen' in einen aktiven **Status** wie 'In Bearbeitung' wechselt.
Warum es wichtig ist

Dieser Meilenstein markiert das Ende der anfänglichen Wartezeit (Queue Time) und den Beginn der aktiven Lösungsbemühungen. Die Messung der Zeit, bis Arbeit beginnt, ist entscheidend für die Bottleneck-Analyse.

Woher erhalten

Abgeleitet aus der Tabelle 'sys_audit' durch Identifizierung, wann das Feld 'state' in der Tabelle 'incident' in einen Wert wechselt, der aktive Arbeit darstellt, wie 'In Bearbeitung'.

Erfassen

Identifizieren Sie den Timestamp, wenn sich das Feld 'state' in 'In Progress' oder einen ähnlichen Wert ändert.

Ereignistyp inferred
Incident an Gruppe zugewiesen
Diese Aktivität tritt auf, wenn ein Vorfall einer spezifischen Support-Gruppe zur Bearbeitung zugewiesen wird. Sie ist ein Schlüsselschritt im Routing-Prozess und wird durch die Beobachtung von Änderungen im Feld der Zuweisungsgruppe erfasst.
Warum es wichtig ist

Die Verfolgung von Zuweisungen ist unerlässlich, um Handoffs, Wartezeiten (Queue Times) für jede Gruppe und Ineffizienzen bei der Weiterleitung oder Bottlenecks zu analysieren.

Woher erhalten

Abgeleitet aus der Tabelle 'sys_audit' durch Nachverfolgung, wann das Feld 'assignment_group' in der Tabelle 'incident' gefüllt oder geändert wird.

Erfassen

Nutzen Sie den Timestamp aus dem Audit-Log für Änderungen am Feld 'assignment_group'.

Ereignistyp inferred
Incident erstellt
Markiert den **Beginn** des Incident-**Lebenszyklus**, wenn ein neuer Incident formal in **ServiceNow** protokolliert wird. Dieses Event wird explizit mit dem **Erstellungs-Timestamp** des Incident Records erfasst.
Warum es wichtig ist

Dies ist das primäre Start-Event für den Prozess. Die Analyse der Zeit von dieser Activity bis zur Lösung ist grundlegend für die Messung der gesamten Cycle Time und SLA Compliance.

Woher erhalten

Der sys_created_on-Timestamp in der incident-Tabelle dient als expliziter Event Timestamp für diese Activity.

Erfassen

Nutzen Sie den 'sys_created_on' Timestamp aus dem Incident-Datensatz.

Ereignistyp explicit
Incident geschlossen
Dies ist die abschließende Activity im Lebenszyklus, die anzeigt, dass der Incident vollständig gelöst, bestätigt und keine weiteren Maßnahmen erforderlich sind. Das Event wird explizit über den Abschluss-Timestamp erfasst.
Warum es wichtig ist

Als definitiver End-Event ist diese Aktivität entscheidend für die Berechnung der gesamten Lebenszyklusdauer von Vorfällen und die Analyse der Zeit, die für die Nachbearbeitung nach der Lösung benötigt wird.

Woher erhalten

Der closed_at-Timestamp in der incident-Tabelle dient als expliziter Event Timestamp. Dieser wird typischerweise gesetzt, wenn sich das state-Feld in „Closed“ ändert.

Erfassen

Nutzen Sie den 'closed_at' Timestamp aus dem Incident-Datensatz.

Ereignistyp explicit
Lösung vorgeschlagen
Markiert den **Zeitpunkt**, an dem ein **Support-Agent** eine **Lösung** implementiert und den **Incident** in den **Status** 'Gelöst' versetzt hat. Dies ist ein wichtiger **Meilenstein** vor dem endgültigen **Abschluss**.
Warum es wichtig ist

Diese Aktivität signalisiert das Ende der aktiven Arbeit und den Beginn der Bestätigungsphase. Die Zeit zwischen diesem Status und 'Vorfall geschlossen' kann Verzögerungen bei der Benutzerbestätigung oder –verifizierung aufzeigen.

Woher erhalten

Abgeleitet aus der Tabelle 'sys_audit', wenn das Feld 'state' in der Tabelle 'incident' zu 'Gelöst' wechselt. Der 'resolved_at' Timestamp wird oft zu diesem Zeitpunkt gefüllt.

Erfassen

Nutzen Sie den Timestamp, wenn das Statusfeld 'Resolved' wird, oder den 'resolved_at' Timestamp.

Ereignistyp inferred
Zuweisungsgruppe geändert
Stellt eine Übergabe (Handoff) dar, bei der ein Incident von einer Support-Gruppe an eine andere übertragen wird. Dies wird durch die Beobachtung nachfolgender Änderungen im assignment_group-Feld nach dessen Erstbefüllung erfasst.
Warum es wichtig ist

Häufige Neuvergaben können auf eine falsche anfängliche Weiterleitung, Prozesskomplexität oder Wissenslücken hindeuten. Diese Aktivität ist entscheidend für die Messung des KPI 'Durchschnittliche Übergaben pro Incident'.

Woher erhalten

Abgeleitet aus der Tabelle 'sys_audit' durch Nachverfolgung jeder Änderung am Feld 'assignment_group' nach der anfänglichen Zuweisung.

Erfassen

Identifizieren Sie jede mit einem Timestamp versehene Änderung des Feldes 'assignment_group' im Audit-Log.

Ereignistyp inferred
Incident an Agent zugewiesen
Stellt den Zeitpunkt dar, an dem ein spezifischer Agent innerhalb einer Support-Gruppe die Verantwortung für den Incident übernimmt. Dies wird durch die Überwachung von Änderungen im assigned_to-Feld erfasst.
Warum es wichtig ist

Dies bietet einen detaillierten Einblick in die Arbeitslast der Mitarbeiter und die Erstkontaktlösung. Es hilft zu bestimmen, wie lange Incidents auf einen Mitarbeiter warten, bis die Arbeit beginnt, nachdem sie einer Gruppe zugewiesen wurden.

Woher erhalten

Abgeleitet aus der Tabelle 'sys_audit' durch Nachverfolgung, wann das Feld 'assigned_to' in der Tabelle 'incident' gefüllt oder geändert wird.

Erfassen

Nutzen Sie den Timestamp aus dem Audit-Log für Änderungen am Feld 'assigned_to'.

Ereignistyp inferred
Incident eskaliert
Tritt auf, wenn die **Priorität** oder **Schwere** eines **Incidents** erhöht wird, was oft eine schnellere **Reaktion** oder andere **Ressourcen** erfordert. Dies wird durch die **Erkennung** einer **Erhöhung** des **Wertes** im **Feld** 'Priorität' abgeleitet.
Warum es wichtig ist

Eskalationen deuten oft darauf hin, dass ein Incident schwerwiegender ist als ursprünglich angenommen oder kurz vor einer SLA-Verletzung steht. Die Analyse dieser Events hilft, Prozessausnahmen zu verstehen.

Woher erhalten

Abgeleitet aus der Tabelle 'sys_audit' durch Identifizierung einer Änderung im Feld 'Priorität' zu einem Wert mit höherer Dringlichkeit.

Erfassen

Erkennt, wenn der Wert des Feldes 'priority' ansteigt (z.B. von '3 - Moderate' zu '2 - High').

Ereignistyp inferred
Incident kategorisiert
Stellt die initiale Klassifizierung des Incidents dar, bei der Felder wie Category, Subcategory und Priority festgelegt werden. Dieses Event wird typischerweise aus dem Audit Trail abgeleitet, wenn diese Felder erstmals befüllt oder kurz nach der Erstellung aktualisiert werden.
Warum es wichtig ist

Eine präzise Kategorisierung ist entscheidend für die korrekte Weiterleitung und Priorisierung. Das Verfolgen dieser Aktivität hilft, Rekategorisierungsraten und deren Auswirkungen auf die Lösungszeit zu analysieren.

Woher erhalten

Abgeleitet aus der Tabelle 'sys_audit' durch Identifizierung der ersten Änderung in Feldern wie 'Kategorie', 'Unterkategorie' oder 'Priorität' für einen bestimmten Incident.

Erfassen

Identifizieren Sie den Timestamp der ersten Aktualisierung von Klassifizierungsfeldern im Audit-Log.

Ereignistyp inferred
Incident mit Problem verknüpft
Diese Aktivität tritt auf, wenn ein Vorfall formal mit einem Problemdatensatz verknüpft wird, was darauf hinweist, dass er Teil eines größeren, zugrunde liegenden Problems ist. Dies wird abgeleitet, wenn das Feld 'problem_id' im Vorfall-Datensatz gefüllt wird.
Warum es wichtig ist

Die Verknüpfung mit einem Problem ist ein entscheidender Schritt, um von der reaktiven Incident-Behebung zur proaktiven Ursachenanalyse überzugehen. Sie unterstützt das Dashboard 'Wiederkehrendes Incident-Volumen'.

Woher erhalten

Abgeleitet durch die Erkennung, wenn das Referenzfeld 'problem_id' in der Tabelle 'incident' mit einem Wert gefüllt wird.

Erfassen

Identifizieren Sie den Timestamp aus dem Audit-Log, wenn das Feld 'problem_id' gefüllt wird.

Ereignistyp inferred
Incident wiedereröffnet
Tritt auf, wenn ein **Benutzer** meldet, dass das **Problem** weiterhin besteht, nachdem es als gelöst markiert wurde. Dies wird abgeleitet, wenn der Incident-**Status** von 'Gelöst' zurück in einen aktiven **Status** wie 'In Bearbeitung' wechselt.
Warum es wichtig ist

Wiedereröffnete Incidents deuten auf gescheiterte Lösungen und Nacharbeit (Rework) hin. Die Verfolgung dieser Activity ist entscheidend für die Messung der Lösungsqualität und der First-Time Fix Rates.

Woher erhalten

Abgeleitet aus der Tabelle 'sys_audit' durch Erkennung eines Statusfeld-Übergangs von 'Gelöst' zurück in einen aktiven Status wie 'In Bearbeitung' oder 'Zugewiesen'.

Erfassen

Identifizieren Sie den Timestamp, wenn 'state' von 'Resolved' zu einem aktiven Wert wechselt.

Ereignistyp inferred
Support-Kommentar hinzugefügt
Ein Support-Mitarbeiter fügt eine Arbeitsnotiz oder einen für den Benutzer sichtbaren Kommentar hinzu. Dies ist ein explizites Ereignis, das im Aktivitäten-Stream des Incidents protokolliert wird.
Warum es wichtig ist

Verfolgt Kommunikations- und Untersuchungsbemühungen des Support-Teams. Die Analyse der Häufigkeit und des Zeitpunkts dieser Kommentare liefert Einblicke in den Untersuchungsprozess.

Woher erhalten

Erfasst aus der Tabelle 'sys_journal_field', die Einträge für die Felder 'work_notes' und 'comments' in der Tabelle 'incident' protokolliert.

Erfassen

Nutzen Sie den Erstellungs-Timestamp von Journaleinträgen, bei denen das Element 'work_notes' oder 'comments' ist.

Ereignistyp explicit
Warten auf Benutzerbestätigung
Der Vorfall befindet sich in einem schwebenden Zustand und wartet darauf, dass der Benutzer bestätigt, dass die vorgeschlagene Lösung erfolgreich war. Dies wird typischerweise aus einem bestimmten Status wie 'Warten auf Benutzerinformationen' nach der Lösung abgeleitet.
Warum es wichtig ist

Dieser Status kann ein erhebliches Bottleneck darstellen, wenn Benutzer langsam reagieren. Die Messung der in dieser Activity verbrachten Zeit hilft, Kommunikationslücken und Möglichkeiten zur Automatisierung des Abschlusses zu identifizieren.

Woher erhalten

Abgeleitet aus der Tabelle 'sys_audit' durch Identifizierung einer Änderung in einen spezifischen Wartezustand nach der Lösung. Der Statusname kann benutzerdefiniert sein, wie zum Beispiel 'Wartet auf Anrufer'.

Erfassen

Identifizieren Sie den Timestamp, wenn sich 'state' in einen Wert ändert, der auf eine Benutzeraktion wartet.

Ereignistyp inferred
Empfohlen Optional

Extraktionsleitfäden

Wie Sie Ihre Daten aus dem ServiceNow Problem Management erhalten