> Kontinuierliche Prozessverbesserung > Incident Management > ServiceNow Problem Management > Daten Template

Ihr Daten-Template für das Incident Management

ServiceNow Problem Management

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Incident Managements(19) Aktivitäten im Incident Management(13) Anleitungen zum Extrahieren von Daten(2)

Ihr Daten-Template für das Incident Management

Dieses Template zeigt, welche Daten Sie erfassen sollten, um Ihren Incident-Management-Prozess zu analysieren und zu optimieren. Es beschreibt die erforderlichen Datenattribute und wichtigen Aktivitäten sowie die Schritte zum Extrahieren dieser Informationen aus Ihrem Quellsystem. Verwenden Sie diese Anleitung, um ein aussagekräftiges Event Log für eine detaillierte Prozessanalyse und Verbesserungen zu erstellen.

Empfohlene Attribute
Wichtige Aktivitäten zur Erfassung
Anleitung zum Extrahieren von Daten aus ServiceNow Problem Management

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute des Incident Managements

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren Incident-Management-Prozess umfassend zu analysieren.

5 Erforderlich 4 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des konkreten Events oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Lebenszyklus des Incidents stattgefunden hat.
Beschreibung Der Aktivitätsname bezeichnet einen bestimmten Schritt oder eine Statusänderung im Incident-Management-Prozess, etwa 'Incident Created', 'Assigned To Agent' oder 'Incident Closed'. Die Daten stammen in der Regel aus Änderungen wichtiger Incident-Felder wie 'State' oder 'Assignment Group' oder aus bestimmten Protokolleinträgen. Dieses Attribut ist entscheidend für den Aufbau der Prozesslandkarte. Es legt die Knoten im Prozessgraphen fest und ermöglicht es Analysten, den Ablauf von Incidents zu visualisieren, häufige Pfade zu erkennen, Engpässe zwischen Aktivitäten aufzudecken und Prozessvarianten zu analysieren. Genauigkeit und Detailgrad der Aktivitätsnamen wirken sich unmittelbar auf die Qualität der Prozessanalyse aus. Warum das wichtig ist Es legt die Schritte in der Prozesslandkarte fest und bildet damit die Grundlage für Process-Mining-Analysen und Visualisierungen. Woher beziehen Dieses abgeleitete Attribut wird in der Regel durch die Datentransformationslogik erzeugt. Grundlage sind Änderungen an Feldern wie state, assignment_group und assigned_to in den Tabellen sys_audit oder incident. Beispiele Incident erstelltZuweisungsgruppe geändertLösung vorgeschlagenIncident geschlossen
	Event-Zeitpunkt EventTime	Der genaue Timestamp, der angibt, wann die Aktivität stattgefunden hat.
Beschreibung Der Event-Zeitpunkt, häufig als Timestamp bezeichnet, erfasst Datum und Uhrzeit, zu denen eine Aktivität abgeschlossen oder ein Status geändert wurde. In ServiceNow wird er bei Änderungen im Audit-Trail üblicherweise im Feld sys_updated_on gespeichert. Dieses Attribut ist entscheidend, um Events korrekt zu ordnen und zeitbasierte Analysen durchzuführen. Es dient zur Berechnung von Durchlaufzeiten, Wartezeiten und Zeitspannen zwischen Aktivitäten. Diese Kennzahlen sind wichtig, um Engpässe zu erkennen, die Leistung anhand von SLAs zu messen und die Prozesseffizienz zu verstehen. Die Genauigkeit der Timestamps ist entscheidend für die Aussagekraft aller zeitbasierten Kennzahlen. Warum das wichtig ist Dieser Timestamp ordnet alle Aktivitäten chronologisch und ermöglicht die Berechnung zeitbasierter Kennzahlen, etwa von Durchlaufzeiten und Engpässen. Woher beziehen ServiceNow-Tabelle sys_audit, Feld sys_created_on, oder das Feld sys_updated_on aus der Tabelle incident 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 jedes Incident-Datensatzes. Sie dient als Primärschlüssel für die Nachverfolgung des gesamten Lebenszyklus.
Beschreibung Die Incident-ID ist die eindeutige Referenznummer, die jedem in ServiceNow gemeldeten Incident zugewiesen wird. Sie dient als zentrale Case-Kennung und verknüpft alle zugehörigen Aktivitäten, Aktualisierungen und Mitteilungen vom Erstellen bis zum Schließen eines Incidents. Für die Process-Mining-Analyse ist diese ID grundlegend. Das Tool kann damit die Events jedes einzelnen Cases zu einer Abfolge zusammenführen. Diese bildet die Grundlage, um Prozessmodelle zu entdecken, Varianten zu analysieren und Durchlaufzeiten von Anfang bis Ende zu berechnen. Ohne eine eindeutige Incident-ID für jeden Case ließe sich der Weg eines Incidents durch den Lösungsprozess nicht nachvollziehen. Warum das wichtig ist Dies ist die erforderliche Case-ID, die alle Events im Lebenszyklus eines Incidents verknüpft und so die Prozessanalyse von Anfang bis Ende ermöglicht. Woher beziehen ServiceNow-Incident-Tabelle, Feld 'number'. Beispiele INC0010001INC0010045INC0010239
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der angibt, wann die Daten dieses Datensatzes zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder Aktualisierung aus ServiceNow. Es handelt sich um ein Metadatenfeld, das die Aktualität der analysierten Daten angibt, nicht um ein Event im Prozess selbst. Diese Information ist wichtig, um die Aktualität der Analyse einzuschätzen. Sie zeigt Benutzern, wie aktuell die Daten sind. Das ist für operative Dashboards und Entscheidungen auf Basis neuerer Events relevant. So lässt sich besser beurteilen, wie aussagekräftig und aktuell die Daten sind. Warum das wichtig ist Das Attribut informiert über die Aktualität der Daten, die für Relevanz und Genauigkeit der Analyse entscheidend ist. Woher beziehen Dieser Timestamp wird zum Zeitpunkt des Datenimports vom Datenextraktionstool oder -prozess erzeugt und eingetragen. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Quellsystem SourceSystem	Das System, aus dem diese Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt die Herkunft der Incident-Daten an, in diesem Fall ServiceNow Problem Management. Es handelt sich in der Regel um einen statischen Wert, der bei der Datenextraktion und -transformation hinzugefügt wird. Wenn Daten aus mehreren Systemen gemeinsam analysiert werden, ist dieses Feld wichtig für die Datenherkunft und die Trennung der Daten. Es stellt sicher, dass Kennzahlen und Prozesse im richtigen Kontext analysiert werden, und ermöglicht den Vergleich von Prozessen aus verschiedenen Quellsystemen. Warum das wichtig ist Das Attribut gibt wichtige Hinweise zur Datenherkunft. So lässt sich die Datenherkunft nachvollziehen und die Daten können in Umgebungen mit mehreren Systemen korrekt interpretiert werden. Woher beziehen Dabei handelt es sich in der Regel um einen statischen Wert, der bei der Datenextraktion hinzugefügt wird. Beispiele ServiceNow Problem ManagementServiceNow
	Incident-Status IncidentState	Der aktuelle Status des Incidents in seinem Lebenszyklus.
Beschreibung Der Incident-Status gibt die aktuelle Phase eines Incidents an, etwa 'New', 'In Progress', 'On Hold' oder 'Resolved'. Statusänderungen sind häufig die wichtigste Quelle für Aktivitäten im Event Log für Process Mining. Die Verweildauer in den einzelnen Status zu analysieren, ist eine wirksame Methode, um Engpässe zu erkennen. Eine lange Verweildauer im Status 'On Hold' kann beispielsweise auf Abhängigkeiten von externen Faktoren oder Benutzern hindeuten. Die Abfolge der Statusänderungen bildet außerdem die Grundlage der Prozesslandkarte und zeigt, wie Incidents ihrer Lösung näherkommen. Warum das wichtig ist Das Attribut bildet den Fortschritt des Incidents ab. Es ist wichtig, um die Verweildauer in den einzelnen Phasen zu analysieren und Prozessengpässe zu erkennen. Woher beziehen ServiceNow-Incident-Tabelle, Feld incident_state oder state. Beispiele NeuIn BearbeitungWarten auf BenutzerinformationenGelöstGeschlossen
	Priorität Priority	Die Prioritätsstufe des Incidents, die bestimmt, wie dringend darauf reagiert werden muss.
