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

Ihr Daten-Template für Incident Management

ServiceNow Problem Management

Attribute des Incident Managements (19) Aktivitäten des Incident Managements (13) Extraktionsanleitungen (2)

Ihr Daten-Template für Incident Management

Dieses Template bietet eine umfassende Anleitung zur Erfassung der erforderlichen Daten für die Analyse und Optimierung Ihres Incident-Management-Prozesses. Es beschreibt die wichtigsten zu erfassenden Datenattribute, die zentralen zu verfolgenden Aktivitäten und praktische Hinweise zur Extraktion dieser Informationen aus Ihrem Quellsystem. Verwenden Sie diese Ressource, um ein aussagekräftiges Event Log für eine detaillierte Prozessanalyse und Verbesserung zu erstellen.

Empfohlene zu erfassende Attribute
Wichtige zu verfolgende Aktivitäten
Anleitung zur Extraktion für ServiceNow Problem Management

Neu bei Event Logs? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Template herunterladen

Attribute des Incident Managements

Dies sind die empfohlenen Datenfelder, die Sie für eine umfassende Analyse Ihres Incident-Management-Prozesses in Ihr Event Log aufnehmen sollten.

5 Erforderlich 4 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des spezifischen Ereignisses oder Tasks, der zu einem bestimmten Zeitpunkt im Lebenszyklus des Incidents stattgefunden hat.
Beschreibung Der Aktivitätsname beschreibt einen bestimmten Schritt oder eine Statusänderung im Incident-Management-Prozess, etwa „Incident Created“, „Assigned To Agent“ oder „Incident Closed“. Diese Daten werden in der Regel aus Änderungen an wichtigen Incident-Feldern wie „State“ oder „Assignment Group“ oder aus bestimmten Protokolleinträgen abgeleitet. Dieses Attribut ist entscheidend für den Aufbau der Prozessdarstellung. Es definiert die Knoten im Prozessgraphen und ermöglicht es Analysten, den Incident-Fluss zu visualisieren, häufige Abläufe zu erkennen, Engpässe zwischen Aktivitäten aufzudecken und Prozessvarianten zu analysieren. Die Detailtiefe und Genauigkeit dieser Aktivitätsnamen wirken sich unmittelbar auf die Qualität der Prozessanalyse aus. Warum das wichtig ist Es definiert die Schritte in der Prozessdarstellung und bildet damit die Grundlage für sämtliche Process-Mining-Analysen und Visualisierungen. Bezugsquelle Dies ist ein abgeleitetes Attribut, das in der Regel von der Datentransformationslogik auf Basis von Änderungen an Feldern wie state, assignment_group und assigned_to in den Tabellen sys_audit oder incident erzeugt wird. Beispiele Incident erstelltAssignment Group geändertLösung vorgeschlagenIncident geschlossen
	Ereigniszeitpunkt EventTime	Der präzise Timestamp, der angibt, wann die Aktivität stattgefunden hat.
Beschreibung Event Time, häufig als Timestamp bezeichnet, erfasst das genaue Datum und die genaue Uhrzeit, zu denen eine Aktivität abgeschlossen oder eine Statusänderung vorgenommen wurde. In ServiceNow wird dieser Wert typischerweise im Feld sys_updated_on für jede im Audit Trail erfasste Änderung gespeichert. Dieses Attribut ist entscheidend für die korrekte Reihenfolge der Ereignisse und für sämtliche zeitbasierten Analysen. Es wird zur Berechnung von Durchlaufzeiten, Wartezeiten und Zeitspannen zwischen Aktivitäten verwendet. Diese Kennzahlen sind grundlegend, um Engpässe zu identifizieren, die Leistung im Verhältnis zu SLAs zu messen und die Prozesseffizienz zu verstehen. Die Genauigkeit dieser Timestamps ist für die Aussagekraft aller dauerbasierten Kennzahlen entscheidend. Warum das wichtig ist Dieser Timestamp ordnet alle Aktivitäten chronologisch und ermöglicht die Berechnung sämtlicher dauerbasierter Kennzahlen, etwa Durchlaufzeiten und Engpässe. Bezugsquelle ServiceNow-Tabelle sys_audit, Feld sys_created_on oder das Feld sys_updated_on 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	Der eindeutige Bezeichner jedes Incident-Datensatzes, der als Primärschlüssel für die Nachverfolgung des gesamten Lebenszyklus dient.
Beschreibung Die Incident-ID ist die eindeutige Referenznummer, die jedem in ServiceNow gemeldeten Incident zugewiesen wird. Sie dient als zentraler Case-Bezeichner und verknüpft alle zugehörigen Aktivitäten, Aktualisierungen und Mitteilungen vom Erstellen eines Incidents bis zu dessen Abschluss. In der Process-Mining-Analyse ist diese ID grundlegend. Sie ermöglicht es dem Tool, die Ereignisfolge jedes einzelnen Cases zusammenzuführen. Damit bildet sie die Basis für die Ermittlung von Prozessmodellen, die Analyse von Varianten und die Berechnung von End-to-End-Dauern. Ohne eine eindeutige Incident-ID für jeden Case wäre es nicht möglich, den Weg eines Incidents durch den Lösungsprozess nachzuverfolgen. Warum das wichtig ist Dies ist die zentrale Case-ID, die alle Ereignisse im Lebenszyklus eines Incidents verbindet und dadurch eine End-to-End-Prozessanalyse ermöglicht. Bezugsquelle ServiceNow-Incident-Tabelle, Feld „number“. Beispiele INC0010001INC0010045INC0010239
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, 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 Aktualisierung aus ServiceNow. Es handelt sich um ein Metadatenfeld, das die Aktualität der analysierten Daten widerspiegelt, nicht um ein Ereignis im Prozess selbst. Diese Information ist entscheidend, 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 jüngster Ereignisse wichtig. Außerdem hilft sie dabei, Erwartungen an Relevanz und Aktualität der Daten zu steuern. Warum das wichtig ist Es informiert Benutzer über die Aktualität der Daten, die für die Relevanz und Genauigkeit der Analyse entscheidend ist. Bezugsquelle Dieser Timestamp wird vom Datenextraktionstool oder -prozess zum Zeitpunkt des Datenimports 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 identifiziert die Herkunft der Incident-Daten, in diesem Fall ServiceNow Problem Management. In der Regel handelt es sich um einen statischen Wert, der während der Datenextraktion und -transformation hinzugefügt wird. In Umgebungen, in denen Daten aus mehreren Systemen für eine Analyse zusammengeführt werden, ist dieses Feld für Datenherkunft und Trennung der Daten entscheidend. Es stellt sicher, dass Kennzahlen und Prozesse im richtigen Kontext analysiert werden, und ermöglicht den Vergleich von Prozessen aus unterschiedlichen Quellsystemen. Warum das wichtig ist Es liefert wichtigen Kontext zur Datenherkunft, stellt die Datenherkunft sicher und ermöglicht die korrekte Interpretation in Umgebungen mit mehreren Systemen. Bezugsquelle In der Regel handelt es sich um einen statischen Wert, der während der Datenextraktion hinzugefügt wird. Beispiele ServiceNow Problem ManagementServiceNow
	Incident-Status IncidentState	Der aktuelle Status des Incidents in seinem Lebenszyklus.