Beschreibung Die Priorität ist ein wichtiges Feld in ServiceNow. Sie bestimmt, in welcher Reihenfolge und wie schnell ein Incident bearbeitet wird. In der Regel ergibt sie sich aus den Auswirkungen und der Dringlichkeit des Incidents und beeinflusst unmittelbar die SLA-Ziele. Dieses Attribut ist grundlegend für Segmentierungen und Leistungsanalysen. Das Dashboard „SLA-Einhaltung im Überblick“ verwendet die Priorität, um zu prüfen, ob Incidents mit hoher Priorität innerhalb der vorgegebenen Zeit gelöst werden. Ein Vergleich der Durchlaufzeiten nach Priorität zeigt, ob kritische Incidents tatsächlich schneller bearbeitet werden als weniger wichtige. Für fast alle KPIs und Dashboards ist die Priorität eine wichtige Dimension. Warum das wichtig ist Damit lassen sich Incidents nach ihrer geschäftlichen Bedeutung segmentieren. Das ist wichtig, um die SLA-Einhaltung zu überwachen und Ressourcen zuzuweisen. Woher beziehen ServiceNow-Incident-Tabelle, Feld priority. Beispiele 1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
	Zugewiesen an AssignedTo	Der Benutzer oder Agent, der aktuell für die Bearbeitung des Incidents zuständig ist.
Beschreibung Dieses Attribut gibt an, welcher Support-Agent zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Diese Information ist wichtig, um die Verteilung der Arbeitslast, die Leistung der Agents und Übergaben zwischen einzelnen Personen zu verstehen. In der Analyse hilft „Zugewiesen an“, die Ressourcenverteilung darzustellen und überlastete Agents zu erkennen. Im Dashboard zu Übergaben und Neuzuweisungen zeigt das Attribut außerdem, wie oft ein Incident einer anderen Person zugewiesen wird. Das kann auf Ineffizienzen oder Wissenslücken hindeuten. Ein Vergleich der Lösungszeiten nach Agent kann zudem besonders leistungsstarke Mitarbeitende oder zusätzlichen Schulungsbedarf sichtbar machen. Warum das wichtig ist Damit lassen sich Arbeitslast, Leistung und individuelle Übergaben der Agents analysieren. Diese Aspekte sind wichtig, um die Effizienz des Ressourceneinsatzes zu verstehen. Woher beziehen 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 Incidents zuständig ist.
Beschreibung Die Zuweisungsgruppe bezeichnet das Team von Agents, das für die Lösung eines Incidents zuständig ist. Incidents werden häufig zwischen verschiedenen Gruppen weitergeleitet, zum Beispiel vom Helpdesk der Ebene 1 an ein spezialisiertes Netzwerkteam der Ebene 2. Dieses Attribut ist wichtig, um Übergaben zwischen Teams zu analysieren und systemische Engpässe zu erkennen. Das Dashboard „Übergabe- und Neuzuweisungsrate“ verwendet diese Daten, um zu zeigen, welche Teams häufig an Übergaben beteiligt sind. Außerdem ermöglicht das Attribut Leistungsvergleiche zwischen Supportgruppen und zeigt, wo in der Organisation das Wissen zur Incident-Lösung liegt. Warum das wichtig ist Das Attribut zeigt, welches Team zuständig ist, und ermöglicht so die Analyse von Teamleistung, Arbeitslast und Übergaben zwischen Gruppen. Woher beziehen ServiceNow-Incident-Tabelle, Feld assignment_group. Beispiele Service DeskNetzwerk-SupportDatenbankadministratoren
	Anzahl der Neuzuweisungen ReassignmentCount	Wie oft der Incident einer anderen Gruppe oder einem anderen Agenten zugewiesen wurde.
Beschreibung Dieses Feld erfasst, wie oft ein Incident zwischen verschiedenen Zuweisungsgruppen weitergegeben wurde. Es misst direkt den Aufwand durch Übergaben und dient häufig als wichtige Kennzahl. Das Attribut ist die wichtigste Grundlage für das Dashboard „Übergabe- und Neuzuweisungsrate“ und die Kennzahl „Durchschnittliche Übergaben pro Incident“. Eine hohe Zahl von Neuzuweisungen deutet oft auf Probleme wie eine falsche Erstzuweisung, fehlende Kompetenzen in einer Support-Ebene oder unklare Prozessverantwortung hin. Prozessverbesserungen zielen häufig darauf ab, diese Zahl zu senken, da dies in der Regel die Lösungszeiten verkürzt. Warum das wichtig ist Das Attribut misst direkt die Übergaben im Prozess. Diese sind ein wichtiger Hinweis auf Ineffizienz, falsche Zuweisungen und Verbesserungspotenzial. Woher beziehen ServiceNow-Incident-Tabelle, Feld reassignment_count. Beispiele 0135
	Kategorie Category	Die übergeordnete Klassifizierung des Incidents, zum Beispiel Hardware, Software oder Netzwerk.
Beschreibung Die Kategorie gibt einen allgemeinen Überblick über die Art eines Incidents. Zusammen mit einer Unterkategorie hilft sie dabei, den Incident an das richtige Support-Team weiterzuleiten. Außerdem dient sie der Berichterstellung und Trendanalyse. Für Process Mining ist dieses Attribut wichtig für die Dashboards „Genauigkeit der Incident-Kategorisierung“ und „Aufkommen wiederkehrender Incidents“. Wenn Unternehmen analysieren, bei welchen Incidents die Kategorie während des Prozesses geändert wird, können sie Probleme bei der Ersteinschätzung erkennen. Eine Filterung der Prozesslandkarte nach Kategorie zeigt außerdem, ob bestimmte Incident-Arten andere Lösungswege durchlaufen oder eigene Engpässe aufweisen. Warum das wichtig ist Das Attribut ermöglicht die Analyse von Incident-Arten, hilft bei der Messung der Kategorisierungsgenauigkeit und ist wichtig für Routing und Trendanalysen. Woher beziehen ServiceNow-Incident-Tabelle, Feld category. Beispiele HardwareSoftwareNetzwerkDatenbank
	Konfigurationselement ConfigurationItem	Die konkrete IT-Komponente, der Service oder das Asset, das vom Incident betroffen ist.
Beschreibung Das Konfigurationselement (CI) ist das Asset aus der Configuration Management Database (CMDB), das vom Incident betroffen ist. Dabei kann es sich um einen Server, eine Anwendung, einen Laptop oder ein Netzwerkgerät handeln. Die Analyse von Incidents nach CI hilft dabei, unzuverlässige Assets oder Services zu erkennen. Sie zeigt, welche Teile der IT-Infrastruktur die meisten Incidents verursachen, und kann so Entscheidungen über Investitionen in Upgrades oder Ersatz unterstützen. Beim Process Mining kann eine Filterung nach CI aufdecken, ob Incidents zu kritischen Anwendungen anders oder effizienter bearbeitet werden als andere. Warum das wichtig ist Das Attribut kennzeichnet das betroffene Asset. So lassen sich problematische Komponenten der IT-Infrastruktur erkennen und Verbesserungsmaßnahmen gezielt ausrichten. Woher beziehen ServiceNow-Incident-Tabelle, Feld cmdb_ci. Beispiele SAP-ERP-ProduktionOracle-Datenbankserver 05E-Mail-Service
	Lösungscode ResolutionCode	Ein Code, der angibt, wie der Incident letztendlich gelöst wurde.
Beschreibung Der Lösungscode gibt an, wie der Incident behoben wurde, zum Beispiel durch einen Benutzer, aufgrund eines bekannten Fehlers oder mithilfe einer Übergangslösung. In der Regel trägt der Agent diesen Wert ein, wenn er den Incident schließt. Dieses Attribut ist eine wichtige Grundlage für das Dashboard „Wirksamkeit der Lösungstypen“. Damit lässt sich auswerten, wie viele Incidents mit einer dauerhaften Lösung und wie viele mit einer vorübergehenden Übergangslösung geschlossen werden. Das ist ein wichtiger Indikator für die Servicequalität und langfristige Stabilität. Ein hoher Anteil an Übergangslösungen kann darauf hindeuten, dass grundlegende Probleme nicht ausreichend behoben werden. Warum das wichtig ist Das Attribut gibt die Lösungsmethode an. So lässt sich analysieren, ob Incidents dauerhaft oder nur vorübergehend behoben wurden, und die Ursachenanalyse wird unterstützt. Woher beziehen ServiceNow-Incident-Tabelle, Feld close_code oder ein benutzerdefiniertes Feld für den Lösungscode. Beispiele Gelöst (Übergangslösung)Dauerhaft gelöstNicht gelöst (vom Benutzer abgebrochen)Bekannter Fehler
	Meldende Person CallerId	Der Benutzer, der den Incident ursprünglich gemeldet hat.
Beschreibung Die meldende Person ist der Endbenutzer oder Kunde, der vom Incident betroffen ist und ihn gemeldet hat. Diese Information zeigt, wer durch die Serviceunterbrechung beeinträchtigt wird. Auch wenn die meldende Person für den Prozessablauf selbst nicht immer zentral ist, kann eine Analyse nach meldender Person zeigen, ob bestimmte Personen oder Abteilungen überproportional häufig von Problemen betroffen sind. Das kann auf Schulungsbedarf oder lokale Probleme mit der IT-Umgebung hinweisen. Außerdem ermöglicht das Attribut den direkten Kontakt für Zufriedenheitsumfragen und Mitteilungen. Warum das wichtig ist Das Attribut kennzeichnet den betroffenen Benutzer. So lassen sich Incidents nach Abteilung oder Person analysieren und Mitteilungen an Benutzer gezielt ausrichten. Woher beziehen ServiceNow-Incident-Tabelle, Feld caller_id. Beispiele Abel TuterCarolina PashDon Goodliffe
	Problem-ID ProblemId	Die Kennung des zugehörigen Problem-Datensatzes, wenn der Incident mit einem übergeordneten Problem verknüpft ist.
Beschreibung Die Problem-ID verknüpft einen Incident mit dem entsprechenden Datensatz im Modul Problem Management. Das geschieht, wenn sich herausstellt, dass ein Incident auf ein größeres zugrunde liegendes Problem zurückgeht, das mehrere Benutzer oder Services betrifft. Diese Verknüpfung ist entscheidend für das Dashboard „Volumen wiederkehrender Incidents“ und die Kennzahl „Rate wiederkehrender Incidents“. Analysten können damit Incidents nach gemeinsamer Ursache gruppieren, die Gesamtauswirkungen eines Problems messen und verfolgen, wie wirksam die Problemlösung ist. Eine hohe Zahl von Incidents, die mit Problemen verknüpft sind, deutet auf einen reaktiven Support hin. Warum das wichtig ist Das Attribut verknüpft Incidents mit ihrer Ursache. Das ist wichtig, um wiederkehrende Probleme zu analysieren und die Auswirkungen des Problem Managements zu messen. Woher beziehen ServiceNow-Incident-Tabelle, Feld problem_id. Beispiele PRB0040001PRB0040015PRB0040102
	Schweregrad Severity	Das Ausmaß der geschäftlichen Auswirkungen des Incidents.
Beschreibung Der Schweregrad gibt an, wie stark ein Incident den Geschäftsbetrieb beeinträchtigt. Zusammen mit der Dringlichkeit wird er häufig verwendet, um die Priorität des Incidents automatisch zu berechnen. In der Analyse ist der Schweregrad eine wichtige Dimension für das Dashboard „Übersicht zur SLA-Konformität“. Er zeigt, ob die Service-Level bei besonders störenden Incidents eingehalten werden. Damit ergänzt er die operative Sicht auf die Leistung, die sich aus der Priorität ergibt, um eine geschäftliche Perspektive. Warum das wichtig ist Das Attribut misst die geschäftlichen Auswirkungen eines Incidents. Es ist eine wichtige Dimension, um Maßnahmen zu priorisieren und die Bearbeitung kritischer Probleme zu analysieren. Woher beziehen ServiceNow-Incident-Tabelle, Feld severity. Beispiele 1 - Hoch2 - Mittel3 - Niedrig
	SLA-Fälligkeit SlaDueDate	Datum und Uhrzeit, bis zu denen der Incident gemäß SLA gelöst sein soll.
Beschreibung Die SLA-Fälligkeit ist ein berechneter Timestamp, der die Frist für die Lösung eines Incidents angibt. Sie wird anhand des für den Incident geltenden Service Level Agreement (SLA) und seiner Merkmale, etwa der Priorität, bestimmt. Dieses Attribut ist wichtig für das Dashboard „Übersicht zur SLA-Konformität“ und die Kennzahl „SLA-Verletzungsrate bei kritischen Incidents“. Es dient als Vergleichswert für die tatsächliche Lösungszeit. Die Analyse von Incidents, deren SLA-Fälligkeit kurz bevorsteht, kann eine frühzeitige Eskalation und Priorisierung unterstützen. Warum das wichtig ist Das Attribut legt das Lösungsziel fest. So lässt sich die SLA-Konformität messen und erkennen, bei welchen Incidents eine Fristüberschreitung droht. Woher beziehen Dieser Wert steht in der Regel in der Tabelle task_sla, die mit der Incident-Tabelle verknüpft ist. Der relevante Timestamp ist das Feld planned_end_time. Beispiele 2023-05-20T17:00:00Z2023-06-01T09:00:00Z
	SLA-Frist überschritten IsSlaBreached	Ein Kennzeichen dafür, ob die Lösung des Incidents nach der SLA-Fälligkeit erfolgte.
Beschreibung Dieses berechnete boolesche Attribut kennzeichnet Incidents, bei denen das Service Level Agreement verletzt wurde. Es ergibt sich aus dem Vergleich des tatsächlichen Lösungs-Timestamps mit der „SLA-Fälligkeit“. Liegt die Lösungszeit nach der Fälligkeit, wird das Kennzeichen auf „true“ gesetzt. Das Attribut bildet die Grundlage für das Dashboard „Übersicht zur SLA-Konformität“ und die zugehörigen Kennzahlen. Es vereinfacht die Analyse, indem es einen komplexen Zeitvergleich in eine einfache Ja-Nein-Dimension überführt. So können Sie alle Incidents mit Fristüberschreitung filtern und gemeinsame Merkmale wie Kategorie, Zuweisungsgruppe oder Priorität untersuchen. Warum das wichtig ist Das Attribut vereinfacht die Analyse der SLA-Konformität. Sie können alle Incidents, bei denen die Frist nicht eingehalten wurde, gezielt filtern und genauer untersuchen. Woher beziehen Berechnet durch Vergleich des Timestamps „Resolved At“ mit dem Timestamp „SlaDueDate“. (Resolved At > SlaDueDate). Beispiele truefalse
	Wiedereröffnet IsReopened	Ein Kennzeichen dafür, ob ein Incident nach seiner Lösung wiedereröffnet wurde.
Beschreibung Dieses boolesche Kennzeichen wird auf „true“ gesetzt, wenn der Status eines Incidents nach „Gelöst“ oder „Geschlossen“ wieder auf einen aktiven Status geändert wurde, zum Beispiel „In Bearbeitung“. Dies lässt sich in der Regel anhand der Aktivität „Incident Reopened“ im Event Log erkennen. Wiedereröffnete Incidents weisen häufig auf unvollständige oder unwirksame Lösungen hin. Ihre Analyse hilft, verfrühte Abschlüsse und wiederkehrende Probleme zu erkennen, die beim ersten Mal nicht behoben wurden. Eine hohe Wiedereröffnungsrate kann die Benutzerzufriedenheit und die Produktivität des Teams beeinträchtigen. Sie ist daher eine wichtige Kennzahl für die Qualitätskontrolle. Warum das wichtig ist Das Kennzeichen macht Schwachstellen im Lösungsprozess sichtbar und zeigt Incidents, bei denen nach der vermeintlichen Lösung weitere Arbeit erforderlich war. Woher beziehen Berechnet durch Prüfung der Aktivitätsfolge für jeden Incident: Folgt auf einen Status „Gelöst“ ein Status „Offen“? Beispiele truefalse

Erforderlich Empfohlen Optional

Aktivitäten im Incident Management

Erfassen Sie diese wichtigen Prozessschritte und Meilensteine in Ihrem Event Log, um den Prozess zuverlässig zu entdecken und zu optimieren.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Arbeit begonnen	Zeigt an, dass ein Agent mit der Untersuchung oder Bearbeitung des Incidents begonnen hat. Dies wird meist daraus abgeleitet, dass sich der Status des Incidents von 'New' oder 'Assigned' in einen aktiven Status wie 'In Progress' ändert.
Warum das wichtig ist Dieser Meilenstein markiert das Ende der anfänglichen Wartezeit in der Warteschlange und den Beginn der aktiven Bearbeitung. Die Zeit bis zum Arbeitsbeginn ist eine wichtige Kennzahl für die Engpassanalyse. Woher beziehen Wird aus der Tabelle 'sys_audit' abgeleitet, indem ermittelt wird, wann sich das Feld 'state' in der Tabelle 'incident' in einen Status für aktive Arbeit ändert, etwa 'In Progress'. Erfassung Ermitteln Sie den Timestamp, an dem sich das Feld 'state' in 'In Progress' oder einen ähnlichen Status ändert. Ereignistyp inferred
	Incident einer Gruppe zugewiesen	Diese Aktivität tritt ein, wenn ein Incident einer bestimmten Supportgruppe zur Bearbeitung zugewiesen wird. Sie ist ein wichtiger Schritt im Routing und wird anhand von Änderungen am Feld für die Zuweisungsgruppe erfasst.