Beschreibung Der Incident State zeigt die aktuelle Phase eines Incidents an, etwa „New“, „In Progress“, „On Hold“ oder „Resolved“. Statusänderungen sind häufig die wichtigste Quelle für die Erzeugung von Aktivitäten im Event Log für Process Mining. Die Analyse der in jedem Status verbrachten Zeit ist eine wirkungsvolle Methode, um Engpässe zu identifizieren. Eine lange Dauer im Status „On Hold“ kann beispielsweise auf Abhängigkeiten von externen Faktoren oder Benutzern hinweisen. Die Abfolge der Statusänderungen bildet außerdem die Grundlage der Prozessdarstellung und zeigt, wie Incidents ihrer Lösung näherkommen. Warum das wichtig ist Es verfolgt den Fortschritt des Incidents und ist entscheidend für die Analyse der in verschiedenen Phasen verbrachten Zeit sowie die Identifizierung von Prozessengpässen. Bezugsquelle ServiceNow-Incident-Tabelle, Feld incident_state oder state. Beispiele NeuIn BearbeitungWarten auf BenutzerinformationenGelöstGeschlossen
	Priorität Priority	Die Prioritätsstufe des Incidents, die die erforderliche Dringlichkeit der Reaktion bestimmt.
Beschreibung Priority ist ein wichtiges Feld in ServiceNow und bestimmt Reihenfolge und Geschwindigkeit der Incident-Bearbeitung. Der Wert wird typischerweise aus Auswirkung und Dringlichkeit des Incidents abgeleitet und beeinflusst unmittelbar die SLA-Ziele. Dieses Attribut ist grundlegend für Segmentierung und Leistungsanalyse. Das Dashboard „SLA Compliance Overview“ verwendet Priority, um zu bewerten, ob Incidents mit hoher Priorität innerhalb ihrer Zielzeiten gelöst werden. Die Analyse von Durchlaufzeiten nach Priorität hilft zu bestätigen, dass kritische Incidents tatsächlich schneller bearbeitet werden als weniger wichtige. Priority ist eine zentrale Dimension für nahezu jeden KPI und jedes Dashboard. Warum das wichtig ist Es ermöglicht die Segmentierung von Incidents nach geschäftlicher Bedeutung und ist entscheidend für die Überwachung der SLA-Compliance sowie die Ressourcenverteilung. Bezugsquelle ServiceNow-Incident-Tabelle, Feld priority. Beispiele 1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
	Zugewiesen an AssignedTo	Der Benutzer oder Agent, der aktuell mit der Bearbeitung des Incidents betraut ist.
Beschreibung Dieses Attribut identifiziert den konkreten Support-Agenten, der zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Diese Information ist entscheidend, um die Verteilung der Arbeitslast, die Leistung von Agenten und Übergaben zwischen einzelnen Personen zu verstehen. In der Analyse hilft „Assigned To“ dabei, die Ressourcenverteilung zu visualisieren und überlastete Agenten zu erkennen. Das Attribut wird außerdem im Dashboard „Handoff and Reassignment“ verwendet, um zu verfolgen, wie oft sich die individuelle Verantwortung für einen Incident ändert. Dies kann auf Ineffizienzen oder Wissenslücken hindeuten. Die Analyse der Lösungszeiten nach Agent kann zudem besonders leistungsstarke Personen oder Personen mit zusätzlichem Schulungsbedarf sichtbar machen. Warum das wichtig ist Es ermöglicht die Analyse von Arbeitslast, Leistung und individuellen Übergaben von Agenten. Diese Aspekte sind entscheidend, um die Ressourceneffizienz zu verstehen. Bezugsquelle ServiceNow-Incident-Tabelle, Feld assigned_to. Beispiele Beth AnglinDavid LooHoward Johnson
	Zuweisungsgruppe AssignmentGroup	Das Supportteam oder die Supportgruppe, die für die Bearbeitung des Incidents verantwortlich ist.