Warum das wichtig ist Die Analyse der Zuweisungen ist wichtig, um Übergaben und Wartezeiten in den einzelnen Gruppen zu untersuchen und Ineffizienzen oder Engpässe im Routing zu erkennen. Woher beziehen Wird aus der Tabelle 'sys_audit' abgeleitet, indem Änderungen am Feld 'assignment_group' in der Tabelle 'incident' erfasst werden. Erfassung Verwenden Sie den Timestamp der Änderungen am Feld 'assignment_group' im Audit-Log. Ereignistyp inferred
	Incident erstellt	Markiert den Beginn des Incident-Lebenszyklus, wenn ein neuer Incident in ServiceNow offiziell erfasst wird. Dieses Event wird anhand des Erstellungs-Timestamps des Incident-Datensatzes eindeutig erfasst.
Warum das wichtig ist Dies ist das primäre Start-Event des Prozesses. Die Zeit von dieser Aktivität bis zur Lösung ist eine wichtige Grundlage, um die gesamte Durchlaufzeit und die SLA-Einhaltung zu messen. Woher beziehen Der Timestamp 'sys_created_on' in der Tabelle 'incident' dient als eindeutiger Event-Timestamp für diese Aktivität. Erfassung Verwenden Sie den Timestamp 'sys_created_on' aus dem Incident-Datensatz. Ereignistyp explicit
	Incident geschlossen	Dies ist die letzte Aktivität im Lebenszyklus. Sie zeigt an, dass der Incident vollständig gelöst und bestätigt wurde und keine weiteren Maßnahmen erforderlich sind. Das Event wird anhand des Abschluss-Timestamps eindeutig erfasst.
Warum das wichtig ist Als abschließendes End-Event ist diese Aktivität wichtig, um die Gesamtdauer des Incident-Lebenszyklus zu berechnen und die Dauer der Nachbearbeitung nach der Lösung zu analysieren. Woher beziehen Der Timestamp 'closed_at' in der Tabelle 'incident' dient als eindeutiger Event-Timestamp. Er wird in der Regel gesetzt, wenn sich das Feld 'state' in 'Closed' ändert. Erfassung Verwenden Sie den Timestamp 'closed_at' aus dem Incident-Datensatz. Ereignistyp explicit
	Lösung vorgeschlagen	Markiert den Zeitpunkt, an dem ein Support-Agent eine Lösung umgesetzt und den Incident in den Status 'Resolved' versetzt hat. Dieser wichtige Meilenstein geht dem endgültigen Abschluss voraus.
Warum das wichtig ist Diese Aktivität kennzeichnet das Ende der aktiven Bearbeitung und den Beginn der Bestätigungsphase. Die Zeit bis zu 'Incident Closed' kann Verzögerungen bei der Bestätigung durch Benutzer oder bei der Überprüfung sichtbar machen. Woher beziehen Wird aus der Tabelle 'sys_audit' abgeleitet, wenn sich das Feld 'state' in der Tabelle 'incident' in 'Resolved' ändert. Der Timestamp 'resolved_at' wird häufig zu diesem Zeitpunkt eingetragen. Erfassung Verwenden Sie den Timestamp, an dem das Feld 'state' den Wert 'Resolved' annimmt, oder den Timestamp 'resolved_at'. Ereignistyp inferred
	Zuweisungsgruppe geändert	Steht für eine Übergabe, bei der ein Incident von einer Supportgruppe an eine andere übertragen wird. Erfasst wird dies anhand weiterer Änderungen am Feld 'assignment_group' nach der ersten Zuweisung.
Warum das wichtig ist Häufige Neuzuweisungen können auf eine falsche Erstzuweisung, komplexe Abläufe oder fehlendes Wissen hindeuten. Diese Aktivität ist entscheidend für die Kennzahl „Durchschnittliche Übergaben pro Incident“. Woher beziehen Wird aus der Tabelle 'sys_audit' abgeleitet, indem alle Änderungen am Feld 'assignment_group' nach der ersten Zuweisung erfasst werden. Erfassung Ermitteln Sie im Audit-Log den Timestamp jeder Änderung am Feld 'assignment_group'. Ereignistyp inferred
	Incident einem Agent zugewiesen	Markiert den Zeitpunkt, an dem ein bestimmter Agent innerhalb einer Supportgruppe die Verantwortung für den Incident übernimmt. Erfasst wird dies anhand von Änderungen am Feld 'assigned_to'.
Warum das wichtig ist Diese Aktivität zeigt die Arbeitslast der Agents und die Lösungsquote beim Erstkontakt im Detail. Sie macht sichtbar, wie lange Incidents nach der Zuweisung an eine Gruppe warten, bis eine einzelne Person mit der Bearbeitung beginnt. Woher beziehen Wird aus der Tabelle 'sys_audit' abgeleitet, indem erfasst wird, wann das Feld 'assigned_to' in der Tabelle 'incident' ausgefüllt oder geändert wird. Erfassung Verwenden Sie den Timestamp der Änderungen am Feld 'assigned_to' im Audit-Log. Ereignistyp inferred
	Incident erneut geöffnet	Tritt ein, wenn ein Benutzer meldet, dass das Problem nach der Kennzeichnung als gelöst weiterhin besteht. Abgeleitet wird dies, wenn der Incident-Status von 'Resolved' zurück in einen aktiven Status wie 'In Progress' wechselt.
Warum das wichtig ist Erneut geöffnete Incidents weisen auf fehlgeschlagene Lösungen und Nacharbeit hin. Diese Aktivität zu erfassen, ist wichtig, um die Lösungsqualität und die Quote erfolgreicher Lösungen beim ersten Versuch zu messen. Woher beziehen Wird aus der Tabelle 'sys_audit' abgeleitet, indem ein Wechsel des Felds 'state' von 'Resolved' zurück in einen aktiven Status wie 'In Progress' oder 'Assigned' erkannt wird. Erfassung Ermitteln Sie den Timestamp, an dem 'state' von 'Resolved' in einen aktiven Status wechselt. Ereignistyp inferred
	Incident eskaliert	Tritt ein, wenn die Priorität oder der Schweregrad eines Incidents erhöht wird und dadurch häufig eine schnellere Reaktion oder andere Ressourcen erforderlich sind. Ermittelt wird dies anhand einer Erhöhung des Werts im Feld 'priority'.
Warum das wichtig ist Eine Eskalation kann darauf hindeuten, dass ein Incident schwerwiegender ist als zunächst angenommen oder ein SLA-Verstoß droht. Die Analyse dieser Events hilft, Ausnahmen im Prozess zu verstehen. Woher beziehen Wird aus der Tabelle 'sys_audit' abgeleitet, indem eine Änderung des Felds 'priority' auf einen Wert mit höherer Dringlichkeit ermittelt wird. Erfassung Ermitteln Sie, wann der Wert im Feld 'priority' steigt, zum Beispiel von '3 - Moderate' auf '2 - High'. Ereignistyp inferred
	Incident kategorisiert	Steht für die erste Klassifizierung des Incidents. Dabei werden Felder wie Category, Subcategory und Priority festgelegt. Dieses Event wird meist aus dem Audit-Trail abgeleitet, wenn diese Felder erstmals oder kurz nach der Erstellung aktualisiert werden.
Warum das wichtig ist Eine korrekte Kategorisierung ist entscheidend für die richtige Weiterleitung und Priorisierung. Die Analyse dieser Aktivität zeigt, wie oft Incidents neu kategorisiert werden und wie sich das auf die Lösungszeit auswirkt. Woher beziehen Wird aus der Tabelle 'sys_audit' abgeleitet, indem die erste Änderung an Feldern wie 'category', 'subcategory' oder 'priority' für einen Incident ermittelt wird. Erfassung Ermitteln Sie im Audit-Log den Timestamp der ersten Aktualisierung eines Klassifizierungsfelds. Ereignistyp inferred
	Incident mit Problem verknüpft	Diese Aktivität tritt ein, wenn ein Incident offiziell einem Problem-Datensatz zugeordnet wird. Das weist darauf hin, dass er Teil eines größeren zugrunde liegenden Problems ist. Abgeleitet wird dies, wenn das Feld 'problem_id' im Incident-Datensatz ausgefüllt wird.