Beschreibung Die Assignment Group bezeichnet das Team von Agenten, das mit der Lösung des Incidents betraut ist. Incidents werden häufig zwischen verschiedenen Gruppen weitergeleitet, etwa von einem Level-1-Helpdesk an ein spezialisiertes Level-2-Netzwerkteam. Dieses Attribut ist entscheidend für die Analyse von Übergaben zwischen Teams und die Identifizierung systemischer Engpässe. Das Dashboard „Handoff and Reassignment Rate“ stützt sich maßgeblich auf diese Daten und zeigt, welche Teams häufig an Übergaben beteiligt sind. Außerdem ermöglicht das Attribut Leistungsvergleiche zwischen verschiedenen Supportgruppen und hilft dabei, den Ort der Lösungskompetenz innerhalb des Unternehmens zu verstehen. Warum das wichtig ist Es zeigt, welches Team verantwortlich ist, und ermöglicht dadurch die Analyse von Teamleistung, Arbeitslast und Übergaben zwischen Gruppen. Bezugsquelle ServiceNow-Incident-Tabelle, Feld assignment_group. Beispiele Service DeskNetzwerksupportDatenbankadministratoren
	Anzahl der Neuzuweisungen ReassignmentCount	Die Anzahl der Fälle, in denen der Incident einer anderen Gruppe oder einem anderen Agenten zugewiesen wurde.
Beschreibung Dieses Feld erfasst die Gesamtzahl der Übertragungen eines Incidents zwischen verschiedenen Assignment Groups. Es ist ein direktes Maß für Reibungsverluste im Prozess und wird häufig als zentrale Leistungskennzahl verwendet. Dieses Attribut ist die wichtigste Grundlage für das Dashboard „Handoff and Reassignment Rate“ und den KPI „Average Handoffs per Incident“. Eine hohe Zahl von Neuzuweisungen weist häufig auf Probleme wie eine fehlerhafte anfängliche Weiterleitung, fehlende Kompetenzen in einer Supportstufe oder unklare Prozessverantwortung hin. Die Reduzierung dieser Zahl ist ein häufiges Ziel von Prozessverbesserungen, da sie typischerweise zu kürzeren Lösungszeiten führt. Warum das wichtig ist Es misst Übergaben im Prozess direkt und ist damit ein wichtiger Indikator für Ineffizienz, fehlerhaftes Routing und Verbesserungspotenzial. Bezugsquelle ServiceNow-Incident-Tabelle, Feld reassignment_count. Beispiele 0135
	Configuration Item ConfigurationItem	Die konkrete IT-Komponente, der Service oder das Asset, das vom Incident betroffen ist.