Warum das wichtig ist Die Verknüpfung mit einem Problem ist ein wichtiger Schritt, um von der reaktiven Incident-Behebung zur proaktiven Ursachenanalyse überzugehen. Sie unterstützt das Dashboard „Aufkommen wiederkehrender Incidents“. Woher beziehen Wird abgeleitet, indem erkannt wird, wann das Referenzfeld 'problem_id' in der Tabelle 'incident' einen Wert erhält. Erfassung Ermitteln Sie im Audit-Log den Timestamp, an dem das Feld 'problem_id' ausgefüllt wird. Ereignistyp inferred
	Support-Kommentar hinzugefügt	Ein Support-Agent fügt eine Arbeitsnotiz oder einen für Benutzer sichtbaren Kommentar hinzu. Dieses Event wird ausdrücklich im Aktivitätsverlauf des Incidents protokolliert.
Warum das wichtig ist Erfasst die Kommunikation und die Untersuchungsarbeit des Support-Teams. Häufigkeit und Zeitpunkt der Kommentare geben Aufschluss über den Untersuchungsprozess. Woher beziehen Wird aus der Tabelle 'sys_journal_field' erfasst, in der Einträge zu den Feldern 'work_notes' und 'comments' der Tabelle 'incident' protokolliert werden. Erfassung Verwenden Sie den Erstellungs-Timestamp der Journaleinträge, bei denen 'work_notes' oder 'comments' als Element angegeben ist. Ereignistyp explicit
	Warten auf Bestätigung durch Benutzer	Der Incident befindet sich in einem ausstehenden Status. Es wird darauf gewartet, dass der Benutzer den Erfolg der vorgeschlagenen Lösung bestätigt. Dies wird meist anhand eines bestimmten Status wie 'Awaiting User Info' nach der Lösung abgeleitet.
Warum das wichtig ist Dieser Status kann einen erheblichen Engpass darstellen, wenn Benutzer nur verzögert antworten. Die Messung der Verweildauer in dieser Aktivität hilft, Kommunikationslücken und Möglichkeiten für einen automatischen Abschluss zu erkennen. Woher beziehen Wird aus der Tabelle 'sys_audit' abgeleitet, indem nach der Lösung eine Änderung in einen bestimmten ausstehenden Status ermittelt wird. Der Statusname kann angepasst sein, zum Beispiel 'Awaiting Caller'. Erfassung Ermitteln Sie den Timestamp, an dem sich 'state' in einen Wert ändert, der auf das Warten auf eine Rückmeldung des Benutzers hinweist. Ereignistyp inferred

Anleitungen zum Extrahieren von Daten

So exportieren Sie Ihre Daten aus ServiceNow Problem Management

Schritte

ServiceNow-Zugriff einrichten: Richten Sie ein Servicekonto für ServiceNow ein. Dieses Konto benötigt Leseberechtigungen (ACLs) für die Tabellen incident und sys_audit sowie für alle erforderlichen Felder, darunter sys_id, number, sys_created_on, resolved_at, closed_at, assignment_group, assigned_to, priority, incident_state, state, category, subcategory, problem_id, comments und work_notes.
Node.js-Umgebung konfigurieren: Installieren Sie Node.js auf dem Rechner, auf dem das Extraktionsskript ausgeführt wird. Installieren Sie die Bibliothek axios für HTTP-Anfragen, indem Sie im Terminal npm install axios ausführen.
Extraktionsskript vorbereiten: Kopieren Sie den bereitgestellten JavaScript-Code in eine Datei, zum Beispiel extract_incidents.js. Tragen Sie oben im Skript die URL Ihrer ServiceNow-Instanz sowie Ihren Benutzernamen und Ihr Passwort anstelle der Platzhalter ein.
Extraktionsparameter festlegen: Passen Sie im Skript die Variablen startDate und endDate an den Zeitraum der Incidents an, die Sie extrahieren möchten. Für den ersten Durchlauf empfiehlt sich ein kurzer Zeitraum, zum Beispiel eine Woche, um die Ergebnisse zu prüfen.
Skript ausführen: Starten Sie das Skript im Terminal mit dem Befehl node extract_incidents.js. Das Skript ruft anschließend Incident-Daten und die zugehörigen Audit-Protokolle über die ServiceNow-API ab.
Fortschritt überwachen: Das Skript gibt den Fortschritt in der Konsole aus und zeigt an, wie viele Incidents verarbeitet wurden. Bei großen Datenmengen kann der Vorgang aufgrund der erforderlichen API-Aufrufe viel Zeit in Anspruch nehmen.
API-Antworten verarbeiten: Das Skript verarbeitet die Incidents nacheinander. Für jeden Incident fragt es die Tabelle sys_audit ab, um den vollständigen Änderungsverlauf abzurufen. Anschließend ermittelt es daraus die 13 erforderlichen Aktivitäten und versieht sie mit Timestamps.
Abgeleitete Aktivitäten berücksichtigen: Das Skript leitet Aktivitäten anhand von Feldänderungen ab. „Incident Escalated“ wird beispielsweise erstellt, wenn der neue Wert des Felds priority niedriger ist als der alte Wert, was eine höhere Priorität bedeutet. „Work Started“ wird anhand der ersten Statusänderung zu „In Progress“ erkannt.
Event Log strukturieren: Die erkannten Aktivitäten werden als Event-Log-Datensätze formatiert. Jeder Datensatz enthält die erforderlichen Spalten, darunter IncidentId und ActivityName sowie EventTime.
Ausgabe speichern: Nach Abschluss speichert das Skript das erstellte Event Log als JSON-Datei mit dem Namen servicenow_incident_event_log.json im selben Verzeichnis. Die Datei enthält ein Array aller extrahierten Ereignisse.
In CSV umwandeln: Für den Upload in ProcessMind müssen Sie die JSON-Ausgabe möglicherweise in eine CSV-Datei umwandeln. Verwenden Sie dafür ein gängiges Datentool oder ein einfaches Skript. Achten Sie darauf, dass die Spaltenüberschriften den erforderlichen Attributen entsprechen.

Konfiguration

API-Endpunkte: Das Skript greift auf zwei zentrale ServiceNow Table API-Endpunkte zu:
- https://[Your ServiceNow Instance].service-now.com/api/now/table/incident
- https://[Your ServiceNow Instance].service-now.com/api/now/table/sys_audit
Authentifizierung: Das bereitgestellte Skript verwendet die Basisauthentifizierung mit Benutzername und Passwort. Prüfen Sie, ob die Zugangsdaten des Servicekontos korrekt und das Konto aktiv ist.
Filter für den Zeitraum: Die Abfrage filtert nach dem Erstellungsdatum des Incidents (sys_created_on). Den Zeitraum legen Sie im Skript über die Variablen startDate und endDate fest. Für eine aussagekräftige Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten. Beginnen Sie zum Testen jedoch mit einem kürzeren Zeitraum.
Wichtige Abfrageparameter:
- sysparm_query: Filtert Datensätze. Das Skript erstellt eine codierte Abfragezeichenfolge, um Incidents nach ihrem Erstellungsdatum zu filtern.
- sysparm_fields: Legt fest, welche Spalten abgerufen werden. So verringern Sie die Größe der API-Antwort und verbessern die Leistung.
- sysparm_limit: Steuert die Seitennavigation, indem die Anzahl der Datensätze pro Anfrage festgelegt wird. Das Skript verwendet den gängigen Grenzwert 1000.
- sysparm_offset: Wird zusammen mit sysparm_limit verwendet, um die folgenden Datenseiten abzurufen.
Leistungshinweise: Die Abfrage der Tabelle sys_audit für jeden Incident beansprucht viele Ressourcen. Bei sehr großen ServiceNow-Instanzen sollten Sie den Export außerhalb der Spitzenzeiten ausführen. Das Skript verarbeitet Incidents nacheinander, um die API nicht zu überlasten. Dadurch kann sich die Gesamtlaufzeit verlängern.
Voraussetzungen: Für die Ausführung des Skripts benötigen Sie eine Node.js-Umgebung. Der Benutzer oder das Servicekonto, das den Export ausführt, benötigt die erforderlichen Leseberechtigungen (ACLs) für die Tabellen incident und sys_audit.

Beispielabfrage javascript

const axios = require('axios');
const fs = require('fs');

// --- Configuration ---
const INSTANCE_URL = 'https://[your-instance].service-now.com';
const USERNAME = '[your-username]';
const PASSWORD = '[your-password]';

// Define the date range for the extraction
const startDate = '2023-01-01 00:00:00';
const endDate = '2023-03-31 23:59:59';

const BATCH_SIZE = 1000; // Records per API call for incidents
const SOURCE_SYSTEM = 'ServiceNow';

// --- Main Extraction Logic ---
async function extractIncidentData() {
    const auth = { username: USERNAME, password: PASSWORD };
    const allEvents = [];
    let offset = 0;
    let hasMoreRecords = true;

    console.log(`Starting extraction for incidents created between ${startDate} and ${endDate}...`);

    while (hasMoreRecords) {
        try {
            // 1. Fetch a batch of incidents
            const incidentQuery = `sys_created_on>=${startDate}^sys_created_on<=${endDate}`;
            const incidentFields = [
                'sys_id', 'number', 'sys_created_on', 'resolved_at', 'closed_at',
                'assigned_to', 'assignment_group', 'priority', 'incident_state',
                'state', 'sys_updated_on'
            ].join(',');

            console.log(`Fetching incidents, offset: ${offset}...`);
            const incidentResponse = await axios.get(`${INSTANCE_URL}/api/now/table/incident`, {
                auth,
                params: {
                    sysparm_query: incidentQuery,
                    sysparm_fields: incidentFields,
                    sysparm_limit: BATCH_SIZE,
                    sysparm_offset: offset
                }
            });

            const incidents = incidentResponse.data.result;
            if (incidents.length === 0) {
                hasMoreRecords = false;
                continue;
            }

            // 2. For each incident, fetch its audit trail and generate events
            for (const incident of incidents) {
                const lastDataUpdate = new Date().toISOString();

                // --- Explicit Events from Incident Table ---
                allEvents.push(createEvent(incident, 'Incident Created', incident.sys_created_on, lastDataUpdate));
                if (incident.resolved_at) {
                    allEvents.push(createEvent(incident, 'Resolution Proposed', incident.resolved_at, lastDataUpdate));
                }
                if (incident.closed_at) {
                    allEvents.push(createEvent(incident, 'Incident Closed', incident.closed_at, lastDataUpdate));
                }

                // --- Inferred Events from Audit Table ---
                const auditQuery = `documentkey=${incident.sys_id}`;
                const auditFields = 'sys_created_on,fieldname,oldvalue,newvalue';
                const auditResponse = await axios.get(`${INSTANCE_URL}/api/now/table/sys_audit`, {
                    auth,
                    params: { sysparm_query: auditQuery, sysparm_fields: auditFields, sysparm_display_value: 'true' }
                });

                const auditRecords = auditResponse.data.result.sort((a, b) => new Date(a.sys_created_on) - new Date(b.sys_created_on));
                
                let isCategorized = false, isGroupAssigned = false, isAgentAssigned = false, isWorkStarted = false, isProblemLinked = false, isReopened = false;
                let lastPriority = null;
                
                for (const audit of auditRecords) {
                    const eventTime = audit.sys_created_on;
                    
                    if (!isCategorized && (audit.fieldname === 'category' || audit.fieldname === 'subcategory') && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Categorized', eventTime, lastDataUpdate));
                        isCategorized = true;
                    }
                    if (!isGroupAssigned && audit.fieldname === 'assignment_group' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Assigned To Group', eventTime, lastDataUpdate));
                        isGroupAssigned = true;
                    } else if (isGroupAssigned && audit.fieldname === 'assignment_group' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Assignment Group Changed', eventTime, lastDataUpdate));
                    }
                    if (!isAgentAssigned && audit.fieldname === 'assigned_to' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Assigned To Agent', eventTime, lastDataUpdate));
                        isAgentAssigned = true;
                    }
                    if (!isWorkStarted && (audit.fieldname === 'state' || audit.fieldname === 'incident_state') && audit.newvalue.toLowerCase().includes('progress')) {
                        allEvents.push(createEvent(incident, 'Work Started', eventTime, lastDataUpdate));
                        isWorkStarted = true;
                    }
                    if ((audit.fieldname === 'comments' || audit.fieldname === 'work_notes') && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Support Comment Added', eventTime, lastDataUpdate));
                    }
                    if (audit.fieldname === 'priority') {
                         const oldPriorityVal = parseInt(audit.oldvalue.match(/\d+/), 10);
                         const newPriorityVal = parseInt(audit.newvalue.match(/\d+/), 10);
                         if (lastPriority !== null && newPriorityVal < lastPriority) {
                             allEvents.push(createEvent(incident, 'Incident Escalated', eventTime, lastDataUpdate));
                         }
                         lastPriority = newPriorityVal;
                    }
                    if (!isProblemLinked && audit.fieldname === 'problem_id' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Linked To Problem', eventTime, lastDataUpdate));
                        isProblemLinked = true;
                    }
                    if ((audit.fieldname === 'state' || audit.fieldname === 'incident_state') && audit.newvalue.toLowerCase().includes('awaiting')) {
                         allEvents.push(createEvent(incident, 'Awaiting User Confirmation', eventTime, lastDataUpdate));
                    }
                    if (!isReopened && (audit.fieldname === 'state' || audit.fieldname === 'incident_state') && (audit.oldvalue.toLowerCase().includes('resolved') || audit.oldvalue.toLowerCase().includes('closed')) && audit.newvalue.toLowerCase().includes('progress')) {
                        allEvents.push(createEvent(incident, 'Incident Reopened', eventTime, lastDataUpdate));
                        isReopened = true; 
                    }
                }
            }

            offset += BATCH_SIZE;
            console.log(`Processed ${incidents.length} incidents. Total events so far: ${allEvents.length}`);

        } catch (error) {
            console.error('An error occurred:', error.response ? error.response.data : error.message);
            hasMoreRecords = false; // Stop on error
        }
    }

    // 3. Save results to a file
    fs.writeFileSync('servicenow_incident_event_log.json', JSON.stringify(allEvents, null, 2));
    console.log(`Extraction complete. ${allEvents.length} events saved to servicenow_incident_event_log.json`);
}

// --- Helper Function to create a standard event object ---
function createEvent(incident, activityName, eventTime, lastDataUpdate) {
    return {
        IncidentId: incident.number,
        ActivityName: activityName,
        EventTime: eventTime,
        SourceSystem: SOURCE_SYSTEM,
        LastDataUpdate: lastDataUpdate,
        AssignedTo: incident.assigned_to.display_value || '',
        AssignmentGroup: incident.assignment_group.display_value || '',
        Priority: incident.priority.display_value || '',
        IncidentState: incident.incident_state.display_value || incident.state.display_value || ''
    };
}

// --- Run the script ---
extractIncidentData();

Schritte

Voraussetzungen: Installieren Sie Python 3.6 oder höher auf Ihrem System. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install requests pandas.
ServiceNow einrichten: Erstellen Sie für den Export ein eigenes Servicekonto in ServiceNow. Weisen Sie diesem Benutzer die Rollen itil und rest_api_explorer zu, damit er Lesezugriff auf die erforderlichen Tabellen incident, sys_audit und sys_journal_field hat.
Skript konfigurieren: Öffnen Sie das bereitgestellte Python-Skript. Ersetzen Sie im Konfigurationsabschnitt am Anfang die Platzhalter SNOW_INSTANCE, SNOW_USER und SNOW_PASSWORD durch die URL Ihrer ServiceNow-Instanz und die Zugangsdaten des Servicekontos. Legen Sie mit START_DATE und END_DATE den gewünschten Exportzeitraum fest.
Skript ausführen: Starten Sie das Skript über die Befehlszeile mit python your_script_name.py. Das Skript authentifiziert sich bei ServiceNow und führt die API-Aufrufe aus.
Daten abrufen: Zunächst ruft das Skript alle Incidents aus der Tabelle incident ab, die im angegebenen Zeitraum erstellt wurden. Anschließend verwendet es die Incident-IDs, um den zugehörigen Änderungsverlauf aus sys_audit und alle Kommentare aus sys_journal_field abzurufen.
Event Log erstellen: Das Skript verarbeitet die Rohdaten im Arbeitsspeicher. Es durchläuft die vordefinierten Aktivitäten und erstellt für jede Aktivität eigene Zeilen. Das Ereignis „Incident Created“ wird beispielsweise anhand des Felds sys_created_on und „Incident Closed“ anhand des Felds closed_at ermittelt. Bei anderen Ereignissen analysiert das Skript das Audit-Protokoll, um Statusübergänge, Feldänderungen und Eskalationen zu erkennen.
Attribute zuordnen: Für jede erstellte Ereigniszeile ergänzt das Skript Kontextattribute aus dem Incident-Hauptdatensatz, etwa AssignmentGroup, AssignedTo, Priority und IncidentState zum Zeitpunkt des Ereignisses.
Daten zusammenführen: Alle einzelnen Event-DataFrames, jeweils einer pro Aktivitätstyp, werden zu einem umfassenden Event-Log-DataFrame zusammengeführt.
Abschließende Umwandlung: Der zusammengeführte DataFrame wird nach IncidentId und EventTime sortiert, damit die Ereignisse jedes Falls chronologisch geordnet sind. Die Spalten SourceSystem und LastDataUpdate werden mit festen Werten ergänzt.
Als CSV exportieren: Das fertige Event Log wird im selben Verzeichnis, in dem das Skript ausgeführt wurde, als servicenow_incident_event_log.csv gespeichert. Diese Datei kann in eine Process-Mining-Software hochgeladen werden.