Beschreibung Das Configuration Item (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 ist besonders wertvoll, um unzuverlässige Assets oder Services zu identifizieren. Sie zeigt, welche Teile der IT-Infrastruktur die meisten Incidents verursachen, und kann dadurch Investitionen in Upgrades oder Ersatz unterstützen. Im Process Mining kann eine Filterung nach CI sichtbar machen, ob Incidents im Zusammenhang mit kritischen Anwendungen anders oder effizienter bearbeitet werden als andere. Warum das wichtig ist Es identifiziert das betroffene Asset, hilft bei der Erkennung problematischer Komponenten in der IT-Infrastruktur und richtet Verbesserungsmaßnahmen gezielt aus. Bezugsquelle ServiceNow-Incident-Tabelle, Feld cmdb_ci. Beispiele SAP ERP ProduktionOracle DB Server 05E-Mail-Service
	Erneut geöffnet IsReopened	Ein Kennzeichen dafür, ob ein Incident nach seiner Lösung erneut geöffnet wurde.
Beschreibung Dieses boolesche Kennzeichen wird auf true gesetzt, wenn der Status eines Incidents nach dem Erreichen des Status „Resolved“ oder „Closed“ wieder in einen aktiven Status, etwa „In Progress“, geändert wurde. Dies wird üblicherweise anhand einer Aktivität „Incident Reopened“ im Event Log erkannt. Erneut geöffnete Incidents weisen deutlich auf unvollständige oder unwirksame Lösungen hin. Die Analyse dieser Fälle hilft, vorzeitige Schließungen oder wiederkehrende Probleme zu erkennen, die beim ersten Mal nicht ordnungsgemäß behoben wurden. Eine hohe Quote erneut geöffneter Incidents kann die Benutzerzufriedenheit und die Produktivität des Teams beeinträchtigen und ist daher eine wichtige Kennzahl für die Qualitätskontrolle. Warum das wichtig ist Dieses Kennzeichen macht Fehler im Lösungsprozess sichtbar und hebt Incidents hervor, die nach ihrer vermeintlichen Lösung zusätzliche Arbeit erforderten. Bezugsquelle Berechnet durch die Prüfung der Aktivitätsfolge jedes Incidents darauf, ob auf einen Status „resolved“ ein Status „open“ folgt. Beispiele truefalse
	Kategorie Category	Die übergeordnete Klassifizierung des Incidents, etwa Hardware, Software oder Netzwerk.
Beschreibung Die Category liefert eine übergeordnete Klassifizierung der Art eines Incidents. Zusammen mit einer Subcategory unterstützt sie häufig die Weiterleitung an das richtige Supportteam und wird für Berichte und Trendanalysen verwendet. Für Process Mining ist dieses Attribut entscheidend für die Dashboards „Incident Categorization Accuracy“ und „Recurring Incident Volume“. Durch die Analyse von Incidents, bei denen die Kategorie während des Prozesses geändert wird, können Unternehmen Probleme bei der ersten Triage erkennen. Eine Filterung der Prozessdarstellung nach Kategorie kann außerdem zeigen, ob bestimmte Incident-Typen andere Lösungswege durchlaufen oder besondere Engpässe aufweisen. Warum das wichtig ist Es ermöglicht die Analyse von Incident-Typen, unterstützt die Messung der Kategorisierungsgenauigkeit und ist für Routing und Trendanalyse unverzichtbar. Bezugsquelle ServiceNow-Incident-Tabelle, Feld category. Beispiele HardwareSoftwareNetzwerkDatenbank
	Lösungscode ResolutionCode	Ein Code, der angibt, wie der Incident letztlich gelöst wurde.
Beschreibung Der Resolution Code beschreibt die Art der angewendeten Lösung, beispielsweise ob der Benutzer das Problem selbst gelöst hat, ein bekannter Fehler behoben wurde oder eine Umgehungslösung bereitgestellt wurde. Dieses Feld wird in der Regel vom Agenten beim Schließen des Incidents ausgefüllt. Dieses Attribut unterstützt unmittelbar das Dashboard „Resolution Type Effectiveness“. Es ermöglicht die Analyse, wie viele Incidents mit dauerhaften Korrekturen statt mit vorübergehenden Umgehungslösungen geschlossen werden. Das ist ein wichtiger Indikator für Servicequalität und langfristige Stabilität. Ein hoher Anteil an Umgehungslösungen kann darauf hindeuten, dass zugrunde liegende Probleme nicht ausreichend behoben werden. Warum das wichtig ist Es macht die Lösungsmethode transparent, ermöglicht den Vergleich dauerhafter Korrekturen mit vorübergehenden Umgehungslösungen und unterstützt die Ursachenanalyse. Bezugsquelle ServiceNow-Incident-Tabelle, Feld close_code oder ein kundenspezifisches Feld für den Lösungscode. Beispiele Gelöst (Workaround)Gelöst (dauerhaft)Nicht gelöst (vom Benutzer abgebrochen)Bekannter Fehler
	Meldende Person CallerId	Die Person, die den Incident ursprünglich gemeldet hat.
Beschreibung Die meldende Person bezeichnet den Endbenutzer oder Kunden, der vom Incident betroffen ist und ihn gemeldet hat. Diese Information zeigt, wer von einer Serviceunterbrechung betroffen ist. Auch wenn diese Information für den Prozessablauf selbst nicht immer zentral ist, kann die Analyse nach meldender Person zeigen, ob bestimmte Personen oder Abteilungen überproportional häufig von Problemen betroffen sind. Das kann auf Schulungsbedarf oder lokale Umgebungsprobleme hinweisen. Außerdem stellt die Information eine direkte Verbindung zum Kunden für Zufriedenheitsumfragen und Mitteilungen her. Warum das wichtig ist Es identifiziert den betroffenen Benutzer, ermöglicht Analysen nach Abteilung oder Person und liefert Kontext für die Kommunikation mit Benutzern. Bezugsquelle ServiceNow-Incident-Tabelle, Feld caller_id. Beispiele Abel TuterCarolina PashDon Goodliffe
	Problem-ID ProblemId	Der Bezeichner des zugehörigen Problem-Datensatzes, wenn der Incident mit einem größeren Problem verknüpft ist.
Beschreibung Die Problem-ID verknüpft einen Incident mit dem entsprechenden Datensatz im Modul Problem Management. Dies geschieht, wenn ein Incident als Symptom eines größeren zugrunde liegenden Problems erkannt wird, das mehrere Benutzer oder Services betrifft. Diese Verknüpfung ist entscheidend für das Dashboard „Recurring Incident Volume“ und den KPI „Recurring Incident Rate“. Sie ermöglicht es Analysten, Incidents mit derselben Ursache zu gruppieren, die vollständige Auswirkung eines Problems zu messen und die Wirksamkeit der Problemlösung nachzuverfolgen. Eine hohe Zahl mit Problemen verknüpfter Incidents weist auf eine reaktive Supportumgebung hin. Warum das wichtig ist Sie verknüpft Incidents mit einer Ursache und ist damit entscheidend für die Analyse wiederkehrender Probleme sowie die Messung der Wirkung des Problem Managements. Bezugsquelle ServiceNow-Incident-Tabelle, Feld problem_id. Beispiele PRB0040001PRB0040015PRB0040102
	Schweregrad Severity	Das Ausmaß der geschäftlichen Auswirkungen, die durch den Incident verursacht werden.
Beschreibung Severity beschreibt, wie stark ein Incident den Geschäftsbetrieb beeinträchtigt. Zusammen mit der Dringlichkeit wird dieser Wert häufig verwendet, um die Priorität eines Incidents automatisch zu berechnen. In der Analyse ist Severity eine zentrale Dimension für das Dashboard „SLA Compliance Overview“. Sie hilft Unternehmen zu verstehen, ob sie die Servicelevel für besonders störende Incidents einhalten. Damit bietet sie eine geschäftsorientierte Sicht auf die Leistung und ergänzt die operative Perspektive von Priority. Warum das wichtig ist Es misst die geschäftlichen Auswirkungen eines Incidents und liefert eine entscheidende Dimension für die Priorisierung von Maßnahmen sowie die Leistungsanalyse bei kritischen Problemen. Bezugsquelle ServiceNow-Incident-Tabelle, Feld severity. Beispiele 1 - Hoch2 - Mittel3 - Niedrig
	SLA verletzt IsSlaBreached	Ein Kennzeichen dafür, ob die Lösung des Incidents über das SLA-Fälligkeitsdatum hinaus gedauert hat.
Beschreibung Dieses berechnete boolesche Attribut kennzeichnet Incidents, bei denen das Service Level Agreement verletzt wurde. Es wird durch den Vergleich des tatsächlichen Lösungs-Timestamps mit dem „SLA-Fälligkeitsdatum“ ermittelt. Liegt die Lösungszeit nach dem Fälligkeitsdatum, wird das Kennzeichen auf true gesetzt. Dieses Attribut bildet die Grundlage für das Dashboard „SLA-Compliance-Übersicht“ und die zugehörigen KPIs. Es vereinfacht die Analyse, indem es einen komplexen Zeitvergleich in eine einfache true/false-Dimension überführt. Dadurch lassen sich alle Incidents mit SLA-Verletzung leicht filtern und nach gemeinsamen Merkmalen wie Kategorie, Zuweisungsgruppe oder Priorität analysieren. Warum das wichtig ist Es vereinfacht die Analyse der SLA-Compliance und ermöglicht das einfache Filtern sowie die detaillierte Untersuchung aller Incidents, die ihre Ziele nicht erreicht haben. Bezugsquelle Berechnet durch den Vergleich des Timestamps „Resolved At“ mit dem Timestamp „SlaDueDate“. (Resolved At > SlaDueDate). Beispiele truefalse
	SLA-Fälligkeitsdatum SlaDueDate	Das Datum und die Uhrzeit, bis zu denen der Incident gemäß seinem SLA voraussichtlich gelöst sein soll.
Beschreibung Das SLA-Fälligkeitsdatum ist ein berechneter Timestamp, der die Lösungsfrist für einen Incident angibt. Dieses Datum wird anhand des Service Level Agreement (SLA) bestimmt, das mit den Merkmalen des Incidents, etwa seiner Priorität, verknüpft ist. Dieses Attribut ist für das Dashboard „SLA-Compliance-Übersicht“ und die KPI „Quote kritischer Incidents mit SLA-Verletzung“ von zentraler Bedeutung. Es dient als Referenzwert für den Vergleich mit der tatsächlichen Lösungszeit. Die Analyse von Incidents, deren SLA-Fälligkeitsdatum näher rückt, unterstützt eine proaktive Eskalation und Priorisierung. Warum das wichtig ist Es definiert das Lösungsziel und ermöglicht dadurch, die SLA-Compliance zu messen sowie Incidents zu identifizieren, bei denen eine Verletzung des Ziels droht. Bezugsquelle Dieser Wert befindet sich üblicherweise in der Tabelle task_sla, die mit der Tabelle incident verknüpft ist. Das relevante Feld ist planned_end_time. Beispiele 2023-05-20T17:00:00Z2023-06-01T09:00:00Z

Erforderlich Empfohlen Optional

Aktivitäten des Incident Managements

Dies sind die zentralen Prozessschritte und Meilensteine, die Sie für eine präzise Prozesserkennung und Optimierung in Ihrem Event Log erfassen sollten.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Assignment Group geändert	Bezeichnet eine Übergabe, bei der ein Incident von einer Supportgruppe an eine andere übertragen wird. Dies wird durch nachfolgende Änderungen am Feld „assignment_group“ nach dessen erstmaliger Befüllung erfasst.
Warum das wichtig ist Häufige Neuzuweisungen können auf eine fehlerhafte anfängliche Weiterleitung, komplexe Abläufe oder Wissenslücken hindeuten. Diese Aktivität ist entscheidend für die Messung des KPI „Average Handoffs per Incident“. Bezugsquelle Abgeleitet aus der Tabelle „sys_audit“, indem jede Änderung am Feld „assignment_group“ nach der ersten Zuweisung erfasst wird. Erfassen Ermitteln Sie jeden mit einem Timestamp versehenen Änderungszeitpunkt des Feldes „assignment_group“ im Audit Log. Ereignistyp inferred
	Bearbeitung begonnen	Zeigt an, dass ein Agent mit der aktiven Untersuchung oder Bearbeitung des Incidents begonnen hat. Dies wird in der Regel abgeleitet, wenn 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 und den Beginn der aktiven Lösungsarbeit. Die Messung der Zeit bis zum Bearbeitungsbeginn ist entscheidend für die Engpassanalyse. Bezugsquelle Abgeleitet aus der Tabelle „sys_audit“, indem identifiziert wird, wann sich das Feld „state“ in der Tabelle „incident“ in einen Wert ändert, der aktive Arbeit bezeichnet, etwa „In Progress“. Erfassen Ermitteln Sie den Timestamp, an dem sich das Feld „state“ in „In Progress“ oder einen vergleichbaren Wert ändert. Ereignistyp inferred
	Incident einer Gruppe zugewiesen	Diese Aktivität findet statt, wenn ein Incident einer bestimmten Supportgruppe zur Bearbeitung zugewiesen wird. Sie ist ein wichtiger Schritt im Routing-Prozess und wird durch die Beobachtung von Änderungen am Feld der Assignment Group erfasst.
Warum das wichtig ist Die Nachverfolgung von Zuweisungen ist entscheidend, um Übergaben, Wartezeiten in den einzelnen Gruppen sowie ineffiziente Routing-Abläufe und Engpässe zu analysieren. Bezugsquelle Abgeleitet aus der Tabelle „sys_audit“, indem erfasst wird, wann das Feld „assignment_group“ in der Tabelle „incident“ ausgefüllt oder geändert wird. Erfassen Verwenden Sie den Timestamp aus dem Audit Log für Änderungen am Feld „assignment_group“. Ereignistyp inferred
	Incident erstellt	Kennzeichnet den Beginn des Incident-Lebenszyklus, sobald ein neuer Incident in ServiceNow offiziell erfasst wurde. Dieses Ereignis wird ausdrücklich über den Erstellungszeitpunkt des Incident-Datensatzes erfasst.
Warum das wichtig ist Dies ist das primäre Start-Ereignis des Prozesses. Die Analyse der Zeit von dieser Aktivität bis zur Lösung ist grundlegend, um die gesamte Durchlaufzeit und die SLA-Compliance zu messen. Bezugsquelle Der Timestamp „sys_created_on“ in der Tabelle „incident“ dient als ausdrücklicher Ereigniszeitpunkt für diese Aktivität. Erfassen 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 ist und keine weiteren Maßnahmen erforderlich sind. Das Ereignis wird ausdrücklich über den Schließzeitpunkt erfasst.
Warum das wichtig ist Als abschließendes Endereignis ist diese Aktivität entscheidend für die Berechnung der gesamten Incident-Lebenszyklusdauer und die Analyse der Zeit für nachgelagerte Verarbeitungsschritte. Bezugsquelle Der Timestamp „closed_at“ in der Tabelle „incident“ dient als ausdrücklicher Ereigniszeitpunkt. Er wird in der Regel gesetzt, wenn sich das Feld „state“ in „Closed“ ändert. Erfassen Verwenden Sie den Timestamp „closed_at“ aus dem Incident-Datensatz. Ereignistyp explicit
	Lösung vorgeschlagen	Markiert den Zeitpunkt, an dem ein Support-Agent eine Korrektur umgesetzt und den Incident in den Status „Resolved“ versetzt hat. Dies ist ein wichtiger Meilenstein vor dem endgültigen Abschluss.
Warum das wichtig ist Diese Aktivität signalisiert das Ende der aktiven Arbeit und den Beginn der Bestätigungsphase. Die Zeit zwischen diesem Ereignis und „Incident Closed“ kann Verzögerungen bei der Benutzerbestätigung oder Verifizierung sichtbar machen. Bezugsquelle Abgeleitet aus der Tabelle „sys_audit“, wenn sich das Feld „state“ in der Tabelle „incident“ in „Resolved“ ändert. Der Timestamp „resolved_at“ wird zu diesem Zeitpunkt häufig ausgefüllt. Erfassen Verwenden Sie den Timestamp, an dem das Feld „state“ den Wert „Resolved“ annimmt, oder den Timestamp „resolved_at“. Ereignistyp inferred
	Incident einem Agenten zugewiesen	Bezeichnet den Zeitpunkt, an dem ein bestimmter Agent innerhalb einer Supportgruppe die Verantwortung für den Incident übernimmt. Dies wird durch die Überwachung von Änderungen am Feld „assigned_to“ erfasst.
Warum das wichtig ist Dies ermöglicht eine detaillierte Betrachtung der Arbeitslast von Agenten und der Lösung beim Erstkontakt. So lässt sich ermitteln, wie lange Incidents nach der Zuweisung zu einer Gruppe auf den Beginn der Bearbeitung durch eine einzelne Person warten. Bezugsquelle Abgeleitet aus der Tabelle „sys_audit“, indem erfasst wird, wann das Feld „assigned_to“ in der Tabelle „incident“ ausgefüllt oder geändert wird. Erfassen Verwenden Sie den Timestamp aus dem Audit Log für Änderungen am Feld „assigned_to“. Ereignistyp inferred
	Incident erneut geöffnet	Tritt ein, wenn ein Benutzer meldet, dass das Problem weiterhin besteht, nachdem der Incident als gelöst markiert wurde. Dies wird abgeleitet, wenn sich der Incident-Status von „Resolved“ zurück in einen aktiven Status wie „In Progress“ ändert.
Warum das wichtig ist Erneut geöffnete Incidents weisen auf fehlgeschlagene Lösungen hin und stellen Nacharbeit dar. Die Nachverfolgung dieser Aktivität ist entscheidend, um die Lösungsqualität und die Rate der beim ersten Versuch behobenen Incidents zu messen. Bezugsquelle Abgeleitet aus der Tabelle „sys_audit“, indem ein Übergang des Feldes „state“ von „Resolved“ zurück in einen aktiven Status wie „In Progress“ oder „Assigned“ erkannt wird. Erfassen Ermitteln Sie den Timestamp, an dem sich „state“ von „Resolved“ in einen aktiven Wert ändert. Ereignistyp inferred
	Incident eskaliert	Tritt ein, wenn die Priorität oder der Schweregrad eines Incidents erhöht wird und häufig eine schnellere Reaktion oder andere Ressourcen erforderlich sind. Dies wird durch die Erkennung einer Aufwärtsänderung im Wert des Feldes „priority“ abgeleitet.
Warum das wichtig ist Eskalationen weisen häufig darauf hin, dass ein Incident schwerwiegender ist als zunächst angenommen oder ein SLA-Verstoß droht. Die Analyse dieser Ereignisse hilft dabei, Ausnahmen im Prozess zu verstehen. Bezugsquelle Abgeleitet aus der Tabelle „sys_audit“, indem eine Änderung des Feldes „priority“ auf einen Wert mit höherer Dringlichkeit identifiziert wird. Erfassen Erkennen Sie, wenn der Wert des Feldes „priority“ steigt, beispielsweise von „3 - Moderate“ auf „2 - High“. Ereignistyp inferred
	Incident kategorisiert	Stellt die erste Klassifizierung des Incidents dar, bei der Felder wie Category, Subcategory und Priority festgelegt werden. Dieses Ereignis wird in der Regel aus dem Audit Trail abgeleitet, sobald diese Felder erstmals ausgefüllt oder kurz nach der Erstellung aktualisiert werden.
Warum das wichtig ist Eine präzise Kategorisierung ist entscheidend für die korrekte Weiterleitung und Priorisierung. Die Nachverfolgung dieser Aktivität hilft dabei, die Rate von Rekategorisierungen und deren Einfluss auf die Lösungszeit zu analysieren. Bezugsquelle Abgeleitet aus der Tabelle „sys_audit“, indem die erste Änderung an Feldern wie „category“, „subcategory“ oder „priority“ für einen bestimmten Incident identifiziert wird. Erfassen Ermitteln Sie den Timestamp der ersten Aktualisierung von Klassifizierungsfeldern im Audit Log. Ereignistyp inferred
	Incident mit Problem verknüpft	Diese Aktivität findet statt, wenn ein Incident offiziell mit einem Problem-Datensatz verknüpft wird. Dies weist darauf hin, dass er Teil eines größeren zugrunde liegenden Problems ist. Abgeleitet wird das Ereignis, wenn das Feld „problem_id“ im Incident-Datensatz ausgefüllt wird.
Warum das wichtig ist Die Verknüpfung mit einem Problem ist ein entscheidender Schritt auf dem Weg von der reaktiven Incident-Behebung zur proaktiven Ursachenanalyse. Sie unterstützt das Dashboard „Recurring Incident Volume“. Bezugsquelle Abgeleitet durch die Erkennung, dass das Referenzfeld „problem_id“ in der Tabelle „incident“ mit einem Wert befüllt wird. Erfassen Ermitteln Sie den Timestamp aus dem Audit Log, 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 den Benutzer sichtbaren Kommentar hinzu. Dies ist ein ausdrücklich im Aktivitätsverlauf des Incidents protokolliertes Ereignis.
Warum das wichtig ist Erfasst die Kommunikation und Untersuchungsarbeit des Supportteams. Die Analyse von Häufigkeit und Zeitpunkt dieser Kommentare liefert Erkenntnisse über den Untersuchungsprozess. Bezugsquelle Erfasst aus der Tabelle „sys_journal_field“, in der Einträge für die Felder „work_notes“ und „comments“ der Tabelle „incident“ protokolliert werden. Erfassen Verwenden Sie den Erstellungszeitpunkt von Journaleinträgen, bei denen das Element „work_notes“ oder „comments“ lautet. Ereignistyp explicit
	Warten auf Benutzerbestätigung	Der Incident befindet sich in einem ausstehenden Status und wartet darauf, dass der Benutzer den Erfolg der vorgeschlagenen Lösung bestätigt. Dies wird in der Regel aus einem 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 langsam antworten. Die Messung der in dieser Aktivität verbrachten Zeit hilft dabei, Kommunikationslücken und Möglichkeiten zur automatisierten Schließung zu erkennen. Bezugsquelle Abgeleitet aus der Tabelle „sys_audit“, indem eine Änderung in einen bestimmten ausstehenden Status nach der Lösung identifiziert wird. Der Statusname kann kundenspezifisch sein, etwa „Awaiting Caller“. Erfassen Ermitteln Sie den Timestamp, an dem sich „state“ in einen Wert ändert, der auf das Warten auf Benutzereingaben hinweist. Ereignistyp inferred

Extraktionsanleitungen

So erhalten Sie Ihre Daten aus ServiceNow Problem Management

Schritte

ServiceNow-Zugriff einrichten: Beschaffen Sie die Zugangsdaten für ein Servicekonto in ServiceNow. 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: Stellen Sie sicher, dass Node.js auf dem Rechner installiert ist, auf dem das Extraktionsskript ausgeführt wird. Installieren Sie die Bibliothek axios für HTTP-Anfragen mit dem Befehl npm install axios in Ihrem Terminal.
Extraktionsskript vorbereiten: Kopieren Sie den bereitgestellten JavaScript-Code in eine Datei, zum Beispiel extract_incidents.js. Ersetzen Sie am Anfang des Skripts die Platzhalter für die URL Ihrer ServiceNow-Instanz, den Benutzernamen und das Passwort.
Extraktionsparameter definieren: Passen Sie die Variablen startDate und endDate im Skript an, um den Zeitraum für die zu extrahierenden Incidents festzulegen. Für erste Ausführungen empfiehlt sich ein kurzer Zeitraum, etwa eine Woche, um die Ergebnisse zu prüfen.
Skript ausführen: Starten Sie das Skript in Ihrem Terminal mit dem Befehl node extract_incidents.js. Das Skript ruft anschließend Incident-Daten und die zugehörigen Audit-Logs über die ServiceNow API ab.
Fortschritt überwachen: Das Skript protokolliert den Fortschritt in der Konsole und zeigt an, wie viele Incidents verarbeitet wurden. Bei großen Datenmengen kann dieser Vorgang aufgrund der erforderlichen API-Aufrufe viel Zeit in Anspruch nehmen.
API-Antworten verarbeiten: Das Skript durchläuft programmgesteuert jeden Incident. Für jeden Incident fragt es die Tabelle sys_audit ab, um die vollständige Änderungshistorie abzurufen. Anschließend identifiziert und versieht es die 13 erforderlichen Aktivitäten mit Timestamps.
Abgeleitete Aktivitäten verarbeiten: Das Skript enthält eine Logik, um Aktivitäten aus Feldänderungen abzuleiten. Beispielsweise wird „Incident Escalated“ erstellt, wenn der neue Wert des Feldes priority niedriger ist als der alte Wert, was eine höhere Priorität bedeutet. „Work Started“ wird durch die erste Statusänderung auf „In Progress“ erkannt.
Event Log strukturieren: Sobald Aktivitäten identifiziert sind, werden sie als Event-Log-Datensätze formatiert. Jeder Datensatz enthält die erforderlichen Spalten IncidentId, ActivityName, EventTime und weitere Spalten.
Ausgabe speichern: Nach Abschluss des Skripts wird das generierte Event Log als JSON-Datei mit dem Namen servicenow_incident_event_log.json im selben Verzeichnis gespeichert. Diese Datei enthält ein Array aller extrahierten Ereignisse.
In CSV umwandeln: Für den Upload in ProcessMind müssen Sie die finale JSON-Ausgabe möglicherweise in eine CSV-Datei umwandeln. Verwenden Sie dafür ein gängiges Datentool oder ein einfaches Skript. Wandeln Sie das JSON-Array in ein tabellarisches CSV-Format um und stellen Sie sicher, dass die Spaltenüberschriften den erforderlichen Attributen entsprechen.

Konfiguration

API-Endpunkt: Das Skript verwendet zwei zentrale ServiceNow-Table-API-Endpunkte:
- 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. Stellen Sie sicher, dass die Zugangsdaten des Servicekontos korrekt und das Konto aktiv ist.
Filterung nach Datumsbereich: Die Abfrage wird nach dem Erstellungsdatum des Incidents (sys_created_on) gefiltert. Dies wird über die Variablen startDate und endDate im Skript konfiguriert. Für eine aussagekräftige Analyse empfiehlt sich die Extraktion von Daten aus einem Zeitraum von 3 bis 6 Monaten. Beginnen Sie zum Testen jedoch mit einem kürzeren Zeitraum.
Wichtige Abfrageparameter:
- sysparm_query: Dient zum Filtern von Datensätzen. Das Skript erstellt eine codierte Abfragezeichenfolge, um Incidents nach Erstellungsdatum zu filtern.
- sysparm_fields: Legt fest, welche Spalten abgerufen werden. Dadurch wird die Größe der API-Nutzlast reduziert und die Leistung verbessert.
- sysparm_limit: Steuert die Seitennavigation, indem die Anzahl der Datensätze pro Anfrage festgelegt wird. Das Skript verwendet ein Limit von 1000, was gängiger Praxis entspricht.
- sysparm_offset: Wird zusammen mit sysparm_limit verwendet, um nachfolgende Datenseiten abzurufen.
Leistungsaspekte: Die Abfrage der Tabelle sys_audit für jeden Incident ist ressourcenintensiv. Bei sehr großen ServiceNow-Instanzen sollten Sie die Extraktion in einem Zeitraum mit geringer Auslastung 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 ist eine Node.js-Umgebung erforderlich. Der Benutzer oder das Servicekonto, das die Extraktion ausführt, muss über die erforderlichen Leseberechtigungen (ACLs) für die Tabellen incident und sys_audit verfügen.

a 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: Stellen Sie sicher, dass Python 3.6 oder höher auf Ihrem System installiert ist. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install requests pandas.
ServiceNow einrichten: Erstellen Sie in ServiceNow ein eigenes Servicekonto für diese Extraktion. 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 erhält.
Skript konfigurieren: Öffnen Sie das bereitgestellte Python-Skript. Suchen Sie den Konfigurationsabschnitt am Anfang und ersetzen Sie die Platzhalter für SNOW_INSTANCE, SNOW_USER und SNOW_PASSWORD durch die URL Ihrer ServiceNow-Instanz und die Zugangsdaten des Servicekontos. Passen Sie START_DATE und END_DATE an, um den gewünschten Extraktionszeitraum festzulegen.
Skript ausführen: Starten Sie das Skript über die Befehlszeile mit python your_script_name.py. Das Skript authentifiziert sich anschließend bei ServiceNow und führt API-Aufrufe aus.
Daten abrufen: Zunächst ruft das Skript aus der Tabelle incident eine Liste aller Incidents ab, die im angegebenen Zeitraum erstellt wurden. Anschließend verwendet es diese Incident-IDs, um die zugehörige Audit-Historie aus sys_audit und alle Kommentare aus sys_journal_field abzurufen.
Event Log erzeugen: Das Skript verarbeitet die Rohdaten im Arbeitsspeicher. Es durchläuft die vordefinierten Aktivitäten und erzeugt für jede Aktivität einen eigenen Satz von Zeilen. Beispielsweise erkennt es das Ereignis „Incident Created“ anhand des Feldes sys_created_on und das Ereignis „Incident Closed“ anhand des Feldes closed_at. Für weitere Ereignisse analysiert es das Audit-Log, um Statusübergänge, Feldänderungen und Eskalationen zu bestimmen.
Attribute zuordnen: Für jede erzeugte Ereigniszeile reichert das Skript die Daten durch eine Abfrage mit Kontextattributen aus dem Hauptdatensatz des Incidents an, 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 vollständigen Event-Log-DataFrame zusammengeführt.
Finale Transformation: Der zusammengeführte DataFrame wird nach IncidentId und EventTime sortiert, damit die Ereignisse jedes Cases chronologisch korrekt angeordnet sind. Die Spalten SourceSystem und LastDataUpdate werden mit statischen Werten ergänzt.
In CSV exportieren: Das finale Event Log wird im selben Verzeichnis, in dem das Skript ausgeführt wurde, als servicenow_incident_event_log.csv gespeichert. Diese Datei kann in 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. Für Produktivumgebungen sollten Sie statt der Basic Authentication OAuth oder eine tokenbasierte Authentifizierung in Betracht ziehen.
Zeitraum (START_DATE, END_DATE): Legt das Extraktionsfenster anhand des Erstellungsdatums der Incidents fest. Für eine erste Analyse empfiehlt sich ein Zeitraum von drei bis sechs Monaten, um Datenvolumen und Erkenntnisgewinn auszubalancieren. Größere Zeiträume verlängern die Extraktion erheblich.
API-Abfrageparameter (sysparm_query): Das Skript verwendet sysparm_query, um Incidents nach ihrem Erstellungsdatum (sys_created_on) zu filtern. Sie können hier weitere Bedingungen ergänzen, etwa active=false^company=[Your Company Sys ID], um nur geschlossene Incidents eines bestimmten Unternehmens zu extrahieren.
API-Ratenbegrenzung: Beachten Sie die Ratenbegrenzungen der ServiceNow API. Das Skript unterstützt die Seitennavigation, enthält jedoch keine ausdrückliche Behandlung von Ratenbegrenzungen. Bei sehr großen Instanzen müssen Sie möglicherweise zwischen den Anfragen time.sleep()-Aufrufe einfügen, um eine Überschreitung der Limits zu vermeiden.
Erforderliche Berechtigungen: Der angegebene Benutzer benötigt Lesezugriff (ACLs) auf die Tabellen incident, sys_audit und sys_journal_field. Die Rolle itil gewährt diesen Zugriff üblicherweise. Ihre Instanz kann jedoch eigene Zugriffskontrollen verwenden.

a 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}")

Bereit für den Start?

Mit diesem Template verfügen Sie über alles, was Sie für den Einstieg in Ihr Process-Mining-Projekt im Incident Management benötigen. Beginnen Sie noch heute damit, die Lösung Ihrer Incidents zu verbessern.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

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

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

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Beginnen Sie innerhalb weniger Minuten mit der Optimierung.

Ihr Daten-Template für Incident Management

Ihr Daten-Template für Incident Management

Attribute des Incident Managements

Aktivitäten des Incident Managements

Extraktionsanleitungen

Direkte Extraktion über die ServiceNow Table REST API

Schritte

Konfiguration

a Beispielabfrage javascript

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

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

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

Ihr Daten-Template für Incident Management

Ihr Daten-Template für Incident Management

Attribute des Incident Managements

Aktivitäten des Incident Managements

Extraktionsanleitungen

Direkte Extraktion über die ServiceNow Table REST API

Schritte

Konfiguration

a Beispielabfrage javascript

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

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

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

Ihre Privatsphäre ist uns wichtig