Konfiguration

ServiceNow-Instanz (SNOW_INSTANCE): Die vollständige URL Ihrer ServiceNow-Instanz, zum Beispiel https://yourcompany.service-now.com.
Zugangsdaten (SNOW_USER, SNOW_PASSWORD): Authentifizierungsdaten für das Servicekonto. In Produktionsumgebungen sollten Sie OAuth oder eine tokenbasierte Authentifizierung anstelle der Basisauthentifizierung in Betracht ziehen.
Zeitraum (START_DATE, END_DATE): Legt den Zeitraum für den Export anhand des Erstellungsdatums der Incidents fest. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten, um Datenvolumen und Aussagekraft auszubalancieren. Bei längeren Zeiträumen verlängert sich der Export deutlich.
API-Abfrageparameter (sysparm_query): Das Skript verwendet sysparm_query, um Incidents nach ihrem Erstellungsdatum (sys_created_on) zu filtern. Sie können weitere Bedingungen ergänzen, um den Umfang einzugrenzen, zum Beispiel active=false^company=[Your Company Sys ID], um nur geschlossene Incidents eines bestimmten Unternehmens zu exportieren.
API-Ratenbegrenzung: Beachten Sie die Ratenbegrenzungen der ServiceNow-API. Das Skript unterstützt die Seitennavigation, enthält aber keine ausdrückliche Behandlung von Ratenbegrenzungen. Bei sehr großen Instanzen müssen Sie möglicherweise zwischen Anfragen time.sleep()-Aufrufe einfügen, damit die Grenzwerte nicht überschritten werden.
Erforderliche Berechtigungen: Der angegebene Benutzer benötigt Lesezugriff (ACLs) auf die Tabellen incident, sys_audit und sys_journal_field. In der Regel gewährt die Rolle itil diesen Zugriff. Ihre Instanz kann jedoch benutzerdefinierte Zugriffskontrollen verwenden.

Beispielabfrage python

import requests
import pandas as pd
from datetime import datetime
import getpass

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your ServiceNow instance URL, e.g., class="hl-string">'https://yourinstance.service-now.com'
SNOW_INSTANCE = class="hl-string">"[Your ServiceNow Instance URL]"
class=class="hl-string">"hl-comment"># Replace with your ServiceNow user. Consider using a dedicated service account.
SNOW_USER = class="hl-string">"[Your Username]"
class=class="hl-string">"hl-comment"># It's recommended to use a secure way to handle passwords, like environment variables or a secrets manager.
class=class="hl-string">"hl-comment"># getpass is used here for interactive entry to avoid hardcoding.
SNOW_PASSWORD = getpass.getpass(class="hl-string">"Enter ServiceNow Password: ")

class=class="hl-string">"hl-comment"># Define the date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"

SOURCE_SYSTEM_NAME = class="hl-string">"ServiceNow"

class=class="hl-string">"hl-comment"># --- Helper Function for Paginated API Calls ---
def fetch_all_records(url, headers, params):
    class="hl-string">"""Fetches all records from a paginated ServiceNow API endpoint."""
    all_records = []
    offset = 0
    limit = 1000
    while True:
        params[class="hl-string">'sysparm_offset'] = offset
        params[class="hl-string">'sysparm_limit'] = limit
        response = requests.get(url, headers=headers, params=params)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for bad status codes
        data = response.json().get(class="hl-string">'result', [])
        if not data:
            break
        all_records.extend(data)
        offset += len(data)
        print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
    return all_records

class=class="hl-string">"hl-comment"># --- Main Script ---
if __name__ == class="hl-string">"__main__":
    auth = (SNOW_USER, SNOW_PASSWORD)
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">"Z"

    class=class="hl-string">"hl-comment"># 1. Fetch base Incident Data
    print(class="hl-string">"\n--- Fetching Incident Data ---")
    incident_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/incident"
    incident_query = fclass="hl-string">"sys_created_on>={START_DATE} 00:00:00^sys_created_on<={END_DATE} 23:59:59"
    incident_params = {
        class="hl-string">'sysparm_query': incident_query,
        class="hl-string">'sysparm_fields': class="hl-string">'sys_id,number,sys_created_on,closed_at,opened_at,priority,state,assignment_group,assigned_to,problem_id'
    }
    incidents_raw = fetch_all_records(incident_url, headers, auth, incident_params)
    incidents_df = pd.DataFrame(incidents_raw)
    
    if incidents_df.empty:
        print(class="hl-string">"No incidents found for the given date range. Exiting.")
        exit()

    class=class="hl-string">"hl-comment"># Map sys_id to readable values for easier processing later
    for col in [class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'problem_id']:
        if col in incidents_df.columns:
            incidents_df[col] = incidents_df[col].apply(lambda x: x[class="hl-string">'display_value'] if isinstance(x, dict) and x else None)
            
    incident_sys_ids = class="hl-string">','.join(incidents_df[class="hl-string">'sys_id'].unique())

    class=class="hl-string">"hl-comment"># 2. Fetch Audit (sys_audit) Data for these incidents
    print(class="hl-string">"\n--- Fetching Audit Data ---")
    audit_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/sys_audit"
    audit_query = fclass="hl-string">"documentkeyIN{incident_sys_ids}"
    audit_params = {
        class="hl-string">'sysparm_query': audit_query,
        class="hl-string">'sysparm_fields': class="hl-string">'documentkey,sys_created_on,fieldname,oldvalue,newvalue'
    }
    audit_raw = fetch_all_records(audit_url, headers, auth, audit_params)
    audit_df = pd.DataFrame(audit_raw)
    audit_df.rename(columns={class="hl-string">'documentkey': class="hl-string">'sys_id'}, inplace=True)

    class=class="hl-string">"hl-comment"># 3. Fetch Journal (comments) Data for these incidents
    print(class="hl-string">"\n--- Fetching Journal/Comment Data ---")
    journal_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/sys_journal_field"
    journal_query = fclass="hl-string">"element_idIN{incident_sys_ids}^element=work_notes,comments"
    journal_params = {
        class="hl-string">'sysparm_query': journal_query,
        class="hl-string">'sysparm_fields': class="hl-string">'element_id,sys_created_on'
    }
    journal_raw = fetch_all_records(journal_url, headers, auth, journal_params)
    journal_df = pd.DataFrame(journal_raw)
    journal_df.rename(columns={class="hl-string">'element_id': class="hl-string">'sys_id'}, inplace=True)

    print(class="hl-string">"\n--- Processing Data and Generating Event Log ---")
    event_log_frames = []

    class=class="hl-string">"hl-comment"># Merge incident details into audit and journal logs for context
    incidents_context_df = incidents_df[[class="hl-string">'sys_id', class="hl-string">'number', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state']].copy()
    incidents_context_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId'}, inplace=True)

    if not audit_df.empty:
        audit_df = pd.merge(audit_df, incidents_context_df, on=class="hl-string">'sys_id', how=class="hl-string">'left')
    if not journal_df.empty:
        journal_df = pd.merge(journal_df, incidents_context_df, on=class="hl-string">'sys_id', how=class="hl-string">'left')

    class=class="hl-string">"hl-comment"># Activity: Incident Created
    created_df = incidents_df[[class="hl-string">'number', class="hl-string">'sys_created_on', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state']].copy()
    created_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Created'
    created_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId', class="hl-string">'sys_created_on': class="hl-string">'EventTime', class="hl-string">'assignment_group': class="hl-string">'AssignmentGroup', class="hl-string">'assigned_to': class="hl-string">'AssignedTo', class="hl-string">'priority': class="hl-string">'Priority', class="hl-string">'state': class="hl-string">'IncidentState'}, inplace=True)
    event_log_frames.append(created_df)

    class=class="hl-string">"hl-comment"># Activity: Incident Closed
    closed_df = incidents_df[incidents_df[class="hl-string">'closed_at'].notna() & (incidents_df[class="hl-string">'closed_at'] != class="hl-string">'')].copy()
    closed_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Closed'
    closed_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId', class="hl-string">'closed_at': class="hl-string">'EventTime', class="hl-string">'assignment_group': class="hl-string">'AssignmentGroup', class="hl-string">'assigned_to': class="hl-string">'AssignedTo', class="hl-string">'priority': class="hl-string">'Priority', class="hl-string">'state': class="hl-string">'IncidentState'}, inplace=True)
    event_log_frames.append(closed_df.drop(columns=[class="hl-string">'sys_created_on']))

    class=class="hl-string">"hl-comment"># Process audit data for remaining activities
    if not audit_df.empty:
        audit_df.sort_values(by=[class="hl-string">'sys_id', class="hl-string">'sys_created_on'], inplace=True)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Categorized (first change to category, subcategory, or priority)
        categorized_fields = [class="hl-string">'category', class="hl-string">'subcategory', class="hl-string">'priority']
        categorized_df = audit_df[audit_df[class="hl-string">'fieldname'].isin(categorized_fields)].copy()
        categorized_df = categorized_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        categorized_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Categorized'
        event_log_frames.append(categorized_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Assigned To Group
        assign_group_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'assignment_group') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        assign_group_first_df = assign_group_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        assign_group_first_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Assigned To Group'
        event_log_frames.append(assign_group_first_df)
        
        class=class="hl-string">"hl-comment"># Activity: Assignment Group Changed (subsequent changes)
        assign_group_changed_df = assign_group_df.loc[assign_group_df.index.difference(assign_group_first_df.index)]
        assign_group_changed_df[class="hl-string">'ActivityName'] = class="hl-string">'Assignment Group Changed'
        event_log_frames.append(assign_group_changed_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Assigned To Agent
        assign_agent_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'assigned_to') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        assign_agent_df = assign_agent_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        assign_agent_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Assigned To Agent'
        event_log_frames.append(assign_agent_df)

        class=class="hl-string">"hl-comment"># Activity: Work Started (State changed to In Progress)
        work_started_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        class=class="hl-string">"hl-comment"># Note: The class="hl-string">'newvalue' for state is often a numeric ID. Common value for class="hl-string">'In Progress' is class="hl-string">'2'. Adjust if needed.
        work_started_df = work_started_df[work_started_df[class="hl-string">'newvalue'].isin([class="hl-string">'2', class="hl-string">'In Progress', class="hl-string">'Work in Progress'])]
        work_started_df = work_started_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        work_started_df[class="hl-string">'ActivityName'] = class="hl-string">'Work Started'
        event_log_frames.append(work_started_df)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Escalated (Priority increases)
        priority_map = {class="hl-string">'1 - Critical': 1, class="hl-string">'2 - High': 2, class="hl-string">'3 - Moderate': 3, class="hl-string">'4 - Low': 4, class="hl-string">'5 - Planning': 5}
        escalated_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'priority'].copy()
        escalated_df[class="hl-string">'old_priority_val'] = escalated_df[class="hl-string">'oldvalue'].map(priority_map)
        escalated_df[class="hl-string">'new_priority_val'] = escalated_df[class="hl-string">'newvalue'].map(priority_map)
        escalated_df.dropna(subset=[class="hl-string">'old_priority_val', class="hl-string">'new_priority_val'], inplace=True)
        escalated_df = escalated_df[escalated_df[class="hl-string">'new_priority_val'] < escalated_df[class="hl-string">'old_priority_val']]
        escalated_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Escalated'
        event_log_frames.append(escalated_df)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Linked To Problem
        linked_problem_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'problem_id') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        linked_problem_df = linked_problem_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        linked_problem_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Linked To Problem'
        event_log_frames.append(linked_problem_df)
        
        class=class="hl-string">"hl-comment"># Activity: Resolution Proposed (State changed to Resolved)
        resolved_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        class=class="hl-string">"hl-comment"># Note: Common value for class="hl-string">'Resolved' is class="hl-string">'6'. Adjust if needed.
        resolved_df = resolved_df[resolved_df[class="hl-string">'newvalue'].isin([class="hl-string">'6', class="hl-string">'Resolved'])]
        resolved_df[class="hl-string">'ActivityName'] = class="hl-string">'Resolution Proposed'
        event_log_frames.append(resolved_df)
        
        class=class="hl-string">"hl-comment"># Activity: Awaiting User Confirmation (State changed to Awaiting User Info, after resolved)
        class=class="hl-string">"hl-comment"># This logic is complex and dependent on workflow. A simplified version is shown.
        state_changes = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        state_changes[class="hl-string">'prev_state'] = state_changes.groupby(class="hl-string">'sys_id')[class="hl-string">'oldvalue'].shift(-1)
        awaiting_df = state_changes[
            (state_changes[class="hl-string">'newvalue'].isin([class="hl-string">'Awaiting User Info', class="hl-string">'3'])) & 
            (state_changes[class="hl-string">'oldvalue'].isin([class="hl-string">'Resolved', class="hl-string">'6']))
        ].copy()
        awaiting_df[class="hl-string">'ActivityName'] = class="hl-string">'Awaiting User Confirmation'
        event_log_frames.append(awaiting_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Reopened
        reopened_df = audit_df[
            (audit_df[class="hl-string">'fieldname'] == class="hl-string">'state') & 
            (audit_df[class="hl-string">'oldvalue'].isin([class="hl-string">'6', class="hl-string">'7', class="hl-string">'Resolved', class="hl-string">'Closed']))
        ].copy()
        reopened_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Reopened'
        event_log_frames.append(reopened_df)
        
    class=class="hl-string">"hl-comment"># Activity: Support Comment Added
    if not journal_df.empty:
        comment_df = journal_df.copy()
        comment_df[class="hl-string">'ActivityName'] = class="hl-string">'Support Comment Added'
        event_log_frames.append(comment_df)

    class=class="hl-string">"hl-comment"># 4. Consolidate all event dataframes
    print(class="hl-string">"\n--- Consolidating Final Event Log ---")
    final_log = pd.DataFrame()
    for df in event_log_frames:
        if class="hl-string">'sys_created_on' in df.columns:
             df.rename(columns={class="hl-string">'sys_created_on': class="hl-string">'EventTime'}, inplace=True)
        if class="hl-string">'IncidentId' not in df.columns:
            continue class=class="hl-string">"hl-comment"># Skip frames that couldn't be processed
        
        common_cols = {
            class="hl-string">'IncidentId': None,
            class="hl-string">'ActivityName': None,
            class="hl-string">'EventTime': None,
            class="hl-string">'AssignedTo': None,
            class="hl-string">'AssignmentGroup': None,
            class="hl-string">'Priority': None,
            class="hl-string">'IncidentState': None
        }
        
        class=class="hl-string">"hl-comment"># Select and reorder columns, filling missing ones with None
        current_cols = {col: None for col in common_cols.keys()}
        df_subset = df[list(set(df.columns) & set(common_cols.keys()))].copy()
        final_log = pd.concat([final_log, df_subset], ignore_index=True)

    class=class="hl-string">"hl-comment"># 5. Final Cleaning and Formatting
    final_log.dropna(subset=[class="hl-string">'IncidentId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    final_log[class="hl-string">'EventTime'] = pd.to_datetime(final_log[class="hl-string">'EventTime'])
    final_log.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTime'], inplace=True)
    
    final_log[class="hl-string">'SourceSystem'] = SOURCE_SYSTEM_NAME
    final_log[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Reorder columns to the desired format
    final_log = final_log[[
        class="hl-string">'IncidentId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', 
        class="hl-string">'AssignedTo', class="hl-string">'AssignmentGroup', class="hl-string">'Priority', class="hl-string">'IncidentState'
    ]]

    class=class="hl-string">"hl-comment"># 6. Save to CSV
    output_filename = class="hl-string">'servicenow_incident_event_log.csv'
    final_log.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"\nSuccessfully extracted {len(final_log)} events for {final_log['IncidentId'].nunique()} incidents.")
    print(fclass="hl-string">"Event log saved to {output_filename}")

Möchten Sie loslegen?

Mit diesem Template erhalten Sie alles, was Sie für den Einstieg ins Process Mining Ihres Incident-Management-Prozesses benötigen. Beginnen Sie noch heute damit, die Lösung Ihrer Incidents zu verbessern.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Incidents schneller lösen: Steigern Sie jetzt die Effizienz in ServiceNow

Senken Sie die MTTR in ServiceNow um 35 %. Erkennen Sie Probleme und verbessern Sie die Zufriedenheit.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Beginnen Sie in wenigen Minuten mit der Optimierung.

Ihr Daten-Template für das Incident Management

Ihr Daten-Template für das Incident Management

Attribute des Incident Managements

Aktivitäten im Incident Management

Anleitungen zum Extrahieren von Daten

Direkter Datenexport über die ServiceNow Table REST API

Schritte

Konfiguration

Beispielabfrage javascript

Datenexport mit einem Python-Skript über die ServiceNow REST API

Schritte

Konfiguration

Beispielabfrage python

Möchten Sie loslegen?

Incidents schneller lösen: Steigern Sie jetzt die Effizienz in ServiceNow